maxwills / seekerdebugger Goto Github PK

To step an execution, Executor now should create an extra thread per tcu. So the TCUs are advanced by each thread, however, they synchronize with executor to know which one advances.
In theory, the threads themselves can define the execution order, which is closer to the actual scheduling of Pharo. I should record such order, and for replay, no extra threads are required, one the ecu stepping each tcu according to the records, while ignoring waits and signals?

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.

I'm trying to use Seeker with Toplo (Bloc UI layer) but when I'm starting an example I have an error :

See my video :
https://user-images.githubusercontent.com/49183340/229313577-60c55d83-fbc6-4b4f-8f83-ca01f2d73203.mp4

My configuration :

• Windows 11 Pro
• Pharo-11.0.0+build.659

Imagine having a class named UserSystemCall.
Each subclass targets a method (lazily, so it is Class+ selector rather than a CompiledMethod), an action to use as replacement (or not), a rule for enable or disable, and a groupName.
Add a new UI (like SeekerConfig) to enable or disable these methods.
SystemCalls are not undoable, and the debugger will not query inside them. In turn, they act as if it is only one instruction, and they are interpreted faster. It could be useful to enable
Possible use cases:

• Treat announcements as system calls.
• Ignore drawing or layout calls in general (there are a lot!).

During a normal debugging session, have a command to turn it into a seeker debugging session.
The recording starts in the current context.
Mid context support not available yet. (although it might be possible if a context shallow copy is stored to recover the literals at the target PC). Would also require to set an offset for the PC (Or just set it directly after restarting the context without undoing).

The current version always recreate records on replay (Except OIDs, although not 100% sure).
Have a configurable flag to control this behavior: a boolean that determines if the records are recreated on each replay or only during first.
Also, add an API to clear the record. The goal is to be able to make DDD seamlessly within Seeker, if possible.

Just a random idea (Need to be refined): Additionally, add an option to change the value of variable in the current context of the debugged program (or in case of message sends, to change the sender or the arguments about to be sent. (no need to modify the return of a method), and to override the returned value of a return expression (when inside the returning method)

Two bytecodes correspond to that node, the first one has the tested value in the context top, and the next one has the test result (true or false).
The problem is that currently, only the second one is considered a message send (because of "it will jump"), but the receiver of the message at that moment is wrong (cause it should be the tested value and not true or false).
TODO: Consider the message send to be the first bytecode for inlined ifNil (and similar) so the message receiver can be retrieved.
The next bytecode could be considered the return value of the ifNil message send (which never happens in application level, because of optimizations)

Fails when recompiling SeekerConfig with one TAutoproperty. Does not happen if other traits are present.
The dirty fix.

I'm trying to debug a problem with seeker in my project Molecule.
I'm debugging a test with Seeker and there are a lot of problem seems to be complicated :)

The test is MolComponentFactoryTest>>testComponentSubclassesTraitsUses

This video show the problem :

After there is a loop with all messages and this is not possible to continue without stop the image.

My config :

• Pharo-11.0.0+build.688 64 bits
• Windows 11 Pro

Performing StepOver operations when debugging with Seeker doesn't have the same behavior as when the same action is performed using the StDebugger only (without Seeker) in case of inlined loops blocks.

Symptoms

For example, consider the code:

1 to: 10: do: [:i|
    Transcript show: i asString; cr.
 ]

If using the StDebugging only (No Seeker), performing stepOver actions until the end of the execution would make the developer to go through the 10 iterations of the block.
If Seeker is enabled, the developer would only go through the first iteration of the block, and then continue with the rest of the program.

Reason

Since Seeker tries to keep count of every executed bytecode of the execution, the StepOver operation was rewritten and "simulated" using the basic bytecode stepping of Seeker. The implemented heuristic relies on part on information of the ast and the activated contexts to know when to stop executing bytecodes to perform a stepOver.
The problem is that certain loops are inlined, which means that while the AST corresponds to a block, the bytecode is executed in the same context of the definition method (and not in the context that would normally introduced by a non inlined block), which introduces a special case for the heuristic that is currently not handled.

Possible fixes.

• Implement a copy of the original StepOver mechanism performed by the StDebugger, but in Seeker terms (Might be an overkill solution, since there is a lot of methods called that would need to be converted to Seeker terms (including methods from Context).
• Implement the heuristic correction to properly handle these inlined loop cases.

The idea is that the developer don't need to re-run a query if it was already done.
A new TTQ will create a new tab. and it will be always accessible during the session, unless manually closed.

Analyze process termination for every use case.
Also, check for tests setups and cleanup

When called on some (if not all) inlined message sends, the message receiver is not properly calculated, and therefore, the methodAboutToExecute calculation is wrong.

A possible solution might be to check the AST in inlined sends, and if the message receiver of the message node is a block, then at least we can retrieve the correct method about to execute (even though we cant actually retrieve the message receiver if it was supposedly a block (prior to be inlined))

Just a reminder of possible NDS:

• Methods that read from file system (for example, to iterate over the files of a folder).
• SystemOrganizer? Or any methods that read from the class of the system.
• calls of allInstances, all subinstances.
• Should the debugger record all external variables readings? for replay? every external method return? (as extra measure of enforcing determinism?). Same for external methods? (One or the other or both?). Make it configurable.

• Opens a playground with some bindings:
  seeker (or seekerDebugger?)
  programStates

• Has an example script. (Similar to the scripting panel).

The only problem is that bindings are worthless after debugger is closed.
Im not sure if realding a Playground page will try to restore old bindings or it is just the text. (later case works well for us)

Add a system to create bookmarks for current step.
And maybe add the capacity to edit a label
step| label (defaults to node source)| stack depth| stack path? |
Should store a list that owned by the session.
In the future, it might persist but (or remembered some how), but need to think how to migrate it to the new and potentially different execution.

A change broke the stepOver, and now the program steps to the end in some circumstances.
TODO: Fix stepping in general