On Mon, Dec 16, 2019 at 11:53:23AM +0000, Thiede, Christoph wrote:
> Squeak 5.3beta #19276
> 
> Image 68021 (64 bit)
> 
> VM 201911282316
> 
> Win10 (1903).
> 
> 
> @Dave As mentioned, in Squeak 5.1, we get an emergency debugger instead of infinite debuggers. I think this point is clearly a regression.
> 

I can also confirm that the emergency debugger part of the problem
happened somewhere between Squeak4.5-13352 and Squeak4.6-15102.
Testing with interpreter VM (to totally exclude Cog/Spur as a
cause), I see the emergency debugger with Squeak4.5-13352, and
infinite debuggers with Squeak4.6-15102.

I think that this aligns with the Squeak 5.1 -> Squeak 5.2 period,
so we are both seeing the same thing, and it is not a VM problem.

> See Morphic-ct.1610 for an approach to prevent countless debuggers - I'm afraid it does not fix this problem, but it prevents others.
> 
> 
> 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.
> 

I was referring to the emergency interrupt handler, which should
result in just one debugger as you see with your Squeak 5.1 test.

Dave


> 
> 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.
> 
> 
> Best,
> 
> Christoph
> 
> 
> ________________________________
> Von: Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im Auftrag von Taeumel, Marcel
> Gesendet: Montag, 16. Dezember 2019 11:49:55
> An: John Pfersich via Squeak-dev
> Betreff: Re: [squeak-dev] BUG/REGRESSION while debugging Generator >> #nextPut:
> 
> Hi all.
> 
> I am just investigating this issue. However, looking at the tests for Generator, I would :-) suggest :-) to re-phrase this example:
> 
> Generator on: [:g | g yield: #foo].
> 
> -or-
> 
> Generator on: [:generator | generator yield: #foo].
> 
> In any case, countless debuggers show up on "step over". "Step into" works fine.
> 
> [cid:f4de31a1-db76-485a-8eed-ce0b553021f1]
> 
> Squeak 5.3beta #19273
> Image 6521 (32 bit)
> VM: 201911282316 (cog.spur)
> Windows 10
> 
> Best,
> Marcel
> 
> Am 16.12.2019 02:39:38 schrieb David T. Lewis <lewis at mail.msen.com>:
> 
> On Sun, Dec 15, 2019 at 08:18:53PM -0500, David T. Lewis wrote:
> > Hi Eliot,
> >
> > On Sun, Dec 15, 2019 at 01:55:13PM -0800, Eliot Miranda wrote:
> > > Hi David, Hi Christoph,
> > >
> > > On Sun, Dec 15, 2019 at 8:52 AM David T. Lewis wrote:
> > >
> > > > On Sat, Dec 14, 2019 at 04:09:22PM -0800, Eliot Miranda wrote:
> > > > >
> > > > >
> > > > > > On Dec 14, 2019, at 5:43 AM, Thiede, Christoph
> > > > Christoph.Thiede at student.hpi.uni-potsdam.de> wrote:
> > > > > >
> > > > > > ???
> > > > > > By request, screenshots from a clean image ...
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > ??? Press over
> > > > > >
> > > > > > Press cmd-dot ???
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > The screenshots from 5.1 were made in a clean 5.1 image.
> > > > > >
> > > > >
> > > > > Hi Christoph,
> > > > >
> > > > > I???ve tried this in two trunk 64-bit images, one with the
> > > > V3PlusClosures bytecode set and one with the SistaV1 bytecode set and no
> > > > problem occurs in either case. If this only happens in a clean 5.1 image
> > > > then I suspect it has already been fixed.
> > > > >
> > > >
> > > >
> > > > I can reproduce the problem in my trunk image. Chrostoph's example
> > > > is to debug this:
> > > >
> > > > Generator on: [:stream | stream nextPut: #foo]
> > > >
> > > > The failure happens when I step over the #nextPut:
> > > >
> > > > If I step into the #nextPut: then all is well.
> > > >
> > >
> > > Interesting. I indeed do step over (/not/ step into) and do /not/ see the
> > > bug. Dave, Christoph, what VMs are you running?
> > >
> >
> > The VM that I used is:
> >
> > /usr/local/lib/squeak/5.0-201911282316/squeak
> > Open Smalltalk Cog[Spur] VM [CoInterpreterPrimitives VMMaker.oscog-eem.2597]
> > Unix built on Nov 28 2019 23:23:45 Compiler: 4.2.1 Compatible Clang 7.0.0 (tags/RELEASE_700/final)
> > platform sources revision VM: 201911282316 https://github.com/OpenSmalltalk/opensmalltalk-vm.git Date: Thu Nov 28 15:16:31 2019 CommitHash: 4710c5a Plugins: 201911282316 https://github.com/OpenSmalltalk/opensmalltalk-vm.git
> > CoInterpreter VMMaker.oscog-eem.2597 uuid: 7a69be2e-f0d0-4d41-9854-65432d621fed Nov 28 2019
> > StackToRegisterMappingCogit VMMaker.oscog-eem.2596 uuid: 8500baf3-a5ae-4594-9f3b-08cedfdf1fb3 Nov 28 2019
> >
> > But I do not think that this is a VM issue. I get the same result
> > when I run Christoph's snippet on a trunk-level V3 image with an
> > interpreter VM. So the issue must be in the image, not in the VM.
> >
> 
> Indeed, I did a quick check on Squeak4.6-15102.image with an interpreter
> VM, and again I get the same symptoms.
> 
> We are probably seeing two different issues here:
> 
> 1) The debugger gets confused when trying to step over Generator>>nextPut:
> (presumably something related to the context swap).
> 
> 2) The interrupt handler gets confused when trying to figure
> out what to attach itself to after 1) happens.
> 
> Both of these are probably issues that have been with us for a long time,
> and are just now being noticed.
> 
> Dave
> 
> 



>