[squeak-dev] SIGTRAP when Proceeding from BlockCannotReturn

Marcel Taeumel marcel.taeumel at hpi.de
Fri May 6 14:39:20 UTC 2022


I just merged Tests-jar.464. Did that test change somehow?

Best,
Marcel
Am 06.05.2022 16:35:14 schrieb Nicolas Cellier <nicolas.cellier.aka.nice at gmail.com>:


Le ven. 6 mai 2022 à 16:26, Marcel Taeumel <marcel.taeumel at hpi.de [mailto:marcel.taeumel at hpi.de]> a écrit :

Hmm... #testSimpleResignalVsOuter1 is still failing.

?
I don't see that, it seems to pass here.
 

Best,
Marcel
Am 06.05.2022 16:13:09 schrieb Marcel Taeumel <marcel.taeumel at hpi.de [mailto:marcel.taeumel at hpi.de]>:
Hi Nicolas --

> I would also consider 1445 1421 and most importantly 1447.

I will also take a look at KernelTests-jar.421 to check whether any new semantics are okay.

Best,
Marcel
Am 06.05.2022 16:00:56 schrieb Nicolas Cellier <nicolas.cellier.aka.nice at gmail.com [mailto:nicolas.cellier.aka.nice at gmail.com]>:
I have merged Kernel-jar.1446 which is trivial (re-signal an Exception).
I would also consider 1445 1421 and most importantly 1447.


Le jeu. 5 mai 2022 à 14:50, Jaromir Matas <mail at jaromir.net [mailto:mail at jaromir.net]> a écrit :

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 [mailto: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 [mailto: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 [mailto: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 [mailto:squeak-dev-bounces at lists.squeakfoundation.org]> im Auftrag von Lauren Pullen <drurowin at gmail.com [mailto:drurowin at gmail.com]>
Gesendet: Donnerstag, 28. April 2022 07:25:44
An: squeak-dev at lists.squeakfoundation.org [mailto: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/20220506/8782f7ed/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/8782f7ed/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/8782f7ed/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/8782f7ed/attachment-0005.png>


More information about the Squeak-dev mailing list