NDS issues

[maxwills]

While running the test ComputedSlotTest>>#testWriteComputedSlotCompiled a problematic scenario was encountered. The calls shown in the image execute a non deterministic number of steps (previously risking breaking the image (freezing) on time-travels, but It has been fixed by some VM Update. Tested in Pharo12 on 2023-04-25).

Suspects:

• A buggy UndoBlock used almost exclusively in these methods (check for objectAt:put: and related writing primitives and their undoBlock creation). Might not be raising an exception and could be silently corrupting Dictionaries or other objects during reversal. (might still be worth to check this interaction)
• Could be related to the usage of ASTCache in the code. The concern is that Seeker could be modifying the ASTCache (during stepping) and at the same time, the debugged program modifies it. On a reversal, only the debugged program performs the undo and Seeker changes remain, which introduces an NDS.
• Something related to announcements? I don't think it is the current problem but it is still a concern: an announcment of method compilation is sent to all suscribers in the system. If the number of suscribers change from one replay to another, an NDS is introduced.

[maxwills]

After using the debugger for some time with this method, a segmentation fault occurs when saving the image. I suspect something related to WeakIdentitySet(or Dictionaries). I guess that the after some time, the undoblocks try to undo changes in these dictionaries that have been modified by the system in the meantime (to reclaim memory or similar). The exception related to no more free space in the Weak collection could be a clue (It occurs in some collections unrelated to the debugger, but of the system). Maybe that test affect that collections, and the changes are not properly undone (specially after the system modifies them). One idea is to treat operations in these collections as key-based (so, the undoblock will undo an add: operation using the remove: by using a key instead of an index (which is the current approach). Note that weak hash-based collections instantiated by the execution should not have this problem since they are re-created and replayed deterministically (although if they might face the same issue after pausing the debug session for a while). A partial and "dirty" workaround, which at least would serve to diagnose the problem, is to replace instantiations of Weak collections completely by the non weak equivalent (which can be done easily by treating the instantiation as a system call). this would only solve the issue about the local weak collection and not for externals. Finally, I need to change all Weak collections used by the debugger to Non weak... it might solve the issue because it would "pin" objects, however there is still some concerns about using index based undoing in these collections.