You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Bug description
Occasionally, I see a Spec2 list seem to get "disconnected" and the rest of the gui wouldn't update after a selection change.
I chased the problem down and eventually I observed that SpMultipleSelectionMode>>selectIndexes: wasn't honoring the subscription blocks in the selectedIndexes ObservableSlot. Turns out that the lock inst var in the ObservableValueHolder would get stuck to true. If lock gets stuck to true, the gui won't update anymore. The culprit may be that there is a tiny window where if a process in ObservableValueHolder>>#value: is terminated after lock is set to true, but before the ensure block is invoked, lock will forever be true. See code below.
value: anObject
"Handle circular references as explained in the class comment"
lock ifTrue: [ ^ self ].
lock := true. <<<<<<<< If the process is terminated after lock is set to true, but before the block is invoked, lock will forever be true.
[ | oldValue |
oldValue := value.
value := anObject.
self valueChanged: oldValue ]
ensure: [ lock := false ]
Some potential fixes:
Move "lock := true" code inside the ensure block.
Wrap the "lock := true" in another ensure block which runs the original ensure block.
Possibly use a #valueUninterruptably (but that could have unintended side effects)
I'm experimenting with #1 and #2 solutions to see if they eliminate the problem.
To Reproduce
Hard to reproduce, but you can try killing processes that are changing slot values.
Expected behavior
Don't let lock get stuck in true so subscription blocks will always run
Screenshots
None
Version information:
Reproduced in Pharo 11.
Code is identical in Pharo 12.
Pharo 12.0.0
Build information: Pharo-12.0.0+SNAPSHOT.build.1516.sha.25ecf718d4a363b275862b4a093b1a240ec7e8d2 (64 Bit)
Expected development cost
Shouldn't be too hard to fix if my analysis is correct.
Additional context
Very hard to reproduce this problem but was impacting user severely.
The text was updated successfully, but these errors were encountered:
ObservableValueHolder had a window where lock inst var could get stuck in `true` preventing updates. Not sure this is the best fix - still testing. May be able to put `lock := true` inside inner ensure block but saw some weird behavior when I tried that so went this way.
pharo-project/pharo#16858
Bug description
Occasionally, I see a Spec2 list seem to get "disconnected" and the rest of the gui wouldn't update after a selection change.
I chased the problem down and eventually I observed that SpMultipleSelectionMode>>selectIndexes: wasn't honoring the subscription blocks in the selectedIndexes ObservableSlot. Turns out that the lock inst var in the ObservableValueHolder would get stuck to true. If lock gets stuck to true, the gui won't update anymore. The culprit may be that there is a tiny window where if a process in ObservableValueHolder>>#value: is terminated after lock is set to true, but before the ensure block is invoked, lock will forever be true. See code below.
Some potential fixes:
I'm experimenting with #1 and #2 solutions to see if they eliminate the problem.
To Reproduce
Hard to reproduce, but you can try killing processes that are changing slot values.
Expected behavior
Don't let
lock
get stuck in true so subscription blocks will always runScreenshots
None
Version information:
Reproduced in Pharo 11.
Code is identical in Pharo 12.
Pharo 12.0.0
Build information: Pharo-12.0.0+SNAPSHOT.build.1516.sha.25ecf718d4a363b275862b4a093b1a240ec7e8d2 (64 Bit)
Expected development cost
Shouldn't be too hard to fix if my analysis is correct.
Additional context
Very hard to reproduce this problem but was impacting user severely.
The text was updated successfully, but these errors were encountered: