Interactions with timeline after undo makes Blender crash #107860

New Issue

Closed

opened 2023-05-12 03:51:34 +02:00 by Mark · 10 comments

Mark commented

2023-05-12 03:51:34 +02:00

System Information
Operating system: Windows-10-10.0.19045-SP0 64 Bits
Graphics card: NVIDIA GeForce RTX 3070 Ti/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 531.61

Blender Version
Broken: version: 3.5.1, branch: blender-v3.5-release, commit date: 2023-04-24 18:11, hash: e1ccd9d4a1d3;
version: 3.5.1, branch: blender-v3.5-release, commit date: 2023-05-11 18:11, hash: 6ee8aa4997ee

Additionally: 3.4.1 and previous versions open the file and immediately crashes.

Short description of error
Undo of an action that moves on the timeline and interaction with it afterwards causes Blender to crash

Exact steps for others to reproduce the error

I can replicate the issue if I:

Open attached file
Move time line
Select an object
Undo undo till the beginning
Select an object, crashes

Open attached file
Move between frames, select some objects so Blender counts it as a new undo step
Use undo a couple times and move on the timeline (may take a couple tries)

Does not produce the crash logs on my end
Animation playback instead of manual scrubbing works fine, but does not prevent crash if timeline is being interacted with after that
It wasn't there from the very start and began only after some work been done (I was making some minor changes in the library file in the process, and the other file dependant on it has the same issue now)

**System Information** Operating system: Windows-10-10.0.19045-SP0 64 Bits Graphics card: NVIDIA GeForce RTX 3070 Ti/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 531.61 **Blender Version** Broken: version: 3.5.1, branch: blender-v3.5-release, commit date: 2023-04-24 18:11, hash: `e1ccd9d4a1d3`; version: 3.5.1, branch: blender-v3.5-release, commit date: 2023-05-11 18:11, hash: `6ee8aa4997ee` Additionally: 3.4.1 and previous versions open the file and immediately crashes. **Short description of error** Undo of an action that moves on the timeline and interaction with it afterwards causes Blender to crash **Exact steps for others to reproduce the error** I can replicate the issue if I: - Open attached file - Move time line - Select an object - Undo undo till the beginning - Select an object, crashes Open attached file Move between frames, select some objects so Blender counts it as a new undo step Use undo a couple times and move on the timeline (may take a couple tries) Does not produce the crash logs on my end Animation playback instead of manual scrubbing works fine, but does not prevent crash if timeline is being interacted with after that It wasn't there from the very start and began only after some work been done (I was making some minor changes in the library file in the process, and the other file dependant on it has the same issue now)

Timeline undo crash.blend

48 MiB

Mark added the

labels 2023-05-12 03:51:34 +02:00

YimingWu added the

label 2023-05-12 08:12:41 +02:00

YimingWu commented

2023-05-12 08:36:26 +02:00

Member

I can replicate the issue if I:

Move time line
Select an object
Undo undo till the beginning
Select an object, crashes

Will look into it.

I can replicate the issue if I: - Move time line - Select an object - Undo undo till the beginning - Select an object, crashes Will look into it.

YimingWu commented

2023-05-12 08:49:07 +02:00

Member

Crashes at source/blender/blenkernel/intern/lib_override.cc line 4020:

    if (!(!ID_IS_LINKED(id) && ID_IS_OVERRIDE_LIBRARY_REAL(id) &&
          (id->override_library->runtime->tag & LIBOVERRIDE_TAG_NEEDS_RESTORE) != 0))

          // Here the `id->override_library->runtime` is NULL.

Adding a && id->override_library->runtime check seems to do the trick but I'm not sure that's the intended logic in this context. @mont29 Would you take a look at this?

