Page MenuHome

Crash on leaving local view on the shading tab.
Closed, ResolvedPublic

Description

System Information
Operating system: Windows-10-10.0.17763 64 Bits
Graphics card: GeForce GTX 1070/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 430.64

Blender Version
Broken: version: 2.80 (sub 62), branch: master, commit date: 2019-05-13 09:55, hash: rB86650b01d873
Worked: (optional)

Short description of error
When leaving the local view on the shading tab there is a exception raise (with crash) due to a null on cache->surf_per_mat_tris
It seems surf_per_mat_tris is missing from cache.

line 5306 - draw_cache_impl_mesh.c

if (DRW_ibo_requested(cache->surf_per_mat_tris[0])) {
    mesh_create_loops_tris(rdata, cache->surf_per_mat_tris, cache->mat_len, use_hide);
}

Exact steps for others to reproduce the error
[Please describe the exact steps needed to reproduce the issue]
[Based on the default startup or an attached .blend file (as simple as possible)]

Event Timeline

As a workaround I added a null check to my local build just to avoid this, mostly because I don't know where the cache is populated, still "learning" my way around the blender source code.

Philipp Oeser (lichtwerk) triaged this task as Needs Information from User priority.

Cannot reproduce here (maybe I am misunderstanding something).

  • Are we talking about View > Local View > Toggle Local View in the Shading workspace (cannot get it to crash/assert there)?
  • Or is this about the Material tab in the Properties Editor?
  • Do you have a .blend file for us where this happens?

Unfortunately, I can't share the file. This happens after working for a while. I was doing complex baking of some meshes, in the Shading workspace. This happened twice until I added the null pointer check, one of the time was while leaving the Local View (/ Numpad), the other was whne moving from the Shading to the Layout workspace. I will make a build without my patch to see if I get any crash during the day.

And it still crashed. Left blender rendering a Diffuse bake map, and went to take care of my garden. Come back and it crashed in the same line. Going to put back the null check again.
State of blender at crash.

Stack trace:

Just for the record the fix is just this:

diff --git a/source/blender/draw/intern/draw_cache_impl_mesh.c b/source/blender/draw/intern/draw_cache_impl_mesh.c
index 02930d38b04..0f53877a311 100644
--- a/source/blender/draw/intern/draw_cache_impl_mesh.c
+++ b/source/blender/draw/intern/draw_cache_impl_mesh.c
@@ -5303,7 +5303,7 @@ void DRW_mesh_batch_cache_create_requested(
   if (DRW_ibo_requested(cache->ibo.loops_tris)) {
     mesh_create_loops_tris(rdata, &cache->ibo.loops_tris, 1, use_hide);
   }
-  if (DRW_ibo_requested(cache->surf_per_mat_tris[0])) {
+  if (cache->surf_per_mat_tris && DRW_ibo_requested(cache->surf_per_mat_tris[0])) {
     mesh_create_loops_tris(rdata, cache->surf_per_mat_tris, cache->mat_len, use_hide);
   }
Philipp Oeser (lichtwerk) raised the priority of this task from Needs Information from User to Waiting for Developer to Reproduce.May 14 2019, 12:47 PM

@Clément Foucault (fclem), does this ring a bell?

I was looking into the code where surf_per_mat_tris is inited, and there may be a corner case that could cause this, I have some objects without materials and the allocation takes in account the material count, well if the material count is zero, the new array pointer will be effectively zero in length.
This happens on draw_cache_impl_mesh.c line 2105.

To me, it sounds like it has to do with some VBO garbage collection we are doing.

@Philipp Oeser (lichtwerk) can you confirm?

And diving a little further, the MEM_lockfree_callocN makes no assumption on the request memory block asked, so if we ask a 0 block it will create one because it always has some memory used by MemHead. But I don't see a problem with this, and of course maybe its by design.

If you guys guide me a little, since I don't know the blender code (I used to create plugins for 3dsmax, houdini and maya in the past), maybe I can help track the problem. @Clément Foucault (fclem) Where should I look for the garbage collection, I quite savvy on C/C++, have about 20 years of developer experience in all kinds of languages including C/C++.

Call stack for the latest commit (3db4284 - Fix T64601 Error division by zero in GPUVertexFormat) :

blender.exe!DRW_mesh_batch_cache_create_requested(Object * ob, Mesh * me, const ToolSettings * ts, const bool is_paint_mode, const bool use_hide) Line 5316 (d:\dev\blender\blender\source\blender\draw\intern\draw_cache_impl_mesh.c:5316)
blender.exe!drw_batch_cache_generate_requested(Object * ob) Line 4064 (d:\dev\blender\blender\source\blender\draw\intern\draw_cache.c:4064)
blender.exe!drw_engines_cache_populate(Object * ob) Line 1193 (d:\dev\blender\blender\source\blender\draw\intern\draw_manager.c:1193)
blender.exe!DRW_draw_render_loop_ex(Depsgraph * depsgraph, RenderEngineType * engine_type, ARegion * ar, View3D * v3d, GPUViewport * viewport, const bContext * evil_C) Line 1656 (d:\dev\blender\blender\source\blender\draw\intern\draw_manager.c:1656)
blender.exe!DRW_draw_view(const bContext * C) Line 1583 (d:\dev\blender\blender\source\blender\draw\intern\draw_manager.c:1583)
blender.exe!view3d_main_region_draw(const bContext * C, ARegion * ar) Line 1450 (d:\dev\blender\blender\source\blender\editors\space_view3d\view3d_draw.c:1450)
blender.exe!ED_region_do_draw(bContext * C, ARegion * ar) Line 572 (d:\dev\blender\blender\source\blender\editors\screen\area.c:572)
blender.exe!wm_draw_window_offscreen(bContext * C, wmWindow * win, bool stereo) Line 597 (d:\dev\blender\blender\source\blender\windowmanager\intern\wm_draw.c:597)
blender.exe!wm_draw_window(bContext * C, wmWindow * win) Line 735 (d:\dev\blender\blender\source\blender\windowmanager\intern\wm_draw.c:735)
blender.exe!wm_draw_update(bContext * C) Line 901 (d:\dev\blender\blender\source\blender\windowmanager\intern\wm_draw.c:901)
blender.exe!WM_main(bContext * C) Line 425 (d:\dev\blender\blender\source\blender\windowmanager\intern\wm.c:425)
blender.exe!main(int argc, const unsigned char * * UNUSED_argv_c) Line 502 (d:\dev\blender\blender\source\creator\creator.c:502)
[Inline Frame] blender.exe!invoke_main() Line 78 (d:\agent\_work\4\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:78)
blender.exe!__scrt_common_main_seh() Line 288 (d:\agent\_work\4\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:288)
kernel32.dll!00007ff8358d7974() (Unknown Source:0)
ntdll.dll!00007ff836caa271() (Unknown Source:0)

@Daniel Santana (dgsantana) the garbage collection happens in DRW_batch_cache_free_old. But let me investigate this.

It a bit weird, now it happened when zooming out on the layout workspace with Solid Texture mode. Spend an hour doing decimate on highpoly to low poly people, switching from Wire to Solid Texture, and done tons of zoom in/out. When I was about to call it a day, and zooming out to see the an overview, puff :D.
No work lost thanks to great the autoback ;).