Crash rendering with EEVEE in mesh edit-mode #94230

New Issue

Kent Davis · 2021-12-18T19:01:30+01:00

Kent Davis commented

2021-12-18 19:01:30 +01:00

System Information
Operating system: macOS-12.0.1-x86_64-i386-64bit 64 Bits
Graphics card: AMD Radeon Pro 575 OpenGL Engine ATI Technologies Inc. 4.1 ATI-4.7.29

Blender Version
Broken: version: 3.1.0 Alpha, branch: master, commit date: 2021-12-14 00:16, hash: c1f5d8d023
Worked: (newest version of Blender that worked as expected)

Caused by aa6f0f3d1f

Short description of error
Crash guide

Exact steps for others to reproduce the error
@PratikPB2123
and
@lichtwerk

Open file then already have edit mode then push the F12 render cause crash any thing also edit mode select crash unknown how to explain. See youtube
Blender crash guide 3.1.0 December 17, 2021.txt

See youtube: https://youtu.be/XkKoX2lM-_0

Hand 9 fruit tree 1.1.0.blend

NOTE: The test file from this report is quite large, this is a simplified file with a command to redo the bug, @ideasman42

Test file: T94230_simple_test.blend

Command to reproduce the crash:

blender \
  --factory-startup \
  T94230_simple_test.blend \
  --enable-event-simulate --python tests/python/bl_run_operators_event_simulate.py \
  -- \
  --actions 'event(type="F12", value="TAP")' \
            'event(type="F5", value="TAP", shift=True)' \
  --keep-open

