Hi Nicolas, Eliot,
here's what I understand is happening (see the enclosed screenshot):
1) we fork a new process to evaluate [^1]
2) the new process evaluates [^1] which means instruction 18 is being evaluated, hence pc points to instruction 19 now
3) however, the home context where ^1 should return to is gone by this time (the process that executed the fork has already returned - notice the two up arrows in the debugger screenshot)
4) the VM can't finish the instruction and returns control to the image via placing the #cannotReturn: context on top of the [^1] context
5) #cannotReturn: evaluation results in signalling the BCR exception which is then handled by the #resume handler
(in our debugged case the [:ex | self halt. ex resume] handler)
6) ex resume is evaluated, however, this means requesting the VM to evaluate instruction 19 of the [^1] context - which is past the last instruction of the context and the crash ensues
I wonder whether such situations could/should be prevented inside the VM or whether such an expectation is wrong for some reason.
Thanks,
Jaromir
------ Original Message ------
Date 11/16/2023 6:48:43 PM
Subject Re: [squeak-dev] Re: Resuming on BlockCannotReturn exception
Hi Jaromir,
Hi Nicloas,
No no, I don't have any practical scenario in mind, I'm just trying to understand why the VM is implemented like this, whether there were a reason to leave this possibility of a crash, e.g. it would slow down the VM to try to prevent such a dumb situation (who would resume from BCR in his right mind? :) ) - or perhaps I have overlooked some good reason to even keep this behavior in the VM. That's all.
Let’s first understand what’s really happening. Presumably at tone point a context is resumed those pc is already at the block return bytecode (effectively, because it crashes in JITted code, but I bet the stack vm will crash also, but not as cleanly - it will try and execute the bytes in the encoded method trailer). So which method actually sends resume, and to what, and what state is resume’s receiver when resume is sent?
Regards,
Jaromir
------ Original Message ------
Date 11/16/2023 7:20:20 AM
Subject Re: [squeak-dev] Resuming on BlockCannotReturn exception
Hi Jaromir,
Is there a scenario where it would make sense to resume a BlockCannotReturn?
If not, I would suggest to protect at image side and override #resume.
Hi Eliot, Christoph, All,
It's known the following example crashes the VM. Is this an intended behavior or a "tolerated bug"?
`[[^ 1] on: BlockCannotReturn do: #resume] fork`
I understand why it crashes: the non-local return has nowhere to return to and so resuming the computation leads to a crash. But why not raise another BCR exception to prevent the crash? Potential infinite loop? Perhaps I'm just missing the purpose of this behavior...
Thanks for an explanation.
Best,
Jaromir