110387 - Crash on exiting venkman

Status: VERIFIED FIXED

(Other Applications Graveyard :: Venkman JS Debugger, defect, P1)

Description

[Phil Schwartau]

Using a Mozilla debug build 2001-11-14 on WinNT. 
STEPS TO REPRODUCE:

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
7. CRASH!


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

[Phil Schwartau]

Attachment: WinNT stack trace

Comment 2

[z-aillon.c-obsolete2]

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 
/*HM_Loader.js
* by Peter Belesis. v4.0.8 010405

That version of hiermenus may be permanently found here:
http://www.webreference.com/dhtml/column51/HM4-0-8.zip

Comment 3

[Nicolás Lichtmaier]

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

[Phil Schwartau]

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

[Phil Schwartau]

Attachment: Stack trace from Talkback incident TB448725H

Comment 6

[Phil Schwartau]

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

[Robert Ginda]

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.

Comment 8

[Robert Ginda]

I'll work around this with an onclose handler RSN.

Comment 9

[Robert Ginda]

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

Comment 10

[Matthew Mastracci]

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

Comment 11

[Robert Ginda]

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

[Matthew Mastracci]

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

Comment 13

[Robert Ginda]

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

Comment 14

[Robert Ginda]

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

[Robert Ginda]

checked in

Comment 16

[Phil Schwartau]

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


STEPS TO REPRODUCE
1. Load http://warp.mcom.com/u/pschwartau/JSDebuggerDemo/JSDebuggerDemo.html
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.

Comment 17

[Robert Ginda]

I exit cleanly when following those steps.  A stack trace would be very helpful
here.

Comment 18

[Phil Schwartau]

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

[Phil Schwartau]

Attachment: WinNT stack trace

Comment 20

[Robert Ginda]

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.

Comment 21

[Phil Schwartau]

Marking Verified FIXED using Mozilla trunk binary 2002022009 on WinNT.
Following Steps 1-7 in Comment #16, we exit cleanly from Venkman -