Crash switching to material preview due to incorrect free with Cycles #80042

New Issue

Robert Guetzkow · 2020-08-23T15:23:05+02:00

Robert Guetzkow commented

2020-08-23 15:23:05 +02:00

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

Blender Version
Broken: version: 2.91.0 Alpha, branch: master, commit date: 2020-08-23 11:17, hash: e74ba9e09e
Worked: (newest version of Blender that worked as expected)

Short description of error
Blender crashes when switching the viewport shading to Material Preview when the material preview in the material properties isn't properly rendered yet.
This was tested on a debug build.

Exact steps for others to reproduce the error

Set the render engine to Cycles.
Switch viewport shading to Rendered.
Open the material properties and the preview panel within.
Switch to the shader ball preview shape and wait until it is properly displayed.

Switch to another preview shape like the sphere and before it displays the change, switch the viewport shading to Material Preview.

ccl::Stats::mem_free(unsigned __int64 size) Line 44	C++
ccl::rtc_memory_monitor_func(void * userPtr, const __int64 bytes, const bool __formal) Line 267	C++
[External Code]	
ccl::BVHEmbree::destroy(RTCSceneTy * scene) Line 391	C++
ccl::GeometryManager::device_free(ccl::Device * device, ccl::DeviceScene * dscene) Line 1418	C++
ccl::Scene::free_memory(bool final) Line 161	C++
ccl::Scene::~Scene() Line 131	C++
[External Code]	
ccl::Session::~Session() Line 132	C++
[External Code]	
ccl::BlenderSession::free_session() Line 262	C++
ccl::BlenderSession::~BlenderSession() Line 116	C++
[External Code]	
ccl::free_func(_object * __formal, _object * value) Line 273	C++
[External Code]	
BPY_DECREF_RNA_INVALIDATE(void * pyob_ptr) Line 458	C
RE_engine_free(RenderEngine * engine) Line 151	C
RE_engine_render(Render * re, int do_all) Line 918	C
do_render_3d(Render * re) Line 1137	C
RE_PreviewRender(Render * re, Main * bmain, Scene * sce) Line 2685	C
shader_preview_render(ShaderPreview * sp, ID * id, int split, int first) Line 900	C
shader_preview_startjob(void * customdata, short * stop, short * do_update) Line 938	C
common_preview_startjob(void * customdata, short * stop, short * do_update, float * UNUSED_progress) Line 1181	C
do_job_thread(void * job_v) Line 396	C
tslot_thread_start(void * tslot_p) Line 227	C++
[External Code]

**System Information** Operating system: Windows-10-10.0.19041-SP0 64 Bits Graphics card: GeForce GTX 1080 Ti/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 436.30 **Blender Version** Broken: version: 2.91.0 Alpha, branch: master, commit date: 2020-08-23 11:17, hash: `e74ba9e09e` Worked: (newest version of Blender that worked as expected) **Short description of error** Blender crashes when switching the viewport shading to *Material Preview* when the material preview in the material properties isn't properly rendered yet. This was tested on a debug build. **Exact steps for others to reproduce the error** - Set the render engine to *Cycles*. - Switch viewport shading to *Rendered*. - Open the material properties and the preview panel within. - Switch to the *shader ball* preview shape and wait until it is properly displayed. # Switch to another preview shape like the *sphere* and before it displays the change, switch the viewport shading to *Material Preview*. ``` ccl::Stats::mem_free(unsigned __int64 size) Line 44 C++ ccl::rtc_memory_monitor_func(void * userPtr, const __int64 bytes, const bool __formal) Line 267 C++ [External Code] ccl::BVHEmbree::destroy(RTCSceneTy * scene) Line 391 C++ ccl::GeometryManager::device_free(ccl::Device * device, ccl::DeviceScene * dscene) Line 1418 C++ ccl::Scene::free_memory(bool final) Line 161 C++ ccl::Scene::~Scene() Line 131 C++ [External Code] ccl::Session::~Session() Line 132 C++ [External Code] ccl::BlenderSession::free_session() Line 262 C++ ccl::BlenderSession::~BlenderSession() Line 116 C++ [External Code] ccl::free_func(_object * __formal, _object * value) Line 273 C++ [External Code] BPY_DECREF_RNA_INVALIDATE(void * pyob_ptr) Line 458 C RE_engine_free(RenderEngine * engine) Line 151 C RE_engine_render(Render * re, int do_all) Line 918 C do_render_3d(Render * re) Line 1137 C RE_PreviewRender(Render * re, Main * bmain, Scene * sce) Line 2685 C shader_preview_render(ShaderPreview * sp, ID * id, int split, int first) Line 900 C shader_preview_startjob(void * customdata, short * stop, short * do_update) Line 938 C common_preview_startjob(void * customdata, short * stop, short * do_update, float * UNUSED_progress) Line 1181 C do_job_thread(void * job_v) Line 396 C tslot_thread_start(void * tslot_p) Line 227 C++ [External Code] ```

