Enabling Viewer Border in Compositor Crashes Blender #76277

New Issue

Emir Sinan Gürlek · 2020-04-30T20:55:51+02:00

2020-04-30 20:55:51 +02:00

System Information
Operating system: Windows-10 64 Bits
Graphics card: GeForce GTX 1070 442.74

Blender Version
Broken: version: 2.83 (sub 15), branch: master, commit date: 2020-04-26 22:51, hash: d0d16eb7d3
Working: 2.82a at least. didn't test in between.

Short description of error
Enabling "Viewer Border" under Options>Performance in Compositor Editor type crashes Blender.
Exact steps for others to reproduce the error
1- Launch Blender.
2- Click Compositing workspace tab.
3- Enable Use Nodes.
4- Click Options at the side bar.
5- Enable "Viewer Border" and Blender will crash. (It crashes %90 of the time but not always)

**System Information** Operating system: Windows-10 64 Bits Graphics card: GeForce GTX 1070 442.74 **Blender Version** Broken: version: 2.83 (sub 15), branch: master, commit date: 2020-04-26 22:51, hash: `d0d16eb7d3` Working: 2.82a at least. didn't test in between. **Short description of error** Enabling "Viewer Border" under Options>Performance in Compositor Editor type crashes Blender. **Exact steps for others to reproduce the error** 1- Launch Blender. 2- Click Compositing workspace tab. 3- Enable Use Nodes. 4- Click Options at the side bar. 5- Enable "Viewer Border" and Blender will crash. (It crashes %90 of the time but not always)

Emir Sinan Gürlek commented

2020-04-30 20:55:51 +02:00

Added subscriber: @filibis

Ankit Meel commented

2020-04-30 21:12:51 +02:00

Added subscriber: @ankitm

Ankit Meel commented

2020-04-30 21:12:51 +02:00

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

Ankit Meel commented

2020-04-30 21:12:51 +02:00

Do you happen to have a working version too ?

- 0	 in node_free_node at source/blender/blenkernel/intern/node.c:2115
- 1	 in ntree_free_data at source/blender/blenkernel/intern/node.c:231
- 2	 in ntreeFreeTree at source/blender/blenkernel/intern/node.c:2251
- 3	 in ntreeLocalMerge at source/blender/blenkernel/intern/node.c:2514
- 4	 in compo_freejob at source/blender/editors/space_node/node_edit.c:192
- 5	 in wm_jobs_timer at source/blender/windowmanager/intern/wm_jobs.c:676
- 6	 in wm_window_timer at source/blender/windowmanager/intern/wm_window.c:1618
- 7	 in wm_window_process_events at source/blender/windowmanager/intern/wm_window.c:1656
- 8	 in WM_main at source/blender/windowmanager/intern/wm.c:447
- 9	 in main at source/creator/creator.c:528

Do you happen to have a working version too ? ``` - 0 in node_free_node at source/blender/blenkernel/intern/node.c:2115 - 1 in ntree_free_data at source/blender/blenkernel/intern/node.c:231 - 2 in ntreeFreeTree at source/blender/blenkernel/intern/node.c:2251 - 3 in ntreeLocalMerge at source/blender/blenkernel/intern/node.c:2514 - 4 in compo_freejob at source/blender/editors/space_node/node_edit.c:192 - 5 in wm_jobs_timer at source/blender/windowmanager/intern/wm_jobs.c:676 - 6 in wm_window_timer at source/blender/windowmanager/intern/wm_window.c:1618 - 7 in wm_window_process_events at source/blender/windowmanager/intern/wm_window.c:1656 - 8 in WM_main at source/blender/windowmanager/intern/wm.c:447 - 9 in main at source/creator/creator.c:528 ```

Emir Sinan Gürlek commented

2020-04-30 21:42:41 +02:00

I just tested an it doesn't crash in this version: 2.82 (sub 7), branch: master, commit date: 2020-02-12 16:20, hash: 77d23b0bd7

I just tested an it doesn't crash in this version: 2.82 (sub 7), branch: master, commit date: 2020-02-12 16:20, hash: `77d23b0bd7`

Robert Guetzkow commented

2020-04-30 22:59:29 +02:00

Added subscriber: @rjg

Robert Guetzkow commented

2020-04-30 22:59:29 +02:00

Replacing the "rna_NodeTree_update" with NULL for the use_viewer_border in rna_nodetree.c property avoids the crash. I haven't found the source of the issue yet, that would explain why ntree->typeinfo points to the wrong memory location though (use after free?).

