Ok, thanks to you two for these nice answers. I made a pull-request to improve the comment of the DebugSession class based on your answers. Thomas On 01/12/2018 19:02, Eliot Miranda wrote:

Hi Andrei, Hi Thomas,

    Andrei, you are right; they are different and the difference is important.  As you say, suspendedContext is the top (“hot”) context in a process’s context chain, but interruptedContext is the context which sent the signal message that eventually raised the exception that invoked the debugger.  suspendedContext is therefore where execution is in the process, but interruptedContext is where the debugger should show the stack.

Thomas, because the exception system is implemented in Smalltalk the handling of the initial signal (eg in Object>>#halt), all the way to opening a debugger, is itself Smalltalk code, and exists as activations from suspendedContext to interruptedContext.  The debugger, with help from the exception system, carefully hides this processing from the programmer.  If it did not we would have to wade through many activations before we found where the exception occurred.

When a process is interrupted by control period things are different.  Here, another process handles opening the debugger and indeed suspendedContext and interruptedContext are the same.

So the difference between suspendedContext and interruptedContext is vital to the debugger.  Without it we would  see the inner machinery of the exception system when errors or exceptions are raised.

HTH

_,,,^..^,,,_ (phone)

On Nov 30, 2018, at 7:42 AM, Andrei Chis <chisvasileandrei@gmail.com <mailto:chisvasileandrei@gmail.com>> wrote:

...

Hi,

From what I remember they are not always redundant, but I'm not 100% sure they are both needed.

`suspendedContext` from Process is always the top context of a process. After execution actions like Step Into, Step Over, Step Through it will be the same as interruptedContext in the debugger.

They will be different when opening the debugger as a result of an exception. Exception>>#debug triggers the workflow for opening a debugger. This uses `self signalerContext` as the context that is being debugged. This is the context where the exception was raised and this will be put in the interruptedContext. As this point the execution of the current process is not over and it will continue up to `MorphicUIManager>>#debugProcess:context:label:fullView:notification: ` where the current process is suspended. At that point the two will be different, as suspendedContext will be the context of the method MorphicUIManager>>#debugProcess:context:label:fullView:notification: and the interruptedContext the context that triggered the exception.

But it might be that they are not both needed. One  possible option might be to force the process to step to the context that raised the exception when the debugger is created. For example in DebugSession>>process:context:. Apart from when opening the debugger I do not know if there is another situation where those two can diverge.

Cheers, Andrei

On Fri, Nov 30, 2018 at 11:54 AM Thomas Dupriez <tdupriez@ens-paris-saclay.fr <mailto:tdupriez@ens-paris-saclay.fr>> wrote:

Hello,

Instances of DebugSession have an "interruptedContext" and an "interruptedProcess" instance variable.

Instances of Process have a "suspendedContext" instance variable.

Does someone know if there is a relation between the interruptedContext of a DebugSession and the suspendedContext of its interruptedProcess? At first glance it seems like these two variables are redundant and store the same Context.

Thomas Dupriez