Undo system: Debug assert while undoing several operations #75919
Labels
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser
Interest
Asset Browser Project Overview
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
EEVEE & Viewport
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
No Assignees
6 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: blender/blender#75919
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
System Information
Operating system: Windows-10-10.0.18362-SP0 64 Bits
Graphics card: AMD FirePro W2100 ATI Technologies Inc. 4.5.13560 Core Profile Context FireGL 26.20.11024.6001
Blender Version
Broken: version: 2.90 (sub 0), branch: master, commit date: 2020-04-19 19:15, hash:
a331d79900
Worked: (newest version of Blender that worked as expected)
Short description of error
It appears as though there's some badness going on between selection, edit/object mode toggling, and perhaps modal operators? It's been very difficult to nail down for certain. What's below is the smallest repro I've been able to reliably hit the assert.
Exact steps for others to reproduce the error
Start with default scene
Duplicate+Move the cube to the side
Select original cube
Select duplicated cube (don't shift select, just select normally)
Toggle edit mode
Subdivide
(De) Select all
Hit 3 to do Face select
Box select 4 faces of the cube
E then S to extrude then scale
Enable the Transform gizmo
Move the already selected faces
Toggle object mode
Ctrl-Z as far back as you can go
BLI_assert failed: F:\source\blender-git\blender\source\blender\blenlib\intern\BLI_ghash.c:462, ghash_insert_ex(), at '(gh->flag & GHASH_FLAG_ALLOW_DUPES) || (BLI_ghash_haskey(gh, key) == 0)'
Taken with
--debug-io --log "*"
Added subscriber: @deadpin
Added subscriber: @ankitm
couldn't redo on
5cc7e2ae16
is there a hidden setting I forgot to change for undo ?
Added subscriber: @iss
I also can not reproduce.
I can still reproduce as of
9618bd9202
If it doesn't trigger the first time, can you try running through the steps a second time using the same scene.
Added subscriber: @EAW
Crashed for me on the first try but not the second. Investigating.
Added subscriber: @ideasman42
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 @ideasman42 back in 2013.
fbb446dff6
@iss @ankitm are you running in debug mode, and are you using factory startup?
Changed status from 'Needs Triage' to: 'Confirmed'
I probable wasn't able to reproduce, because I haven't run with any --debug argument.
Added subscriber: @mont29
earlier no, now I tried that. but couldn't redo. --debug-io
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.Added subscriber: @brecht
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 inold_idmap
, ..). Or there is something wrong with the way we construct or usefd->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.
@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).
undo_redo_crash_ID_creation.blend
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:
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.
Changed status from 'Confirmed' to: 'Resolved'
Fixed by
0faeca806c
.