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 <lewis at mail.msen.com> 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 ...
> > > >
> > > >
> > > > <pastedImage.png>
> > > >
> > > > ??? Press over
> > > >
> > > > Press cmd-dot ???
> > > >
> > > > <pastedImage.png>
> > > >
> > > >
> > > >
> > > >
> > > > 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.

Dave