614212 - Crash fatal assert when jsdStackFrame::GetExecutionContext is called on an uninitialized jsdcontext.

Status: RESOLVED DUPLICATE of bug 623351

(Core :: JavaScript Engine, defect)

Description

[Jan Honza Odvarko [:Honza] (always need-info? me)]

Every time I test Firebug 1.7:
http://crash-stats.mozilla.com/report/index/f080f9e0-05f3-4734-aa21-953212101123

1. Install Firebug 1.7a7, http://getfirebug.com/releases/firebug/1.7X/
2. Install FBTest 1.7b7, http://getfirebug.com/releases/fbtest/1.7/
3. Open Firebug F12
4. Open FBTest: Firebug > Firebug Icon menu > Open Firebug Test Console
5. Put the URL: https://getfirebug.com/tests/content/testlists/firebug1.7.html,
enter
6. Push the button "Run All"

Wait till the crash

I believe the crash is related to the following code (in updateHRefLabelWidth method):

var rules = domUtils.getCSSStyleRules(hrefLabel);

http://code.google.com/p/fbug/source/browse/branches/firebug1.7/content/firebug/net.js#1632

Honza

Comment 1

[Jan Honza Odvarko [:Honza] (always need-info? me)]

One additional note:

I have set browser.cache.memory.enable to false to avoid crash reported in Bug 551001 

Honza

Comment 2

[Boris Zbarsky [:bzbarsky]]

Uh... that's a completely busted stack.  ContentEnumFunc doesn't call into supports arrays.

Comment 3

[Boris Zbarsky [:bzbarsky]]

I never get to the crash you mention; I die much earlier with a fatal assert when jsdStackFrame::GetExecutionContext is called on an uninitialized jsdcontext.

In a release build I can see this continuing on instead and corrupting memory, for sure...  Note that over here in a release build from today I get to the end of the tests without crashing.

Over to jsd for the one definite issue I see.

Comment 4

[John J. Barton]

I guess Boris is on a debug build and thus hits the assert. That is almost certainly a different problem, one that we can narrow down to a test case (I assume it is not intermittent). 

Both Steve Fink and I also see the CSS style rule problem, lets cover that in bug 623351 and use this bug for Boris' assert (which we don't see on non-Debug builds)

Comment 5

[John J. Barton]

I'm changing the summary here, Boris maybe this one is not needed?

Comment 6

[David Mandelin [:dmandelin]]

Re-noming based on comment 5 (waiting for bz to weigh in before unblocking).

Comment 7

[Boris Zbarsky [:bzbarsky]]

I'm not sure what the question is.  John, are you no longer seeing crashes in opt builds?

Or is the question whether I still see the sort of asserts that indicate memory corruption in a debug build?

Comment 8

[John J. Barton]

(In reply to comment #7)
> I'm not sure what the question is.  John, are you no longer seeing crashes in
> opt builds?

I believe the crash honza reported here is a dupe of bug 623351. 

> 
> Or is the question whether I still see the sort of asserts that indicate memory
> corruption in a debug build?

Yes, you reported a problem on debug builds and I wanted to see if it was reproducible and use this bug to fix it.

Comment 9

[Boris Zbarsky [:bzbarsky]]

> I believe the crash honza reported here is a dupe of bug 623351. 

Ah, that seems plausible, yes.

Sounds like we should mark this bug dependent on bug 623351 and I should file a separate bug (and nominate it for blocking) on the issue I saw, yes?

Comment 10

[John J. Barton]

yes I suppose that is the correct solution

Comment 11

[David Mandelin [:dmandelin]]

OK, I'll keep this blocking on the assumption it is a dup of bug 623351.

Comment 12

[John J. Barton]

Boris, FYI, regarding jsdStackFrame::GetExecutionContext, Firebug calls for frame.executionContext only in three places:
  1. When we hit a break and halt to show the user (to disable JS)
  2. When we return from a break (to enable JS)
  3. When we break because of break on error (new in latest SVN commit).
In fixing #3 I realized that Firebug can grab a stack that starts from a chrome window (eg Firebug in browser.xul running its DOM panel) but calls into web page code (toString()), then break because an error. In this case, the executionContext is from the chrome window (my commit causes Firebug to check the executionContext and not break in this case).

Comment 13

[Steve Fink [:sfink] [:s:]]

Are there known steps to reproduce this problem (the uninitialized jsdcontext) without hitting bug 623351 first? I tried, but apparently failed.

Comment 14

[Steve Fink [:sfink] [:s:]]

bz, are you still able to reproduce the uninitialized jsdcontext?

I think it's time to close this bug. There's nothing here that isn't covered by bug 623351, unless the jsdcontext problem is reproducible, in which case it's time for a new bug.

Comment 15

[Boris Zbarsky [:bzbarsky]]

Seems to workforme for the uninitialized bit on TM tip.

Comment 16

[Steve Fink [:sfink] [:s:]]

Ok, thanks!