Crashes at `source/blender/blenkernel/intern/lib_override.cc` line 4020: ```Cpp if (!(!ID_IS_LINKED(id) && ID_IS_OVERRIDE_LIBRARY_REAL(id) && (id->override_library->runtime->tag & LIBOVERRIDE_TAG_NEEDS_RESTORE) != 0)) // Here the `id->override_library->runtime` is NULL. ``` Adding a `&& id->override_library->runtime` check seems to do the trick but I'm not sure that's the intended logic in this context. @mont29 Would you take a look at this?

YimingWu added

and removed

labels 2023-05-12 08:49:31 +02:00

YimingWu referenced a pull request that will close this issue

2023-05-12 09:07:26 +02:00

Fix #107860: NULL check override_library->runtime #107865

Bastien Montagne commented

2023-05-12 12:40:27 +02:00

Owner

This file is extremely broken, it has dependency issues in Turret collection, as noted by the depsgraph error message in the console:

Dependency cycle detected:
  OBRIG-Turret/DRIVER(pose.bones["MCH-thigh_ik_mid.R"].scale) depends on
  OBRIG-Turret/DRIVER(pose.bones["MCH-thigh_ik_mid.R"].scale) via 'Driver Serialization'
  OBRIG-Turret/DRIVER(pose.bones["MCH-thigh_ik_mid.R"].scale) via 'Driver Serialization'
  OBRIG-Turret/DRIVER(pose.bones["MCH-thigh_ik_mid.R"].scale) via 'Driver Serialization'
Dependency cycle detected:
  OBRIG-Turret/DRIVER(pose.bones["MCH-thigh_ik_mid.L"].scale) depends on
  OBRIG-Turret/DRIVER(pose.bones["MCH-thigh_ik_mid.L"].scale) via 'Driver Serialization'
  OBRIG-Turret/DRIVER(pose.bones["MCH-thigh_ik_mid.L"].scale) via 'Driver Serialization'
  OBRIG-Turret/DRIVER(pose.bones["MCH-thigh_ik_mid.L"].scale) via 'Driver Serialization'
Dependency cycle detected:
  OBRIG-Turret/DRIVER(pose.bones["MCH-thigh_ik_mid.L"].scale) depends on
  OBRIG-Turret/DRIVER(pose.bones["MCH-thigh_ik_mid.L"].scale) via 'Driver Serialization'
  OBRIG-Turret/DRIVER(pose.bones["MCH-thigh_ik_mid.L"].scale) via 'Driver Serialization'
  OBRIG-Turret/DRIVER(pose.bones["MCH-thigh_ik_mid.L"].scale) via 'Driver Serialization'
Dependency cycle detected:
  OBRIG-Turret/DRIVER(pose.bones["MCH-thigh_ik_mid.R"].scale) depends on
  OBRIG-Turret/DRIVER(pose.bones["MCH-thigh_ik_mid.R"].scale) via 'Driver Serialization'
  OBRIG-Turret/DRIVER(pose.bones["MCH-thigh_ik_mid.R"].scale) via 'Driver Serialization'
  OBRIG-Turret/DRIVER(pose.bones["MCH-thigh_ik_mid.R"].scale) via 'Driver Serialization'

Somehow, it also manages to have (in current file) both a liboverride Turret and a linked Turret collections as children of the (liboverride) Characters collection, this should never be possible.

Further more, liboverride resync process somehow manage to generate 5 (!) times Turret liboverrides as children of the Characters one...

So there are way more issues here than the runtime being null. Still trying to understand how to fix this...

