calling obj.data.materials.clear() on an object with 2+ materials in lookdev or rendered(eevee) shading crashes Blender #67999

New Issue

MACHIN3 · 2019-07-31T14:46:20+02:00

MACHIN3 commented

2019-07-31 14:46:20 +02:00

System Information
Operating system: Linux-4.13.10-041310-generic-x86_64-with-debian-stretch-sid 64 Bits
Graphics card: GeForce GTX 1050/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 390.67

Blender Version
Broken: version: 2.80 (sub 75), branch: master, commit date: 2019-07-29 14:47, hash: f6cb5f5449,
Also Broken: version: 2.81 (sub 0), branch: master, commit date: 2019-07-30 20:50, hash: 5359b7a033

Short description of error
Have object with 2 or more materials applied. Be in lookdev or rendered shading(using Eevee).
Use obj.data.materials.clear() in the console or from a script to remove materials and slots. Blender crashes.
I've had sb. else mention it takes more than 2 materials for him, but for me 2 are sufficient, and clearing them crashes Blender every time.

obj.data.matrials.clear()_crashes_blender_in_eevee_shading.blend

Exact steps for others to reproduce the error

load the blend file
if you aren't already in the scripting layout, enter C.active_object.data.materials.clear() in the python console and hit return, otherwise it's already typed out and you can just hit return
Blender should crash

**System Information** Operating system: Linux-4.13.10-041310-generic-x86_64-with-debian-stretch-sid 64 Bits Graphics card: GeForce GTX 1050/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 390.67 **Blender Version** Broken: version: 2.80 (sub 75), branch: master, commit date: 2019-07-29 14:47, hash: `f6cb5f5449`, Also Broken: version: 2.81 (sub 0), branch: master, commit date: 2019-07-30 20:50, hash: `5359b7a033` **Short description of error** Have object with 2 or more materials applied. Be in lookdev or rendered shading(using Eevee). Use `obj.data.materials.clear()` in the console or from a script to remove materials and slots. Blender crashes. I've had sb. else mention it takes more than 2 materials for him, but for me 2 are sufficient, and clearing them crashes Blender every time. [obj.data.matrials.clear()_crashes_blender_in_eevee_shading.blend](https://archive.blender.org/developer/F7639576/obj.data.matrials.clear___crashes_blender_in_eevee_shading.blend) **Exact steps for others to reproduce the error** * load the blend file * if you aren't already in the scripting layout, enter `C.active_object.data.materials.clear()` in the python console and hit return, otherwise it's already typed out and you can just hit return * Blender should crash

MACHIN3 commented

2019-07-31 14:46:20 +02:00

Added subscriber: @MACHIN3

MACHIN3 changed title from ~~calling obj.data.materials.clear() on an object with 2+ materials in lookedev or rendered(eevee) shading crashes Blender~~ to calling obj.data.materials.clear() on an object with 2+ materials in lookdev or rendered(eevee) shading crashes Blender

2019-07-31 14:46:51 +02:00

Sybren A. Stüvel commented

2019-07-31 16:09:10 +02:00

Added subscriber: @dr.sybren

Sybren A. Stüvel commented

2019-07-31 16:09:10 +02:00

I can confirm this crash on current master (03be31e817). In debug mode it fails an assertion, showing that there is a difference between the number of material slots on the mesh and the object:

/usr/lib/x86_64-linux-gnu/libasan.so.4(+0x558c0) [0x7f28459b88c0]
blenderdebug(BLI_system_backtrace+0xaa) [0x55cf9cb1c9ef]
blenderdebug(DRW_mesh_batch_cache_get_surface_shaded+0x1d1) [0x55cf9defa966]
blenderdebug(DRW_cache_mesh_surface_shaded_get+0x158) [0x55cf9de7334b]
blenderdebug(DRW_cache_object_surface_material_get+0x155) [0x55cf9de620e9]
blenderdebug(EEVEE_materials_cache_populate+0xaf0) [0x55cf9ddd9350]
blenderdebug(EEVEE_cache_populate+0x20d) [0x55cf9dd9bd46]
blenderdebug(+0x449f839) [0x55cf9dd17839]
blenderdebug(DRW_draw_render_loop_ex+0x9f7) [0x55cf9dd1a038]
blenderdebug(DRW_draw_view+0x276) [0x55cf9dd1963e]
blenderdebug(+0x526b2ed) [0x55cf9eae32ed]
blenderdebug(view3d_main_region_draw+0x43) [0x55cf9eae33eb]
blenderdebug(ED_region_do_draw+0x3a6) [0x55cf9ed05d59]
blenderdebug(+0x3a3ee12) [0x55cf9d2b6e12]
blenderdebug(+0x3a3f935) [0x55cf9d2b7935]
blenderdebug(wm_draw_update+0xec) [0x55cf9d2b851f]
blenderdebug(WM_main+0x48) [0x55cf9d2ad0fc]
blenderdebug(+0x2958d97) [0x55cf9c1d0d97]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xe7) [0x7f283db91b97]
blenderdebug(_start+0x2a) [0x55cf9c1d042a]
BLI_assert failed: /home/sybren/workspace/blender-git/blender/source/blender/draw/intern/draw_cache_impl_mesh.c:4546, DRW_mesh_batch_cache_get_surface_shaded(), at 'gpumat_array_len == cache->mat_len'

