[squeak-dev] SIGTRAP when Proceeding from BlockCannotReturn

Eliot Miranda eliot.miranda at gmail.com
Fri May 6 23:00:13 UTC 2022


On Thu, May 5, 2022 at 5:50 AM Jaromir Matas <mail at jaromir.net> wrote:

> Hi Marcel, Christoph,
>
>
>
> >> If would be nice if we could integrate some of the proposed fixes from
> you and Jaromir into Trunk/6.0.
>
>
>
> > Sure, this would be very helpful. Unfortunately, it takes a lot of
> energy because many of these proposals and related discussions are very
> convoluted. But I will prioritize this higher on my to-do list. Maybe a
> third opinion/pair of eyes on some of these discussions would also help. :-)
>
>
>
> Just to avoid any confusion, Christoph's proposal avoids BCR "problem" in
> the image nicely IMO and my latest #terminate rewrite in Kernel-jar.1447
> removed any dependency on fixing the BCR situation altogether so both fixes
> can be applied independently of each other :) (Cuis has implemented the
> equivalent of Kernel-jar.1447 a few months ago; no complaints so far :) )
>
>
>
> Thanks,
>
> Jaromir
>
>
>
> *From: *Thiede, Christoph <Christoph.Thiede at student.hpi.uni-potsdam.de>
> *Sent: *Thursday, May 5, 2022 13:35
> *To: *squeak-dev <squeak-dev at lists.squeakfoundation.org>
> *Subject: *Re: [squeak-dev] SIGTRAP when Proceeding from BlockCannotReturn
>
>
>
> Hi Marcel,
>
>
>
> > If would be nice if we could integrate some of the proposed fixes from
> you and Jaromir into Trunk/6.0.
>
>
>
> Sure, this would be very helpful. Unfortunately, it takes a lot of energy
> because many of these proposals and related discussions are very
> convoluted. But I will prioritize this higher on my to-do list. Maybe a
> third opinion/pair of eyes on some of these discussions would also help. :-)
>
>
>
> > ... Still, a VM crash is not acceptable. Is this an issue with the VM or
> some misused primitive?
>
>
>
> I think the VM was simply not designed for resuming from #cannotReturn:.
> If you inspect the sender context in a debugger, you can see that its pc is
> larger than its endPC, which obviously invalid. Until this is fixed on the
> VM side, we could fix this on the image side like in my proposal ... maybe
> with a flag: #workaround.
>

If the Context is not resumable (if it answers true to isDead) then the
image should not schedule it.  Perhaps the best solution is to have the
image mark a context that has provoked a BlockCannotReturn error as dead.
We don't want expensive tests on every process switch, etc.

But for my information, what's the reproducible case leading to the crash
here?


>
> Best,
>
> Christoph
>
> *Von:* Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im
> Auftrag von Taeumel, Marcel
> *Gesendet:* Donnerstag, 5. Mai 2022 12:48:05
> *An:* squeak-dev
> *Betreff:* Re: [squeak-dev] SIGTRAP when Proceeding from BlockCannotReturn
>
>
>
> ... Still, a VM crash is not acceptable. Is this an issue with the VM or
> some misused primitive?
>
>
>
>
>
> Best,
>
> Marcel
>
> Am 05.05.2022 12:46:50 schrieb Marcel Taeumel <marcel.taeumel at hpi.de>:
>
> Hi Christoph --
>
>
>
> If would be nice if we could integrate some of the proposed fixes from you
> and Jaromir into Trunk/6.0.
>
>
>
> Best,
>
> Marcel
>
> Am 04.05.2022 19:59:59 schrieb Thiede, Christoph <
> christoph.thiede at student.hpi.uni-potsdam.de>:
>
>
>
> Hi Lauren,
>
>
>
> I think this issue has already been discussed in Kernel-ct.1405 et al.
> (Squeak Inbox Talk might be a nice way to find all related discussions to
> "BlockCannotReturn"). What do you think about the solutions proposed there?
> :-)
>
>
>
> Best,
>
> Christoph
>
> *Von:* Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im
> Auftrag von Lauren Pullen <drurowin at gmail.com>
> *Gesendet:* Donnerstag, 28. April 2022 07:25:44
> *An:* squeak-dev at lists.squeakfoundation.org
> *Betreff:* [squeak-dev] SIGTRAP when Proceeding from BlockCannotReturn
>
>
>
> I found a VM crash while doing my UI testing.
>
> platform sources revision VM: 202204190959
> runner at Mac-1650369142700.local:work/opensmalltalk-vm/opensmalltalk-vm
> Date: Tue Apr 19 11:59:48 2022 CommitHash: 2a0e785 Plugins: 202204190959
> runner at Mac-1650369142700.local:work/opensmalltalk-vm/opensmalltalk-vm
>
> If you make the novice mistake of putting a ^ in a block and evaluating
> that block after the method returns, a debugger window helpfully appears
> saying BlockCannotReturn.
>
> If you press Proceed the OS will kill Squeak.  No crash.dmp file is
> created for this crash.
>
> The debugger does not respect the value of #isResumable (which
> BlockCannotReturn returns true for, by the way) and always permits the
> user to resume the operation using the Proceed button.  I believe there
> is a method on Exception that also disregards #isResumable  To force an
> operation to never proceed you must return the Exception after signaling
> it.
>
> Where is the best place to fix this?  We can make the debugger respect
> #isResumable and set BlockCannotReturn to return false.  We can also
> make Context>>cannotReturn:to: never return normally.  We can also catch
> nil in the VM.
>
>
>
>

-- 
_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20220506/5ff0ce7e/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 4826B8F0B46244139BDA3D9D0E7A9F88.png
Type: image/png
Size: 159 bytes
Desc: not available
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20220506/5ff0ce7e/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 19AC8B9213B442EE996EB1D55B308628.png
Type: image/png
Size: 61157 bytes
Desc: not available
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20220506/5ff0ce7e/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: BFA78D32233944C99216BECD41B4000D.png
Type: image/png
Size: 161 bytes
Desc: not available
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20220506/5ff0ce7e/attachment-0005.png>


More information about the Squeak-dev mailing list