Good, closing as archived then :)

With asan enabled this produces the following output:

=================================================================
==123600==ERROR: AddressSanitizer: heap-use-after-free on address 0x6030004a7288 at pc 0x000003ce2fdb bp 0x7fffffffd170 sp 0x7fffffffd160
READ of size 8 at 0x6030004a7288 thread T0
    #0 0x3ce2fda in BKE_ptcache_id_from_softbody /.../blender/source/blender/blenkernel/intern/pointcache.c:883
    #1 0x3ce978f in foreach_object_ptcache /.../blender/source/blender/blenkernel/intern/pointcache.c:1218
    #2 0x3cea1eb in BKE_ptcache_ids_from_object /.../blender/source/blender/blenkernel/intern/pointcache.c:1274
    #3 0x98d67c2 in timeline_draw_cache /.../blender/source/blender/editors/space_action/action_draw.c:555
    #4 0x98c0652 in action_main_region_draw /.../blender/source/blender/editors/space_action/space_action.c:221
    #5 0x7c1103b in ED_region_do_draw /.../blender/source/blender/editors/screen/area.c:558
    #6 0x521a89c in wm_draw_window_offscreen /.../blender/source/blender/windowmanager/intern/wm_draw.c:724
    #7 0x521bab0 in wm_draw_window /.../blender/source/blender/windowmanager/intern/wm_draw.c:864
    #8 0x521cf1f in wm_draw_update /.../blender/source/blender/windowmanager/intern/wm_draw.c:1065
    #9 0x520d0eb in WM_main /.../blender/source/blender/windowmanager/intern/wm.c:652
    #10 0x367a449 in main /.../blender/source/creator/creator.c:520
    #11 0x7ffff6e48cb1 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x28cb1)
    #12 0x36795fd in _start (/.../build_linux_debug/bin/blender+0x36795fd)

I can confirm this on the latest 2.93.0 Alpha, branch: master, commit date: 2021-03-31 15:10, hash: rB4fd7b1f3db34.

Please consider implementing my proposal:
https://devtalk.blender.org/t/variation-system-my-proposal-based-on-current-asset-browser

Can't wait for more thumbnails for node groups. Or custom thumbnails!

In T86297#1124960, @Roger B (rboxman) wrote:

That build, from the asset-browser-branch, is no longer supported. Please use a recent 2.93 alpha build going forward and enable the Asset Browser in the Experimental user preferences. I can not reproduce your issue in any recent build.

That build, from the asset-browser-branch, is no longer supported. Please use a recent 2.93 alpha build going forward and enable the Asset Browser in the Experimental user preferences. I can not reproduce your issue in any recent build.

Will asset manager support custom node tree data blocks so such add-ons as animation nodes or sverchok could use to save some node trees?

The dependency graph is fully rebuilt on changes. Evaluated datablocks are either reused, or discarded if they end up unused after the rebuild.

In T84397#1090855, @Brecht Van Lommel (brecht) wrote:

@Julian Eisel (Severin), I expect the depsgraph can use session UUIDs as key values for id_info_hash_ and any similar maps directly, without the need to maintain an additional map.

What happens on ID deletion, do we rebuild the depsgraph or remove the nodes to be deleted? If it's the latter I guess the ID should be removed from id_info_hash_?
I assumed the IDInfo.id_cow could be an issue over undos, but didn't look into it much and trust your judgement there.
Anyway, if using session_uuid solves the issue: yay!

I will also first try to make depsgraph use those session uuids first, this looks like the most obvious solution indeed.

@Julian Eisel (Severin), I expect the depsgraph can use session UUIDs as key values for id_info_hash_ and any similar maps directly, without the need to maintain an additional map.

In T84397#1089432, @Campbell Barton (campbellbarton) wrote:

When creating many ID's, an Object ID (in my case) is getting allocated at the address previously used for a mesh, causing the IDNode.id_cow to copy mesh data into an object pointer (hence the buffer overrun in BKE_id_copy_ex).

Great work everybody!

Nice find! That fixes the issue for me as well.

Looked into this bug, the problem is caused by the depsgraph using a Map (DepsgraphNodeBuilder.id_info_hash_) keeping a map of ID to IDInfo data between undo steps.

Alight now that the "where" is known (BKE_id_copy_ex), drawing the issue out of the shadows is rather straight forward,

This likely got fixed with rB691c021679f6. I'm not sure if this is a reliable fix though, it may break again so better keep an eye on it.

@Jacques Lucke (JacquesLucke) I can't reproduce either and I remember it crashed before. Now it seems fixed.

Is this fixed? I don't seem to be able to reproduce it. If it is not fixed, can you provide more precise steps?

some good news some bad news

I tested it and i can confirm your findings.

I tested it and i can confirm your findings.

Yes, rBb852db57ba24: Add experimental global undo speedup., which is not terribly useful in tracking down the origin of the corruption , the issues seem "different" yet somehow connected, this is fun :)

I just noticed that it might be related to rBL62457, which also isn't very useful...
I checked out rB9db4e44961d3ae46b1a9a2dd2ff4c0743e8263f5 + one of the patches below. This compiles with rBL62457 (broken) and rBL62402 (works). Maybe some cmake options have to be disabled if it does not work immediately.
Interestingly, the crash is still caused by subdiv_ccg being invalid, so the crash is very predictable.
Another weird thing is that when P1868 is applied, subdiv_ccg will always be 0x1.
When I apply P1869 instead. subdiv_ccg will always be 0x200200002002.
I don't know how that is possible. But I can reproduce this every time.