Robert Guetzkow commented

2020-08-23 15:23:05 +02:00

Added subscriber: @rjg

Robert Guetzkow changed title from ~~Crash material preview due to incorrect free with Cycles~~ to Crash switching to material preview due to incorrect free with Cycles

2020-08-23 15:24:40 +02:00

Petter Lundh commented

2020-08-23 21:04:28 +02:00

Added subscriber: @PetterLundh

Germano Cavalcante commented

2020-08-25 17:33:51 +02:00

Added subscriber: @mano-wii

Germano Cavalcante commented

2020-08-25 17:33:51 +02:00

When you say "before it displays the change", is it before the samples are complete or before the image appears?
I cannot reproduce the problem:

When you say "before it displays the change", is it before the samples are complete or before the image appears? I cannot reproduce the problem: ![preview_crash.gif](https://archive.blender.org/developer/F8810667/preview_crash.gif)

Robert Guetzkow commented

2020-08-25 18:52:42 +02:00

Before the image appears. That's at least how I could quite reliably reproduce it on my system. I was using a debug build and the rendering was therefore slower, which allowed me to do this.

I'm not sure if this is relevant, but I've also just used the default material.

Before the image appears. That's at least how I could quite reliably reproduce it on my system. I was using a debug build and the rendering was therefore slower, which allowed me to do this. I'm not sure if this is relevant, but I've also just used the default material.

Germano Cavalcante commented

2020-08-25 21:49:00 +02:00

I also can't reproduce the problem in Debug Build.

Operating system: Windows-10-10.0.18941 64 Bits
Graphics card: Radeon (TM) RX 480 Graphics ATI Technologies Inc. 4.5.13596 Core Profile Context 20.10.19.02 27.20.1019.2002

I also can't reproduce the problem in Debug Build. ---- **Operating system:** Windows-10-10.0.18941 64 Bits **Graphics card:** Radeon (TM) RX 480 Graphics ATI Technologies Inc. 4.5.13596 Core Profile Context 20.10.19.02 27.20.1019.2002

Robert Guetzkow commented

2020-08-25 22:11:28 +02:00

@mano-wii Did you check with the same commit or latest master?

Germano Cavalcante commented

2020-08-25 23:54:00 +02:00

Tested with the latest master

Richard Antalik commented

2020-08-26 06:13:28 +02:00

Added subscriber: @iss

Richard Antalik commented

2020-08-26 06:13:28 +02:00

Also can't repro on master

Robert Guetzkow commented

2020-08-26 10:24:58 +02:00

This is still reproducible for me with the latest master and the same steps.

I can try to investigate the cause, but I'm currently quite busy so this will have to wait to until the weekend.

This is still reproducible for me with the latest master and the same steps. I can try to investigate the cause, but I'm currently quite busy so this will have to wait to until the weekend.

Brecht Van Lommel commented

2020-08-26 15:07:59 +02:00

Added subscribers: @Stefan_Werner, @brecht

Brecht Van Lommel commented

2020-08-26 15:07:59 +02:00

@Stefan_Werner, I guess there is some issue in the Embree freeing code, maybe in cases where rendering is aborted before the BVH is built?

Stefan Werner commented

2020-08-31 13:31:52 +02:00

It won't crash every time, but this crash is reproducible:
The cause is that all Cycles instances share the same Embree device, but use separate ccl::Stats objects. Embree's memory callback can then end up contributing to the wrong Stats object, or worst case, run into an invalid pointer.

It won't crash every time, but this crash is reproducible: The cause is that all Cycles instances share the same Embree device, but use separate ccl::Stats objects. Embree's memory callback can then end up contributing to the wrong Stats object, or worst case, run into an invalid pointer.

Robert Guetzkow commented

2020-08-31 13:40:04 +02:00

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