Blender 3.6 crashes when opening 3.5 files with library overrides / shape keys. #112623

New Issue

MKRelax · 2023-09-20T14:23:54+02:00

MKRelax commented

2023-09-20 14:23:54 +02:00

System Information
Operating system: Windows 10
Graphics card: RTX 3080Ti

Blender Version
Broken: 3.6.3 Release Candidate (71b55b491e)
Worked: 3.5

Short description of error
I recently switched from 3.5 to 3.6 but I noticed that many of my Blender 3.5 .blend files make Blender 3.6 crash whenever I open them. The issue seems to be a null pointer reference in shapekey_owner_pointer_get in one of my mesh assets with shape keys. The debug build aborts with a failed assertion:

BLI_assert failed: X:\blender\source\blender\blenkernel\intern\key.cc:98, shapekey_owner_pointer_get(), at 'key->from != nullptr'

All of my problematic .blend files use library overrides of mesh objects with shape keys. Additionally, some of the included assets were changed (in 3.5, maybe in 3.6).Blender 3.5 simply logs some missing meshes as usual but does not crash. Also these do not include the specific mesh that Blender 3.6 crashes on, that one was unchanged AFAIK. However, after opening and saving in 3.5, I can succesfully open them in 3.6 so the missing meshes may somehow play a role.

Exact steps for others to reproduce the error
I have not been able to reproduce this in a simple setup and I cannot share my production files. However I have bisected and the following commit introduced this behavior:

Edit: Changed 89bd7b64026 (which turned out to be fine) to 5f67b25c28b6.

5f67b25c28b689384c1a0e30f183207afa307aff is the first bad commit
commit 5f67b25c28b689384c1a0e30f183207afa307aff
Author: Bastien Montagne <bastien@blender.org>
Date:   Tue Apr 25 14:06:50 2023 +0200

    LibOverride: Do not attempt to resync a hierarchy when the root goes missing.

    This addresses an issue here at the Blender studio, where a root
    collection of a set was removed by mistake from the set library .blend file.

    Since all the other linked data (sub collections, actual objects etc.)
    of the set were still available, the liboverride resync code went crazy
    trying to resync all these scattered pieces of a set, finding new valid
    root IDs for the hierarchies, and so on.

    So from now on, do not attempt to resync anything that is part of a
    liboverride hierarchy which root ID linked reference has gone missing.

 source/blender/blenkernel/intern/lib_override.cc | 93 ++++++++++++++----------
 1 file changed, 55 insertions(+), 38 deletions(-)

@mont29 So under some circumstances, this fix results in key->from being NULL in shapekey_owner_pointer_get() (key.cc:98). Hopefully this is enough information to solve that. Otherwise I will continue to try and reproduce this in a simple setup and post an example .blend file.

**System Information** Operating system: Windows 10 Graphics card: RTX 3080Ti **Blender Version** Broken: 3.6.3 Release Candidate (71b55b491e9c) Worked: 3.5 **Short description of error** I recently switched from 3.5 to 3.6 but I noticed that many of my Blender 3.5 .blend files make Blender 3.6 crash whenever I open them. The issue seems to be a null pointer reference in `shapekey_owner_pointer_get` in one of my mesh assets with shape keys. The debug build aborts with a failed assertion: ``` BLI_assert failed: X:\blender\source\blender\blenkernel\intern\key.cc:98, shapekey_owner_pointer_get(), at 'key->from != nullptr' ``` All of my problematic .blend files use library overrides of mesh objects with shape keys. Additionally, some of the included assets were changed (in 3.5, maybe in 3.6).Blender 3.5 simply logs some missing meshes as usual but does not crash. Also these do _not_ include the specific mesh that Blender 3.6 crashes on, that one was unchanged AFAIK. However, after opening and saving in 3.5, I can succesfully open them in 3.6 so the missing meshes may somehow play a role. **Exact steps for others to reproduce the error** I have not been able to reproduce this in a simple setup and I cannot share my production files. However I have bisected and the following commit introduced this behavior: Edit: Changed `89bd7b64026` (which turned out to be fine) to `5f67b25c28b6`. ``` 5f67b25c28b689384c1a0e30f183207afa307aff is the first bad commit commit 5f67b25c28b689384c1a0e30f183207afa307aff Author: Bastien Montagne <bastien@blender.org> Date: Tue Apr 25 14:06:50 2023 +0200 LibOverride: Do not attempt to resync a hierarchy when the root goes missing. This addresses an issue here at the Blender studio, where a root collection of a set was removed by mistake from the set library .blend file. Since all the other linked data (sub collections, actual objects etc.) of the set were still available, the liboverride resync code went crazy trying to resync all these scattered pieces of a set, finding new valid root IDs for the hierarchies, and so on. So from now on, do not attempt to resync anything that is part of a liboverride hierarchy which root ID linked reference has gone missing. source/blender/blenkernel/intern/lib_override.cc | 93 ++++++++++++++---------- 1 file changed, 55 insertions(+), 38 deletions(-) ``` @mont29 So under some circumstances, this fix results in `key->from` being `NULL` in `shapekey_owner_pointer_get()` (`key.cc:98`). Hopefully this is enough information to solve that. Otherwise I will continue to try and reproduce this in a simple setup and post an example `.blend` file.

MKRelax added the

