In any case, buildbot does not compile with ASAN? so silencing this false positive may 'fix' the issue when running ctest locally on a Mac with an ASAN-enabled build, but I doubt it would help buildbot case at all?

Cannot reproduce a crash, but this file looks quite badly built to me, generates dependency cycles in Depsgraph, and a lot of errors during RB simulation…

Thanks for the report, but there is no bug here, we do not want to update the whole UI at every frame for performances reasons, and that would be the only way to ensure all animated properties are updated real time in UI during animation playback. Just hovering the settings with the mouse is enough to update them though.

In T81077#1022200, @Sergey Sharybin (sergey) wrote:

Those tests are run in parallel now

Where this information is coming from?

The issue can be easily reproduced on macOS by:

1. Compile Blender with ASAN
2. ctest -R id_management

Please look into actual problems rather than speculating that something is wrong on the buildbot.

This is a known issue actually, caused by design flaw in vgroups (they are stored partly in mesh, partly in object). Edit mesh undo steps cannot store undo data for anything else than the mesh, so to support this we'd need to either store a global memfile undo step (which is not possible currently in Edit mode afaik).

I can confirm that roughness texture is exported by Blender in the FBX file… Beyond that, hard to do or say much from our side.

No activity for more than a week. As per the tracker policy we assume the issue is gone and can be closed.

No activity for more than a week. As per the tracker policy we assume the issue is gone and can be closed.

No activity for more than a week. As per the tracker policy we assume the issue is gone and can be closed.

Possibly related to T53908?

@Alaska (Alaska) fairly sure the dependency cycle is not the issue here, this only involves bones, nothing to do with issue in T77460. ;)

Aren't you simply running out of memory? This is a very heavy scene, I can barely load it on my 16G laptop in a debug build, and cannot even render in viewport in release build (crashes due to lack of RAM). So we need at least two more info here:

• amount of RAM on your system, and check that it is not fully used just before the crash;
• Are you rendering on CPU or GPU?

Regarding id_management, did someone check that it was not a mere 'out of RAM' issue? Those tests are run in parallel now, iirc this can consume quite a lot of memory… Would also explain why it passes sometimes, and sometimes not?

That mesh does have some vgroup data layer (unfortunately, vgroups are kind of 'split' between Object and Mesh data, if the object part does not match the mesh part the later remains there, but unseen).

Based solely on the traceback you pasted above, I tried this hack:

Also, I think there is a step missing in your description? You do reload the edited library before trying to resync its overrides, right?

Hrmmm… Actually cannot reproduce anymore.

Grrr, wrong number in commit message...

Ok, could reproduce here with debug+Asan build and using Rain v2… Will check further tomorrow, thanks for the report.

LGTM, always better to factorize logic, even if only for a few lines of code.

I indeed much prefer the #define solution here, looks much less intrusive to me.

LGTM.

Patch LGTM, besides nit-picky style comments below.

Note:

This is actually more a depsgraph/physics evaluation issue than a data/IO one.

Looks like this has been solved, at least cannot reproduce with current master. thanks for the report.

Note that ideally, operators poll functions from that add-on should also be updated to be able to return meaningful error messages to the user (and even disable themselves in UI) when trying to perform invalid operations on 'original' data…