Crash with Viewport measurements turned on #77195

New Issue

Daniel Santana · 2020-05-30T13:23:00+02:00

Daniel Santana commented

2020-05-30 13:23:00 +02:00

System Information
Operating system: Windows-10-10.0.19041-SP0 64 Bits
Graphics card: GeForce RTX 2080 SUPER/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 446.14

Blender Version
Broken: version: 2.90.0 Alpha, branch: master, commit date: 2020-05-29 18:08, hash: 2ee94c954d
Worked: deaff945d0b965d1^ (caused by deaff945d0)

Short description of error
Blender crashes when using build new faces from edges.
Stack trace:

blender.exe!DRW_text_edit_mesh_measure_stats(ARegion * region, View3D * v3d, Object * ob, const UnitSettings * unit) Line 415 (d:\dev\blender\blender\source\blender\draw\intern\draw_manager_text.c:415)
blender.exe!OVERLAY_edit_mesh_cache_populate(OVERLAY_Data * vedata, Object * ob) Line 321 (d:\dev\blender\blender\source\blender\draw\engines\overlay\overlay_edit_mesh.c:321)
blender.exe!OVERLAY_cache_populate(void * vedata, Object * ob) Line 305 (d:\dev\blender\blender\source\blender\draw\engines\overlay\overlay_engine.c:305)
blender.exe!drw_engines_cache_populate(Object * ob) Line 994 (d:\dev\blender\blender\source\blender\draw\intern\draw_manager.c:994)
blender.exe!DRW_draw_render_loop_ex(Depsgraph * depsgraph, RenderEngineType * engine_type, ARegion * region, View3D * v3d, GPUViewport * viewport, const bContext * evil_C) Line 1465 (d:\dev\blender\blender\source\blender\draw\intern\draw_manager.c:1465)
blender.exe!DRW_draw_view(const bContext * C) Line 1393 (d:\dev\blender\blender\source\blender\draw\intern\draw_manager.c:1393)
blender.exe!view3d_main_region_draw(const bContext * C, ARegion * region) Line 1634 (d:\dev\blender\blender\source\blender\editors\space_view3d\view3d_draw.c:1634)
blender.exe!ED_region_do_draw(bContext * C, ARegion * region) Line 543 (d:\dev\blender\blender\source\blender\editors\screen\area.c:543)
blender.exe!wm_draw_window_offscreen(bContext * C, wmWindow * win, bool stereo) Line 689 (d:\dev\blender\blender\source\blender\windowmanager\intern\wm_draw.c:689)
blender.exe!wm_draw_window(bContext * C, wmWindow * win) Line 812 (d:\dev\blender\blender\source\blender\windowmanager\intern\wm_draw.c:812)
blender.exe!wm_draw_update(bContext * C) Line 1013 (d:\dev\blender\blender\source\blender\windowmanager\intern\wm_draw.c:1013)
blender.exe!WM_main(bContext * C) Line 482 (d:\dev\blender\blender\source\blender\windowmanager\intern\wm.c:482)
blender.exe!main(int argc, const unsigned char * * UNUSED_argv_c) Line 530 (d:\dev\blender\blender\source\creator\creator.c:530)
[Inline Frame] blender.exe!invoke_main() Line 78 (d:\A01\_work\6\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:78)
blender.exe!__scrt_common_main_seh() Line 288 (d:\A01\_work\6\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:288)
kernel32.dll!00007ff942836fd4() (Unknown Source:0)
ntdll.dll!00007ff94393cec1() (Unknown Source:0)

Exact steps for others to reproduce the error

Open Blender
Select the cube and enter edit mode
Delete the cube top face.
Turn on Edge Lenght and Face Area
Select the cube top loop to close
Press 'F'
Crash

**System Information** Operating system: Windows-10-10.0.19041-SP0 64 Bits Graphics card: GeForce RTX 2080 SUPER/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 446.14 **Blender Version** Broken: version: 2.90.0 Alpha, branch: master, commit date: 2020-05-29 18:08, hash: `2ee94c954d` Worked: deaff945d0b965d1^ (caused by deaff945d0) **Short description of error** Blender crashes when using build new faces from edges. Stack trace: ``` blender.exe!DRW_text_edit_mesh_measure_stats(ARegion * region, View3D * v3d, Object * ob, const UnitSettings * unit) Line 415 (d:\dev\blender\blender\source\blender\draw\intern\draw_manager_text.c:415) blender.exe!OVERLAY_edit_mesh_cache_populate(OVERLAY_Data * vedata, Object * ob) Line 321 (d:\dev\blender\blender\source\blender\draw\engines\overlay\overlay_edit_mesh.c:321) blender.exe!OVERLAY_cache_populate(void * vedata, Object * ob) Line 305 (d:\dev\blender\blender\source\blender\draw\engines\overlay\overlay_engine.c:305) blender.exe!drw_engines_cache_populate(Object * ob) Line 994 (d:\dev\blender\blender\source\blender\draw\intern\draw_manager.c:994) blender.exe!DRW_draw_render_loop_ex(Depsgraph * depsgraph, RenderEngineType * engine_type, ARegion * region, View3D * v3d, GPUViewport * viewport, const bContext * evil_C) Line 1465 (d:\dev\blender\blender\source\blender\draw\intern\draw_manager.c:1465) blender.exe!DRW_draw_view(const bContext * C) Line 1393 (d:\dev\blender\blender\source\blender\draw\intern\draw_manager.c:1393) blender.exe!view3d_main_region_draw(const bContext * C, ARegion * region) Line 1634 (d:\dev\blender\blender\source\blender\editors\space_view3d\view3d_draw.c:1634) blender.exe!ED_region_do_draw(bContext * C, ARegion * region) Line 543 (d:\dev\blender\blender\source\blender\editors\screen\area.c:543) blender.exe!wm_draw_window_offscreen(bContext * C, wmWindow * win, bool stereo) Line 689 (d:\dev\blender\blender\source\blender\windowmanager\intern\wm_draw.c:689) blender.exe!wm_draw_window(bContext * C, wmWindow * win) Line 812 (d:\dev\blender\blender\source\blender\windowmanager\intern\wm_draw.c:812) blender.exe!wm_draw_update(bContext * C) Line 1013 (d:\dev\blender\blender\source\blender\windowmanager\intern\wm_draw.c:1013) blender.exe!WM_main(bContext * C) Line 482 (d:\dev\blender\blender\source\blender\windowmanager\intern\wm.c:482) blender.exe!main(int argc, const unsigned char * * UNUSED_argv_c) Line 530 (d:\dev\blender\blender\source\creator\creator.c:530) [Inline Frame] blender.exe!invoke_main() Line 78 (d:\A01\_work\6\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:78) blender.exe!__scrt_common_main_seh() Line 288 (d:\A01\_work\6\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:288) kernel32.dll!00007ff942836fd4() (Unknown Source:0) ntdll.dll!00007ff94393cec1() (Unknown Source:0) ``` **Exact steps for others to reproduce the error** - Open Blender - Select the cube and enter edit mode - Delete the cube top face. - Turn on Edge Lenght and Face Area - Select the cube top loop to close - Press 'F' - Crash

