[Cuis-dev] Resuming on BlockCannotReturn exception

[Jaromir Matas]

Hi Juan, all,

Question: Was there a particular reason for this definition:
```
suspendedContext
     "Answer the context the receiver has suspended.
     I am Ready to Run or Suspended. Answer the context I was running 
when last preempted.

     Otherwise, (Running or Terminated) answer nil."

     ^self isTerminated ifFalse: [ suspendedContext ]
```
instead of using the simple original:
```
suspendedContext
     "Answer the context the receiver has suspended."

     ^suspendedContext
```

The reason I'm asking is it messes up with debugging some edge case 
scenarios I've been working on:

With Eliot we've fixed VM crashes when running e.g.

     [[^ 1] on: BlockCannotReturn do: [:ex | ex resume] ] fork

However, even after fixing the crashes the debugging of this scenario 
remained broken. I've identified the root cause in an incorrect 
simulation of returns in #return:from:. The fix is enclosed, but the 
debugging in Cuis still fails in some cases - e.g. if you debug the 
following example and just keep stepping over until a nonsensical error 
appears.

     [[self halt. ^ 1] on: BlockCannotReturn do: [:ex | ex resume] ] fork

And here I've tracked the root cause to your version of 
#suspendedContext. It answers nil for a terminated process but a process 
may be terminated yet a sender's context chain still hanging there; by 
nilling the suspended context you lose that information and the 
debugging fails.

I've included the "original" simple version of #suspendedContext in the 
enclosed changeset but feel free to make any changes, of course.

Now debugging of the example works fine for any of stepping over, 
through or into.

Explanation of the #return:from: bug:
Previously the method allowed returning to a dead or nil context, and, 
in addition, didn't nil the context that can't be returned to. These are 
two independent bugs. The VM doesn't allow such returns and does nil the 
context.

Fixing #return:from:, however, changes (i.e. fixes) the (incorrect) 
semantics of some other simulation methods: #stepToCallee won't return 
to a dead or nil sender now and the same goes for #step. There are cases 
where this incorrect bahavior has been (mis)used, e.g. in 
#runUntilErrorOrReturnFrom:

In order to fix this the easiest possible way I've created a version of 
#stepToCallee fulfilling this incorrect expectation - see 
#stepToCalleeOrNil. Ideally, I think, the use of #stepToCalleeOrNil in 
#runUntilErrorOrReturnFrom should be replaced with a "standard" (as 
opposed to a "simulation") code, e.g. using #releaseTo:, as the next 
step later.

Explanation of the VM crash fix:
The fix simply nills the context that can't be returned to. This can be 
done either in #cannotReturn: just by setting pc to nil before returning 
but Eliot suggested a more conceptual solution: in #cannotReturn:to:. 
This way we can save the failing context, and the pc where the return 
failed, inside the BCR exception for further use when debugging.

One more note: the direct debugger invocation in #cannotReturn: had to 
be replaced with raising an error in order to be able to test this 
situation properly - see the enclosed test.

It is possible there are some more cases taking advantage of making an 
illegal return to a dead or nil context during simulation, especially 
some debugger tests may be (mis)designed (because simplified) using this 
"feature" ;)

I hope I haven't missed something important; please let me know what you 
think.

Best regards,
Jaromir

--
Jaromir Matas
mail at jaromir.net

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20231201/63998343/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: BaseImageTests-jar.001.cs.st
Type: application/octet-stream
Size: 1379 bytes
Desc: not available
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20231201/63998343/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 5671-CuisCore-JaromirMatas-2023Nov30-23h52m-jar.001.cs.st
Type: application/octet-stream
Size: 5253 bytes
Desc: not available
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20231201/63998343/attachment-0001.obj>