I can confirm this crash on current master (03be31e817a21ebd658). In debug mode it fails an assertion, showing that there is a difference between the number of material slots on the mesh and the object: ``` /usr/lib/x86_64-linux-gnu/libasan.so.4(+0x558c0) [0x7f28459b88c0] blenderdebug(BLI_system_backtrace+0xaa) [0x55cf9cb1c9ef] blenderdebug(DRW_mesh_batch_cache_get_surface_shaded+0x1d1) [0x55cf9defa966] blenderdebug(DRW_cache_mesh_surface_shaded_get+0x158) [0x55cf9de7334b] blenderdebug(DRW_cache_object_surface_material_get+0x155) [0x55cf9de620e9] blenderdebug(EEVEE_materials_cache_populate+0xaf0) [0x55cf9ddd9350] blenderdebug(EEVEE_cache_populate+0x20d) [0x55cf9dd9bd46] blenderdebug(+0x449f839) [0x55cf9dd17839] blenderdebug(DRW_draw_render_loop_ex+0x9f7) [0x55cf9dd1a038] blenderdebug(DRW_draw_view+0x276) [0x55cf9dd1963e] blenderdebug(+0x526b2ed) [0x55cf9eae32ed] blenderdebug(view3d_main_region_draw+0x43) [0x55cf9eae33eb] blenderdebug(ED_region_do_draw+0x3a6) [0x55cf9ed05d59] blenderdebug(+0x3a3ee12) [0x55cf9d2b6e12] blenderdebug(+0x3a3f935) [0x55cf9d2b7935] blenderdebug(wm_draw_update+0xec) [0x55cf9d2b851f] blenderdebug(WM_main+0x48) [0x55cf9d2ad0fc] blenderdebug(+0x2958d97) [0x55cf9c1d0d97] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xe7) [0x7f283db91b97] blenderdebug(_start+0x2a) [0x55cf9c1d042a] BLI_assert failed: /home/sybren/workspace/blender-git/blender/source/blender/draw/intern/draw_cache_impl_mesh.c:4546, DRW_mesh_batch_cache_get_surface_shaded(), at 'gpumat_array_len == cache->mat_len' ```

Sybren A. Stüvel self-assigned this 2019-07-31 16:15:05 +02:00

blender-admin commented

2019-07-31 17:18:04 +02:00

This issue was referenced by 92a3995c6d

This issue was referenced by 92a3995c6d4487e5bc0735b35fbef5c34b29421a

Sybren A. Stüvel commented

2019-07-31 17:19:58 +02:00

Changed status from 'Open' to: 'Resolved'

Sybren A. Stüvel closed this issue

2019-07-31 17:19:58 +02:00

MACHIN3 commented

2019-08-15 11:21:16 +02:00

Changed status from 'Resolved' to: 'Open'

MACHIN3 reopened this issue

2019-08-15 11:21:16 +02:00

MACHIN3 commented

2019-08-15 11:21:16 +02:00

I'm opening this one again, because the issue seems to have re-appeared in cb7ead2e3b. Seems like it's - in my case at least - for 3+ Materials now, so make sure to use the cube on the right in the example blend above.

I'm opening this one again, because the issue seems to have re-appeared in `cb7ead2e3b`. Seems like it's - in my case at least - for 3+ Materials now, so make sure to use the cube on the right in the example blend above.

Sybren A. Stüvel commented

2019-08-16 10:47:47 +02:00

Added subscriber: @brecht

Sybren A. Stüvel commented

2019-08-16 10:47:47 +02:00

The root cause of the crash is that something is allowed via Python that we never do from C. The Mesh.materials.clear() function will remove all the material slots from the mesh, but it keeps the polygon material indices (mpoly->mat_nr) intact. The drawing code then uses mpoly->mat_nr to index into the material slots, which crashes because they aren't there.

The crash is resolved by passing Mesh.materials.clear(update_data=True). From C we always pass update_data=true to the underlying BKE_material_clear_id() function, as that updates the polygon material and keeps things in sync. My proposal is to remove the update_data parameter altogether, both in C and Python, and always update the polygon material indices. This would then have the same effect as removing the material slots one by one in the UI (that also removes the poly assignment). I do want to discuss this with @brecht though.

I've updated extract_tris_init() (the function that crashes) to clamp the material indices to the number of material slots, to see what would be drawn in that case. It's clear that this isn't supported by the rest of the draw code:

(left/right = before/after material removal)

The root cause of the crash is that something is allowed via Python that we never do from C. The `Mesh.materials.clear()` function will remove all the material slots from the mesh, but it keeps the polygon material indices (`mpoly->mat_nr`) intact. The drawing code then uses `mpoly->mat_nr` to index into the material slots, which crashes because they aren't there. The crash is resolved by passing `Mesh.materials.clear(update_data=True)`. From C we always pass `update_data=true` to the underlying `BKE_material_clear_id()` function, as that updates the polygon material and keeps things in sync. My proposal is to remove the `update_data` parameter altogether, both in C and Python, and always update the polygon material indices. This would then have the same effect as removing the material slots one by one in the UI (that also removes the poly assignment). I do want to discuss this with @brecht though. I've updated `extract_tris_init()` (the function that crashes) to clamp the material indices to the number of material slots, to see what would be drawn in that case. It's clear that this isn't supported by the rest of the draw code: ![image.png](https://archive.blender.org/developer/F7667048/image.png) (left/right = before/after material removal)

MACHIN3 commented

2019-08-16 10:57:33 +02:00

Thanks for looking into this! I've also occasionally seen those vanishing faces when it didn't crash. Also, wasn't aware of the update_data argument, either.

blender-admin commented

2019-08-16 14:36:57 +02:00

This issue was referenced by c70f975d5c

This issue was referenced by c70f975d5c3b961e0c77eba3a35c8a892f39214d

Sybren A. Stüvel commented

2019-08-16 14:38:23 +02:00

Changed status from 'Open' to: 'Resolved'

Sybren A. Stüvel closed this issue

2019-08-16 14:38:23 +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

calling obj.data.materials.clear() on an object with 2+ materials in lookdev or rendered(eevee) shading crashes Blender #67999