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<mailto:Christoph.Thiede at student.hpi.uni-potsdam.de>
Sent: Thursday, May 5, 2022 13:35
To: squeak-dev<mailto: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.

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?

[cid:image003.png at 01D8608F.62A32B00]

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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20220505/fe70c063/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 4826B8F0B46244139BDA3D9D0E7A9F88.png
Type: image/png
Size: 159 bytes
Desc: 4826B8F0B46244139BDA3D9D0E7A9F88.png
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20220505/fe70c063/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 19AC8B9213B442EE996EB1D55B308628.png
Type: image/png
Size: 61157 bytes
Desc: 19AC8B9213B442EE996EB1D55B308628.png
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20220505/fe70c063/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: BFA78D32233944C99216BECD41B4000D.png
Type: image/png
Size: 161 bytes
Desc: BFA78D32233944C99216BECD41B4000D.png
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20220505/fe70c063/attachment-0005.png>