<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Exchange Server">
<!-- converted from text --><style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left: #800000 2px solid; } --></style>
</head>
<body>
<meta content="text/html; charset=UTF-8">
<style type="text/css" style="">
<!--
p
{margin-top:0;
margin-bottom:0}
-->
</style>
<div dir="ltr">
<div id="x_divtagdefaultwrapper" dir="ltr" style="font-size:12pt; color:#000000; font-family:Calibri,Helvetica,sans-serif">
<p>Wow, great to hear that you could locate the probable reason! :-)</p>
<p><br>
</p>
<p>By the way, do we have any kind of automation code for the search you did? Is squeak-history capable of doing so? If not, I think such a thing could be a powerful tool!</p>
<p><br>
</p>
<div id="x_Signature">
<div id="x_divtagdefaultwrapper" dir="ltr" style="font-size:12pt; color:rgb(0,0,0); font-family:Calibri,Helvetica,sans-serif,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols">
<div name="x_divtagdefaultwrapper" style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:; margin:0">
<div>
<div class="x__rp_T4" id="x_Item.MessagePartBody">
<div class="x__rp_U4 x_ms-font-weight-regular x_ms-font-color-neutralDark x_rpHighlightAllClass x_rpHighlightBodyClass" id="x_Item.MessageUniqueBody" style="font-family:wf_segoe-ui_normal,"Segoe UI","Segoe WP",Tahoma,Arial,sans-serif,serif,EmojiFont">
<div dir="ltr">
<div id="x_divtagdefaultwrapper"><font face="Calibri,Helvetica,sans-serif,EmojiFont,Apple Color Emoji,Segoe UI Emoji,NotoColorEmoji,Segoe UI Symbol,Android Emoji,EmojiSymbols">
<div id="x_Signature">
<div style="margin:0px"><font style="font-family:Calibri,Arial,Helvetica,sans-serif,serif,EmojiFont"></font></div>
</div>
</font></div>
</div>
</div>
</div>
<div class="x__rp_T4" id="x_Item.MessagePartBody">Best,</div>
<div class="x__rp_T4" id="x_Item.MessagePartBody">Christoph</div>
</div>
<div><font size="2" color="#808080"></font></div>
</div>
</div>
</div>
</div>
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="x_divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>Von:</b> Squeak-dev <squeak-dev-bounces@lists.squeakfoundation.org> im Auftrag von David T. Lewis <lewis@mail.msen.com><br>
<b>Gesendet:</b> Mittwoch, 18. Dezember 2019 04:01:04<br>
<b>An:</b> The general-purpose Squeak developers list<br>
<b>Betreff:</b> Re: [squeak-dev] BUG/REGRESSION while debugging Generator >> #nextPut:</font>
<div> </div>
</div>
</div>
<font size="2"><span style="font-size:10pt;">
<div class="PlainText">On Mon, Dec 16, 2019 at 12:45:28PM -0500, David T. Lewis wrote:<br>
> On Mon, Dec 16, 2019 at 11:53:23AM +0000, Thiede, Christoph wrote:<br>
> > Squeak 5.3beta #19276<br>
> > <br>
> > Image 68021 (64 bit)<br>
> > <br>
> > VM 201911282316<br>
> > <br>
> > Win10 (1903).<br>
> > <br>
> > <br>
> > @Dave As mentioned, in Squeak 5.1, we get an emergency debugger instead of infinite debuggers. I think this point is clearly a regression.<br>
> > <br>
> <br>
> I can also confirm that the emergency debugger part of the problem<br>
> happened somewhere between Squeak4.5-13352 and Squeak4.6-15102.<br>
> Testing with interpreter VM (to totally exclude Cog/Spur as a<br>
> cause), I see the emergency debugger with Squeak4.5-13352, and<br>
> infinite debuggers with Squeak4.6-15102.<br>
> <br>
> I think that this aligns with the Squeak 5.1 -> Squeak 5.2 period,<br>
> so we are both seeing the same thing, and it is not a VM problem.<br>
> <br>
<br>
I have stepped through the update maps in the trunk update stream to<br>
find where this problem was introduced.<br>
<br>
The last good update map is update-nice.282.mcm.<br>
The first bad update map is update-dtl.283.mcm.<br>
<br>
The changes between mcm 282 and 283 include:<br>
Compiler-eem.283 -> Compiler-eem.284<br>
Kernel-eem.854 -> Kernel-eem.857.<br>
<br>
Checking for the regression:<br>
<br>
Load Compiler-eem.284 -> GOOD<br>
Load Kernel-cmm.855 -> GOOD<br>
Load Kernel-dtl.856 -> GOOD<br>
Load Kernel-eem.857 -> BAD<br>
<br>
I have not yet found the root cause, but the problem was apparently<br>
introduced in Kernel-eem.857.<br>
<br>
I am out of time to look at it this evening, but I think this narrows<br>
the problem down to about a dozen method changes :-)<br>
<br>
Dave<br>
<br>
<br>
<br>
<br>
> > See Morphic-ct.1610 for an approach to prevent countless debuggers - I'm afraid it does not fix this problem, but it prevents others.<br>
> > <br>
> > <br>
> > What code are you exactly referring to when you talk about the interrupt handler? Via debugging, I found out that the BlockCannotReturn errors are already raised before interrupting. The debugger chain is only blocking itself. You can test this by putting
a simple #inform: before the Debugger opening.<br>
> > <br>
> <br>
> I was referring to the emergency interrupt handler, which should<br>
> result in just one debugger as you see with your Squeak 5.1 test.<br>
> <br>
> Dave<br>
> <br>
> <br>
> > <br>
> > Maybe the bug is related to the other context simulation bugs I reported a few weeks ago? I could not explain why the error does not occur if you step into ... Via debugging the debugger, I found out that the bug is raised in the debugged process itself,
not in the debugger process.<br>
> > <br>
> > <br>
> > Best,<br>
> > <br>
> > Christoph<br>
> > <br>
> > <br>
> > ________________________________<br>
> > Von: Squeak-dev <squeak-dev-bounces@lists.squeakfoundation.org> im Auftrag von Taeumel, Marcel<br>
> > Gesendet: Montag, 16. Dezember 2019 11:49:55<br>
> > An: John Pfersich via Squeak-dev<br>
> > Betreff: Re: [squeak-dev] BUG/REGRESSION while debugging Generator >> #nextPut:<br>
> > <br>
> > Hi all.<br>
> > <br>
> > I am just investigating this issue. However, looking at the tests for Generator, I would :-) suggest :-) to re-phrase this example:<br>
> > <br>
> > Generator on: [:g | g yield: #foo].<br>
> > <br>
> > -or-<br>
> > <br>
> > Generator on: [:generator | generator yield: #foo].<br>
> > <br>
> > In any case, countless debuggers show up on "step over". "Step into" works fine.<br>
> > <br>
> > [cid:f4de31a1-db76-485a-8eed-ce0b553021f1]<br>
> > <br>
> > Squeak 5.3beta #19273<br>
> > Image 6521 (32 bit)<br>
> > VM: 201911282316 (cog.spur)<br>
> > Windows 10<br>
> > <br>
> > Best,<br>
> > Marcel<br>
> > <br>
> > Am 16.12.2019 02:39:38 schrieb David T. Lewis <lewis@mail.msen.com>:<br>
> > <br>
> > On Sun, Dec 15, 2019 at 08:18:53PM -0500, David T. Lewis wrote:<br>
> > > Hi Eliot,<br>
> > ><br>
> > > On Sun, Dec 15, 2019 at 01:55:13PM -0800, Eliot Miranda wrote:<br>
> > > > Hi David, Hi Christoph,<br>
> > > ><br>
> > > > On Sun, Dec 15, 2019 at 8:52 AM David T. Lewis wrote:<br>
> > > ><br>
> > > > > On Sat, Dec 14, 2019 at 04:09:22PM -0800, Eliot Miranda wrote:<br>
> > > > > ><br>
> > > > > ><br>
> > > > > > > On Dec 14, 2019, at 5:43 AM, Thiede, Christoph<br>
> > > > > Christoph.Thiede@student.hpi.uni-potsdam.de> wrote:<br>
> > > > > > ><br>
> > > > > > > ???<br>
> > > > > > > By request, screenshots from a clean image ...<br>
> > > > > > ><br>
> > > > > > ><br>
> > > > > > ><br>
> > > > > > ><br>
> > > > > > > ??? Press over<br>
> > > > > > ><br>
> > > > > > > Press cmd-dot ???<br>
> > > > > > ><br>
> > > > > > ><br>
> > > > > > ><br>
> > > > > > ><br>
> > > > > > ><br>
> > > > > > ><br>
> > > > > > > The screenshots from 5.1 were made in a clean 5.1 image.<br>
> > > > > > ><br>
> > > > > ><br>
> > > > > > Hi Christoph,<br>
> > > > > ><br>
> > > > > > I???ve tried this in two trunk 64-bit images, one with the<br>
> > > > > V3PlusClosures bytecode set and one with the SistaV1 bytecode set and no<br>
> > > > > problem occurs in either case. If this only happens in a clean 5.1 image<br>
> > > > > then I suspect it has already been fixed.<br>
> > > > > ><br>
> > > > ><br>
> > > > ><br>
> > > > > I can reproduce the problem in my trunk image. Chrostoph's example<br>
> > > > > is to debug this:<br>
> > > > ><br>
> > > > > Generator on: [:stream | stream nextPut: #foo]<br>
> > > > ><br>
> > > > > The failure happens when I step over the #nextPut:<br>
> > > > ><br>
> > > > > If I step into the #nextPut: then all is well.<br>
> > > > ><br>
> > > ><br>
> > > > Interesting. I indeed do step over (/not/ step into) and do /not/ see the<br>
> > > > bug. Dave, Christoph, what VMs are you running?<br>
> > > ><br>
> > ><br>
> > > The VM that I used is:<br>
> > ><br>
> > > /usr/local/lib/squeak/5.0-201911282316/squeak<br>
> > > Open Smalltalk Cog[Spur] VM [CoInterpreterPrimitives VMMaker.oscog-eem.2597]<br>
> > > Unix built on Nov 28 2019 23:23:45 Compiler: 4.2.1 Compatible Clang 7.0.0 (tags/RELEASE_700/final)<br>
> > > platform sources revision VM: 201911282316 <a href="https://github.com/OpenSmalltalk/opensmalltalk-vm.git">
https://github.com/OpenSmalltalk/opensmalltalk-vm.git</a> Date: Thu Nov 28 15:16:31 2019 CommitHash: 4710c5a Plugins: 201911282316
<a href="https://github.com/OpenSmalltalk/opensmalltalk-vm.git">https://github.com/OpenSmalltalk/opensmalltalk-vm.git</a><br>
> > > CoInterpreter VMMaker.oscog-eem.2597 uuid: 7a69be2e-f0d0-4d41-9854-65432d621fed Nov 28 2019<br>
> > > StackToRegisterMappingCogit VMMaker.oscog-eem.2596 uuid: 8500baf3-a5ae-4594-9f3b-08cedfdf1fb3 Nov 28 2019<br>
> > ><br>
> > > But I do not think that this is a VM issue. I get the same result<br>
> > > when I run Christoph's snippet on a trunk-level V3 image with an<br>
> > > interpreter VM. So the issue must be in the image, not in the VM.<br>
> > ><br>
> > <br>
> > Indeed, I did a quick check on Squeak4.6-15102.image with an interpreter<br>
> > VM, and again I get the same symptoms.<br>
> > <br>
> > We are probably seeing two different issues here:<br>
> > <br>
> > 1) The debugger gets confused when trying to step over Generator>>nextPut:<br>
> > (presumably something related to the context swap).<br>
> > <br>
> > 2) The interrupt handler gets confused when trying to figure<br>
> > out what to attach itself to after 1) happens.<br>
> > <br>
> > Both of these are probably issues that have been with us for a long time,<br>
> > and are just now being noticed.<br>
> > <br>
> > Dave<br>
> > <br>
> > <br>
> <br>
<br>
</div>
</span></font>
</body>
</html>