Crash on exiting venkman

VERIFIED FIXED in mozilla0.9.9


Other Applications
Venkman JS Debugger
16 years ago
13 years ago


(Reporter: Phil Schwartau, Assigned: Robert Ginda)



Windows NT

Firefox Tracking Flags

(Not tracked)




(4 attachments)



16 years ago
Using a Mozilla debug build 2001-11-14 on WinNT. 

1. Load the given site
2. Set a breakpoint in venkman, say inside the function HM_f_ItemOver()
3. Mouseover the DHTML menus at the site
4. Hit "F5", "F10", "F11", etc. in venkman to keep code execution going
5. Repeat steps 3 and 4 for a while
6. x-dismiss venkman

Will attach WinNT stack trace below. Note: in the MS c++ debugger, 
the Alt+4 window (for trees of local values) included this at the top:

 _jsd_global_lock     0x05941450

I don't know if that's relevant or not...

Comment 1

16 years ago
Created attachment 58046 [details]
WinNT stack trace


16 years ago
Keywords: crash

Comment 2

16 years ago
The site is being evangelized in bug 110287.  As a result the files on that page
are subject (hopefully) to change soon.

For reference, note that the version of HierMenus being used is 
* by Peter Belesis. v4.0.8 010405

That version of hiermenus may be permanently found here:

Comment 3

16 years ago
Hi, Mozilla just crashed on me when closing the Javascript debugger. The
talkback id is TB448725H.

I'm on Linux, using build 2001121108.

Comment 4

16 years ago
For some reason, incident TB448725H exists but is coming up blank
off the Talkback server. I've got a ticket in to see what's up.

Comment 5

16 years ago
Created attachment 61986 [details]
Stack trace from Talkback incident TB448725H

Comment 6

16 years ago
The Talkback stack trace looks the same as the debug stack trace above.

Nicolás: do you recall if you exited venkman while still in the process of 
debugging? That's what I did: I exited while there was still a "yellow line" 
highlighting a line of code.

Comment 7

16 years ago
This looks like the #1 reason people crash in venkman, according to talkback. 
Venkman can't deal with being closed while it is stopped at a breakpoint.
Severity: normal → critical
Priority: -- → P1

Comment 8

16 years ago
I'll work around this with an onclose handler RSN.
Target Milestone: --- → mozilla0.9.9

Comment 9

16 years ago
*** Bug 121499 has been marked as a duplicate of this bug. ***

Comment 10

16 years ago
I guess the best behaviour might just be to resume execution onclose.  

Comment 11

16 years ago
I thought I'd pop up a "You are stopped at a breakpoint, are you sure you want
to exit the debugger?" dialog, and continue if they said "Yes, exit".

"resume execution" requires that the call stack completely unwind first, which
means we *can't* alow the window to close while we're stopped.  I'll have to
cancel the close, and set a timeout to do the real one, or something.

Comment 12

16 years ago
Could the window visually disappear until the call stack unwound, when the
debugger is in a state to shut down?

Comment 13

16 years ago
I don't think so, XUL doesn't allow JS to hide top level windows AFAIK.

Comment 14

16 years ago
Created attachment 67053 [details] [diff] [review]
ui patch

I'm going to check this on and move on, but if anyone has comments on the patch
please feel free to say so.

Comment 15

16 years ago
checked in
Last Resolved: 16 years ago
Resolution: --- → FIXED

Comment 16

16 years ago
Using Mozilla binary 2002020411 on WinNT; have to reopen this. 

1. Load
2. Set a breakpoint on the single line in function showTest()
3. In the browser, click on the red row (i.e. the bottom one)
4. You are now stopped at the breakpoint
5. x-dismiss Venkman
6. You get an alert, "Debugging in progress, close anyway?"
7. Click OK
8. Crash -

I don't have a current debug build; will post a stack trace when I do.
Resolution: FIXED → ---

Comment 17

16 years ago
I exit cleanly when following those steps.  A stack trace would be very helpful

Comment 18

16 years ago
Confirming crash on Linux as well, as outlined in Comment #16.
I crash on both a debug Mozilla build and a trunk binary, both
dating from today. 

Unfortunately my debug build is taking forever to load under the
gdb and ddd debuggers, so I can't get a stack trace yet. Will
rebuild and try again tomorrow -

Comment 19

16 years ago
Created attachment 68164 [details]
WinNT stack trace

Comment 20

16 years ago
I think I see the problem.  I hadn't tested to see if the debugger was still on
before re-connecting the hooks in jsdService::unPause().  I've checked in a test
that should fix this.
Last Resolved: 16 years ago16 years ago
Resolution: --- → FIXED

Comment 21

16 years ago
Marking Verified FIXED using Mozilla trunk binary 2002022009 on WinNT.
Following Steps 1-7 in Comment #16, we exit cleanly from Venkman -
Product: Core → Other Applications
You need to log in before you can comment on or make changes to this bug.