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.



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/50332bae/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 55888 bytes
Desc: not available
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20191216/50332bae/attachment-0001.png>