Page MenuHome

Entering Edit Mode when Viewport Display set as Wire or Bounds leads to crash
Closed, ResolvedPublicBUG


System Information
Operating system: Windows-10-10.0.19041-SP0 64 Bits
Graphics card: GeForce GTX 970/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 451.48

Blender Version
Broken: version: 2.90.0 Alpha, branch: master, commit date: 2020-07-17 19:20, hash: rBaa8279648e22
Worked: 2.83.2

Short description of error
Entering Edit Mode when Viewport Display set as Wire or Bounds leads to the instant crash

Exact steps for others to reproduce the error

  1. Create a scene
  2. Select the Cube, set Viewport Display in the Object Properties to WIre or Bounds
  3. Press Tab.

Event Timeline

Alaska (Alaska) changed the task status from Needs Triage to Confirmed.Jul 19 2020, 12:42 AM
Alaska (Alaska) edited projects, added BF Blender (2.90); removed BF Blender.
Alaska (Alaska) changed the subtype of this task from "Report" to "Bug".

I can reproduce this issue with the viewport display set to bounds.

Bisecting points to rB9582797d4b50. Not sure why, doesn't look like it should impact this.
CC @Jeroen Bakker (jbakker)

System Information:
Operating system: Linux-5.7.0-1-amd64-x86_64-with-debian-bullseye-sid 64 Bits
Graphics card: GeForce RTX 2060 Super 440.100
Blender version: 2.90.0 Alpha, branch: master, commit date: 2020-07-18 16:26, hash: rBb8601b64c7cb

# Blender 2.90.0, Commit date: 2020-07-18 16:26, Hash b8601b64c7cb
bpy.context.space_data.context = 'OBJECT'  # Property
bpy.context.object.display_type = 'BOUNDS'  # Property
bpy.ops.object.editmode_toggle()  # Operator

# backtrace
.../blender(BLI_system_backtrace+0x20) [0x82449c0]
.../blender() [0xe229da]
/lib/x86_64-linux-gnu/ [0x7f1691c26800]
.../blender(GPU_batch_vao_cache_clear+0) [0x6ea3400]
.../blender(GPU_batch_elembuf_set+0x11) [0x6ea37e1]
.../blender() [0x12a0c32]
.../blender() [0x12a4448]
.../blender() [0x12a45b8]
.../blender() [0x10d53f5]
.../blender() [0x8245b9f]
.../blender() [0x8246c44]
.../blender() [0x10d3a85]
.../blender() [0x10d3d3b]
.../blender() [0x10d62b2]
.../blender(BLI_task_graph_work_and_wait+0x4e) [0x824505e]
.../blender() [0x122c894]
.../blender(DRW_draw_render_loop_ex+0x258) [0x122e908]
.../blender(view3d_main_region_draw+0x8f) [0x18845ef]
.../blender(ED_region_do_draw+0x801) [0x147a501]
.../blender(wm_draw_update+0x4ca) [0x10dad8a]
.../blender(WM_main+0x30) [0x10d8cf0]
.../blender(main+0x311) [0xd5c071]
/lib/x86_64-linux-gnu/ [0x7f1691c11e0b]
.../blender(_start+0x2a) [0xe1f1ea]
diff --git a/source/blender/draw/intern/draw_cache_extract_mesh.c b/source/blender/draw/intern/draw_cache_extract_mesh.c
index 1737f8b2ff9..c95980be7d5 100644
--- a/source/blender/draw/intern/draw_cache_extract_mesh.c
+++ b/source/blender/draw/intern/draw_cache_extract_mesh.c
@@ -890,7 +890,7 @@ static void extract_tris_finish(const MeshRenderData *mr, void *ibo, void *_data
   MeshExtract_Tri_Data *data = _data;
   GPU_indexbuf_build_in_place(&data->elb, ibo);
   /* HACK: Create ibo sub-ranges and assign them to each #GPUBatch. */
-  if (mr->use_final_mesh) {
+  if (mr->use_final_mesh && mr->cache->surface_per_mat && mr->cache->surface_per_mat[0]) {
     for (int i = 0; i < mr->mat_len; i++) {
       /* Multiply by 3 because these are triangle indices. */
       const int mat_start = data->tri_mat_start[i];

Fixes the issue. Still need to test other situations.