[Cuis-dev] Resuming on BlockCannotReturn exception

[Juan Vuletich]

Hi Jaromir,

Again, thanks for your continued support for Cuis! This is VERY much 
appreciated.

(inline)

On 12/1/2023 10:52 AM, Jaromir Matas via Cuis-dev wrote:
> 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
> ```
>

Well, that method is from 2013. It was modified in 
1696-ProcessEnh-JuanVuletich-2013May10-09h59m-jmv.1.cs.st. I just guess 
it made sense to me at the time. No existing tests are made to fail, so 
I'm ok with this change. I'd still tell the reason in the method 
comment, though.

> 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.

In the comment of the test you provided, the argument to on:do: is a 
symbol. This is not supported in Cuis. The idiom you used in your email, 
passing a block, is ok.

I see that you did your testing and fix on a Cuis system updated to 
#5670. Latest published Cuis update is #6092. You're missing almost a 
year of updates. And, for instance, in #6091, Facundo modified 
#runUntilErrorOrReturnFrom:

Can you please review and retest your changes on a fully updated Cuis?

Thanks!!!

>
> 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 <mailto:mail at jaromir.net>
>
>


-- 
Juan Vuletich
cuis.st
github.com/jvuletich
researchgate.net/profile/Juan-Vuletich
independent.academia.edu/JuanVuletich
patents.justia.com/inventor/juan-manuel-vuletich
linkedin.com/in/juan-vuletich-75611b3
twitter.com/JuanVuletich

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20231201/1b4b19e2/attachment-0001.htm>