labels 2023-09-20 14:23:55 +02:00

MKRelax commented

2023-09-20 16:24:43 +02:00

This crash occurs most of the time, but not always. This made bisecting difficult because commits looked good that were actually bad. Commit 89bd7b64026 which was originally reported here turned out to be fine. The commit that introduced this behaviour seems to be 5f67b25c28b6. The issue was edited to reflect this.

This crash occurs most of the time, but not always. This made bisecting difficult because commits looked `good` that were actually `bad`. Commit `89bd7b64026` which was originally reported here turned out to be fine. The commit that introduced this behaviour seems to be `5f67b25c28b6`. The issue was edited to reflect this.

Germano Cavalcante commented

2023-09-21 03:57:07 +02:00

Thanks for the report, @MKRelax.

While I understand that you are unable to share your production files, it would be helpful if you could try to reproduce the issue in a simplified setup and provide an example .blend file that triggers the crash. This will allow us to investigate the issue more effectively.

Thanks for the report, @MKRelax. While I understand that you are unable to share your production files, it would be helpful if you could try to reproduce the issue in a simplified setup and provide an example .blend file that triggers the crash. This will allow us to investigate the issue more effectively.

Germano Cavalcante added

Status

Needs Information from User

and removed

Status

Needs Triage

labels 2023-09-21 03:57:18 +02:00

MKRelax commented

2023-09-23 14:56:04 +02:00

@mano-wii I have spent a full day debugging and trying to create a simplified setup, but to no avail. It seems that library overrides are processed in some multitreaded way (or otherwise in a random order) and for some reason the shapekey_owner_pointer_get() gets called before the library override for that armature/mesh is processed (or: that processing is skipped for some reason, after which shapekey_owner_pointer_get() crashes). It only happens in large, complex files with many library overrides and drivers, shape keys. Whenever I create a simplified setup (or re-save the complex setup), the resulting file loads fine.

I'm pretty sure that 5f67b25c28 is the first bad commit as I have loaded over 50 files with its previous commit b666d2d1bd without any crashes and 5f67b25c28 crashes about 50% of the time (and Blender 3.6.3 crashes 100% of the time).
However I'm not sure why 5f67b25c28 would cause this, as the specific condition it targets (a missing root ID linked reference) is never triggered.

Hopefully @mont29 can shine a light on why this might be happening.

For now, I have loaded all of my files in 3.5.1, saved them and I can now open them in 3.6.3 again. I have no more time to investigate this. Feel free to close this issue if the given information is insufficient.

@mano-wii I have spent a full day debugging and trying to create a simplified setup, but to no avail. It seems that library overrides are processed in some multitreaded way (or otherwise in a random order) and for some reason the `shapekey_owner_pointer_get()` gets called before the library override for that armature/mesh is processed (or: that processing is skipped for some reason, after which `shapekey_owner_pointer_get()` crashes). It only happens in large, complex files with many library overrides and drivers, shape keys. Whenever I create a simplified setup (or re-save the complex setup), the resulting file loads fine. I'm pretty sure that 5f67b25c28b6 is the first `bad` commit as I have loaded over 50 files with its previous commit b666d2d1bd6 without any crashes and 5f67b25c28b6 crashes about 50% of the time (and Blender 3.6.3 crashes 100% of the time). However I'm not sure why 5f67b25c28b6 would cause this, as the specific condition it targets (a missing root ID linked reference) is never triggered. Hopefully @mont29 can shine a light on why this might be happening. For now, I have loaded all of my files in 3.5.1, saved them and I can now open them in 3.6.3 again. I have no more time to investigate this. Feel free to close this issue if the given information is insufficient.

Bastien Montagne commented

2023-09-25 16:11:50 +02:00

Can't say for sure without checking (am on holidays currently), but pretty confident this is related to recent bug found, where deleting a mesh would not always delete its shapekey data. This was fixed in main a few weeks ago, together with some extra checks/sanitizing code about unowned shapekeys when opening a blendfile. Likely not back-ported to any LTS though.

Will check for a 'safe' fix in 3.6 once am back.

Can't say for sure without checking (am on holidays currently), but pretty confident this is related to recent bug found, where deleting a mesh would not always delete its shapekey data. This was fixed in main a few weeks ago, together with some extra checks/sanitizing code about unowned shapekeys when opening a blendfile. Likely not back-ported to any LTS though. Will check for a 'safe' fix in 3.6 once am back.

Bastien Montagne self-assigned this 2023-09-25 16:12:05 +02:00

Bastien Montagne commented

2023-10-04 20:20:12 +02:00

Not having reproducible case makes it fairly difficult to be sure what's happening here, but am going to bet that eadc54bb5d can fix the issue, so I will backport it to 3.6LTS, and you can test with the most recent 3.6 build if that works for you.

Not having reproducible case makes it fairly difficult to be sure what's happening here, but am going to bet that eadc54bb5d can fix the issue, so I will backport it to 3.6LTS, and you can test with the [most recent 3.6 build](https://builder.blender.org/download/daily/) if that works for you.

👍 1

Bastien Montagne referenced this issue

2023-10-04 20:22:46 +02:00

Blender LTS: Maintenance Task 3.6 #109399

Bastien Montagne added

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Blender 3.6 crashes when opening 3.5 files with library overrides / shape keys. #112623