**System Information** Operating system: macOS-12.0.1-x86_64-i386-64bit 64 Bits Graphics card: AMD Radeon Pro 575 OpenGL Engine ATI Technologies Inc. 4.1 ATI-4.7.29 **Blender Version** Broken: version: 3.1.0 Alpha, branch: master, commit date: 2021-12-14 00:16, hash: `c1f5d8d023` Worked: (newest version of Blender that worked as expected) Caused by aa6f0f3d1f **Short description of error** Crash guide **Exact steps for others to reproduce the error** @PratikPB2123 and @lichtwerk ![image.png](https://archive.blender.org/developer/F12760329/image.png) Open file then already have edit mode then push the F12 render cause crash any thing also edit mode select crash unknown how to explain. See youtube [Blender crash guide 3.1.0 December 17, 2021.txt](https://archive.blender.org/developer/F12760355/Blender_crash_guide_3.1.0_December_17__2021.txt) See youtube: https://youtu.be/XkKoX2lM-_0 [Hand 9 fruit tree 1.1.0.blend](https://archive.blender.org/developer/F12760357/Hand_9_fruit_tree_1.1.0.blend) ---- NOTE: The test file from this report is quite large, this is a simplified file with a command to redo the bug, @ideasman42 Test file: [T94230_simple_test.blend](https://archive.blender.org/developer/F12800101/T94230_simple_test.blend) Command to reproduce the crash: ``` blender \ --factory-startup \ T94230_simple_test.blend \ --enable-event-simulate --python tests/python/bl_run_operators_event_simulate.py \ -- \ --actions 'event(type="F12", value="TAP")' \ 'event(type="F5", value="TAP", shift=True)' \ --keep-open ```

Kent Davis commented

2021-12-18 19:01:30 +01:00

Added subscribers: @PratikPB2123, @lichtwerk, @Kent-Davis

blender-admin commented

2021-12-18 19:01:30 +01:00

#94652 was marked as duplicate of this issue

Kent Davis commented

2021-12-18 19:02:35 +01:00

Youtube: https://youtu.be/XkKoX2lM-_0

Pratik Borhade commented

2021-12-19 10:33:44 +01:00

Hello @Kent-Davis , thanks for the report. Can confirm the crash with your file.

Is it possible to reduce the file size? (Remove unwanted textures, shaders,objects from the scene. Also present file even has 4-5 additional scenes, try to remove them?).
~800mb file size is quite large.

Stack trace:

blender.exe         :0x00007FF7AD1BD540  GPU_material_from_nodetree_find C:\Users\Pratik\Desktop\BlenderOSP\blender\source\blender\gpu\intern\gpu_material.c:578
blender.exe         :0x00007FF7AC95AC40  DRW_shader_find_from_material C:\Users\Pratik\Desktop\BlenderOSP\blender\source\blender\draw\intern\draw_manager_shader.c:450
blender.exe         :0x00007FF7AC963C60  eevee_material_get_ex C:\Users\Pratik\Desktop\BlenderOSP\blender\source\blender\draw\engines\eevee\eevee_shaders.c:1460
blender.exe         :0x00007FF7AC961DF0  EEVEE_material_get C:\Users\Pratik\Desktop\BlenderOSP\blender\source\blender\draw\engines\eevee\eevee_shaders.c:1517
blender.exe         :0x00007FF7AC94F9E0  material_opaque C:\Users\Pratik\Desktop\BlenderOSP\blender\source\blender\draw\engines\eevee\eevee_materials.c:596
blender.exe         :0x00007FF7AC94E970  EEVEE_materials_cache_populate C:\Users\Pratik\Desktop\BlenderOSP\blender\source\blender\draw\engines\eevee\eevee_materials.c:825
blender.exe         :0x00007FF7AC946AB0  EEVEE_cache_populate C:\Users\Pratik\Desktop\BlenderOSP\blender\source\blender\draw\engines\eevee\eevee_engine.c:126
blender.exe         :0x00007FF7AC9186A0  drw_engines_cache_populate C:\Users\Pratik\Desktop\BlenderOSP\blender\source\blender\draw\intern\draw_manager.c:1084
blender.exe         :0x00007FF7AC914E80  DRW_draw_render_loop_ex C:\Users\Pratik\Desktop\BlenderOSP\blender\source\blender\draw\intern\draw_manager.c:1687
blender.exe         :0x00007FF7AC915F30  DRW_draw_view C:\Users\Pratik\Desktop\BlenderOSP\blender\source\blender\draw\intern\draw_manager.c:1609
blender.exe         :0x00007FF7ACF5A690  view3d_main_region_draw C:\Users\Pratik\Desktop\BlenderOSP\blender\source\blender\editors\space_view3d\view3d_draw.c:1584
blender.exe         :0x00007FF7AC528C20  ED_region_do_draw C:\Users\Pratik\Desktop\BlenderOSP\blender\source\blender\editors\screen\area.c:563
blender.exe         :0x00007FF7AC50F0A0  wm_draw_window_offscreen C:\Users\Pratik\Desktop\BlenderOSP\blender\source\blender\windowmanager\intern\wm_draw.c:732
blender.exe         :0x00007FF7AC50EEF0  wm_draw_window C:\Users\Pratik\Desktop\BlenderOSP\blender\source\blender\windowmanager\intern\wm_draw.c:884
blender.exe         :0x00007FF7AC50EA30  wm_draw_update C:\Users\Pratik\Desktop\BlenderOSP\blender\source\blender\windowmanager\intern\wm_draw.c:1083
blender.exe         :0x00007FF7AC4E97E0  WM_main C:\Users\Pratik\Desktop\BlenderOSP\blender\source\blender\windowmanager\intern\wm.c:646
blender.exe         :0x00007FF7AC4E4FD0  main C:\Users\Pratik\Desktop\BlenderOSP\blender\source\creator\creator.c:566
blender.exe         :0x00007FF7AD3013B8  __scrt_common_main_seh d:\A01\_work\12\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:288
KERNEL32.DLL        :0x00007FFBD7637020  BaseThreadInitThunk
ntdll.dll           :0x00007FFBD9622630  RtlUserThreadStart```

Hello @Kent-Davis , thanks for the report. Can confirm the crash with your file. Is it possible to reduce the file size? (Remove unwanted textures, shaders,objects from the scene. Also present file even has 4-5 additional scenes, try to remove them?). ~800mb file size is quite large. Stack trace: ```lines blender.exe :0x00007FF7AD1BD540 GPU_material_from_nodetree_find C:\Users\Pratik\Desktop\BlenderOSP\blender\source\blender\gpu\intern\gpu_material.c:578 blender.exe :0x00007FF7AC95AC40 DRW_shader_find_from_material C:\Users\Pratik\Desktop\BlenderOSP\blender\source\blender\draw\intern\draw_manager_shader.c:450 blender.exe :0x00007FF7AC963C60 eevee_material_get_ex C:\Users\Pratik\Desktop\BlenderOSP\blender\source\blender\draw\engines\eevee\eevee_shaders.c:1460 blender.exe :0x00007FF7AC961DF0 EEVEE_material_get C:\Users\Pratik\Desktop\BlenderOSP\blender\source\blender\draw\engines\eevee\eevee_shaders.c:1517 blender.exe :0x00007FF7AC94F9E0 material_opaque C:\Users\Pratik\Desktop\BlenderOSP\blender\source\blender\draw\engines\eevee\eevee_materials.c:596 blender.exe :0x00007FF7AC94E970 EEVEE_materials_cache_populate C:\Users\Pratik\Desktop\BlenderOSP\blender\source\blender\draw\engines\eevee\eevee_materials.c:825 blender.exe :0x00007FF7AC946AB0 EEVEE_cache_populate C:\Users\Pratik\Desktop\BlenderOSP\blender\source\blender\draw\engines\eevee\eevee_engine.c:126 blender.exe :0x00007FF7AC9186A0 drw_engines_cache_populate C:\Users\Pratik\Desktop\BlenderOSP\blender\source\blender\draw\intern\draw_manager.c:1084 blender.exe :0x00007FF7AC914E80 DRW_draw_render_loop_ex C:\Users\Pratik\Desktop\BlenderOSP\blender\source\blender\draw\intern\draw_manager.c:1687 blender.exe :0x00007FF7AC915F30 DRW_draw_view C:\Users\Pratik\Desktop\BlenderOSP\blender\source\blender\draw\intern\draw_manager.c:1609 blender.exe :0x00007FF7ACF5A690 view3d_main_region_draw C:\Users\Pratik\Desktop\BlenderOSP\blender\source\blender\editors\space_view3d\view3d_draw.c:1584 blender.exe :0x00007FF7AC528C20 ED_region_do_draw C:\Users\Pratik\Desktop\BlenderOSP\blender\source\blender\editors\screen\area.c:563 blender.exe :0x00007FF7AC50F0A0 wm_draw_window_offscreen C:\Users\Pratik\Desktop\BlenderOSP\blender\source\blender\windowmanager\intern\wm_draw.c:732 blender.exe :0x00007FF7AC50EEF0 wm_draw_window C:\Users\Pratik\Desktop\BlenderOSP\blender\source\blender\windowmanager\intern\wm_draw.c:884 blender.exe :0x00007FF7AC50EA30 wm_draw_update C:\Users\Pratik\Desktop\BlenderOSP\blender\source\blender\windowmanager\intern\wm_draw.c:1083 blender.exe :0x00007FF7AC4E97E0 WM_main C:\Users\Pratik\Desktop\BlenderOSP\blender\source\blender\windowmanager\intern\wm.c:646 blender.exe :0x00007FF7AC4E4FD0 main C:\Users\Pratik\Desktop\BlenderOSP\blender\source\creator\creator.c:566 blender.exe :0x00007FF7AD3013B8 __scrt_common_main_seh d:\A01\_work\12\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:288 KERNEL32.DLL :0x00007FFBD7637020 BaseThreadInitThunk ntdll.dll :0x00007FFBD9622630 RtlUserThreadStart```

Kent Davis commented

2021-12-19 18:44:14 +01:00

Hello @PratikPB2123
Oh well you are use Windows.
Would you like to go Macintosh only please. Do not use Windows.

Hello @PratikPB2123 Oh well you are use Windows. Would you like to go Macintosh only please. Do not use Windows.

Michael commented

2021-12-19 19:20:07 +01:00

Added subscriber: @michael64

Michael commented

2021-12-19 19:20:07 +01:00

@Kent-Davis Thanks for the report. It is good to test a bug on different systems though and here
we might have a bug than crashes differently on different systems.
The diff in D13628 fixes this crash on macOS 12.1/M1 for me.

@Kent-Davis Thanks for the report. It is good to test a bug on different systems though and here we might have a bug than crashes differently on different systems. The diff in [D13628](https://archive.blender.org/developer/D13628) fixes this crash on macOS 12.1/M1 for me.

Kent Davis commented

2021-12-19 19:23:11 +01:00

@michael64
That is good your answer. I am wait for them to fix Blender non crash guide.

@michael64 That is good your answer. I am wait for them to fix Blender non crash guide.

Kent Davis commented

2021-12-19 19:23:36 +01:00

Me Intel year 2017.Macintosh

Philipp Oeser commented

2021-12-22 14:43:53 +01:00

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

Philipp Oeser commented

2021-12-22 14:43:53 +01:00

Cannot repro the crash on my side, but will confirm, since we have two people apparently who can (and there is a potetial fix available already).

Philipp Oeser changed title from ~~Blender crash guide~~ to Compositor crash

2021-12-22 14:44:36 +01:00

Kent Davis commented

2021-12-22 15:33:53 +01:00

@lichtwerk
Ok no problem.

@lichtwerk Ok no problem.

Michael commented

2021-12-22 17:15:51 +01:00

Hello @lichtwerk, I would to see D13628 applied and hope that @Kent-Davis sees a positive effect.
On macOS that was necessary to prevent one crash.
In the meantime I also tested on Windows with D13628 applied
which still crashed at the same site that @PratikPB2123 found.
Why wasn't Windows crashing in the function containing char[1000000]?
The default Windows stack size for a thread is 1MB (1024*1024) so either
it fits or the error is triggered even earlier than on macOS.

I have been running AddressSanitizer on Windows for this crash and have
seen that a Material instance is referenced at the crash site that has been
deallocated earlier.
To verify this one can simply comment out the line

MEM_freeN(id_cow);

in deg_node_id.cc and this prevents the crash.
That is obviously not a solution but uncommenting the DEG_DEBUG_COW_POINTERS
define helps in locating the root cause.
I am still slowly working on this bug the questions to be answered are:

where was the Material deallocated that was referenced later?
should the Material have been deallocated at this place and time?
if so, where does the dangling reference come from that still allowed dereferencing.

I'll report back if I make any progress on Windows.

Hello @lichtwerk, I would to see [D13628](https://archive.blender.org/developer/D13628) applied and hope that @Kent-Davis sees a positive effect. On macOS that was necessary to prevent one crash. In the meantime I also tested on Windows with [D13628](https://archive.blender.org/developer/D13628) applied which still crashed at the same site that @PratikPB2123 found. Why wasn't Windows crashing in the function containing char[1000000]? The default Windows stack size for a thread is 1MB (1024*1024) so either it fits or the error is triggered even earlier than on macOS. I have been running AddressSanitizer on Windows for this crash and have seen that a Material instance is referenced at the crash site that has been deallocated earlier. To verify this one can simply comment out the line ``` MEM_freeN(id_cow); ``` in deg_node_id.cc and this prevents the crash. That is obviously not a solution but uncommenting the DEG_DEBUG_COW_POINTERS define helps in locating the root cause. I am still slowly working on this bug the questions to be answered are: - where was the Material deallocated that was referenced later? - should the Material have been deallocated at this place and time? - if so, where does the dangling reference come from that still allowed dereferencing. I'll report back if I make any progress on Windows.

Kent Davis commented

2021-12-22 17:58:57 +01:00

@michael64
Good job.

@michael64 Good job.

Ray molenkamp commented

2021-12-22 18:04:06 +01:00

Added subscriber: @LazyDodo

Ray molenkamp commented

2021-12-22 18:04:06 +01:00

Why wasn't Windows crashing in the function containing char[1000000]? The default Windows stack size for a thread is 1MB (1024*1024) so either it fits or the error is triggered even earlier than on macOS.

While the logic of that argument will still stand, you're wrong on the numbers both here and in D13628, The Stack size for windows is 2MB, while on mac we use 1MB

and while I agree having such a a large array on the stack is without a doubt bad, and needs fixing, couple of things

I see no evidence in either the crash dump produced by @Kent-Davis nor @PratikPB2123 that the large stack allocation in DebugInfo::graphviz is a contributing factor to the crash reported in this ticket.
The const COM_EXPORT_GRAPHVIZ is by default false, in which case the compiler will do the right thing, eliminate all dead code and generate the following code for DebugInfo::graphviz

0000000000000490 <blender::compositor::DebugInfo::graphviz(blender::compositor::ExecutionSystem const*, blender::StringRefNull)>:
     490:	f3 0f 1e fa          	endbr64 
     494:	c3                   	ret

No large stack allocation, actually no real code at all, which leads me to the conclusion while the bug you found while investigating #94230 is annoying, D13628 is not a fix for #94230 (but a nice find nonetheless)
best to ignore this distraction for the remainder of this ticket, I will land D13628 though.

> Why wasn't Windows crashing in the function containing char[1000000]? The default Windows stack size for a thread is 1MB (1024*1024) so either it fits or the error is triggered even earlier than on macOS. While the logic of that argument will still stand, you're wrong on the numbers both here and in [D13628](https://archive.blender.org/developer/D13628), The Stack size for windows is [2MB](https:*developer.blender.org/diffusion/B/browse/master/build_files/cmake/platform/platform_win32.cmake$238), while on mac we use [1MB](https:*developer.blender.org/diffusion/B/browse/master/build_files/cmake/platform/platform_apple.cmake$363) and while I agree having such a a large array on the stack is without a doubt bad, and needs fixing, couple of things 1) I see no evidence in either the crash dump produced by @Kent-Davis nor @PratikPB2123 that the large stack allocation in `DebugInfo::graphviz` is a contributing factor to the crash reported in this ticket. 2) The const `COM_EXPORT_GRAPHVIZ` is by default `false`, in which case the compiler will do the right thing, eliminate all dead code and generate the following code for `DebugInfo::graphviz` ``` 0000000000000490 <blender::compositor::DebugInfo::graphviz(blender::compositor::ExecutionSystem const*, blender::StringRefNull)>: 490: f3 0f 1e fa endbr64 494: c3 ret ``` No large stack allocation, actually no real code at all, which leads me to the conclusion while the bug you found while investigating #94230 is annoying, [D13628](https://archive.blender.org/developer/D13628) is not a fix for #94230 (but a nice find nonetheless) best to ignore this distraction for the remainder of this ticket, I will land [D13628](https://archive.blender.org/developer/D13628) though.

Michael commented

2021-12-22 19:16:12 +01:00

Hi @LazyDodo, in P2679 you have the full dump of the crash.
I compiled a lite build with '#define DEG_DEBUG_COW_POINTERS' enabled.
I also added the file and line information to the remapping log messages to see the two different ways the remapping is called.
Starting from the end of the paste maybe the situation is clear to some developer.
Feel free to mention a developer who knows these parts of the code well, I am gonna dig in deeper as well.

Hi @LazyDodo, in [P2679](https://archive.blender.org/developer/P2679.txt) you have the full dump of the crash. I compiled a lite build with '#define DEG_DEBUG_COW_POINTERS' enabled. I also added the file and line information to the remapping log messages to see the two different ways the remapping is called. Starting from the end of the paste maybe the situation is clear to some developer. Feel free to mention a developer who knows these parts of the code well, I am gonna dig in deeper as well.

Kent Davis commented

2021-12-22 19:57:49 +01:00

@michael64
I am really proud of you awesome about MacOS 12.1 and 12.2 Beta (21D5025f) too.
I do agree with you.

@michael64 I am really proud of you awesome about MacOS 12.1 and 12.2 Beta (21D5025f) too. I do agree with you.

Michael commented

2021-12-28 13:37:59 +01:00

Added subscriber: @ideasman42

Michael commented

2021-12-28 13:37:59 +01:00

This crash can be easily reproduced without the scene file as follows:

Have the standard default cube scene with the default cube selected
Go to material preview
Enter edit mode
Press F12 to render
If Blender did not crash at this point click in the 3d viewport and rotate the cube if necessary
Blender should now have crashed.

This bug was introduces in aa6f0f3d1f and is still present in the latest revision.
In P2685 you find a small patch so that the crash can be easily investigated without using the AddressSanitizer.
If you'd run the latest master with the P2685 applied you'd see the following output when you follow the 5 steps above (abbreviated):

Create shallow copy for MAMaterial: id_orig=0x117074a38 id_cow=0x167b37288
...
Expanding datablock for MECube: id_orig=0x11690ee08 id_cow=0x117cc3208
  Remapping ID links for MECube: id_orig=0x11690ee08 id_cow=0x117cc3208
    Remapping datablock for MAMaterial: id_orig=0x117074a38 id_cow=0x167b37288
Expanding datablock for MAMaterial: id_orig=0x117074a38 id_cow=0x167b37288
  Remapping ID links for NTShader Nodetree: id_orig=0x117073768 id_cow=0x167b3ea98
  Remapping ID links for MAMaterial: id_orig=0x117074a38 id_cow=0x167b37288
    Remapping datablock for NTShader Nodetree: id_orig=0x117074ba8 id_cow=0x167b38148
    Remapping datablock for NTShader Nodetree: id_orig=0x167b38148 id_cow=0x167b38148
  Remapping ID links for OBCube: id_orig=0x1168d0608 id_cow=0x117cb8008
    Remapping datablock for MECube: id_orig=0x11690ee08 id_cow=0x117cc3208
...
Destroy CoW for MAMaterial: id_orig=0x117074a38 id_cow=0x0
...
Found a material that was registered as deallocated: 0x167b37288, exiting...
[1]    78502 abort

The crash happens in the following line in eevee_materials.c with ma==0x167b37288 being the id_cow that was deallocated so ma is a dangling pointer:

    switch (ma->blend_method) {

When not using AddressSanitizer the crash might also happen a little later when the code is running operations on previously-but-no-more defined memory.
Immediately before the crash get_evaluated_object_data_with_materials is called and the ID data is taken from the edit mesh because we are in edit mode and that is where the dangling pointer comes from.

The "Destroy CoW for MAMaterial" was triggered by the blender::deg::Depsgraph::~Depsgraph machinery that was called by render_pipeline_free on the render thread while the crash happens on the main but this is not a race-condition but simply a use-after-free error.

In my opinion somewhere near ~Depsgraph the edit_mesh needs to cleared of dangling pointers after the "Destroy CoW" but I cannot offer a good solution here.
Instead I'd like to ask @ideasman42 to take a look at this for a proper fix.

This crash can be easily reproduced without the scene file as follows: 1) Have the standard default cube scene with the default cube selected 2) Go to material preview 3) Enter edit mode 4) Press F12 to render 5) If Blender did not crash at this point click in the 3d viewport and rotate the cube if necessary Blender should now have crashed. This bug was introduces in aa6f0f3d1f and is still present in the latest revision. In [P2685](https://archive.blender.org/developer/P2685.txt) you find a small patch so that the crash can be easily investigated without using the AddressSanitizer. If you'd run the latest master with the [P2685](https://archive.blender.org/developer/P2685.txt) applied you'd see the following output when you follow the 5 steps above (abbreviated): ``` Create shallow copy for MAMaterial: id_orig=0x117074a38 id_cow=0x167b37288 ... Expanding datablock for MECube: id_orig=0x11690ee08 id_cow=0x117cc3208 Remapping ID links for MECube: id_orig=0x11690ee08 id_cow=0x117cc3208 Remapping datablock for MAMaterial: id_orig=0x117074a38 id_cow=0x167b37288 Expanding datablock for MAMaterial: id_orig=0x117074a38 id_cow=0x167b37288 Remapping ID links for NTShader Nodetree: id_orig=0x117073768 id_cow=0x167b3ea98 Remapping ID links for MAMaterial: id_orig=0x117074a38 id_cow=0x167b37288 Remapping datablock for NTShader Nodetree: id_orig=0x117074ba8 id_cow=0x167b38148 Remapping datablock for NTShader Nodetree: id_orig=0x167b38148 id_cow=0x167b38148 Remapping ID links for OBCube: id_orig=0x1168d0608 id_cow=0x117cb8008 Remapping datablock for MECube: id_orig=0x11690ee08 id_cow=0x117cc3208 ... Destroy CoW for MAMaterial: id_orig=0x117074a38 id_cow=0x0 ... Found a material that was registered as deallocated: 0x167b37288, exiting... [1] 78502 abort ``` The crash happens in the following line in eevee_materials.c with ma==0x167b37288 being the id_cow that was deallocated so ma is a dangling pointer: ``` switch (ma->blend_method) { ``` When not using AddressSanitizer the crash might also happen a little later when the code is running operations on previously-but-no-more defined memory. Immediately before the crash get_evaluated_object_data_with_materials is called and the ID data is taken from the edit mesh because we are in edit mode and that is where the dangling pointer comes from. The "Destroy CoW for MAMaterial" was triggered by the blender::deg::Depsgraph::~Depsgraph machinery that was called by render_pipeline_free on the render thread while the crash happens on the main but this is not a race-condition but simply a use-after-free error. In my opinion somewhere near ~Depsgraph the edit_mesh needs to cleared of dangling pointers after the "Destroy CoW" but I cannot offer a good solution here. Instead I'd like to ask @ideasman42 to take a look at this for a proper fix.

RJ Silk commented

2022-01-08 02:08:32 +01:00

Added subscriber: @rjsilk

Campbell Barton self-assigned this 2022-01-10 11:17:07 +01:00

Campbell Barton changed title from ~~Compositor crash~~ to Crash rendering with EEVEE in mesh edit-mode

2022-01-12 06:09:24 +01:00

Germano Cavalcante commented

2022-01-20 18:02:44 +01:00

Added subscribers: @mano-wii, @ankitm

Brecht Van Lommel commented

2022-02-28 17:46:43 +01:00

Added subscriber: @brecht

Brecht Van Lommel commented

2022-02-28 17:46:43 +01:00

Is this solved by {D13824}?

Is this solved by {[D13824](https://archive.blender.org/developer/D13824)}?

Kent Davis commented

2022-02-28 18:01:40 +01:00

Now I am use Blender 3.2.0 Alpha.

Sergey Sharybin commented

2022-03-01 15:12:19 +01:00

Added subscriber: @Sergey

Sergey Sharybin commented

2022-03-01 15:12:19 +01:00

Changed status from 'Confirmed' to: 'Resolved'

Sergey Sharybin closed this issue

2022-03-01 15:12:19 +01:00

Sergey Sharybin commented

2022-03-01 15:12:19 +01:00

Ive tested this bug with 0f89bcdbeb and it does not happen, but it happens with the revision right prior to that. Quite sure the issue got fixed by the D13824.

Ive tested this bug with 0f89bcdbebf and it does not happen, but it happens with the revision right prior to that. Quite sure the issue got fixed by the [D13824](https://archive.blender.org/developer/D13824).

Kent Davis commented

2022-03-02 00:53:10 +01:00

Thanks @everyone

Thomas Dinges added this to the 3.1 milestone 2023-02-08 15:53:05 +01: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 rendering with EEVEE in mesh edit-mode #94230