Much to learn, I still have.


On 30-Dec-23 11:29:53 PM, lewis@mail.msen.com wrote:

Understand it no one does.


On 2023-12-30 21:13, Jaromir Matas wrote:

> nit: You mixed up the order of arguments for #assert:equals:

oops, sorry :) It happens to me all the time; I've never actually understood why the strange, almost Yodaesque, order... as if you asked in English:
 
"Make sure 18 is his age."
 
Thanks,
Jaromir
 
 
On 30-Dec-23 9:13:56 PM, christoph.thiede@student.hpi.uni-potsdam.de wrote:
 
nit: You mixed up the order of arguments for #assert:equals: (it is assert: expected equals: actual) and could have used it in the final assert again, but that's clearly no reason to hold back a useful test. ;-) Merged, thanks! :-)

Best,
Christoph

---
Sent from Squeak Inbox Talk

On 2023-12-30T17:33:08+00:00, mail@jaromir.net wrote:

> Hi Christoph,
>
> Thanks for merging the fixes; I've just sent another test in
> KernelTests-jar.448 to complement them.
>
> Please take a look and if ok I'd appreciate it if you could merge it as
> well.
>
> Best regards and Happy New Year to you too!
> Jaromir
>
>
> On 30-Dec-23 6:15:25 PM, christoph.thiede(a)student.hpi.uni-potsdam.de
> wrote:
>
> >Hi Jaromir, hi all,
> >
> >finally I have found the time to review these suggestions.
> >Kernel-jar.1537, Kernel-jar.1538, and Kernel-jar.1539 look excellent to
> >me as well. Clear, straightforward, useful. :-) I have merged them into
> >the trunk via Kernel-ct.1545.
> >
> >Regarding DebuggerTests>>test16HandleSimulationError, I have patched it
> >via ToolsTests-ct.125. Nothing to rack your brains over: "thisContext
> >pc: nil" just mimicks any kind of unhandled error inside the simulator
> >- since we now gently handle this via #cannotReturn:, I just replaced
> >it with "thisContext pc: false". :-) Sorry for not clarifying that
> >earlier and letting you speculate.
> >
> >Thanks for your work, and I already wish you a happy new year!
> >
> >Best,
> >Christoph
> >
> >---
> >Sent from Squeak Inbox Talk
> ><https://github.com/hpi-swa-lab/squeak-inbox-talk>
> >
> >On 2023-11-29T13:31:09+00:00, mail(a)jaromir.net wrote:
> >
> > > Hi Marcel,
> > >
> > > > [myself] whether the patch would have been necessary should the
> > > #return:from: had been fixed then
> > >
> > > Nonsense, I just mixed it up with another issue :)
> > >
> > >
> > > On 29-Nov-23 1:51:21 PM, "Jaromir Matas" <mail(a)jaromir.net> wrote:
> > >
> > > >Thanks Marcel! This test somehow slipped my attention :)
> > > >
> > > >The test can no longer work as is. It takes advantage of the
> >erroneous
> > > >behavior of #return:from: in the sense that if you simulate
> > > >
> > > > thisContext pc: nil
> > > >
> > > >it'll happily return to a dead context (i.e. to thisContext from
> >#pc:
> > > >nil context) - which is not what the VM does during runtime. It
> >should
> > > >immediately raise an illegal return exception not only during
> >runtime
> > > >but also during simulation.
> > > >
> > > >The test mentions a patch for an infinite debugger chain
> > > >(http://forum.world.st/I-broke-the-debugger-td5110752.html). I
> >wonder
> > > >whether the problem could have something to do with this simulation
> >bug
> > > >in return:from:; and a terrible idea occurred to me whether the
> >patch
> > > >would have been necessary should the #return:from: had been fixed
> >then
> > > >;O
> > > >
> > > >We may potentially come up with more examples like this, even in the
> > > >trunk, where the bug from #return:from: propagated and was taken
> > > >advantage of. I've found and fixed #runUntilErrorOrReturnFrom: but
> >more
> > > >can still be surviving undetected...
> > > >
> > > >I'd place the test into #expectedFailures for now but maybe it's
> >time
> > > >to remove it; Christoph should decide :)
> > > >
> > > >Thanks again,
> > > >Jaromir
> > > >
> > > >
> > > >On 29-Nov-23 10:28:38 AM, "Taeumel, Marcel via Squeak-dev"
> > > ><squeak-dev(a)lists.squeakfoundation.org> wrote:
> > > >
> > > >>Hi Jaromir --
> > > >>
> > > >>Looks good. Still, what about that #test16HandleSimulationError
> >now?
> > > >>:-) It is failing with your changes ... how would you adapt it?
> > > >>
> > > >>
> > > >>
> > > >>Best,
> > > >>Marcel
> > > >>>Am 28.11.2023 01:29:39 schrieb Jaromir Matas <mail(a)jaromir.net>:
> > > >>>
> > > >>>Hi Eliot, Marcel, all,
> > > >>>
> > > >>>I've sent a fix Kernel-jar.1539 to the Inbox that solves the
> > > >>>remaining bit of the chain of bugs described in the previous post.
> > > >>>All tests are green now and I think the root cause has been found
> >and
> > > >>>fixed.
> > > >>>
> > > >>>In this last bit I've created a version of stepToCallee that would
> > > >>>identify a potential illegal return to a nil sender and avoid it.
> > > >>>
> > > >>>Now this example can be debugged without any problems:
> > > >>>
> > > >>>[[self halt. ^ 1] on: BlockCannotReturn do: #resume ] fork
> > > >>>
> > > >>>If you're happy with the solution in Kernel-jar.1539,
> > > >>>Kernel-jar.1538, Kernel-jar.1537 and the test in
> >KernelTests-jar.447,
> > > >>>could you please double-check and merge, please? (And remove
> > > >>>Kernel-mt.1534 and Tools-jar.1240 from the Inbox)
> > > >>>
> > > >>>Best,
> > > >>>Jaromir
> > > >>>
> > > >>>
> > > >>>
> > > >>>On 27-Nov-23 12:09:37 AM, "Jaromir Matas" <mail(a)jaromir.net>
> >wrote:
> > > >>>
> > > >>>>Hi Eliot, Christoph, all
> > > >>>>
> > > >>>>It looks like there are some more skeletons in the closet :/
> > > >>>>
> > > >>>>If you run this example
> > > >>>>
> > > >>>>[[self halt. ^ 1] on: BlockCannotReturn do: [:ex | ex resume] ]
> >fork
> > > >>>>
> > > >>>>and step over halt and then step over ^1 you get a nonsensical
> >error
> > > >>>>as a result of decoding nil as an instruction.
> > > >>>>
> > > >>>>It turns out that the root cause is in the #return:from: method:
> >it
> > > >>>>only checks whether aSender is dead but ignores the possibility
> >that
> > > >>>>aSender sender may be nil or dead in which cases the VM also
> > > >>>>responds with sending #cannotReturn, hence I assume the simulator
> > > >>>>should do the same. In addition, the VM nills the pc in such
> > > >>>>scenario, so I added the same functionality here too:
> > > >>>>
> > > >>>>Context >> return: value from: aSender
> > > >>>> "For simulation. Roll back self to aSender and return value
> > > >>>>from it. Execute any unwind blocks on the way. ASSUMES aSender is
> > > >>>>a sender of self"
> > > >>>>
> > > >>>> | newTop |
> > > >>>> newTop := aSender sender.
> > > >>>> (aSender isDead or: [newTop isNil or: [newTop isDead]]) ifTrue:
> > > >>>> "<--------- this is extended ------"
> > > >>>> [^self pc: nil; send: #cannotReturn: to: self with:
> > > >>>>{value}]. "<------ pc: nil is added ----"
> > > >>>> (self findNextUnwindContextUpTo: newTop) ifNotNil:
> > > >>>> "Send #aboutToReturn:through: with nil as the second
> > > >>>>argument to avoid this bug:
> > > >>>> Cannot #stepOver '^2' in example '[^2] ensure: []'.
> > > >>>> See
> > >
> > >>>>http://lists.squeakfoundation.org/pipermail/squeak-dev/2022-June/220975.html
> > >
> > >>>><http://lists.squeakfoundation.org/pipermail/squeak-dev/2022-June/220975.html>"
> > > >>>> [^self send: #aboutToReturn:through: to: self with: {value.
> > > >>>>nil}].
> > > >>>> self releaseTo: newTop.
> > > >>>> newTop ifNotNil: [newTop push: value].
> > > >>>> ^newTop
> > > >>>>
> > > >>>>In order for this to work #cannotReturn: has to be modified as in
> > > >>>>Kernel-jar.1537:
> > > >>>>
> > > >>>>Context >> cannotReturn: result
> > > >>>>
> > > >>>> closureOrNil ifNotNil: [^ self cannotReturn: result to: self
> > > >>>>home sender].
> > > >>>> self error: 'Computation has been terminated!'
> > > >>>>"<----------- this has to be an Error -----"
> > > >>>>
> > > >>>>Then it almost works except when you keep stepping over in the
> > > >>>>example above, you get an MNU error on `self previousPc` in
> > > >>>>#cannotReturn:to:` with your solution of the VM crash. If you
> >don't
> > > >>>>mind I've amended your solution and added the final context where
> > > >>>>the computation couldn't return along with the pc:
> > > >>>>
> > > >>>>Context >> cannotReturn: result to: homeContext
> > > >>>> "The receiver tried to return result to homeContext that cannot
> > > >>>>be returned from.
> > > >>>> Capture the return context/pc in a BlockCannotReturn. Nil the pc
> > > >>>>to prevent repeat
> > > >>>> attempts and/or invalid continuation. Answer the result of
> > > >>>>raising the exception."
> > > >>>>
> > > >>>> | exception previousPc |
> > > >>>> exception := BlockCannotReturn new.
> > > >>>> previousPc := pc ifNotNil: [self previousPc]. "<----- here's a
> > > >>>>fix ----"
> > > >>>> exception
> > > >>>> result: result;
> > > >>>> deadHome: homeContext;
> > > >>>> finalContext: self; "<----- here's the new state, if
> > > >>>>that's fine ----"
> > > >>>> pc: previousPc.
> > > >>>> pc := nil.
> > > >>>> ^exception signal
> > > >>>>
> > > >>>>Unfortunately, this is still not the end of the story: there are
> > > >>>>situations where #runUntilErrorOrReturnFrom: places the two guard
> > > >>>>contexts below the bottom context. And that is a problem because
> > > >>>>when the method tries to remove the two guard contexts before
> > > >>>>returning at the end it uses #stepToCalee to do the job but this
> > > >>>>unforotunately was (ab)using the above bug in #return:from: -
> >I'll
> > > >>>>explain: #return:from: didn't check whether aSender sender was
> >nil
> > > >>>>and as a result it allowed to simulate a return to a "nil
> >context"
> > > >>>>which was then (ab)used in the clean-up via #stepToCalee in the
> > > >>>>#runUntilErrorOrReturnFrom:.
> > > >>>>
> > > >>>>When I fixed the #return:from: bug, the
> >#runUntilErrorOrReturnFrom:
> > > >>>>cleanup of the guard contexts no longer works in that very
> >special
> > > >>>>case where the guard contexts are below the bottom context.
> >There's
> > > >>>>one case where this is being used: #terminateAggresively by
> > > >>>>Christoph.
> > > >>>>
> > > >>>>If I'm right with this analysis, the #runUntilErrorOrReturnFrom:
> > > >>>>should get fixed too but I'll be away now for a few days and I
> >won't
> > > >>>>be able to respond. If you or Christoph had a chance to take a
> >look
> > > >>>>at Kernel-jar.1538 and Kernel-jar.1537 I'd be very grateful. I
> >hope
> > > >>>>this super long message at least makes some sense :)
> > > >>>>Best,
> > > >>>>Jaromir
> > > >>>>
> > > >>>>[1] Kernel-jar.1538, Kernel-jar.1537
> > > >>>>[2] KernelTests-jar.447
> > > >>>>
> > > >>>>
> > > >>>>PS: Christoph,
> > > >>>>
> > > >>>>With Kernel-jar.1538 + Kernel-jar.1537 your example
> > > >>>>
> > > >>>>process :=
> > > >>>> [(c := thisContext) pc: nil.
> > > >>>> 2+3] newProcess.
> > > >>>>process runUntil: [:ctx | ctx selector = #cannotReturn:].
> > > >>>>self assert: process suspendedContext sender sender = c.
> > > >>>>self assert: process suspendedContext arguments = {c}.
> > > >>>>
> > > >>>>works fine, I've just corrected your first assert.
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>On 21-Nov-23 6:40:32 PM, "Eliot Miranda"
> ><eliot.miranda(a)gmail.com>
> > > >>>>wrote:
> > > >>>>
> > > >>>>>Hi Jaromir,
> > > >>>>>
> > > >>>>>>On Nov 20, 2023, at 11:51 PM, Jaromir Matas
> ><mail(a)jaromir.net>
> > > >>>>>>wrote:
> > > >>>>>>
> > > >>>>>>
> > > >>>>>>Hi Eliot,
> > > >>>>>>Very elegant! Now I finally got what you meant exactly :)
> >Thanks.
> > > >>>>>>
> > > >>>>>>Two questions:
> > > >>>>>>1. in order for the enclosed test to work I'd need an Error
> > > >>>>>>instead of Processor debugWithTitle:full: call in
> >#cannotReturn:.
> > > >>>>>>Otherwise I don't know how to catch a plain invocation of the
> > > >>>>>>Debugger:
> > > >>>>>>
> > > >>>>>>cannotReturn: result
> > > >>>>>>
> > > >>>>>> closureOrNil ifNotNil: [^ self cannotReturn: result to: self
> > > >>>>>>home sender].
> > > >>>>>> self error: 'Computation has been terminated!'
> > > >>>>>
> > > >>>>>Much nicer.
> > > >>>>>
> > > >>>>>>2. We are capturing a pc of self which is completely different
> > > >>>>>>context from homeContext indeed.
> > > >>>>>
> > > >>>>>Right. The return is attempted from a specific return bytecode
> >in a
> > > >>>>>specific block. This is the coordinate of the return that cannot
> >be
> > > >>>>>made. This is the relevant point of origin of the cannot return
> > > >>>>>exception.
> > > >>>>>
> > > >>>>>Why the return fails is another matter:
> > > >>>>>- the home context's sender is a dead context (cannot be
> >resumed)
> > > >>>>>- the home context's sender is nil (home already returned from)
> > > >>>>>- the block activation's home is nil rather than a context
> >(should
> > > >>>>>not happen)
> > > >>>>>
> > > >>>>>But in all these cases the pc of the home context is immaterial.
> > > >>>>>The hike is being returned through/from, rather than from; the
> > > >>>>>home's pc is not relevant.
> > > >>>>>
> > > >>>>>>Maybe we could capture self in the exception too to make it
> >more
> > > >>>>>>clear/explicit what is going on: what context the captured pc
> >is
> > > >>>>>>actually associated with. Just a thought...
> > > >>>>>
> > > >>>>>Yes, I like that. I also like the idea of somehow passing the
> > > >>>>>block activation's pc to the debugger so that the relevant
> >return
> > > >>>>>expression is highlighted in the debugger.
> > > >>>>>
> > > >>>>>>
> > > >>>>>>Thanks again,
> > > >>>>>>Jaromir
> > > >>>>>
> > > >>>>>You're welcome. I love working in this part of the system.
> >Thanks
> > > >>>>>for dragging me there. I'm in a slump right now and appreciate
> >the
> > > >>>>>fellowship.
> > > >>>>>
> > > >>>>>>------ Original Message ------
> > > >>>>>>From "Eliot Miranda" <eliot.miranda(a)gmail.com>
> > > >>>>>>To "Jaromir Matas" <mail(a)jaromir.net>
> > > >>>>>>Cc squeak-dev(a)lists.squeakfoundation.org
> > > >>>>>>Date 11/21/2023 2:17:21 AM
> > > >>>>>>Subject Re: Re[2]: [squeak-dev] Re: Resuming on
> >BlockCannotReturn
> > > >>>>>>exception
> > > >>>>>>
> > > >>>>>>>Hi Jaromir,
> > > >>>>>>>
> > > >>>>>>> see Kernel-eem.1535 for what I was suggesting. This example
> > > >>>>>>>now has an exception with the right pc value in it:
> > > >>>>>>>
> > > >>>>>>>[[^1] on: BlockCannotReturn do: [:ex| ex pc inspect. ex
> >resume]]
> > > >>>>>>>fork
> > > >>>>>>>
> > > >>>>>>>The fix is simply
> > > >>>>>>>
> > > >>>>>>>Context>>cannotReturn: result to: homeContext
> > > >>>>>>> "The receiver tried to return result to homeContext that
> > > >>>>>>>cannot be returned from.
> > > >>>>>>> Capture the return pc in a BlockCannotReturn. Nil the pc to
> > > >>>>>>>prevent repeat
> > > >>>>>>> attempts and/or invalid continuation. Answer the result of
> > > >>>>>>>raising the exception."
> > > >>>>>>>
> > > >>>>>>> | exception |
> > > >>>>>>> exception := BlockCannotReturn new.
> > > >>>>>>> exception
> > > >>>>>>> result: result;
> > > >>>>>>> deadHome: homeContext;
> > > >>>>>>> pc: self previousPc.
> > > >>>>>>> pc := nil.
> > > >>>>>>> ^exception signal
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>>The VM crash is now avoided. The debugger displays the method,
> > > >>>>>>>but does not highlight the offending pc, which is no big deal.
> >A
> > > >>>>>>>suitable defaultHandler for B lockCannotReturn may be able to
> >get
> > > >>>>>>>the debugger to highlight correctly on opening. Try the
> > > >>>>>>>following examples:
> > > >>>>>>>
> > > >>>>>>>[[^1] on: BlockCannotReturn do: #resume] fork.
> > > >>>>>>>
> > > >>>>>>>[[^1] on: BlockCannotReturn do: [:ex| ex pc inspect. ex
> >resume]]
> > > >>>>>>>fork
> > > >>>>>>>
> > > >>>>>>>[[^1] value] fork.
> > > >>>>>>>
> > > >>>>>>>They al; seem to behave perfectly acceptably to me. Does this
> > > >>>>>>>fix work for you?
> > > >>>>>>>
> > > >>>>>>>On Fri, Nov 17, 2023 at 3:14 PM Jaromir Matas
> ><mail(a)jaromir.net>
> > > >>>>>>>wrote:
> > > >>>>>>>>Hi Eliot,
> > > >>>>>>>>
> > > >>>>>>>>How about to nil the pc just before making the return:
> > > >>>>>>>>```
> > > >>>>>>>>Context >> #cannotReturn: result
> > > >>>>>>>>
> > > >>>>>>>> self push: self pc. "backup the pc for the sake of
> > > >>>>>>>>debugging"
> > > >>>>>>>> closureOrNil ifNotNil: [^self cannotReturn: result to: self
> > > >>>>>>>>home sender; pc: nil].
> > > >>>>>>>> Processor debugWithTitle: 'Computation has been terminated!'
> > > >>>>>>>>translated full: false
> > > >>>>>>>>```
> > > >>>>>>>>The nilled pc should not even potentially interfere with the
> > > >>>>>>>>#isDead now.
> > > >>>>>>>>
> > > >>>>>>>>I hope this is at least a step in the right direction :)
> > > >>>>>>>>
> > > >>>>>>>>However, there's still a problem when debugging the
> >resumption
> > > >>>>>>>>of #cannotReturn because the encoders expect a reasonable
> >index.
> > > >>>>>>>>I haven't figured out yet where to place a nil check - #step,
> > > >>>>>>>>#stepToSendOrReturn... ?
> > > >>>>>>>>
> > > >>>>>>>>Thanks again,
> > > >>>>>>>>Jaromir
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>>------ Original Message ------
> > > >>>>>>>>From "Eliot Miranda" <eliot.miranda(a)gmail.com>
> > > >>>>>>>>To "Jaromir Matas" <mail(a)jaromir.net>
> > > >>>>>>>>Date 11/17/2023 8:36:50 PM
> > > >>>>>>>>Subject Re: [squeak-dev] Re: Resuming on BlockCannotReturn
> > > >>>>>>>>exception
> > > >>>>>>>>
> > > >>>>>>>>>Hi Jaromir,
> > > >>>>>>>>>
> > > >>>>>>>>>>On Nov 17, 2023, at 7:05 AM, Jaromir Matas
> ><mail(a)jaromir.net>
> > > >>>>>>>>>>wrote:
> > > >>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>>>Eliot, hi again,
> > > >>>>>>>>>>
> > > >>>>>>>>>>Please disregard my previous comment about nilling the
> > > >>>>>>>>>>contexts that have returned. We are indeed talking about
> >the
> > > >>>>>>>>>>context directly under the #cannotReturn context which is
> > > >>>>>>>>>>totally different from the home context in another thread
> > > >>>>>>>>>>that's gone.
> > > >>>>>>>>>>
> > > >>>>>>>>>>I may still be confused but would nilling the pc of the
> > > >>>>>>>>>>context directly under the cannotReturn context help?
> >Here's
> > > >>>>>>>>>>what I mean:
> > > >>>>>>>>>>```
> > > >>>>>>>>>>Context >> #cannotReturn: result
> > > >>>>>>>>>>
> > > >>>>>>>>>> closureOrNil ifNotNil: [^self pc: nil; cannotReturn:
> > > >>>>>>>>>>result to: self home sender].
> > > >>>>>>>>>> Processor debugWithTitle: 'Computation has been
> > > >>>>>>>>>>terminated!' translated full: false.
> > > >>>>>>>>>>```
> > > >>>>>>>>>>Instead of crashing the VM invokes the debugger with the
> > > >>>>>>>>>>'Computation has been terminated!' message.
> > > >>>>>>>>>>
> > > >>>>>>>>>>Does this make sense?
> > > >>>>>>>>>
> > > >>>>>>>>>Nearly. But it loses the information on what the pc actually
> > > >>>>>>>>>is, and that's potentially vital information. So IMO the ox
> > > >>>>>>>>>should only be nilled between the BlockCannotReturn
> >exception
> > > >>>>>>>>>being created and raised.
> > > >>>>>>>>>
> > > >>>>>>>>>[But if you try this don't be surprised if it causes a few
> > > >>>>>>>>>temporary problems. It looks to me that without a little
> > > >>>>>>>>>refactoring this could easily cause an infinite recursion
> > > >>>>>>>>>around the sending of isDead. I'm sure you'll be able to fix
> > > >>>>>>>>>the code to work correctly]
> > > >>>>>>>>>
> > > >>>>>>>>>>Thanks,
> > > >>>>>>>>>>Jaromir
> > > >>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>>>------ Original Message ------
> > > >>>>>>>>>>From "Jaromir Matas" <mail(a)jaromir.net>
> > > >>>>>>>>>>To "Eliot Miranda" <eliot.miranda(a)gmail.com>; "The
> > > >>>>>>>>>>general-purpose Squeak developers list"
> > > >>>>>>>>>><squeak-dev(a)lists.squeakfoundation.org>
> > > >>>>>>>>>>Date 11/17/2023 10:15:17 AM
> > > >>>>>>>>>>Subject [squeak-dev] Re: Resuming on BlockCannotReturn
> > > >>>>>>>>>>exception
> > > >>>>>>>>>>
> > > >>>>>>>>>>>Hi Eliot,
> > > >>>>>>>>>>>
> > > >>>>>>>>>>>
> > > >>>>>>>>>>>
> > > >>>>>>>>>>>------ Original Message ------
> > > >>>>>>>>>>>From "Eliot Miranda" <eliot.miranda(a)gmail.com>
> > > >>>>>>>>>>>To "Jaromir Matas" <mail(a)jaromir.net>
> > > >>>>>>>>>>>Cc "The general-purpose Squeak developers list"
> > > >>>>>>>>>>><squeak-dev(a)lists.squeakfoundation.org>
> > > >>>>>>>>>>>Date 11/16/2023 11:52:45 PM
> > > >>>>>>>>>>>Subject Re: Re[2]: [squeak-dev] Re: Resuming on
> > > >>>>>>>>>>>BlockCannotReturn exception
> > > >>>>>>>>>>>
> > > >>>>>>>>>>>>Hi Jaromir,
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>>On Thu, Nov 16, 2023 at 2:22 PM Jaromir Matas
> > > >>>>>>>>>>>><mail(a)jaromir.net> wrote:
> > > >>>>>>>>>>>>>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.
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>>As Nicolas says, IMO this is best done at the image
> >level.
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>>It could be prevented in the VM, but at great cost, and
> >only
> > > >>>>>>>>>>>>partially. The performance issue is that the last
> >bytecode
> > > >>>>>>>>>>>>in a method is not marked in any way, and that to
> >determine
> > > >>>>>>>>>>>>the last bytecode the bytecodes must be symbolically
> > > >>>>>>>>>>>>evaluated from the start of the method. See implementors
> >of
> > > >>>>>>>>>>>>endPC at the image level (which defer to the method
> >trailer)
> > > >>>>>>>>>>>>and implementors of endPCOf: in the VMMaker code. Doing
> >this
> > > >>>>>>>>>>>>every time execution commences is prohibitively
> >expensive.
> > > >>>>>>>>>>>>The "only partially" issue is that following the return
> > > >>>>>>>>>>>>instruction may be other valid bytecodes, but these are
> >not
> > > >>>>>>>>>>>>a continuation.
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>>Consider the following code in some block:
> > > >>>>>>>>>>>> [self expression ifTrue:
> > > >>>>>>>>>>>> [^1].
> > > >>>>>>>>>>>> ^2
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>>The bytecodes for this are
> > > >>>>>>>>>>>> pushReceiver
> > > >>>>>>>>>>>> send #expression
> > > >>>>>>>>>>>> jumpFalse L1
> > > >>>>>>>>>>>> push 1
> > > >>>>>>>>>>>> methodReturnTop
> > > >>>>>>>>>>>>L1
> > > >>>>>>>>>>>> push 2
> > > >>>>>>>>>>>> methodReturnTop
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>>Clearly if expression is true these should be *no*
> > > >>>>>>>>>>>>continuation in which ^2 is executed.
> > > >>>>>>>>>>>
> > > >>>>>>>>>>>Well, in that case there's a bug because the computation
> >in
> > > >>>>>>>>>>>the following example shouldn't continue past the [^1]
> >block
> > > >>>>>>>>>>>but it silently does:
> > > >>>>>>>>>>>`[[true ifTrue: [^ 1]] on: BlockCannotReturn do: #resume ]
> > > >>>>>>>>>>>fork`
> > > >>>>>>>>>>>
> > > >>>>>>>>>>>The bytecodes are
> > > >>>>>>>>>>> push true
> > > >>>>>>>>>>> jumpFalse L1
> > > >>>>>>>>>>> push 1
> > > >>>>>>>>>>> returnTop
> > > >>>>>>>>>>>L1
> > > >>>>>>>>>>> push nil
> > > >>>>>>>>>>> blockReturn
> > > >>>>>>>>>>>
> > > >>>>>>>>>>>
> > > >>>>>>>>>>>
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>>So even if the VM did try and detect whether the return
> >was
> > > >>>>>>>>>>>>at the last block method, it would only work for special
> > > >>>>>>>>>>>>cases.
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>>It seems to me the issue is simply that the context that
> > > >>>>>>>>>>>>cannot be returned from should be marked as dead (see
> > > >>>>>>>>>>>>Context>>isDead) by setting its pc to nil at some point,
> > > >>>>>>>>>>>>presumably after copying the actual return pc into the
> > > >>>>>>>>>>>>BlockCannotReturn exception, to avoid ever trying to
> >resume
> > > >>>>>>>>>>>>the context.
> > > >>>>>>>>>>>
> > > >>>>>>>>>>>Does this mean, in other words, that every context that
> > > >>>>>>>>>>>returns should nil its pc to avoid being "wrongly"
> > > >>>>>>>>>>>reused/executed in the future, which concerns primarily
> >those
> > > >>>>>>>>>>>being referenced somewhere hence potentially executable in
> > > >>>>>>>>>>>the future, is that right?
> > > >>>>>>>>>>>Hypothetical question: would nilling the pc during returns
> > > >>>>>>>>>>>"fix" the example?
> > > >>>>>>>>>>>Thanks a lot for helping me understand this.
> > > >>>>>>>>>>>Best,
> > > >>>>>>>>>>>Jaromir
> > > >>>>>>>>>>>
> > > >>>>>>>>>>>
> > > >>>>>>>>>>>
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>>Thanks,
> > > >>>>>>>>>>>>>Jaromir
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>><bdxuqalu.png>
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>>------ Original Message ------
> > > >>>>>>>>>>>>>From "Eliot Miranda" <eliot.miranda(a)gmail.com>
> > > >>>>>>>>>>>>>To "Jaromir Matas" <mail(a)jaromir.net>; "The
> >general-purpose
> > > >>>>>>>>>>>>>Squeak developers list"
> > > >>>>>>>>>>>>><squeak-dev(a)lists.squeakfoundation.org>
> > > >>>>>>>>>>>>>Date 11/16/2023 6:48:43 PM
> > > >>>>>>>>>>>>>Subject Re: [squeak-dev] Re: Resuming on
> >BlockCannotReturn
> > > >>>>>>>>>>>>>exception
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>Hi Jaromir,
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>On Nov 16, 2023, at 3:23 AM, Jaromir Matas
> > > >>>>>>>>>>>>>>><mail(a)jaromir.net> wrote:
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>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?
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>Thanks for your reply.
> > > >>>>>>>>>>>>>>>Regards,
> > > >>>>>>>>>>>>>>>Jaromir
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>------ Original Message ------
> > > >>>>>>>>>>>>>>>>From "Nicolas Cellier"
> > > >>>>>>>>>>>>>>><nicolas.cellier.aka.nice(a)gmail.com>
> > > >>>>>>>>>>>>>>>To "Jaromir Matas" <mail(a)jaromir.net>; "The
> > > >>>>>>>>>>>>>>>general-purpose Squeak developers list"
> > > >>>>>>>>>>>>>>><squeak-dev(a)lists.squeakfoundation.org>
> > > >>>>>>>>>>>>>>>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.
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>Le mer. 15 nov. 2023, 23:42, Jaromir Matas
> > > >>>>>>>>>>>>>>>><mail(a)jaromir.net> a écrit :
> > > >>>>>>>>>>>>>>>>>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
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>--
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>Jaromir Matas
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>>--
> > > >>>>>>>>>>>>_,,,^..^,,,_
> > > >>>>>>>>>>>>best, Eliot
> > > >>>>>>>>>><Context-cannotReturn.st>
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>>--
> > > >>>>>>>_,,,^..^,,,_
> > > >>>>>>>best, Eliot
> > > >>>>>><ProcessTest-testResumeAfterBCR.st>