Daniel Santana commented

2020-05-30 13:23:00 +02:00

Added subscriber: @dgsantana

Robert Guetzkow changed title from ~~Crash with Viewport measurements turn on~~ to Crash with Viewport measurements turned on

2020-05-30 14:50:03 +02:00

Robert Guetzkow commented

2020-05-30 14:50:03 +02:00

Changed status from 'Needs Triage' to: 'Confirmed'

Robert Guetzkow commented

2020-05-30 14:56:25 +02:00

Added subscribers: @fclem, @Jeroen-Bakker, @rjg

Robert Guetzkow commented

2020-05-30 14:56:25 +02:00

@fclem @Jeroen-Bakker This is likely related to the recent work on the overlay and viewport drawing.

Clément Foucault commented

2020-05-30 17:11:07 +02:00

Is the crash happening only in master or also in 2.83?

Robert Guetzkow commented

2020-05-30 17:34:18 +02:00

@fclem Only in master branch.

Garry R. Osgood commented

2020-05-31 16:02:20 +02:00

Added subscribers: @ideasman42, @grosgood

Garry R. Osgood commented

2020-05-31 16:02:20 +02:00

@rjg:

This is likely related to the recent work on the overlay and viewport drawing.

This particular run of code near the crash point, line 400 and following in ##draw_manager_text.c##, comes into being with 9516921c05 by @fclem. @ideasman42 introduced the ##use_coords## logic in 6526c3ced8, but I do not think that has bearing on the matter.

You know you are in the weeds when ##poly_to_tri_count()## returns negative counts. When using a debug image, an assert in [poly_to_tri_count()]] catches impending silliness. The particular silliness I'm seeing are corner counts of -1. Polygons that I'm familiar with generally have a positive number of corners. That numeric, I believe, is straight from the mesh face (##f##, below) being queried in the loop beginning at [ https:*developer.blender.org/diffusion/B/browse/master/source/blender/draw/intern/draw_manager_text.c$400|draw_manager_text.c:400 .

(gdb) whatis *f
type = BMFace

(gdb) p *f
$21 = {
  head = {
    data = 0x0,
    index = 5,
    htype = 8 '\b',
    hflag = 1 '\001',
    api_flag = 0 '\000'
  },
  l_first = 0x7fff6a929840,
  len = 4,                    <-- results in numtri == 2 @ line 403 
  no = {0, 0, -1},
  mat_nr = 0
}
(gdb) whatis f->l_first[0]
type = BMLoop

(gdb) p *f->l_first
$22 = {
  head = {
    data = 0x7fff6e45d5c0,
    index = -1,               <-- BM_elem_index_get() fetches this. It is passed
    htype = 4 '\004',             to poly_to_tri_count() as the corner_count.   
    hflag = 0 '\000',             that function either fails on an assert or 
    api_flag = 0 '\000'           returns a negative count, depending on how
  },                              Blender is built. The latter induces
  v = 0x7fff8e3b02f8,             a memory read outside the useful region of 
  e = 0x7fff83e003b0,             em->looptris[...] 
  f = 0x7fff6e452600,
  radial_next = 0x7fff6a929840,
  radial_prev = 0x7fff6a929840,
  next = 0x7fff6a929888,
  prev = 0x7fff6a929918
}

The question on the table is how the ##index## field in the ##BMLoop## buffer (##BMFace->l_first##) is being set up. Stay tuned...