Replacing the `"rna_NodeTree_update"` with `NULL` for the `use_viewer_border` in [rna_nodetree.c ](https://developer.blender.org/diffusion/B/browse/master/source/blender/makesrna/intern/rna_nodetree.c) property avoids the crash. I haven't found the source of the issue yet, that would explain why `ntree->typeinfo` points to the wrong memory location though (use after free?).

Philipp Oeser commented

2020-05-01 10:40:21 +02:00

Added subscriber: @lichtwerk

Philipp Oeser commented

2020-05-01 10:40:21 +02:00

checking...

Philipp Oeser commented

2020-05-01 11:57:46 +02:00

For some reason I cannot get it to crash with a debugger attached (or with ASAN), needs more investigation...

Alaska commented

2020-05-14 03:43:08 +02:00

Added subscriber: @Alaska

Alaska commented

2020-05-14 03:43:08 +02:00

Just adding a comment to say that I've come across this same issue testing with new versions of Blender
Blender 2.83 71298a1da9 (2020-05-13 20:48), Blender 2.90 c8060a78fd (2020-05-13 22:51).

Just adding a comment to say that I've come across this same issue testing with new versions of Blender Blender 2.83 71298a1da971 (2020-05-13 20:48), Blender 2.90 c8060a78fdf3 (2020-05-13 22:51).

Evan Wilson commented

2020-05-14 08:04:33 +02:00

Added subscriber: @EAW

Evan Wilson commented

2020-05-14 08:04:33 +02:00

Changing Priority to High as it is a crash that occurs in 2.83 but not 2.82.

Jeroen Bakker commented

2020-05-14 12:48:54 +02:00

Added subscriber: @Jeroen-Bakker

Jeroen Bakker commented

2020-05-14 14:38:16 +02:00

I am not able to reproduce this one on linux or windows. on b2.83 release branch. Can someone explain how to reproduce this.

Philipp Oeser commented

2020-05-14 15:07:09 +02:00

In #76277#931477, @Jeroen-Bakker wrote:
I am not able to reproduce this one on linux or windows. on b2.83 release branch. Can someone explain how to reproduce this.

In #76277#921461, @lichtwerk wrote:
For some reason I cannot get it to crash with a debugger attached (or with ASAN), needs more investigation...

I can still get it to crash in 236794d07a linux (but only in a debug build without debugger -- with debugger doesnt crash, neither does with ASAN...)

note it then cannot draw the panel anymore for some reason and spits out (if that helps)

rna_uiItemR: property not found: NodeTree.render_quality
build_linux/bin/2.90/scripts/startup/bl_ui/space_node.py:644
rna_uiItemR: property not found: NodeTree.edit_quality
build_linux/bin/2.90/scripts/startup/bl_ui/space_node.py:645
rna_uiItemR: property not found: NodeTree.chunk_size
build_linux/bin/2.90/scripts/startup/bl_ui/space_node.py:646
rna_uiItemR: property not found: NodeTree.use_opencl
build_linux/bin/2.90/scripts/startup/bl_ui/space_node.py:649
rna_uiItemR: property not found: NodeTree.use_groupnode_buffer
build_linux/bin/2.90/scripts/startup/bl_ui/space_node.py:650
rna_uiItemR: property not found: NodeTree.use_two_pass
build_linux/bin/2.90/scripts/startup/bl_ui/space_node.py:651
rna_uiItemR: property not found: NodeTree.use_viewer_border
build_linux/bin/2.90/scripts/startup/bl_ui/space_node.py:652
rna_uiItemR: property not found: NodeTree.render_quality
build_linux/bin/2.90/scripts/startup/bl_ui/space_node.py:644
rna_uiItemR: property not found: NodeTree.edit_quality
build_linux/bin/2.90/scripts/startup/bl_ui/space_node.py:645
rna_uiItemR: property not found: NodeTree.chunk_size
build_linux/bin/2.90/scripts/startup/bl_ui/space_node.py:646
rna_uiItemR: property not found: NodeTree.use_opencl
build_linux/bin/2.90/scripts/startup/bl_ui/space_node.py:649
rna_uiItemR: property not found: NodeTree.use_groupnode_buffer
build_linux/bin/2.90/scripts/startup/bl_ui/space_node.py:650
rna_uiItemR: property not found: NodeTree.use_two_pass
build_linux/bin/2.90/scripts/startup/bl_ui/space_node.py:651
rna_uiItemR: property not found: NodeTree.use_viewer_border
build_linux/bin/2.90/scripts/startup/bl_ui/space_node.py:652

> In #76277#931477, @Jeroen-Bakker wrote: > I am not able to reproduce this one on linux or windows. on b2.83 release branch. Can someone explain how to reproduce this. > In #76277#921461, @lichtwerk wrote: > For some reason I cannot get it to crash with a debugger attached (or with ASAN), needs more investigation... I can still get it to crash in 236794d07a linux (but only in a debug build without debugger -- with debugger doesnt crash, neither does with ASAN...) note it then cannot draw the panel anymore for some reason and spits out (if that helps) ``` rna_uiItemR: property not found: NodeTree.render_quality build_linux/bin/2.90/scripts/startup/bl_ui/space_node.py:644 rna_uiItemR: property not found: NodeTree.edit_quality build_linux/bin/2.90/scripts/startup/bl_ui/space_node.py:645 rna_uiItemR: property not found: NodeTree.chunk_size build_linux/bin/2.90/scripts/startup/bl_ui/space_node.py:646 rna_uiItemR: property not found: NodeTree.use_opencl build_linux/bin/2.90/scripts/startup/bl_ui/space_node.py:649 rna_uiItemR: property not found: NodeTree.use_groupnode_buffer build_linux/bin/2.90/scripts/startup/bl_ui/space_node.py:650 rna_uiItemR: property not found: NodeTree.use_two_pass build_linux/bin/2.90/scripts/startup/bl_ui/space_node.py:651 rna_uiItemR: property not found: NodeTree.use_viewer_border build_linux/bin/2.90/scripts/startup/bl_ui/space_node.py:652 rna_uiItemR: property not found: NodeTree.render_quality build_linux/bin/2.90/scripts/startup/bl_ui/space_node.py:644 rna_uiItemR: property not found: NodeTree.edit_quality build_linux/bin/2.90/scripts/startup/bl_ui/space_node.py:645 rna_uiItemR: property not found: NodeTree.chunk_size build_linux/bin/2.90/scripts/startup/bl_ui/space_node.py:646 rna_uiItemR: property not found: NodeTree.use_opencl build_linux/bin/2.90/scripts/startup/bl_ui/space_node.py:649 rna_uiItemR: property not found: NodeTree.use_groupnode_buffer build_linux/bin/2.90/scripts/startup/bl_ui/space_node.py:650 rna_uiItemR: property not found: NodeTree.use_two_pass build_linux/bin/2.90/scripts/startup/bl_ui/space_node.py:651 rna_uiItemR: property not found: NodeTree.use_viewer_border build_linux/bin/2.90/scripts/startup/bl_ui/space_node.py:652 ```

Dalai Felinto commented

2020-05-14 15:40:34 +02:00

Added subscriber: @dfelinto

Dalai Felinto commented

2020-05-14 15:40:34 +02:00

@Jeroen-Bakker ASAN crash: P1393 (on master - 236794d07a)

@Jeroen-Bakker ASAN crash: [P1393](https://archive.blender.org/developer/P1393.txt) (on master - 236794d07a70)

Robert Guetzkow commented

2020-05-14 15:43:32 +02:00

I can also still reproduce this in 2.90 236794d07a on Windows in debug build.

I can also still reproduce this in 2.90 236794d07a on Windows in debug build.

Dalai Felinto commented

2020-05-14 15:47:57 +02:00

@Jeroen-Bakker I can only reproduce it in master, not in 2.83

Ankit Meel commented

2020-05-14 16:51:29 +02:00

a260d1cd69 is not crashing for me, neither is throwing those rna_uiItemR: property not found: NodeTree.use_opencl in the console.
Just previous build 236794d07a crashes, which is already verified by Robert, Philipp & Dalai.

a260d1cd69 is not crashing for me, neither is throwing those `rna_uiItemR: property not found: NodeTree.use_opencl` in the console. Just previous build 236794d07a crashes, which is already verified by Robert, Philipp & Dalai.

Alaska commented

2020-05-14 16:56:38 +02:00

Just confirming, using Blender 2.83 build 71298a1da9 (2020-05-13 20:48) it still crashes. I will need to test with a newer build. I just don't have time at the moment and the build bot hasn't created a new build.

@Jeroen-Bakker The steps I used to reproduce the crash are as follows:

With the default startup file, open a compositor.
Tick the "Use nodes" button in the top of the compositor.
In the side panel (open with N) select the "Options" tab and enable "Viewer border". Blender should now crash.

Note that creating a viewer border with Ctrl+B does not cause Blender to crash.

Just confirming, using Blender 2.83 build 71298a1da971 (2020-05-13 20:48) it still crashes. I will need to test with a newer build. I just don't have time at the moment and the build bot hasn't created a new build. @Jeroen-Bakker The steps I used to reproduce the crash are as follows: 1. With the default startup file, open a compositor. 2. Tick the "Use nodes" button in the top of the compositor. 3. In the side panel (open with N) select the "Options" tab and enable "Viewer border". Blender should now crash. Note that creating a viewer border with Ctrl+B does not cause Blender to crash.

Ankit Meel commented

2020-05-14 17:02:41 +02:00

dc4983dfdd (from 13 minutes ago) crashes again.

dc4983dfdd (from 13 minutes ago) crashes again.

Alaska commented

2020-05-14 17:21:37 +02:00

Decided to learn how to build Blender (actually quite quick) and my build dc4983dfdd (the same @ankitm just tested) doesn't crash. It's odd.

Decided to learn how to build Blender (actually quite quick) and my build dc4983dfdddc (the same @ankitm just tested) doesn't crash. It's odd.

Dalai Felinto commented

2020-05-14 17:29:19 +02:00

dc4983dfdddc is master, not the blender-v2.83-release branch.

`dc4983dfdddc` is master, not the `blender-v2.83-release` branch.

Robert Guetzkow commented

2020-05-14 17:30:21 +02:00

It seems that the data structure PointerRNA *ptr points to is ~~already broken when calling ~~ wrongly cast inside rna_NodeTree_update. For instance the node retrieved through ptr->data has the cutoff idname "iting Nodetree" instead of "NTCompositing Nodetree" because the address the pointer points to is 0x08 higher than the start of the string.

Edit: The pointer is definitely in the wrong place, since "NTCompositing Nodetree" is not for a node. It should either be "CompositorNodeComposite" or "CompositorNodeRLayers".

The ptr->owner_id and ptr->data are pointing to the same memory address, hence the correct type would be bNodeTree for the cast.

It seems that the data structure `PointerRNA *ptr` points to is ~~already broken when calling ~~ wrongly cast inside `rna_NodeTree_update`. ~~For instance the node retrieved through `ptr->data` has the cutoff `idname` "iting Nodetree" instead of "NTCompositing Nodetree" because the address the pointer points to is 0x08 higher than the start of the string.~~ Edit: The pointer is definitely in the wrong place, since "NTCompositing Nodetree" is not for a node. It should either be "CompositorNodeComposite" or "CompositorNodeRLayers". The `ptr->owner_id` and `ptr->data` are pointing to the same memory address, hence the correct type would be `bNodeTree` for the cast.

Evan Wilson commented

2020-05-14 17:45:13 +02:00

@Jeroen-Bakker I can confirm that using @Alaska's steps above, that I can crash blender-v2.83-release 71298a1da9. However, it doesn't happen every time. For me it crashed on the first, third, and fourth attempt, but not the second. Previously, I had an additional step of rendering.

With the default startup file (via blender_factory_startup.cmd), open the compositor.
Press F12 to render.
Tick the "Use nodes" button in the top of the compositor.
In the side panel (open with N) select the "Options" tab and enable "Viewer border". Blender should now crash.

About 30 to 60 minutes ago, I couldn't get 71298a1da9 to crash with the rendering step included. I estimate that I tried 4 or 5 times. However, ce76e17584 (May 9th) crashed 4 out of 5 tries. Until I saw @Alaska's post above, I thought maybe I was mistaken, and had tested with the May 9 build on accident, before raising the priority to High and tagging 2.83 earlier. Retesting 71298a1da9 just now with the rendering step, it crashed on the second attempt. I am not sure if rendering makes it less likely to crash, or if I was just being a superstitious pigeon.

Note: I am on Windows, so I am starting blender with: blender_factory_startup.cmd

2.83_5.13.2020_71298a1da971_third_try_blender_debug_output.txt

2.83_5.13.2020_71298a1da971_first_try_blender_debug_output.txt

blender_system_info.txt

@Jeroen-Bakker I can confirm that using @Alaska's steps above, that I can crash blender-v2.83-release 71298a1da9. However, it doesn't happen every time. For me it crashed on the first, third, and fourth attempt, but not the second. Previously, I had an additional step of rendering. 1. With the default startup file (via blender_factory_startup.cmd), open the compositor. 2. Press F12 to render. 3. Tick the "Use nodes" button in the top of the compositor. 4. In the side panel (open with N) select the "Options" tab and enable "Viewer border". Blender should now crash. About 30 to 60 minutes ago, I couldn't get 71298a1da9 to crash with the rendering step included. I estimate that I tried 4 or 5 times. However, ce76e17584 (May 9th) crashed 4 out of 5 tries. Until I saw @Alaska's post above, I thought maybe I was mistaken, and had tested with the May 9 build on accident, before raising the priority to High and tagging 2.83 earlier. Retesting 71298a1da9 just now with the rendering step, it crashed on the second attempt. I am not sure if rendering makes it less likely to crash, or if I was just being [a superstitious pigeon](https://en.wikipedia.org/wiki/B._F._Skinner#Superstition_in_the_pigeon). Note: I am on Windows, so I am starting blender with: [blender_factory_startup.cmd](https://archive.blender.org/developer/F8535480/blender_factory_startup.cmd) [2.83_5.13.2020_71298a1da971_third_try_blender_debug_output.txt](https://archive.blender.org/developer/F8535475/2.83_5.13.2020_71298a1da971_third_try_blender_debug_output.txt) [2.83_5.13.2020_71298a1da971_first_try_blender_debug_output.txt](https://archive.blender.org/developer/F8535476/2.83_5.13.2020_71298a1da971_first_try_blender_debug_output.txt) --- [blender_system_info.txt](https://archive.blender.org/developer/F8535482/blender_system_info.txt)

Alaska commented

2020-05-14 17:54:55 +02:00

@EAW When I discovered the issue I tested with a few tests:

Test with render and a viewer node connected then select the "viewer border" button
Test with render (the steps you proposed).
Test with just the compositor, no render (the steps I proposed).

In all three cases, it was consistent in that it would crash the first time everytime.

Note: I may step out of this conversation. It's getting quite late where I am and I don't know enough technical information about Blender to offer anything of use. So my messages will probably just clutter things up.

@EAW When I discovered the issue I tested with a few tests: 1. Test with render and a viewer node connected then select the "viewer border" button 2. Test with render (the steps you proposed). 3. Test with just the compositor, no render (the steps I proposed). In all three cases, it was consistent in that it would crash the first time everytime. Note: I may step out of this conversation. It's getting quite late where I am and I don't know enough technical information about Blender to offer anything of use. So my messages will probably just clutter things up.

Evan Wilson commented

2020-05-14 18:54:27 +02:00

Here is the Windows MSVC debug build call stack when using 2.83 (sub 16), branch: master, commit date: 2020-05-14 14:47, hash: 78e3b7c28d

2.83_May14_2020_78e3b7c28d85_MSVC_Debug_call_stack.txt

Here is the Windows MSVC debug build call stack when using 2.83 (sub 16), branch: master, commit date: 2020-05-14 14:47, hash: 78e3b7c28d [2.83_May14_2020_78e3b7c28d85_MSVC_Debug_call_stack.txt](https://archive.blender.org/developer/F8535706/2.83_May14_2020_78e3b7c28d85_MSVC_Debug_call_stack.txt)

Robert Guetzkow commented

2020-05-14 19:21:13 +02:00

Since ptr->owner_id and ptr->data are pointing to the same memory address, it makes no sense to interpret this as a node, since it's the address of the node tree. Unless there is a need to include a node in the update, this could work as a fix:

diff --git a/source/blender/makesrna/intern/rna_nodetree.c b/source/blender/makesrna/intern/rna_nodetree.c
index 30d1380417f..32999c91fad 100644
--- a/source/blender/makesrna/intern/rna_nodetree.c
+++ b/source/blender/makesrna/intern/rna_nodetree.c
@@ -960,12 +960,11 @@ static bool rna_NodeTree_check(bNodeTree *ntree, ReportList *reports)
 static void rna_NodeTree_update(Main *bmain, Scene *UNUSED(scene), PointerRNA *ptr)
 {
   bNodeTree *ntree = (bNodeTree *)ptr->owner_id;
-  bNode *node = (bNode *)ptr->data;

   WM_main_add_notifier(NC_NODE | NA_EDITED, NULL);
   WM_main_add_notifier(NC_SCENE | ND_NODES, &ntree->id);

-  ED_node_tag_update_nodetree(bmain, ntree, node);
+  ED_node_tag_update_nodetree(bmain, ntree, NULL);
 }

This of course assumes that ptr->owner_id and ptr->data are allowed to be equal. If that's not the case, the actual bug is in the assignment of these pointers.

Since `ptr->owner_id` and `ptr->data` are pointing to the same memory address, it makes no sense to interpret this as a node, since it's the address of the node tree. Unless there is a need to include a node in the update, this could work as a fix: ``` diff --git a/source/blender/makesrna/intern/rna_nodetree.c b/source/blender/makesrna/intern/rna_nodetree.c index 30d1380417f..32999c91fad 100644 --- a/source/blender/makesrna/intern/rna_nodetree.c +++ b/source/blender/makesrna/intern/rna_nodetree.c @@ -960,12 +960,11 @@ static bool rna_NodeTree_check(bNodeTree *ntree, ReportList *reports) static void rna_NodeTree_update(Main *bmain, Scene *UNUSED(scene), PointerRNA *ptr) { bNodeTree *ntree = (bNodeTree *)ptr->owner_id; - bNode *node = (bNode *)ptr->data; WM_main_add_notifier(NC_NODE | NA_EDITED, NULL); WM_main_add_notifier(NC_SCENE | ND_NODES, &ntree->id); - ED_node_tag_update_nodetree(bmain, ntree, node); + ED_node_tag_update_nodetree(bmain, ntree, NULL); } ``` This of course assumes that `ptr->owner_id` and `ptr->data` are allowed to be equal. If that's not the case, the actual bug is in the assignment of these pointers.

Jeroen Bakker commented

2020-05-15 08:50:18 +02:00

Thank you all for your input but I was able to reproduce it (but only on master on linux). I tried multiple machines, os, compilers. I will try to find a fix for master and backport it to blender-v2.83-release. branch.

==51109==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x616000012938 at pc 0x000002ab114a bp 0x7fffffffd970 sp 0x7fffffffd960
READ of size 8 at 0x616000012938 thread T0
    - 0 0x2ab1149 in ntreeLocalize /home/jeroen/blender-git/blender/source/blender/blenkernel/intern/node.c:2549
    - 1 0x727d4fe in compo_initjob /home/jeroen/blender-git/blender/source/blender/editors/space_node/node_edit.c:220
    - 2 0x3aafd6b in WM_jobs_start /home/jeroen/blender-git/blender/source/blender/windowmanager/intern/wm_jobs.c:479
    - 3 0x727e93e in ED_node_composite_job /home/jeroen/blender-git/blender/source/blender/editors/space_node/node_edit.c:346
    - 4 0x72d758f in node_area_refresh /home/jeroen/blender-git/blender/source/blender/editors/space_node/space_node.c:525
    - 5 0x578fb23 in ED_area_do_refresh /home/jeroen/blender-git/blender/source/blender/editors/screen/area.c:182
    - 6 0x3a4c261 in wm_event_do_refresh_wm_and_depsgraph /home/jeroen/blender-git/blender/source/blender/windowmanager/intern/wm_event_system.c:380
    - 7 0x3a4e26f in wm_event_do_notifiers /home/jeroen/blender-git/blender/source/blender/windowmanager/intern/wm_event_system.c:549
    - 8 0x3a39e2f in WM_main /home/jeroen/blender-git/blender/source/blender/windowmanager/intern/wm.c:453
    - 9 0x2684583 in main /home/jeroen/blender-git/blender/source/creator/creator.c:528
    - 10 0x7ffff6e3e0b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x270b2)
    - 11 0x26836fd in _start (/home/jeroen/blender-git/build_linux/bin/blender+0x26836fd)

0x616000012938 is located 72 bytes to the left of 520-byte region [0x616000012980,0x616000012b88)
allocated by thread T0 here:
    - 0 0x7ffff7685dc6 in calloc (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x10ddc6)
    - 1 0xd6e0c61 in MEM_lockfree_callocN /home/jeroen/blender-git/blender/intern/guardedalloc/intern/mallocn_lockfree_impl.c:267
    - 2 0x9c971ca in register_node_tree_type_sh /home/jeroen/blender-git/blender/source/blender/nodes/shader/node_shader_tree.c:191
    - 3 0x2ae4cd3 in init_nodesystem /home/jeroen/blender-git/blender/source/blender/blenkernel/intern/node.c:4333
    - 4 0x26841f9 in main /home/jeroen/blender-git/blender/source/creator/creator.c:416
    - 5 0x7ffff6e3e0b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x270b2)

Something that is curious is that the tree type is set to an unallocated memory with faulty memory pointers. This happens during the first and second compositor job.

diff --git a/source/blender/editors/space_node/space_node.c b/source/blender/editors/space_node/space_node.c
index 9df04c097bb..f792107d781 100644
--- a/source/blender/editors/space_node/space_node.c
+++ b/source/blender/editors/space_node/space_node.c
@@ -514,6 +514,7 @@ static void node_area_refresh(const struct bContext *C, ScrArea *area)
       }
     }
     else if (snode->nodetree->type == NTREE_COMPOSIT) {
+      BLI_assert(snode->nodetree->type == snode->nodetree->typeinfo->type);
       Scene *scene = (Scene *)snode->id;
       if (scene->use_nodes) {
         /* recalc is set on 3d view changes for auto compo */

fails for me in master, but is successful in blender-v2.83-release. but it is successful in master when not built with ASAN.

Thank you all for your input but I was able to reproduce it (but only on master on linux). I tried multiple machines, os, compilers. I will try to find a fix for master and backport it to blender-v2.83-release. branch. ``` ==51109==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x616000012938 at pc 0x000002ab114a bp 0x7fffffffd970 sp 0x7fffffffd960 READ of size 8 at 0x616000012938 thread T0 - 0 0x2ab1149 in ntreeLocalize /home/jeroen/blender-git/blender/source/blender/blenkernel/intern/node.c:2549 - 1 0x727d4fe in compo_initjob /home/jeroen/blender-git/blender/source/blender/editors/space_node/node_edit.c:220 - 2 0x3aafd6b in WM_jobs_start /home/jeroen/blender-git/blender/source/blender/windowmanager/intern/wm_jobs.c:479 - 3 0x727e93e in ED_node_composite_job /home/jeroen/blender-git/blender/source/blender/editors/space_node/node_edit.c:346 - 4 0x72d758f in node_area_refresh /home/jeroen/blender-git/blender/source/blender/editors/space_node/space_node.c:525 - 5 0x578fb23 in ED_area_do_refresh /home/jeroen/blender-git/blender/source/blender/editors/screen/area.c:182 - 6 0x3a4c261 in wm_event_do_refresh_wm_and_depsgraph /home/jeroen/blender-git/blender/source/blender/windowmanager/intern/wm_event_system.c:380 - 7 0x3a4e26f in wm_event_do_notifiers /home/jeroen/blender-git/blender/source/blender/windowmanager/intern/wm_event_system.c:549 - 8 0x3a39e2f in WM_main /home/jeroen/blender-git/blender/source/blender/windowmanager/intern/wm.c:453 - 9 0x2684583 in main /home/jeroen/blender-git/blender/source/creator/creator.c:528 - 10 0x7ffff6e3e0b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x270b2) - 11 0x26836fd in _start (/home/jeroen/blender-git/build_linux/bin/blender+0x26836fd) 0x616000012938 is located 72 bytes to the left of 520-byte region [0x616000012980,0x616000012b88) allocated by thread T0 here: - 0 0x7ffff7685dc6 in calloc (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x10ddc6) - 1 0xd6e0c61 in MEM_lockfree_callocN /home/jeroen/blender-git/blender/intern/guardedalloc/intern/mallocn_lockfree_impl.c:267 - 2 0x9c971ca in register_node_tree_type_sh /home/jeroen/blender-git/blender/source/blender/nodes/shader/node_shader_tree.c:191 - 3 0x2ae4cd3 in init_nodesystem /home/jeroen/blender-git/blender/source/blender/blenkernel/intern/node.c:4333 - 4 0x26841f9 in main /home/jeroen/blender-git/blender/source/creator/creator.c:416 - 5 0x7ffff6e3e0b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x270b2) ``` Something that is curious is that the tree type is set to an unallocated memory with faulty memory pointers. This happens during the first and second compositor job. ``` diff --git a/source/blender/editors/space_node/space_node.c b/source/blender/editors/space_node/space_node.c index 9df04c097bb..f792107d781 100644 --- a/source/blender/editors/space_node/space_node.c +++ b/source/blender/editors/space_node/space_node.c @@ -514,6 +514,7 @@ static void node_area_refresh(const struct bContext *C, ScrArea *area) } } else if (snode->nodetree->type == NTREE_COMPOSIT) { + BLI_assert(snode->nodetree->type == snode->nodetree->typeinfo->type); Scene *scene = (Scene *)snode->id; if (scene->use_nodes) { /* recalc is set on 3d view changes for auto compo */ ``` fails for me in master, but is successful in blender-v2.83-release. but it is successful in master when not built with ASAN.

Alaska commented

2020-05-15 09:14:36 +02:00

@Jeroen-Bakker Thank you for looking into this. When the patch becomes available, I will happily test the 2.83 branch to see if the issue persists.

Jeroen Bakker commented

2020-05-15 12:27:12 +02:00

Bisecting showed my this commit that made ASAN compiles fail on the assert above. e7acf17b74

@JacquesLucke Mind joining the discussion? I don't see anything wrong with the commit.

git bisect start
# bad: [191c562f98ed8c12d505c1c625b577628ef9a804] Merge branch 'blender-v2.83-release'
git bisect bad 191c562f98ed8c12d505c1c625b577628ef9a804
# good: [44b9f6a8885bed381e0b86bec378008490a58511] Fix T74881: Plane-track corner drag fails with LMB select
git bisect good 44b9f6a8885bed381e0b86bec378008490a58511
# good: [44b9f6a8885bed381e0b86bec378008490a58511] Fix T74881: Plane-track corner drag fails with LMB select
git bisect good 44b9f6a8885bed381e0b86bec378008490a58511
# bad: [1960b8a361eedf2f1717e8525c54de21d6ac7d82] UI: Fix animating panels after drag changing region size
git bisect bad 1960b8a361eedf2f1717e8525c54de21d6ac7d82
# bad: [912ac457a68ff9ee919a5ff67acc9a11a78b368e] Merge branch 'blender-v2.83-release'
git bisect bad 912ac457a68ff9ee919a5ff67acc9a11a78b368e
# good: [59d7fbb052bcb7949420fb9ad694d8e69992c846] Merge branch 'blender-v2.83-release'
git bisect good 59d7fbb052bcb7949420fb9ad694d8e69992c846
# bad: [31357913950968c81b704f0169a91ee293984bf8] Tracking: Specify image image for (un)distortion model
git bisect bad 31357913950968c81b704f0169a91ee293984bf8
# good: [251234ad4360632d4fd0f0570ce498fa183cc98f] Merge branch 'blender-v2.83-release'
git bisect good 251234ad4360632d4fd0f0570ce498fa183cc98f
# good: [0247ee5f5362632eb3e48ccb4c7d7fe33040360a] Simulations: Add simulation node tree type
git bisect good 0247ee5f5362632eb3e48ccb4c7d7fe33040360a
# bad: [9f7bea6e83966dbe4e8393bd6ec811f9c54da178] Simulations: UI for core particle nodes
git bisect bad 9f7bea6e83966dbe4e8393bd6ec811f9c54da178
# good: [1b01d10998807b0f0e7276341f8fda0b32df0c7b] Cleanup: typo
git bisect good 1b01d10998807b0f0e7276341f8fda0b32df0c7b
# good: [2b2d3c14fe1a29da0ec01198cec2c0593c38391a] Simulations: Embed simulation node tree in simulation data block
git bisect good 2b2d3c14fe1a29da0ec01198cec2c0593c38391a
# bad: [e7acf17b74582c0938a363805ebe4eb6ffec4a21] Nodes: Add emitters, events, forces and control flow socket types
git bisect bad e7acf17b74582c0938a363805ebe4eb6ffec4a21
# good: [8759813abd9f95daec7adf55e79e8a8adaf19974] Nodes: New Object and Image socket types
git bisect good 8759813abd9f95daec7adf55e79e8a8adaf19974
# first bad commit: [e7acf17b74582c0938a363805ebe4eb6ffec4a21] Nodes: Add emitters, events, forces and control flow socket types

Bisecting showed my this commit that made ASAN compiles fail on the assert above. e7acf17b74 @JacquesLucke Mind joining the discussion? I don't see anything wrong with the commit. ``` git bisect start # bad: [191c562f98ed8c12d505c1c625b577628ef9a804] Merge branch 'blender-v2.83-release' git bisect bad 191c562f98ed8c12d505c1c625b577628ef9a804 # good: [44b9f6a8885bed381e0b86bec378008490a58511] Fix T74881: Plane-track corner drag fails with LMB select git bisect good 44b9f6a8885bed381e0b86bec378008490a58511 # good: [44b9f6a8885bed381e0b86bec378008490a58511] Fix T74881: Plane-track corner drag fails with LMB select git bisect good 44b9f6a8885bed381e0b86bec378008490a58511 # bad: [1960b8a361eedf2f1717e8525c54de21d6ac7d82] UI: Fix animating panels after drag changing region size git bisect bad 1960b8a361eedf2f1717e8525c54de21d6ac7d82 # bad: [912ac457a68ff9ee919a5ff67acc9a11a78b368e] Merge branch 'blender-v2.83-release' git bisect bad 912ac457a68ff9ee919a5ff67acc9a11a78b368e # good: [59d7fbb052bcb7949420fb9ad694d8e69992c846] Merge branch 'blender-v2.83-release' git bisect good 59d7fbb052bcb7949420fb9ad694d8e69992c846 # bad: [31357913950968c81b704f0169a91ee293984bf8] Tracking: Specify image image for (un)distortion model git bisect bad 31357913950968c81b704f0169a91ee293984bf8 # good: [251234ad4360632d4fd0f0570ce498fa183cc98f] Merge branch 'blender-v2.83-release' git bisect good 251234ad4360632d4fd0f0570ce498fa183cc98f # good: [0247ee5f5362632eb3e48ccb4c7d7fe33040360a] Simulations: Add simulation node tree type git bisect good 0247ee5f5362632eb3e48ccb4c7d7fe33040360a # bad: [9f7bea6e83966dbe4e8393bd6ec811f9c54da178] Simulations: UI for core particle nodes git bisect bad 9f7bea6e83966dbe4e8393bd6ec811f9c54da178 # good: [1b01d10998807b0f0e7276341f8fda0b32df0c7b] Cleanup: typo git bisect good 1b01d10998807b0f0e7276341f8fda0b32df0c7b # good: [2b2d3c14fe1a29da0ec01198cec2c0593c38391a] Simulations: Embed simulation node tree in simulation data block git bisect good 2b2d3c14fe1a29da0ec01198cec2c0593c38391a # bad: [e7acf17b74582c0938a363805ebe4eb6ffec4a21] Nodes: Add emitters, events, forces and control flow socket types git bisect bad e7acf17b74582c0938a363805ebe4eb6ffec4a21 # good: [8759813abd9f95daec7adf55e79e8a8adaf19974] Nodes: New Object and Image socket types git bisect good 8759813abd9f95daec7adf55e79e8a8adaf19974 # first bad commit: [e7acf17b74582c0938a363805ebe4eb6ffec4a21] Nodes: Add emitters, events, forces and control flow socket types ```

Jeroen Bakker commented

2020-05-15 12:27:55 +02:00

Added subscriber: @JacquesLucke

Sergey Sharybin commented

2020-05-15 17:07:28 +02:00

Added subscriber: @Sergey

Sergey Sharybin commented

2020-05-15 17:07:28 +02:00

@jbackker, the bisect and different branch is a red herring here. Is just memory allocations, memory placement and things like that are different, and hence memory corruption is less of more likely to happen.

Long story short: the conclusion and patch from @rjg are correct here.

More detailed explanation:
PointerRNA::owner_id points to an ID which owns changed property, so this is node tree in this case. The PointerRNA::data points to a structure which property did change. For example, if you click on node setting it will point to node, if you click on tree setting it will point to tree. So far so good.

The rna_NodeTree_update is used by use_viewer_border, which is a property of node tree, so the PointerRNA::data will be the tree and can not be cast to node (well, it can, as the code shows, but that doesn't make it correct :).

But why the crash happens? Well, this is because the node passed to ED_node_tag_update_nodetree is being checked for connection to output. This involves setting node's flag, so when one passes node tree as a node it will become corrupted.

This callback RNA function is used in a single place, and we do want re-composite in the property change anyway. So to me it seems totally safe for 2.83.

@rjg, please go ahead and commit your patch (the one from #76277#931809)

P.S. This is a mistake in 83824947ba, which makes it 4 years old.

@jbackker, the bisect and different branch is a red herring here. Is just memory allocations, memory placement and things like that are different, and hence memory corruption is less of more likely to happen. Long story short: the conclusion and patch from @rjg are correct here. More detailed explanation: `PointerRNA::owner_id` points to an ID which owns changed property, so this is node tree in this case. The `PointerRNA::data` points to a structure which property did change. For example, if you click on node setting it will point to node, if you click on tree setting it will point to tree. So far so good. The `rna_NodeTree_update` is used by `use_viewer_border`, which is a property of node tree, so the `PointerRNA::data` will be the tree and can not be cast to node (well, it can, as the code shows, but that doesn't make it correct :). But why the crash happens? Well, this is because the node passed to `ED_node_tag_update_nodetree` is being checked for connection to output. This involves setting node's flag, so when one passes node tree as a node it will become corrupted. This callback RNA function is used in a single place, and we do want re-composite in the property change anyway. So to me it seems totally safe for 2.83. @rjg, please go ahead and commit your patch (the one from #76277#931809) P.S. This is a mistake in 83824947ba, which makes it 4 years old.

blender-admin commented

2020-05-15 18:17:38 +02:00

This issue was referenced by 001d70eb2b

This issue was referenced by 001d70eb2bfe94a48de6d104f9cc21de112d6ebe

Robert Guetzkow commented

2020-05-15 18:37:55 +02:00

Changed status from 'Confirmed' to: 'Resolved'

Robert Guetzkow closed this issue

2020-05-15 18:37:55 +02:00

Robert Guetzkow self-assigned this 2020-05-15 18:37:55 +02:00

Alaska commented

2020-05-16 00:31:21 +02:00

@rjg Testing with the latest 2.83 nightly build and can confirm your fix has worked.

Thomas Dinges added this to the 2.83 LTS milestone 2023-02-08 16:35:48 +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

Enabling Viewer Border in Compositor Crashes Blender #76277