This file is extremely broken, it has dependency issues in Turret collection, as noted by the depsgraph error message in the console: ``` Dependency cycle detected: OBRIG-Turret/DRIVER(pose.bones["MCH-thigh_ik_mid.R"].scale) depends on OBRIG-Turret/DRIVER(pose.bones["MCH-thigh_ik_mid.R"].scale) via 'Driver Serialization' OBRIG-Turret/DRIVER(pose.bones["MCH-thigh_ik_mid.R"].scale) via 'Driver Serialization' OBRIG-Turret/DRIVER(pose.bones["MCH-thigh_ik_mid.R"].scale) via 'Driver Serialization' Dependency cycle detected: OBRIG-Turret/DRIVER(pose.bones["MCH-thigh_ik_mid.L"].scale) depends on OBRIG-Turret/DRIVER(pose.bones["MCH-thigh_ik_mid.L"].scale) via 'Driver Serialization' OBRIG-Turret/DRIVER(pose.bones["MCH-thigh_ik_mid.L"].scale) via 'Driver Serialization' OBRIG-Turret/DRIVER(pose.bones["MCH-thigh_ik_mid.L"].scale) via 'Driver Serialization' Dependency cycle detected: OBRIG-Turret/DRIVER(pose.bones["MCH-thigh_ik_mid.L"].scale) depends on OBRIG-Turret/DRIVER(pose.bones["MCH-thigh_ik_mid.L"].scale) via 'Driver Serialization' OBRIG-Turret/DRIVER(pose.bones["MCH-thigh_ik_mid.L"].scale) via 'Driver Serialization' OBRIG-Turret/DRIVER(pose.bones["MCH-thigh_ik_mid.L"].scale) via 'Driver Serialization' Dependency cycle detected: OBRIG-Turret/DRIVER(pose.bones["MCH-thigh_ik_mid.R"].scale) depends on OBRIG-Turret/DRIVER(pose.bones["MCH-thigh_ik_mid.R"].scale) via 'Driver Serialization' OBRIG-Turret/DRIVER(pose.bones["MCH-thigh_ik_mid.R"].scale) via 'Driver Serialization' OBRIG-Turret/DRIVER(pose.bones["MCH-thigh_ik_mid.R"].scale) via 'Driver Serialization' ``` Somehow, it also manages to have (in current file) both a liboverride Turret and a linked Turret collections as children of the (liboverride) Characters collection, this should never be possible. Further more, liboverride resync process somehow manage to generate 5 (!) times Turret liboverrides as children of the Characters one... So there are way more issues here than the runtime being null. Still trying to understand how to fix this...

Bastien Montagne commented

2023-05-12 18:33:29 +02:00

Owner

Ok so in the end, I think am going to have to consider this file as invalid:

On readfile itself (so before any override is applied), the local liboverride Characters collection has two children, Maurice and Turret;
This liboverride Character collection has several weird override operations, e.g one which replaces the linked 'Drone' collection by the 'Turret' one.

This leads to a fully invalid 'applied overrides' Character collection, with three children, among which the linked Turret collection, and the override Turret collection. The resync process then cannot happen in a safe and sound way.

At least that is my current understanding of what's happening here, the situation is extremely weird and complicated to investigate.

Unless you can provide us with a way to reproduce such broken setup, we cannot do much here. Indeed deleting and rebuilding the whole liboverride hierarchy is the best way to rebuild a sane file.

Ok so in the end, I think am going to have to consider this file as invalid: 1. On readfile itself (so before any override is applied), the local liboverride Characters collection has two children, Maurice and Turret; 2. This liboverride Character collection has several weird override operations, e.g one which replaces the linked 'Drone' collection by the 'Turret' one. This leads to a fully invalid 'applied overrides' Character collection, with three children, among which the _linked_ Turret collection, and the _override_ Turret collection. The resync process then cannot happen in a safe and sound way. At least that is my current understanding of what's happening here, the situation is extremely weird and complicated to investigate. Unless you can provide us with a way to reproduce such broken setup, we cannot do much here. Indeed deleting and rebuilding the whole liboverride hierarchy is the best way to rebuild a sane file.

Bastien Montagne added

Needs Information from User

and removed

labels 2023-05-12 18:33:50 +02:00

Mark commented

2023-05-13 03:29:04 +02:00

Author

I've tried rebulding it a couple times and it seems that any file that borrows data from this library breaks (which contradicts my first message regarding "Troubleshoot -> Delete fixes the problem" part, I'll edit that out). By comparing file hierarchy I can assume that it fixes the linking order problems, but the timeline issue remains.

To replicate crash:

