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@lists.squeakfoundation.org im Auftrag von David T. Lewis lewis@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@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@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@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:
- The debugger gets confused when trying to step over Generator>>nextPut:
(presumably something related to the context swap).
- 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