[squeak-dev] BUG/REGRESSION while debugging Generator >> #nextPut:

Thiede, Christoph Christoph.Thiede at student.hpi.uni-potsdam.de
Wed Dec 18 08:07:49 UTC 2019


Wow, great to hear that you could locate the probable reason! :-)


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!


Best,
Christoph
________________________________
Von: Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im Auftrag von David T. Lewis <lewis at mail.msen.com>
Gesendet: Mittwoch, 18. Dezember 2019 04:01:04
An: The general-purpose Squeak developers list
Betreff: Re: [squeak-dev] BUG/REGRESSION while debugging Generator >> #nextPut:

On Mon, Dec 16, 2019 at 12:45:28PM -0500, David T. Lewis wrote:
> 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.
>

I have stepped through the update maps in the trunk update stream to
find where this problem was introduced.

The last good update map is update-nice.282.mcm.
The first bad update map is update-dtl.283.mcm.

The changes between mcm 282 and 283 include:
  Compiler-eem.283 -> Compiler-eem.284
  Kernel-eem.854 -> Kernel-eem.857.

Checking for the regression:

  Load Compiler-eem.284 -> GOOD
  Load Kernel-cmm.855 -> GOOD
  Load Kernel-dtl.856 -> GOOD
  Load Kernel-eem.857 -> BAD

I have not yet found the root cause, but the problem was apparently
introduced in Kernel-eem.857.

I am out of time to look at it this evening, but I think this narrows
the problem down to about a dozen method changes :-)

Dave




> > 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
> >
> >
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20191218/4036fe66/attachment.html>


More information about the Squeak-dev mailing list