Create a scene
Link "All" collection from the attached file
Make a library override
Repeat Undo action sequence described earlier

I turned off the conflicting turret drivers and deleted Drone collection (it was empty anyways)

I've tried rebulding it a couple times and it seems that any file that borrows data from this library breaks (which contradicts my first message regarding "Troubleshoot -> Delete fixes the problem" part, I'll edit that out). By comparing file hierarchy I can assume that it fixes the linking order problems, but the timeline issue remains. To replicate crash: - Create a scene - Link "All" collection from the attached file - Make a library override - Repeat Undo action sequence described earlier I turned off the conflicting turret drivers and deleted Drone collection (it was empty anyways)

MauriceEncounter.blend

34 MiB

Mark commented

2023-05-19 17:16:06 +02:00

Author

Hey, @mont29, sorry for pinging, but seems like I can't change status of the task myself and it will stay the same way without manual attention. I've described the broken scene replication process in the message above

Hey, @mont29, sorry for pinging, but seems like I can't change status of the task myself and it will stay the same way without manual attention. I've described the broken scene replication process in the message above

Bastien Montagne commented

2023-06-09 15:56:24 +02:00

Owner

OK... so undo/redo code changed quiet a bit recently so was waiting for that to get in Main before I check the report again.

Now am getting a 'use after free' issue which is specific to objects using particles ID. Will fix this first, then we see if there are still reproducible issues with this case.

OK... so undo/redo code changed quiet a bit recently so was waiting for that to get in Main before I check the report again. Now am getting a 'use after free' issue which is specific to objects using particles ID. Will fix this first, then we see if there are still reproducible issues with this case.

Bastien Montagne referenced this issue from a commit

2023-06-09 16:59:05 +02:00

Fix (unreported) Object's particle 'foreach_id` potentially accessing other IDs data.

Bastien Montagne commented

2023-06-09 17:00:27 +02:00

Owner

Commit 44e4b5fe33 seems to fix any issue with this report, please let me know if it also works for you or if you can still reproduce crashes.

Commit 44e4b5fe33 seems to fix any issue with this report, please let me know if it also works for you or if you can still reproduce crashes.

Mark commented

2023-06-10 13:47:54 +02:00

Author

The last build (version: 3.6.0 Beta, branch: blender-v3.6-release, commit date: 2023-06-09 15:07, hash: 6a3ca93c7e34) seems to work well. I could not replicate the issue with any of methods described earlier. Thanks a lot, Bastien

The last build (version: 3.6.0 Beta, branch: blender-v3.6-release, commit date: 2023-06-09 15:07, hash: `6a3ca93c7e34`) seems to work well. I could not replicate the issue with any of methods described earlier. Thanks a lot, Bastien

Bastien Montagne commented

2023-06-10 16:53:41 +02:00

Owner

Nice, time to close it then, thanks for the feedback! :D

Nice, time to close it then, thanks for the feedback! :D

Bastien Montagne closed this issue

2023-06-10 16:53:43 +02:00

Blender Bot added

and removed

Needs Information from User

labels 2023-06-10 16:53:45 +02:00

Sign in to join this conversation.

No Label

Animation & Rigging

Asset Browser Project Overview

Automated Testing

Blender Asset Bundle

Dependency Graph

Development Management

EEVEE & Viewport

Images & Movies

Motion Tracking

Nodes & Physics

Pipeline, Assets & IO

Platforms, Builds & Tests

Render & Cycles

Render Pipeline

Sculpt, Paint & Texture

Video Sequencer

Virtual Reality

Blender 2.8 Project

Milestone 1: Basic, Local Asset Browser

Good First Issue

Animation & Rigging

Development Management

EEVEE & Viewport

Nodes & Physics

Pipeline, Assets & IO

Platforms, Builds & Tests

Render & Cycles

Sculpt, Paint & Texture

Needs Info from Developers

Needs Information from User

No Milestone

No project

No Assignees

3 Participants

Notifications

Due Date

The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender#107860

No description provided.