Changing OpenGL selection to OpenGL Occlusion Queries does fix that problem. Thank you.

Can you test if changeing the OpenGL selection method to OpenGL Occlusion Queries fixes the problem?
https://docs.blender.org/manual/en/dev/preferences/system.html#opengl

Not sure… looks like the 'sharp' status of corner vertices somehow survive the subsurf modifier (while sharp edges being totally lost)… maybe @Sergey Sharybin (sergey) will want to have a look?

In D2724#64721, @Bastien Montagne (mont29) wrote:

Hmmmm… this is way too late to add anything like that in master for 2.79 now… :/

Note that this affect other modifiers too (shrinkwrap and simple deform at least).

This is actually a bug in our defvert_array_find_weight_safe(), which was assuming that having a valid vgroup index but NULL vgroup data pointer was same as not having a valid vgroup index, and was returning '1.0' in both cases.

Thanks for the report, but I don’t actually see a bug here - maybe some inconsistency between two rather different tools, but that’s all. Harmonizing this would be a TODO (and it would be slightly hairy too, to avoid old files suddenly starting to behave differently).

Hmmmm… this is way too late to add anything like that in master for 2.79 now… :/

It's been over month with no activity, no idea who normally does modifier code review, @Bastien Montagne (mont29) can you take a peek here?

@Sergey Sharybin (sergey) T51975 shows variants of bug that pops up when this carve object is in scene. Sometime, some part of the mesh (the box containing the vegetables) was missing, sometime the textures were pink, sometime the shader got white. Most of the time hitting F12 would segfault. Sometime it succeeded, but the segfault appeared just after render finished (couldn't even save the file).
@Fable Fox (fablefox) debug builds indeed are working. Of course, replacing carve with bmesh also makes the file stable again.
To more easily the bugs and crash, you have to:

• open with VS2013 buildbots
• append everything in the file attached into a very complex scene (there must be something to corrupt in memory, so many shaders, lot of meshes, etc. make crash more often)
• duplicate in place ( location may be important to trigger the bug) what you appended to make the probability of crash higher (the overflows are more likely to produce a crash if many part of memory are overwritten/corrupted, so duplicate it a hundred time if it doesn't crash)
• then try to render, undo, etc...

This part of the scene was modeledin november last year and wasn't touched since then. The bugs and crash happened more often as scene complexity increased.

@john peterson (bliblubli), please define what exact instability is and how to reproduce it.

I can open it with VS 2015 build (blender-2.78-edc6bec-win64-vc14.zip). Using parameter -d. I changed the modifier type to Carve and save it.

Note that the crash on file open is only on VS2015 release, but instability is in VS2013 = official release too. It just happens randomly during a material change or an undo or a final render start or whatever part of memory was corrupted.

I can confirm the issue, but only happens in release build done with MSVC 2015. It doesn't even happen in RelWithDebInfo configuration, which makes it really hard to troubleshoot.

More than a week passed without a reply.
Due to the tracker policy, archiving until the required additional information / data is provided.

I'm having many "good-in, garbage out" scenarios with carve as well where two manifold input meshes will sometimes return non manifold results. Is Carve even actively maintained? If so, where? I saw something on code.google.com where the last issue was posted 2 years ago and last release 6 years ago and a github repository that was also inactive for 7 years. For what I'm doing right now, if boolean operations were more robust I could eliminate commercial software from my workflow.

Please follow our submission template and guidelines and make a complete, valid bug report, with required info, precise description of the issue, precise steps to reproduce it, small and simple .blend and/or other files to do so if needed, etc.
Videos and/or links to external sites etc. are not acceptable as bug report (they can be provided as additional information only).

looks good :)

I can confirm the bug

I got the problem. I am currently looking for the solution in code. For time being, you can manually select the extra vertices and press Ctrl + X to merge it in Edge. for first scenario. For second case, It will look into details.

Mmmh… in fact there is no bug here, even though the result may not be what one would expect off hands.

Edge group for bevel could be better than vertex group

Someone else requested something similar to what you suggest -- just that when some vertices get blocked, they stay there and the unblocked ones continue to move. Maybe this should be the default, but I'd like to get some kind of consensus from artists before changing. As you say, it could be an option, but there is a lot of pushback on Blender devs from Ton not to add too many options to tools, but rather make them smart enough to "do the right thing" without options.

I think what I'd like to see is a threshold that prevents close vertices from overlapping without blocking the movement of vertices that are far from each other. I suppose something like a weighting that diminishes the bevel effect for close vertices.
Something like in the following which shows how Edge-Slide has less impact on close vertices but a large influence on vertices with larger distances. I think this would have to be an option though since it would best suit organic or choppy shapes like rocks. It would likely be inappropriate for machined surfaces.

For a much simpler testcase, apparently demonstrating a similar problem -- non-solid objects resulting from boolean intersect with BMesh -- see T51236 . Again, "Carve" produces the correct result, "BMesh" doesn't.

The problem is that the clamping is very naive right now: just clamps to the min of the half-length of all the edges involved in a vertex bevel. In this case, that means it clamps to the half length of the vertical edge, which doesn't even have advancing vertices on it, and it is a lot shorter than the edge that the vertices move along. It is a TODO to do much smarter clamping, but I'll spend some time now to see if cases like this, at least, can be improved.

This is different from T50994, as it is only about one edge (as reporter notes). It may overlap with one of the problems reported in T50819, premature clamping. I will look into this one now.

Another requested bevel clamping change. See T50994. Requester would like clamp to apply to edges individually rather than globally. Could be consider as breaking backward compatibility for 2.8. Or an option (but we dislike adding too many options).

But shouldn't a mesh generated by a fluid sim be closed and non-self intersecting?