Click on a color frame in color stack dump the stack

[Alisu]

Describe the bug
Click on a color frame in color stack dump the stack

To Reproduce
Steps to reproduce the behavior:

1. In settings chose the option to color the stack in the debugger
2. Make a debugger open
3. Click on a color stack frame
4. All frames with other colors disappear

Expected behavior
I understand that you want to see all the frames in one color but i want to get back the others afterward.

Version information:

• OS: [OSX Mojave]
• Pharo 9

[dupriezt]

I did not manage to reproduce the bug.

Here is what I did:
I checked this setting

Then executed a self halt in a playground.
A debugger opened like this:

I clicked on the stack frame of the halt method like this:

But I did not see other frames disappear.

Pharo 9 - Ubuntu

[Alisu]

OK, i have it with the bug at #6403

then click on do: and empty stack

[dupriezt]

Ok, I managed to reproduce it in that case.
So the steps to reproduce are:

• Set the "Color the stack" setting to true
• open a spotter
• type any letter
• ctrl/command + b (to browse classes)
• type any letter
• you get a DNU "Instance of ByteString did not understand #cull:"
• click the spotter window and close it with escape if it is still open
• in the debugger window, click on any stack frame
  -> all the stack frame bu the first one (doesNotUnderstand:) disapear

[Edit]
I noticed that the problem does not appear (stack frames do not disappear in the debugger) for as long as the spotter window stays open.
When the "color the stack" setting is false, the problem does not appear even if the spotter window has been closed.

[dupriezt]

Hm. I said I didn't have the problem when the "color the stack" setting was false, but now I think it does not matter.
Sometimes, the stack still shows up in the debugger, but clicking on a stack frame does not inspect it.

I think the problem is that the spotter throws an exception, the debugger opens on it (and on the process in which the spotter was running), the spotter window gets closed, which triggers the termination of the corresponding process, which destroys the stack, which prevents the debugger from working normally.
And sometimes, the UI of the debugger will update to show the now empty stack, and other times it will not, but will still not let you inspect the stack frames it displays because it cannot access them anymore.

Tldr: it looks like the issue is that when the spotter window closes, it terminates the process in which it was running, even if that process was being debugged. And the debugger cannot work properly on a terminated process.

[StevenCostiou]

Any news on that issue @dupriezt @Alisu ?

[dupriezt]

I can't reproduce it in Pharo 9. Probably because the main debugger is the spec one now.

[StevenCostiou]

Ok thanks Thomas, I close it, reopen if it reproduces.