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: rB77d23b0bd76f

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?).

checking...

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

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).

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 T76277#931477, @Jeroen Bakker (jbakker) 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 T76277#921461, @Philipp Oeser (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 rB236794d07a70 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

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

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

@Jeroen Bakker (jbakker) I can only reproduce it in master, not in 2.83

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

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 (jbakker) 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.

rBdc4983dfdddc49ffd0945b8eed4778b120155d37 (from 13 minutes ago) crashes again.

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

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

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.

@Jeroen Bakker (jbakker) I can confirm that using @Alaska (Alaska)'s steps above, that I can crash blender-v2.83-release rB71298a1da971. 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 rB71298a1da971 to crash with the rendering step included. I estimate that I tried 4 or 5 times. However, rBce76e17584ee (May 9th) crashed 4 out of 5 tries. Until I saw @Alaska (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 rB71298a1da971 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:

@Evan Wilson (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.

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: rB78e3b7c28d85

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.

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.

@Jeroen Bakker (jbakker) 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.

Bisecting showed my this commit that made ASAN compiles fail on the assert above. rBe7acf17b7458: Nodes: Add emitters, events, forces and control flow socket types

@Jacques Lucke (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

@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 @Robert Guetzkow (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.

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

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

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