Hi Marcel, Nicolas, Eliot,


> (Nicolas) I have merged Kernel-jar.1446 which is trivial (re-signal an Exception).

Thanks!

> (Marcel) Hmm... #testSimpleResignalVsOuter1 is still failing.

In my latest trunk image it passes ok (5/7/22)

>> (Marcel) I will also take a look at KernelTests-jar.421 to check whether any new semantics are okay.
>>
> (Nicolas) Yes, I did that and got two failing tests
> testTerminateTerminatingProcess
> testResumeTerminatingProcess
>
> both failures look the same, in second self assert: terminator isSuspended.

Yes, they are supposed to fail at the moment so I suggest to make them expected failures/feature requests. However there's a stupid bug in both I’ve fixed now: they were indeed supposed to fail the following assertion:
``` self should: [terminatee terminate] raise: Error. ```

Apologies for the confusion - an updated changeset is enclosed.


However, there's another issue regarding the revised #suspend semantics Eliot has been working on. I've updated the process tests in KernelTests-jar.421 to test both the old and the new #suspend semantics. The two semantics should be distinguishable via Smalltalk processSuspensionUnblocks flag answering true in case of the old semantics and false in case of the revised one; my updated tests use this logic. However, unfortunately the latest VM answers "false" but uses the OLD suspend semantics in #suspend prim 88.

So I'm surprised you haven't observed more tests failing due to the new suspend semantics... What VM have you used – an older one? I'm on the latest trunk's VM 3183. And what is the answer of Smalltalk processSuspensionUnblocks? :) I'm utterly confused...

Hi Eliot - I may be confused here but if the current VM uses the old #suspend prim 88 semantics, shouldn't ```Smalltalk processSuspensionUnblocks``` answer true?


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

Regarding 1421: alternatively, you might consider a newer version 1415 where the only difference is #return:from: passes a block instead of nil to #resume:through: to cause a fresh search for the first unwind context; otherwise they are equivalent.

> (Marcel) Maybe we can just merge
>
> KernelTests-jar.393
> KernelTests-jar.418
> KernelTests-jar.421
>
> And go from there? Or are there any objections?

KernelTests-jar.393 is just a special case of a more general KernelTests-jar.418 test…

In my image all tests are green provided Smalltalk processSuspensionUnblocks answers true and the two above tests Nicolas mentioned are marked expected failures :)

Thanks very much for your feedback,
Jaromir


--

Jaromír Matas

mail at jaromir.net

From: Marcel Taeumel<mailto:marcel.taeumel at hpi.de>
Sent: Friday, May 6, 2022 16:53
To: squeak-dev<mailto:squeak-dev at lists.squeakfoundation.org>
Subject: Re: [squeak-dev] SIGTRAP when Proceeding from BlockCannotReturn

Maybe we can just merge

KernelTests-jar.393
KernelTests-jar.418
KernelTests-jar.421

And go from there? Or are there any objections?

What we cannot treat in time would become part of #expectedFailures?

Best,
Marcel

Am 06.05.2022 16:39:20 schrieb Marcel Taeumel <marcel.taeumel at hpi.de>:
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?

[cid:image002.png at 01D86221.0A458280]

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/20220507/aaab7c95/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: E005684B50144929B96559671E70ECE9.png
Type: image/png
Size: 156 bytes
Desc: E005684B50144929B96559671E70ECE9.png
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20220507/aaab7c95/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: E9CFE92E94774E5B84DC587AF7988305.png
Type: image/png
Size: 47496 bytes
Desc: E9CFE92E94774E5B84DC587AF7988305.png
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20220507/aaab7c95/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 7F329E8B5C244E1BB6D71B6833A6159A.png
Type: image/png
Size: 170 bytes
Desc: 7F329E8B5C244E1BB6D71B6833A6159A.png
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20220507/aaab7c95/attachment-0005.png>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: ProcessTest.jar.1.cs
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20220507/aaab7c95/attachment-0001.ksh>