Crash: Simultaneously altering multiple properties causes race condition in BLField.__get__
#65
Labels
No Label
abstractions
architecture
bug
distribution
docs
duplicate
enhancement
feature
physical
proposal
question
simulation
tooling
tracker
unconfirmed
ux
wontfix
No Milestone
No project
No Assignees
1 Participants
Notifications
Total Time Spent: 22 hours 45 minutes
Due Date
so-rose
22 hours 45 minutes
No due date set.
Dependencies
No dependencies set.
Reference: so-rose/oscillode#65
Loading…
Reference in New Issue
There is no content yet.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may exist for a short time before cleaning up, in most cases it CANNOT be undone. Continue?
Log:
The
PlaneWave
node viz went a little wonky right before the crash. I'm noticing that line 949 is doing this a bunch - is there a race condition where it's being read while being written to? Do we need a lock?Crash Reportto Crash Report: Visualization read seems to crash Blender occasionallyConfirmed (
0fbd3752b3363bb898fd8af68f07e19bee39a347
): Changing (ex. by click-drag) multiple properties at once invokes each property'supdate
method in separate threads - thus triggering Blender property setters, while at the same time anotherupdate
method might have made it to trying to use the property__get__
to get the latest data for the GeoNodes tree.Line 949 in
bl_cache.py
is where Blender is trying to load a Blender property, while that same property is simultaneously being written to. With this kind of thing, we'd at best get mangled data when the race condition triggers; it's actually quite nice of Blender to crash for us!Now that we know what it is, it isn't as bad as we'd thought: Changing one property value at a time should be perfectly safe (barring unfortunate shenanigans). With that said, straight crashes are a bit nasty.
Fix
The fix should be easy enough; just guard the part of
__set__
and__get__
using athreading.Lock
. See https://docs.python.org/3/library/threading.html#.It's a good idea to also guard the global caches, to prevent mangled data from making it into caches during race-conditions and causing havoc, even after Blender properties themselves aren't causing crashes.
Lock contention really shouldn't be an issue - this race condition isn't being triggered outside of this kind of special case.
Crash Report: Visualization read seems to crash Blender occasionallyto Crash: Simultaneously altering multiple properties causes race condition in `BLField.__get__`I'm worried the extent may be further. Sometimes GN modifiers randomly stop displaying (associated with a name change?), then this crash happens. Most curious!
All right, I'm fed up; we're doing this!
Mid-refactor of
bl_cache
. Dinner then continue.Possibly a variant?