343511 - JSD asserts when opening mail, jsdthreadstate->stackDepth > 0

Status: RESOLVED FIXED

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

Description

[Andrew Schultz]

With current trunk seamonky, if I have venkman open (and don't exclude browser files) and open mail, JSD dies with 

Assertion failure: jsdthreadstate->stackDepth > 0, at /build/andrew/moz-debug/mozilla/js/jsd/jsd_stak.c:48

Comment 1

[Andrew Schultz]

Attachment: stack for assertion

Comment 2

[Chris Thomas (CTho) [formerly [e-mail] [e-mail]]]

Crashed on WinXP, similar stack, though I was opening Navigator from Venkman.

Comment 3

[James Ross]

I can't get current trunk SeaMonkey to reproduce this, which makes it impossible to actually debug. More reliable steps are needed.

Comment 4

[Andrew Schultz]

Enabling "stop for exceptions" also seems necessary to hit the assertion.  With that, I see this with a clean profile.

Comment 5

[James Ross]

Yeah, I'd figured out that other setting change. Currently, though, my clean SM install is crashing and burning in XUL land when I try to open mail (something is clobbering the variables of a nsXULPrototypeAttribute instance, so it then tries to allocate 4GB of heap space on destruction).

Comment 6

[Andrew Schultz]

that's bug 341595.  delete your fastload file and all will be well (temporarily)

Comment 7

[James Ross]

Attachment: Only assert what is needed

The destruction code has no reason to require a stack depth > 0, it copes fine with no stack in the thread state.

The reason it was getting into this position is strange, and involves our wonderful old friend XBL. With this patch, it does still stop for the "this.docShell has no properties" error, but it has unwound a single stack frame. This is probably related to it being unable to locate the JSD script object for the top stack frame, which originally caused the assertion.

Comment 8

[James Ross]

The JS stack at the point of failure was:

#  Location (current line)
00 chrome://global/content/bindings/browser.xml(0) (internal) (fun: interpreted)
01 chrome://global/content/bindings/browser.xml(420) (fun: interpreted)
02 chrome://global/content/bindings/browser.xml(403) (internal) (fun: interpreted)
03 NATIVE
04 chrome://global/content/charsetOverlay.js(293)

I'm highly suspicious of the top frame, which *should* be pointing at:

http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/xpfe/global/resources/content/bindings/browser.xml&rev=1.47&mark=230#228

One thing that confused me was that the function object for the top frame (cx->fp->fun) did not have the JSFUN_GETTER flag set, which I expected it to.

Comment 9

[Robert Ginda]

Comment on attachment 228603 [details] [diff] [review]
Only assert what is needed

r=rginda

Comment 10

[James Ross]

Checked in --> FIXED.

Comment 11

[James Ross]

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

Comment 12

[James Ross]

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

Comment 13

[Mike Schroepfer]

Comment on attachment 228603 [details] [diff] [review]
Only assert what is needed

a=schrep for drivers - approving all [181approval pending] bugs now that the tree is open.

Comment 14

[James Ross]

Checked in on MOZILLA_1_8_BRANCH.