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.

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.


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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20191216/9eb5a3a9/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 55888 bytes
Desc: image.png
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20191216/9eb5a3a9/attachment-0001.png>