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.
maxwills
commented
2 years ago
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:
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.