Hello, guest. We have noticed that you are not registered at this bug tracker. Your experience will be greatly enhanced if you log in. To do so, you first must register by clicking on the Register tab at the top. If you are already registered, you can login at the Login tab.
Syndicate Syndicate Listing Display Search Login/Register
Bug Id ?
Reporter ?
MacGDBp / 1.4.1
Status ?
Severity ?
Duplicate Of ?
- none -
Fixed in Revision ?
Mstone ?
Summary ?
Information remains after execution has finished
Report Time ?
August 26, 2011 01:17 AM
Assignment ?
Resolution ?
Priority ?
Dependencies ?
- none -
Mstone (old) ?

For: 1 (100%)
Against: 0 (0%)
Total: 1

August 26, 2011 01:17 AM Luke
The "Variable", "File", and "Code" sections remain even after execution has finished.

Also after you've pushed the "Continue" button and the code is executed it says "Stoping" at the bottom. Press the "Continue" button again and the bar grays out but still says "Stopping".

I've tested 1.4.1 and (got from bug tracker)

March 30, 2012 01:59 AM OsamaBinLogin
after you've done the last Continue and the rest of the page displays on the browser, the @9000 window still shows as though it's paused at the last breakpoint. Would be good if the pink band went away, indicating control is no longer there.

In fact there's a problem in general where you click on a button, and you're not sure if it's doing anything or you have to click again. EG, single stepping by button. Part of the problem is that it's slow, but I can live with that, if the UI shows busy vs stopped. Maybe the wristwatch icon, that would work. The button actuates just fine, looks great. But there's no indication that it's running, although some seconds later, it slowly starts to reconstruct the screen at the next breakpoint - seems to set the pink bar before it puts the proper source file under it, the stack backtrace gets set before that.

I'd rather it displayed it all at once, because that simulates what's going on in the victim program - it doesn't slow down at a breakpoint over a few seconds, it stops instantly - and instantly all the variables have values, the stack is in place and has stopped moving. No reason to paint any of that on the screen until it's all ready to go.

How do I know that it stopped at the end, or at a breakpoint? I have to stare at it for several seconds to see if any other parts of the @9000 window are changing. And, if it's in a loop and keeps hitting the same breakpoint and the visible variables aren't changing, there's absolutely no difference between being stopped at that breakpoint vs the program running. The only way I can tell that the page has finished is by looking at the browser to see if it's got the Reload vs X icon.

September 4, 2019 01:31 PM Robert
It is intentional that the last-displayed information remain in the debugger. In the 2.0 redesign, there is now a clearer status indicator in the toolbar that clearly says "Disconnected" when the debugging session ends.

On September 4, 2019 01:31 PM, Robert changed: