couldn't redo on rB5cc7e2ae16d47c58f4a560efaf3a3a35eafe1352
is there a hidden setting I forgot to change for undo ?

I also can not reproduce.

I can still reproduce as of rB9618bd9202a

If it doesn't trigger the first time, can you try running through the steps a second time using the same scene.

Crashed for me on the first try but not the second. Investigating.

Undo 12 Steps (*: active, #=applied, M=memfile-active, S=skip)
[ #  ]   0 {000001EB71D48868} type='Global Undo', name='Original'
[ #  ]   1 {000001EB71D4A368} type='Global Undo', name='Duplicate Objects'
[*#M ]   2 {000001EB71D49D68} type='Global Undo', name='Select'
[    ]   3 {000001EB71D4A128} type='Global Undo', name='Select'
[    ]   4 {000001EB71D49EE8} type='Edit Mesh', name='Toggle Editmode'
[    ]   5 {000001EB676E0FA8} type='Edit Mesh', name='Subdivide'
[    ]   6 {000001EB676DFF28} type='Edit Mesh', name='(De)select All'
[    ]   7 {000001EB676DEDE8} type='Edit Mesh', name='Select Mode'
[    ]   8 {000001EB676DE7E8} type='Edit Mesh', name='Box Select'
[    ]   9 {000001EB676DE668} type='Edit Mesh', name='Extrude Region and Move'
[    ]  10 {000001EB676E05E8} type='Edit Mesh', name='Move'
[    ]  11 {000001EB676DF628} type='Global Undo', name='Toggle Editmode'
INFO (wm.operator): C:\blender-git\blender\source\blender\windowmanager\intern\wm_event_system.c:857 wm_operator_reports: bpy.ops.ed.undo()
Info: Checking sanity of current .blend file *BEFORE* undo step
Info: Checking sanity of current .blend file *AFTER* undo step

INFO (wm.operator): C:\blender-git\blender\source\blender\windowmanager\intern\wm_operators.c:794 WM_operator_last_properties_store: storing properties for 'ED_OT_undo'
Error   : EXCEPTION_ACCESS_VIOLATION
Address : 0x00007FF65B41DA4D
Module  : C:\blender-git\build_windows_x64_vc16_Release\bin\Release\blender.exe

55a2682348df

Operating system: Windows-10-10.0.18362-SP0 64 Bits
Graphics card: GeForce GTX 470/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 376.51

I have been able to reproduce on both a release build and a debug build running in debug mode. It happens when I start up with my default scene using various --debug commands in the CLI, and then load factory defaults from the menu. I haven't gotten it to occur when I use --factory-startup in combination with --debug from the command line.

The assert was added by @Campbell Barton (campbellbarton) back in 2013. rBfbb446dff620

only checked for in debug mode

@Richard Antalik (ISS) @Ankit Meel (ankitm) are you running in debug mode, and are you using factory startup?

In T75919#914498, @Evan Wilson (EAW) wrote:

I have been able to reproduce on both a release build and a debug build running in debug mode. It happens when I start up with my default scene using various --debug commands in the CLI, and then load factory defaults from the menu. I haven't gotten it to occur when I use --factory-startup in combination with --debug from the command line.

The assert was added by @Campbell Barton (campbellbarton) back in 2013. rBfbb446dff620

only checked for in debug mode

@Richard Antalik (ISS) @Ankit Meel (ankitm) are you running in debug mode, and are you using factory startup?

I probable wasn't able to reproduce, because I haven't run with any --debug argument.

are you running in debug mode, and are you using factory startup?

earlier no, now I tried that. but couldn't redo. --debug-io

can you try running through the steps a second time using the same scene.

Then did this, to get three cubes, couldn't redo.

then did some cycles of cmd + Z to get original scene and then cmd + shift + z to get final scene. After some such cycles, got the trace as in the report.

Very hard to reproduce for me, even more in debug builds... This is related to adding/removing objects, for some reasons once in a while 'things' get corrupted in the Object/Collection area. It can then trigger that assert or not, or crash in the collection update code, or in CoW code in depsgraph, or...

Managed to get it crash with -t 1 so don't think this is a threading issue.

I haven't been able to reproduce this problem, so this is just speculation.

From the backtrace and steps to redo, I think somehow we end up in a situation where two bases point to the same object, which triggers the ghash assert. This seems at least not caused by depsgraph or recalc flags, as the collection sync has the problem on original data.

I would guess that somehow fd->libmap ends up mapping two different pointers to the same object. This would mean either the wrong object is found by undo restore (duplicate session ID, some issue in old_idmap, ..). Or there is something wrong with the way we construct or use fd->libmap.

What I still find odd in the undo restore code is putting the current ID pointer in there. Maybe this can end up being the same as another bhead->old value? Things still seem to work correctly without it, and I'm not sure why it is needed.

So for those who can reproduce, it would be good if this patch can be tested. Even if it's wrong it might give a clue.

--- a/source/blender/blenloader/intern/readfile.c
+++ b/source/blender/blenloader/intern/readfile.c
@@ -9713,9 +9713,8 @@ static bool read_libblock_undo_restore(
     read_libblock_undo_restore_identical(fd, main, id, id_old, id_tag);
 
     /* Insert into library map for lookup by newly read datablocks (with pointer
-     * value bhead->old) or existing datablocks in memory (pointer value id_old). */
+     * value bhead->old). */
     oldnewmap_insert(fd->libmap, bhead->old, id_old, bhead->code);
-    oldnewmap_insert(fd->libmap, id_old, id_old, bhead->code);
 
     *r_id_old = id_old;
     return true;
@@ -9787,10 +9786,9 @@ static BHead *read_libblock(FileData *fd,
   BLI_addtail(lb, id);
 
   /* Insert into library map for lookup by newly read datablocks (with pointer
-   * value bhead->old) or existing datablocks in memory (pointer value id_old). */
+   * value bhead->old). */
   ID *id_target = id_old ? id_old : id;
   oldnewmap_insert(fd->libmap, bhead->old, id_target, bhead->code);
-  oldnewmap_insert(fd->libmap, id_old, id_target, bhead->code);
 
   if (r_id) {
     *r_id = id_target;

@Brecht Van Lommel (brecht) i think you nailed it. At lest when removing those two lines I cannot reproduce any crash anymore, while with current code and file attached below it is fairly easy (just duplicate a few times the whole selection of objects, and undo/redo, usually crashes fairly quickly for me).

I'd like to rethink this tomorrow with a fresh head though, want to recheck the cases where those would/could be needed again...

Was testing this with the details given in #914819 when I got this error while doing undo redo cycles:

Traceback (most recent call last):
  File "/Users/ankitkumar/blender-build/build/bin/Debug/Blender.app/Contents/Resources/2.90/scripts/startup/bl_ui/properties_object.py", line 61, in draw
    row.prop(ob, "location")
TypeError: UILayout.prop(): error with argument 1, "data" -  Function.data does not support a 'None' assignment AnyType type

location: <unknown location>:-1

location: <unknown location>:-1
Traceback (most recent call last):
  File "/Users/ankitkumar/blender-build/build/bin/Debug/Blender.app/Contents/Resources/2.90/scripts/startup/bl_ui/space_view3d.py", line 55, in draw
    VIEW3D_HT_header.draw_xform_template(layout, context)
  File "/Users/ankitkumar/blender-build/build/bin/Debug/Blender.app/Contents/Resources/2.90/scripts/startup/bl_ui/space_view3d.py", line 560, in draw_xform_template
    object_mode = 'OBJECT' if obj is None else obj.mode
AttributeError: 'Image' object has no attribute 'mode'

location: <unknown location>:-1

location: <unknown location>:-1
Traceback (most recent call last):
  File "/Users/ankitkumar/blender-build/build/bin/Debug/Blender.app/Contents/Resources/2.90/scripts/startup/bl_ui/space_view3d.py", line 675, in draw
    object_mode = 'OBJECT' if obj is None else obj.mode
AttributeError: 'Image' object has no attribute 'mode'

location: <unknown location>:-1

location: <unknown location>:-1

Also, can confirm that applying the patch stops crashes in both, the file "undo_redo_crash_ID_creation.blend" & the original steps with the modifications in #914819

Yeah, in fact those mapping entries were needed when we were still lib-linking the whole set of data-blocks. Now we are only ever lib-linking IDs that were actually re-read during that undo step, so we can get rid of those (and avoid the conflicting memory addresses caused by repetitive re-allocations that will happen when undoing/redoing IDs addition/deletion.