@rjg: > This is likely related to the recent work on the overlay and viewport drawing. This particular [run of code ](https://developer.blender.org/diffusion/B/browse/master/source/blender/draw/intern/draw_manager_text.c$400) near the crash point, line 400 and following in ##draw_manager_text.c##, comes into being with 9516921c05 by @fclem. @ideasman42 introduced the ##use_coords## logic in 6526c3ced8, but I do not think that has bearing on the matter. You know you are in the weeds when ##poly_to_tri_count()## returns negative counts. When using a debug image, an assert in [poly_to_tri_count()]] catches impending silliness. The particular silliness I'm seeing are corner counts of -1. Polygons that I'm familiar with generally have a positive number of corners. That numeric, I believe, is straight from the mesh face (##f##, below) being queried in the loop beginning at [[ https:*developer.blender.org/diffusion/B/browse/master/source/blender/draw/intern/draw_manager_text.c$400|draw_manager_text.c:400 ](https:*developer.blender.org/diffusion/B/browse/master/source/blender/blenlib/intern/math_geom_inline.c$253). ``` (gdb) whatis *f type = BMFace (gdb) p *f $21 = { head = { data = 0x0, index = 5, htype = 8 '\b', hflag = 1 '\001', api_flag = 0 '\000' }, l_first = 0x7fff6a929840, len = 4, <-- results in numtri == 2 @ line 403 no = {0, 0, -1}, mat_nr = 0 } (gdb) whatis f->l_first[0] type = BMLoop (gdb) p *f->l_first $22 = { head = { data = 0x7fff6e45d5c0, index = -1, <-- BM_elem_index_get() fetches this. It is passed htype = 4 '\004', to poly_to_tri_count() as the corner_count. hflag = 0 '\000', that function either fails on an assert or api_flag = 0 '\000' returns a negative count, depending on how }, Blender is built. The latter induces v = 0x7fff8e3b02f8, a memory read outside the useful region of e = 0x7fff83e003b0, em->looptris[...] f = 0x7fff6e452600, radial_next = 0x7fff6a929840, radial_prev = 0x7fff6a929840, next = 0x7fff6a929888, prev = 0x7fff6a929918 } ``` The question on the table is how the ##index## field in the ##BMLoop## buffer (##BMFace->l_first##) is being set up. Stay tuned...

Garry R. Osgood commented

2020-06-01 01:25:30 +02:00

T77195_gitbisect.txt
A ##git bisect## exercise leads me to deaff945d0 by @ideasman42 as the commit along the master branch where this bug is first manifest. Confirm that ec26260132, blender-v2.83-release does not exhibit this bug. I have not established any causality chains between the files changed by the good Mr. Barton's commit and the bug. That his commit involves edit-mesh -> mesh is suggestive - and that's all for now. See the attached for bisect details.

[T77195_gitbisect.txt](https://archive.blender.org/developer/F8568675/T77195_gitbisect.txt) A ##git bisect## exercise leads me to deaff945d0 by @ideasman42 as the commit along the master branch where this bug is first manifest. Confirm that ec26260132, **blender-v2.83-release** does not exhibit this bug. I have not established any causality chains between the files changed by the good Mr. Barton's commit and the bug. That his commit involves edit-mesh -> mesh is suggestive - and that's all for now. See the attached for bisect details.

Garry R. Osgood commented

2020-06-01 16:42:18 +02:00

My apologies. Omitted methodology. Designation of 'good' and 'bad' for purposes of ##git bisect## was to open the attached blend file: the default cube with its top face, Fn = {0.0, 0.0, 1.0}, removed and the four edges to form a new top face already selected.

Hit 'f' to invoke ##MESH_OT_f2## and fill the top face in.
- If a face appeared, the binary at that commit was deemed 'good'
- If the assert in ##poly_to_tri_count()## fired off instead, aborting the process, the binary at that commit was deemed 'bad'
For each of the various commit points, built a full binary in an initially empty build directory. I built debug binaries so that the assert points were present.
T77195_bug.blend

My apologies. Omitted methodology. Designation of 'good' and 'bad' for purposes of ##git bisect## was to open the attached blend file: the default cube with its top face, Fn = {0.0, 0.0, 1.0}, removed and the four edges to form a new top face already selected. - Hit 'f' to invoke ##MESH_OT_f2## and fill the top face in. - If a face appeared, the binary at that commit was deemed 'good' - If the assert in ##poly_to_tri_count()## fired off instead, aborting the process, the binary at that commit was deemed 'bad' - For each of the various commit points, built a full binary in an initially empty build directory. I built debug binaries so that the assert points were present. [T77195_bug.blend](https://archive.blender.org/developer/F8569989/T77195_bug.blend)

Garry R. Osgood commented

2020-06-02 14:53:37 +02:00

Few notes:

It is specifically the Face Area checkbox in the Viewport Overlays -> Measurement panel that triggers this bug. The setting of Edge Length is irrelevant. See line 392 of draw_manager_text.c . ##(v3d->overlay.edit_flag & V3D_OVERLAY_EDIT_FACE_AREA) == TRUE ## reflects the setting of this checkbox. That and ##BMFace f->hflag## being odd - indicating the face is selected - sets the condition to render an area annotation on the face; that is when the suspect code runs.
Should I deselect Face Area and then create a face, the operation succeeds. No surprise there: I am not asking for an area annotation so the suspect code does not run. Now, if I select Face Area, leaving the new face selected, the suspect code runs and the area annotation properly appears on the face without triggering the bug. That is because the ##BMLoop## items in the ## BMFace f->l_first## list all have their ##index## members set to positive numbers and ##BM_elem_index_get()## does not feed ##poly_to_tri_count()## negative corner counts. See my notes in the post above.

This leads me to suspect that, "somehow", the new approach of deferring ##edit_mesh -> mesh## is leaving these ##index## members uninitialized - that they are eventually initialized, downstream, so that selecting the face later and asking for area annotation creates no difficulty. I put "somehow" in quotes because all of this is conjecture on my part, not an established causality chain. Stay tuned...

Few notes: - It is specifically the **Face Area** checkbox in the **Viewport Overlays -> Measurement** panel that triggers this bug. The setting of **Edge Length** is irrelevant. See [line 392 of draw_manager_text.c ](https://developer.blender.org/diffusion/B/browse/master/source/blender/draw/intern/draw_manager_text.c$392). ##(v3d->overlay.edit_flag & V3D_OVERLAY_EDIT_FACE_AREA) == TRUE ## reflects the setting of this checkbox. That and ##BMFace f->hflag## being odd - indicating the face is selected - sets the condition to render an area annotation on the face; that is when the suspect code runs. - Should I deselect **Face Area** and then create a face, the operation succeeds. No surprise there: I am not asking for an area annotation so the suspect code does not run. Now, if I select **Face Area**, leaving the new face selected, the suspect code runs and the area annotation properly appears on the face without triggering the bug. That is because the ##BMLoop## items in the ## BMFace f->l_first## list all have their ##index## members set to positive numbers and ##BM_elem_index_get()## does not feed ##poly_to_tri_count()## negative corner counts. See my notes in the post above. This leads me to suspect that, "somehow", the new approach of deferring ##edit_mesh -> mesh## is leaving these ##index## members uninitialized - that they are eventually initialized, downstream, so that selecting the face later and asking for area annotation creates no difficulty. I put "somehow" in quotes because all of this is conjecture on my part, not an established causality chain. Stay tuned...

Garry R. Osgood commented

2020-06-03 13:32:27 +02:00

Added subscriber: @lichtwerk

Garry R. Osgood commented

2020-06-03 13:32:27 +02:00

@lichtwerk
Thank you for the update of the task description. Slight correction: commit "deaff94...." (campbell) is the first version that goes into the `loo, not the last version that worked. The last version that worked was (one of ) your May 25 commits: df8cbdc696. See the git bisect log I attached: T77195_gitbisect.txt on my 01-June post. I'd fix it myself but I don't have the right Magickal Powers, it seems.

@lichtwerk Thank you for the update of the task description. Slight correction: commit "deaff94...." (campbell) is the first version that goes into the `loo, not the last version that worked. The last version that worked was (one of ) your May 25 commits: df8cbdc696. See the git bisect log I attached: **T77195_gitbisect.txt** on my 01-June post. I'd fix it myself but I don't have the right Magickal Powers, it seems.

Philipp Oeser commented

2020-06-03 14:04:51 +02:00

@grosgood : in git terms, deaff945d0b965d1^ is the same as df8cbdc69645589b (^ means the last commit before)

@grosgood : in git terms, `deaff945d0b965d1^` is the same as `df8cbdc69645589b` (`^` means the last commit before)

Garry R. Osgood commented

2020-06-03 14:18:13 +02:00

Ah! Thank you! I stand corrected.

ronan ducluzeau commented

2020-06-05 10:09:25 +02:00

Added subscriber: @zeauro

ronan ducluzeau commented

2020-06-05 10:09:25 +02:00

Same crash on Ubuntu 18.04.
blender.crash.txt

Same crash on Ubuntu 18.04. [blender.crash.txt](https://archive.blender.org/developer/F8578633/blender.crash.txt)

Garry R. Osgood commented

2020-06-07 17:44:19 +02:00

TL;DR
Longish comment. If you must know, It appears to me that a reordering of processing stemming from the commit has put the reindexing of certain BM elements (##BMLoops##) rather late in the pipeline -- too late for the liking of the overlay drawing engine, which is tripping over un-indexed ##BMLoop## elements: the gist of this bug.

A reordering of processing seems to be in order, but hopefully not at the expense of optimization. I'm not decided yet on how to unwrap that wicket. Opinions, observations, tirades welcome...

Immediate cause

See #77195#941825 for background. See also Boundary Mesh Structures.

BM elements ##BMFace##, ##BMEdge##, ##BMVert## and ##BMLoop## all have identical ##BMHeader## structures. Of interest here is ##BMHeader.index## See struct BMHeader .

After pressing {key F}, BM_face_create() gets the nod for generating a new ##BMFace##. This initiates a processing pipeline where a lot of stages have to complete before the overlay drawing engine - where the bug appears - gets to render things, including face-area annotations.

One of those stages entail re-indexing BM elements. Depsgraph evaluation orchestrates that in the context of updating mesh objects. Pseudo-code-ishly, ##BMLoop## re-indexing looks roughly like this:

lang=c, name=Initializing_BMLoops
BMFace *my_current_face;
BMLoop *l_iter, *l_first;
int    j = 0;

BM_ITER_MESH_INDEX (my_current_face, ..., BM_FACES_OF_MESH, ...) { 
   l_iter = l_first = BM_FACE_FIRST_LOOP(my_current_face);
   do {
         /* some processing */ 

         BM_elem_index_set(l_iter, j);
         j++;

         /* some other processing */
      } while ((l_iter = l_iter->next) != l_first);
}

Macros BM_elem_index_get(elem) and BM_elem_index_set(elem, index) furnish low-level getter/setter interfaces to ##BMHeader## indices. One should not assign to or read from the indices directly.

The assignment of unique non-negative indices to ##BMLoops## and other BM elements occur periodically to ensure uniqueness. Apt choices of BM iterator macros determine what BM element type gets re-indexed. When valid, indices are unique to the mesh and BM element type. The index doesn't "mean" anything beyond the rule that a negative index means "not indexed."

Regarding this, the tripwire for the bug exhibits a certain touching innocence:

lang=c, name=draw_manager_text.c:408
   BMLoop *(*l)[3] = &em->looptris[poly_to_tri_count(i, BM_elem_index_get(f->l_first))];
   for (int j = 0; j < numtri; j++) {
...

Here, ##BM_elem_index_get()## retrieves the ##BMLoop## index; the index is passed, unchecked, to [poly_to_tri_count() ]], fully trusting that ##f->l_first## points to a ##BMLoop## element with a non-negative element index. This innocence is natural across tightly coupled interfaces. Innocence is not the issue. The issue is that at this late processing stage - we're now in the midsts of rendering with the overlay engine - BM elements are still not indexed. That is the immediate cause of the bug: ##poly_to_tri_count()## assumes that the ##BMLoop## index is non-negative, but it is - so the function returns a negative value which causes an out-of-bounds access into the tesselation buffer. That, in [https:*en.wikipedia.org/wiki/Damon_Runyon|Runyonesque terms is the ballgame.

Causality

Mesh management, of which re-indexing BM elements is just one facet, is processing intensive. The commit which triggers this bug strives to minimize processing by taking a 'lazy' or just-in-time approach to (re-)generating mesh representations. One might think that deferring BM element re-indexing may be a part of that, but that does not seem to be the case, given the importance of properly indexed elements. But striving toward a just-in-time approach to processing invariably affects the order in which stages occur, and mistakes can creep in on their proper ordering. That seems to be the case here.

Prior to the commit, BM element re-indexing occurred in the context of depsgraph evaluation, orchestrated by ##BKE_object_handle_data_update()##. Part of the parcel of generating a ##Mesh## for modifier evaluation involved BM_mesh_bm_to_me_for_eval() , where iteration blocks similar to those in Initializing_BMLoops can be found. The back trace during the call ##BM_mesh_bm_to_me_for_eval()## looked like this:

lang=c, name=pre-commit
- 0  BM_mesh_bm_to_me_for_eval (bm=0x7fffcea1d238, me=0x7fffce62a338, cd_mask_extra=0x7fffffffb7c0) at /home/gosgood/git_repositories/blender/source/blender/bmesh/intern/bmesh_mesh_conv.c:1138
- 1  0x0000000002b85330 in BKE_mesh_from_bmesh_for_eval_nomain (bm=0x7fffcea1d238, cd_mask_extra=0x7fffffffb7c0, me_settings=0x7fffce62aa38) at /home/gosgood/git_repositories/blender/source/blender/blenkernel/intern/mesh.c:864
- 2  0x0000000002b8537b in BKE_mesh_from_editmesh_with_coords_thin_wrap (em=0x7fff8a527fb8, cd_mask_extra=0x7fffffffb7c0, vertexCos=0x0, me_settings=0x7fffce62aa38) at /home/gosgood/git_repositories/blender/source/blender/blenkernel/intern/mesh.c:877
- 3  0x0000000002e6149e in editbmesh_calc_modifiers (depsgraph=0x7fffcea1cd38, scene=0x7fffce445438, ob=0x7fffce339038, em_input=0x7fff8a527fb8, dataMask=0x7fffffffbc10, r_cage=0x7fffffffbb98, r_final=0x7fffffffbba0) at /home/gosgood/git_repositories/blender/source/blender/blenkernel/intern/DerivedMesh.c:1504
- 4  0x0000000002e6243a in editbmesh_build_data (depsgraph=0x7fffcea1cd38, scene=0x7fffce445438, obedit=0x7fffce339038, em=0x7fff8a527fb8, dataMask=0x7fffffffbc10) at /home/gosgood/git_repositories/blender/source/blender/blenkernel/intern/DerivedMesh.c:1823
- 5  0x0000000002e62712 in makeDerivedMesh (depsgraph=0x7fffcea1cd38, scene=0x7fffce445438, ob=0x7fffce339038, em=0x7fff8a527fb8, dataMask=0x7fffffffbca0) at /home/gosgood/git_repositories/blender/source/blender/blenkernel/intern/DerivedMesh.c:1895
#6  0x0000000002be6b26 in BKE_object_handle_data_update (depsgraph=0x7fffcea1cd38, scene=0x7fffce445438, ob=0x7fffce339038) at /home/gosgood/git_repositories/blender/source/blender/blenkernel/intern/object_update.c:189
...

It was in this context that new BM elements with ##-1##-flagged invalid indices obtained valid ones.

Post commit finds a different back trace, with ##editbmesh_calc_modifiers()## calling newly minted functions that operate in the lazy world of just-in-time service. Both [BKE_mesh_from_editmesh_with_coords_thin_wrap() ]] and ##BKE_mesh_from_bmesh_for_eval_nomain()## have been retired, with [ https:*developer.blender.org/rBdeaff945d0b965d1e588cdecd084080b07db2e1f#change-YT3z01K889pL | BKE_mesh_wrapper_from_editmesh_with_coords() the replacement for both. The back trace now looks like:

lang=c, name=post-commit
- 0 BKE_mesh_wrapper_from_editmesh_with_coords (em=0x7fff8a0a3538, cd_mask_extra=0x7fffffffca10, vertexCos=0x0, me_settings=0x7fffce74f038) at /home/gosgood/git_repositories/blender/source/blender/blenkernel/intern/mesh_wrapper.c:80
- 1 0x0000000002e710c3 in editbmesh_calc_modifiers (depsgraph=0x7fffcea15d38, scene=0x7fff8e816038, ob=0x7fffce353c38, em_input=0x7fff8a0a3538, dataMask=0x7fffffffce60, r_cage=0x7fffffffcde8, r_final=0x7fffffffcdf0) at /home/gosgood/git_repositories/blender/source/blender/blenkernel/intern/DerivedMesh.c:1521
- 2 0x0000000002e721f5 in editbmesh_build_data (depsgraph=0x7fffcea15d38, scene=0x7fff8e816038, obedit=0x7fffce353c38, em=0x7fff8a0a3538, dataMask=0x7fffffffce60) at /home/gosgood/git_repositories/blender/source/blender/blenkernel/intern/DerivedMesh.c:1845
- 3 0x0000000002e724cd in makeDerivedMesh (depsgraph=0x7fffcea15d38, scene=0x7fff8e816038, ob=0x7fffce353c38, em=0x7fff8a0a3538, dataMask=0x7fffffffcef0) at /home/gosgood/git_repositories/blender/source/blender/blenkernel/intern/DerivedMesh.c:1917
#4 0x0000000002bf3e11 in BKE_object_handle_data_update (depsgraph=0x7fffcea15d38, scene=0x7fff8e816038, ob=0x7fffce353c38) at /home/gosgood/git_repositories/blender/source/blender/blenkernel/intern/object_update.c:189
...

Here, ##BM_mesh_bm_to_me_for_eval()## has not been retired, but is no longer called in the context of depsgraph evaluation. So the question arises: "At what point does BM element indexing take place in this new scheme of things"?

Watch points on memory locations to detect changes in values is a common technique for pin-pointing where assignments take place, such as the assignment of valid indices to newly minted BM elements. The usual caution against watching memory locations in de-allocated chunks apply, but such events are infrequent in performant code where expensive allocations and de-allocations are frowned upon. Dropping debug watches on all the ##f->l_first[...].head.index## memory blocks very early in the new face processing pipeline - say ##BM_face_create()## - help establish where hitherto invalidated indices are set valid. Prior to the commit, this watch point exercise yielded ##BM_mesh_bm_to_me_for_eval()## as the point in processing where re-indexing occurred, well before the overlay engine comes into play.

In the new scheme, BM element re-indexing appears to take place for all manner of elements - except ##BMLoops## - even up to the point - late in the processing pipeline - when the overlay engine is generating display lists. The watch points placed on ##f->l_first[...].head.index## memory blocks remain untouched by assignments right up to ##draw_manager_text.c:408##, which trips the bug.

As noted in #77195#942808, eventually the ##BMLoop## elements on the new face's ##f->l_first## list are indexed - just too late. Assignment takes place in drawing code, but after the generation of display lists:

lang=c, name=lateindexing
- 0  _bm_elem_index_set (index=20, head=0x7fff8a82a360) at /home/gosgood/git_repositories/blender/source/blender/bmesh/intern/bmesh_inline.h:131
- 1  BM_mesh_elem_index_ensure_ex (bm=0x7fffcea16238, htype=15 '\017', elem_offset=0x0) at /home/gosgood/git_repositories/blender/source/blender/bmesh/intern/bmesh_mesh.c:1770
- 2  0x000000000309d7c8 in BM_mesh_elem_index_ensure (bm=0x7fffcea16238, htype=15 '\017') at /home/gosgood/git_repositories/blender/source/blender/bmesh/intern/bmesh_mesh.c:1817
- 3  0x000000000334ed26 in mesh_render_data_create (me=0x7fff8e378038, is_editmode=true, is_paint_mode=false, obmat=0x7fffce29eef4, do_final=true, do_uvedit=false, UNUSED_cd_used=0x7fff84b8bc80, ts=0x7fff8a41d838) at /home/gosgood/git_repositories/blender/source/blender/draw/intern/draw_cache_extract_mesh.c:177
- 4  0x000000000337405a in mesh_buffer_cache_create_requested (task_graph=0x7fff8521a250, cache=0x7fff84b8b838, mbc=..., me=0x7fff8e378038, is_editmode=true, is_paint_mode=false, obmat=0x7fffce29eef4, do_final=true, do_uvedit=false, use_subsurf_fdots=false, cd_layer_used=0x7fff84b8bc80, scene=0x7fff8e417038, ts=0x7fff8a41d838, use_hide=true) at /home/gosgood/git_repositories/blender/source/blender/draw/intern/draw_cache_extract_mesh.c:4989
- 5  0x0000000003324dfa in DRW_mesh_batch_cache_create_requested (task_graph=0x7fff8521a250, ob=0x7fffce29ec38, me=0x7fff8e378038, scene=0x7fff8e417038, is_paint_mode=false, use_hide=true) at /home/gosgood/git_repositories/blender/source/blender/draw/intern/draw_cache_impl_mesh.c:1420
- 6  0x000000000330c076 in drw_batch_cache_generate_requested (ob=0x7fffce29ec38) at /home/gosgood/git_repositories/blender/source/blender/draw/intern/draw_cache.c:3537
- 7  0x0000000003293840 in drw_engines_cache_populate (ob=0x7fffce29ec38) at /home/gosgood/git_repositories/blender/source/blender/draw/intern/draw_manager.c:1014
- 8  0x0000000003294dc2 in DRW_draw_render_loop_ex (depsgraph=0x7fffcea15d38, engine_type=0xc3a4f20 <DRW_engine_viewport_eevee_type>, region=0x7fff8a5ece38, v3d=0x7fff8a308238, viewport=0x7fff8b112b38, evil_C=0x7fffe7c395f8) at /home/gosgood/git_repositories/blender/source/blender/draw/intern/draw_manager.c:1480
- 9  0x0000000003294954 in DRW_draw_view (C=0x7fffe7c395f8) at /home/gosgood/git_repositories/blender/source/blender/draw/intern/draw_manager.c:1396
...

As its name implies, BM_mesh_elem_index_ensure() sanitizes BM element indexing. Can it be guaranteed to run before the overlay rendering engine gets to work? That is the question of the day, and, methinks, the road to closing this bug.

Apologies for the wall of words, but I, for one, hanker for bug analysis and investigation. I suppose anyone with opinions on that could take it up with me on DevTalk . Perhaps a terse TL;DR here and the extended commentary over there. I'm inclined to keep Things In One Place, however, not that I'm actually that organized.

References
BMesh Design
BMesh Structures

**TL;DR** Longish comment. If you must know, It appears to me that a reordering of processing stemming from the commit has put the reindexing of certain BM elements (##BMLoops##) rather late in the pipeline -- too late for the liking of the overlay drawing engine, which is tripping over un-indexed ##BMLoop## elements: the gist of this bug. A reordering of processing seems to be in order, but hopefully not at the expense of optimization. I'm not decided yet on how to unwrap that wicket. Opinions, observations, tirades welcome... --- **Immediate cause** See #77195#941825 for background. See also [Boundary Mesh Structures](https://developer.blender.org/diffusion/B/browse/master/source/blender/bmesh/bmesh.h). **BM elements** ##BMFace##, ##BMEdge##, ##BMVert## and ##BMLoop## all have identical ##BMHeader## structures. Of interest here is ##BMHeader.index## See [struct BMHeader ](https://developer.blender.org/diffusion/B/browse/master/source/blender/bmesh/bmesh_class.h$65). After pressing {key F}, [BM_face_create() ](https://developer.blender.org/diffusion/B/browse/master/source/blender/bmesh/intern/bmesh_core.c$424) gets the nod for generating a new ##BMFace##. This initiates a processing pipeline where a lot of stages have to complete before the overlay drawing engine - where the bug appears - gets to render things, including face-area annotations. One of those stages entail re-indexing BM elements. Depsgraph evaluation orchestrates that in the context of updating mesh objects. Pseudo-code-ishly, ##BMLoop## re-indexing looks roughly like this: ``` lang=c, name=Initializing_BMLoops BMFace *my_current_face; BMLoop *l_iter, *l_first; int j = 0; BM_ITER_MESH_INDEX (my_current_face, ..., BM_FACES_OF_MESH, ...) { l_iter = l_first = BM_FACE_FIRST_LOOP(my_current_face); do { /* some processing */ BM_elem_index_set(l_iter, j); j++; /* some other processing */ } while ((l_iter = l_iter->next) != l_first); } ``` Macros [BM_elem_index_get(elem) and BM_elem_index_set(elem, index) ](https://developer.blender.org/diffusion/B/browse/master/source/blender/bmesh/intern/bmesh_inline.h$98) furnish low-level getter/setter interfaces to ##BMHeader## indices. One should not assign to or read from the indices directly. The assignment of unique non-negative indices to ##BMLoops## and other BM elements occur periodically to ensure uniqueness. Apt choices of BM iterator macros determine what BM element type gets re-indexed. When valid, indices are unique to the mesh and BM element type. The index doesn't "mean" anything beyond the rule that a negative index means "not indexed." Regarding this, the tripwire for the bug exhibits a certain touching innocence: ``` lang=c, name=draw_manager_text.c:408 BMLoop *(*l)[3] = &em->looptris[poly_to_tri_count(i, BM_elem_index_get(f->l_first))]; for (int j = 0; j < numtri; j++) { ... ``` Here, ##BM_elem_index_get()## retrieves the ##BMLoop## index; the index is passed, unchecked, to [poly_to_tri_count() ]], fully trusting that ##f->l_first## points to a ##BMLoop## element with a non-negative element index. This innocence is natural across tightly coupled interfaces. Innocence is not the issue. The issue is that at this late processing stage - we're now in the midsts of rendering with the overlay engine - BM elements are still not indexed. That is the immediate cause of the bug: ##poly_to_tri_count()## assumes that the ##BMLoop## index is non-negative, but it is - so the function returns a negative value which causes an out-of-bounds access into the tesselation buffer. That, in [[https:*en.wikipedia.org/wiki/Damon_Runyon|Runyonesque terms ](https:*developer.blender.org/diffusion/B/browse/master/source/blender/blenlib/intern/math_geom_inline.c$253) is the ballgame. **Causality** Mesh management, of which re-indexing BM elements is just one facet, is processing intensive. The commit which triggers this bug strives to minimize processing by taking a 'lazy' or just-in-time approach to (re-)generating mesh representations. One might think that deferring BM element re-indexing may be a part of that, but that does not seem to be the case, given the importance of properly indexed elements. But striving toward a just-in-time approach to processing invariably affects the order in which stages occur, and mistakes can creep in on their proper ordering. That seems to be the case here. Prior to the commit, BM element re-indexing occurred in the context of depsgraph evaluation, orchestrated by ##BKE_object_handle_data_update()##. Part of the parcel of generating a ##Mesh## for modifier evaluation involved [BM_mesh_bm_to_me_for_eval() ](https://developer.blender.org/diffusion/B/browse/master/source/blender/bmesh/intern/bmesh_mesh_convert.c$1130), where iteration blocks similar to those in **Initializing_BMLoops** can be found. The back trace during the call ##BM_mesh_bm_to_me_for_eval()## looked like this: ``` lang=c, name=pre-commit - 0 BM_mesh_bm_to_me_for_eval (bm=0x7fffcea1d238, me=0x7fffce62a338, cd_mask_extra=0x7fffffffb7c0) at /home/gosgood/git_repositories/blender/source/blender/bmesh/intern/bmesh_mesh_conv.c:1138 - 1 0x0000000002b85330 in BKE_mesh_from_bmesh_for_eval_nomain (bm=0x7fffcea1d238, cd_mask_extra=0x7fffffffb7c0, me_settings=0x7fffce62aa38) at /home/gosgood/git_repositories/blender/source/blender/blenkernel/intern/mesh.c:864 - 2 0x0000000002b8537b in BKE_mesh_from_editmesh_with_coords_thin_wrap (em=0x7fff8a527fb8, cd_mask_extra=0x7fffffffb7c0, vertexCos=0x0, me_settings=0x7fffce62aa38) at /home/gosgood/git_repositories/blender/source/blender/blenkernel/intern/mesh.c:877 - 3 0x0000000002e6149e in editbmesh_calc_modifiers (depsgraph=0x7fffcea1cd38, scene=0x7fffce445438, ob=0x7fffce339038, em_input=0x7fff8a527fb8, dataMask=0x7fffffffbc10, r_cage=0x7fffffffbb98, r_final=0x7fffffffbba0) at /home/gosgood/git_repositories/blender/source/blender/blenkernel/intern/DerivedMesh.c:1504 - 4 0x0000000002e6243a in editbmesh_build_data (depsgraph=0x7fffcea1cd38, scene=0x7fffce445438, obedit=0x7fffce339038, em=0x7fff8a527fb8, dataMask=0x7fffffffbc10) at /home/gosgood/git_repositories/blender/source/blender/blenkernel/intern/DerivedMesh.c:1823 - 5 0x0000000002e62712 in makeDerivedMesh (depsgraph=0x7fffcea1cd38, scene=0x7fffce445438, ob=0x7fffce339038, em=0x7fff8a527fb8, dataMask=0x7fffffffbca0) at /home/gosgood/git_repositories/blender/source/blender/blenkernel/intern/DerivedMesh.c:1895 #6 0x0000000002be6b26 in BKE_object_handle_data_update (depsgraph=0x7fffcea1cd38, scene=0x7fffce445438, ob=0x7fffce339038) at /home/gosgood/git_repositories/blender/source/blender/blenkernel/intern/object_update.c:189 ... ``` It was in this context that new BM elements with ##-1##-flagged invalid indices obtained valid ones. Post commit finds a different back trace, with ##editbmesh_calc_modifiers()## calling newly minted functions that operate in the lazy world of just-in-time service. Both [BKE_mesh_from_editmesh_with_coords_thin_wrap() ]] and ##BKE_mesh_from_bmesh_for_eval_nomain()## have been retired, with [[ https:*developer.blender.org/rBdeaff945d0b965d1e588cdecd084080b07db2e1f#change-YT3z01K889pL | BKE_mesh_wrapper_from_editmesh_with_coords() ](https:*developer.blender.org/rBdeaff945d0b965d1e588cdecd084080b07db2e1f#change-qM0HRWfGliwW) the replacement for both. The back trace now looks like: ``` lang=c, name=post-commit - 0 BKE_mesh_wrapper_from_editmesh_with_coords (em=0x7fff8a0a3538, cd_mask_extra=0x7fffffffca10, vertexCos=0x0, me_settings=0x7fffce74f038) at /home/gosgood/git_repositories/blender/source/blender/blenkernel/intern/mesh_wrapper.c:80 - 1 0x0000000002e710c3 in editbmesh_calc_modifiers (depsgraph=0x7fffcea15d38, scene=0x7fff8e816038, ob=0x7fffce353c38, em_input=0x7fff8a0a3538, dataMask=0x7fffffffce60, r_cage=0x7fffffffcde8, r_final=0x7fffffffcdf0) at /home/gosgood/git_repositories/blender/source/blender/blenkernel/intern/DerivedMesh.c:1521 - 2 0x0000000002e721f5 in editbmesh_build_data (depsgraph=0x7fffcea15d38, scene=0x7fff8e816038, obedit=0x7fffce353c38, em=0x7fff8a0a3538, dataMask=0x7fffffffce60) at /home/gosgood/git_repositories/blender/source/blender/blenkernel/intern/DerivedMesh.c:1845 - 3 0x0000000002e724cd in makeDerivedMesh (depsgraph=0x7fffcea15d38, scene=0x7fff8e816038, ob=0x7fffce353c38, em=0x7fff8a0a3538, dataMask=0x7fffffffcef0) at /home/gosgood/git_repositories/blender/source/blender/blenkernel/intern/DerivedMesh.c:1917 #4 0x0000000002bf3e11 in BKE_object_handle_data_update (depsgraph=0x7fffcea15d38, scene=0x7fff8e816038, ob=0x7fffce353c38) at /home/gosgood/git_repositories/blender/source/blender/blenkernel/intern/object_update.c:189 ... ``` Here, ##BM_mesh_bm_to_me_for_eval()## has not been retired, but is no longer called in the context of depsgraph evaluation. So the question arises: "At what point does BM element indexing take place in this new scheme of things"? Watch points on memory locations to detect changes in values is a common technique for pin-pointing where assignments take place, such as the assignment of valid indices to newly minted BM elements. The usual caution against watching memory locations in de-allocated chunks apply, but such events are infrequent in performant code where expensive allocations and de-allocations are frowned upon. Dropping debug watches on all the ##f->l_first[...].head.index## memory blocks very early in the new face processing pipeline - say ##BM_face_create()## - help establish where hitherto invalidated indices are set valid. Prior to the commit, this watch point exercise yielded ##BM_mesh_bm_to_me_for_eval()## as the point in processing where re-indexing occurred, well before the overlay engine comes into play. In the new scheme, BM element re-indexing appears to take place for all manner of elements - except ##BMLoops## - even up to the point - late in the processing pipeline - when the overlay engine is generating display lists. The watch points placed on ##f->l_first[...].head.index## memory blocks remain untouched by assignments right up to ##draw_manager_text.c:408##, which trips the bug. As noted in #77195#942808, eventually the ##BMLoop## elements on the new face's ##f->l_first## list are indexed - just too late. Assignment takes place in drawing code, but after the generation of display lists: ``` lang=c, name=lateindexing - 0 _bm_elem_index_set (index=20, head=0x7fff8a82a360) at /home/gosgood/git_repositories/blender/source/blender/bmesh/intern/bmesh_inline.h:131 - 1 BM_mesh_elem_index_ensure_ex (bm=0x7fffcea16238, htype=15 '\017', elem_offset=0x0) at /home/gosgood/git_repositories/blender/source/blender/bmesh/intern/bmesh_mesh.c:1770 - 2 0x000000000309d7c8 in BM_mesh_elem_index_ensure (bm=0x7fffcea16238, htype=15 '\017') at /home/gosgood/git_repositories/blender/source/blender/bmesh/intern/bmesh_mesh.c:1817 - 3 0x000000000334ed26 in mesh_render_data_create (me=0x7fff8e378038, is_editmode=true, is_paint_mode=false, obmat=0x7fffce29eef4, do_final=true, do_uvedit=false, UNUSED_cd_used=0x7fff84b8bc80, ts=0x7fff8a41d838) at /home/gosgood/git_repositories/blender/source/blender/draw/intern/draw_cache_extract_mesh.c:177 - 4 0x000000000337405a in mesh_buffer_cache_create_requested (task_graph=0x7fff8521a250, cache=0x7fff84b8b838, mbc=..., me=0x7fff8e378038, is_editmode=true, is_paint_mode=false, obmat=0x7fffce29eef4, do_final=true, do_uvedit=false, use_subsurf_fdots=false, cd_layer_used=0x7fff84b8bc80, scene=0x7fff8e417038, ts=0x7fff8a41d838, use_hide=true) at /home/gosgood/git_repositories/blender/source/blender/draw/intern/draw_cache_extract_mesh.c:4989 - 5 0x0000000003324dfa in DRW_mesh_batch_cache_create_requested (task_graph=0x7fff8521a250, ob=0x7fffce29ec38, me=0x7fff8e378038, scene=0x7fff8e417038, is_paint_mode=false, use_hide=true) at /home/gosgood/git_repositories/blender/source/blender/draw/intern/draw_cache_impl_mesh.c:1420 - 6 0x000000000330c076 in drw_batch_cache_generate_requested (ob=0x7fffce29ec38) at /home/gosgood/git_repositories/blender/source/blender/draw/intern/draw_cache.c:3537 - 7 0x0000000003293840 in drw_engines_cache_populate (ob=0x7fffce29ec38) at /home/gosgood/git_repositories/blender/source/blender/draw/intern/draw_manager.c:1014 - 8 0x0000000003294dc2 in DRW_draw_render_loop_ex (depsgraph=0x7fffcea15d38, engine_type=0xc3a4f20 <DRW_engine_viewport_eevee_type>, region=0x7fff8a5ece38, v3d=0x7fff8a308238, viewport=0x7fff8b112b38, evil_C=0x7fffe7c395f8) at /home/gosgood/git_repositories/blender/source/blender/draw/intern/draw_manager.c:1480 - 9 0x0000000003294954 in DRW_draw_view (C=0x7fffe7c395f8) at /home/gosgood/git_repositories/blender/source/blender/draw/intern/draw_manager.c:1396 ... ``` As its name implies, [BM_mesh_elem_index_ensure()](https://developer.blender.org/diffusion/B/browse/master/source/blender/bmesh/intern/bmesh_mesh.c$1701) sanitizes BM element indexing. Can it be guaranteed to run before the overlay rendering engine gets to work? That is the question of the day, and, methinks, the road to closing this bug. Apologies for the wall of words, but I, for one, hanker for bug analysis and investigation. I suppose anyone with opinions on that could take it up with me on [DevTalk ](https://devtalk.blender.org). Perhaps a terse **TL;DR** here and the extended commentary over there. I'm inclined to keep Things In One Place, however, not that I'm actually that organized. **References** [BMesh Design](https://wiki.blender.org/wiki/Source/Modeling/BMesh/Design) [BMesh Structures](https://developer.blender.org/diffusion/B/browse/master/source/blender/bmesh/bmesh.h)

blender-admin commented

2020-06-10 05:36:30 +02:00

This issue was referenced by 48ca66cfe7

This issue was referenced by 48ca66cfe7826985f94a72af6cd6f750d797a46b

Campbell Barton commented

2020-06-10 05:47:22 +02:00

Changed status from 'Confirmed' to: 'Resolved'

Campbell Barton closed this issue

2020-06-10 05:47:22 +02:00

Campbell Barton self-assigned this 2020-06-10 05:47:22 +02:00

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Crash with Viewport measurements turned on #77195