Closed Bug 425499 Opened 16 years ago Closed 16 years ago

Enabling Firebug 1.1 on page with extjs dom scrolling code crashes Firefox [@ js_Invoke][@ nsXPCWrappedJSClass::CallMethod]

Categories

(Core :: JavaScript Engine, defect)

defect
Not set
critical

Tracking

()

VERIFIED FIXED
mozilla1.9

People

(Reporter: humph, Unassigned)

References

Details

(Keywords: crash, Whiteboard: [firebug-p1])

Crash Data

I've been developing a web app using extjs, and I was trying to debug some dom scrolling code, and the browser crashed.  I was able to reproduce it just about every time, and it seemed to happen when Firebug (1.1) was installed and enabled.

I've attached a reduced test case so you can see for yourself.

Steps to Reproduce:

1) Install Firebug 1.1
2) Unzip and open crash.html
3) Enable Firebug for Local Web Pages
4) Click a node in the treepanel.

This should cause it to crash--it does for me every time.
My zip is too big, with extjs included, so here is a link:

http://cs.senecac.on.ca/~david.humphrey/tmp/firebugcrash.zip
See also 425452, top frames are the same.
I can't get this to crash with firebug1.2, and I can't get firebug1.1 (from a very recent svn) to work (ie, show UI at all) in my trunk nightly.  John J. Barton:  Is there a fix/patch for firebug1.1 that I need?
You could use the release at http://getfirebug.com.

If you use branches/firebug1.1 you'll need to run ant build.xml to get install.rdf . http://code.google.com/p/fbug/source/browse/branches/readme.txt
I did run ant.  Nevertheless, I get a number of "failed to load XPCOM components" (for things in my .svn directory, weirdly) and then an "Error: no element found" from chrome://firebug/content/browserOverlay.xul line 1, followed by a "failed to load overlay" warning.

I'll try the release.
(In reply to comment #6)
> I did run ant.  Nevertheless, I get a number of "failed to load XPCOM
> components" (for things in my .svn directory, weirdly) 

This is a FF3 "feature", happens when you rebuild your profile.  Just run FF again if you don't like the messages, I can't do anything about them.

> and then an "Error: no
> element found" from chrome://firebug/content/browserOverlay.xul line 1,

Also a FF message, very unlikely the error is on line 1. Or even in that xul file :-(  I've not seen this.

> followed by a "failed to load overlay" warning.

Wow, that's cool! I've never actually seen a message when overlays fail.

You might just try it with FF2, I don't know that 1.1 has been run off of svn against FF3.

> 
> I'll try the release




I've requested blocking FF3 for this crash. I have a similar one if this one can't be reproduced.
Blocks: 411814
Flags: blocking1.9?
Whiteboard: [firebug-p1]
John:  Please describe your "similar one" fully?
Please see bug 425452
Do we know when this regressed?
Igor, possibly a regression from your patch on bug 421266?
Summary: Enabling Firebug 1.1 on page with extjs dom scrolling code crashes Firefox → Enabling Firebug 1.1 on page with extjs dom scrolling code crashes Firefox [@ js_Invoke][@ nsXPCWrappedJSClass::CallMethod]
(In reply to comment #12)
> Do we know when this regressed?
> 
I have crashes from 3/14 (FF3b4) that could be similar if we assume the stack is bogus per 425452:
http://crash-stats.mozilla.com/report/index/9a2b04c5-f250-11dc-ba3e-001a4bd46e84
Frame  	Signature  	Source
0 	@0x20202a 	
1 	js_Invoke 	
2 	@0x46a06011 	
3/18 (FF3b5pre) is closer 
http://crash-stats.mozilla.com/report/index/ae1c3c9c-f501-11dc-a170-001a4bd46e84

I used FF3b4 quite a bit so I'd put my bet on early in b5pre.
(In reply to comment #14)
> Igor, possibly a regression from your patch on bug 421266?
> 

Is it based on the stack trace alone? AFAICS the trace just tells that the crash happens somewhere in js_Interpret.
Got the same crash under OS X 10.5 after installing Firebug 1.1b12, visited the following crashreporter site and clicked on Frames. Seems to be a simpler testcase as the one from comment 1.

bp-43687935-fdb7-11dc-8adb-001a4bd43ef6
Severity: normal → critical
Keywords: crash
OS: Windows XP → All
Hardware: PC → All
(In reply to comment #16)
> Is it based on the stack trace alone? AFAICS the trace just tells that the
> crash happens somewhere in js_Interpret.

Yes, and I'm sorry. The assumption was wrong. I did a regression test and found a regression window between 20080322-04 and 20080323-04.

http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2008-03-22+03%3A00%3A00&maxdate=2008-03-23+05%3A00%3A00&cvsroot=%2Fcvsroot

Igor, bug 424376 would fit into this timeframe. Could this be the cause?

It's reproducible for me when logging into Gmail. I have to wait some seconds, then Firefox crashes.
I cant see how this is intended behaviour?
Forbidding a download based on a filename policy that can not be disabled/seen anywhere?
(In reply to comment #19)
> I cant see how this is intended behaviour?
> Forbidding a download based on a filename policy that can not be disabled/seen
> anywhere?

Are you commenting in the right bug?
Sorry about that one, wrong manipulation.
(In reply to comment #15)
> I have crashes from 3/14 (FF3b4) that could be similar if we assume the stack
> is bogus per 425452:

Mmh, I think that I was wrong with my latest tests. If you really have crashes from 03/14 I probably see a different bug which has mainly the same stacktrace and is caused by some other inconsistencies. I'll try to find some time tomorrow to take a look at the mentioned testcase from comment 1. I hope to find the real regression window now.
On a side note, disabling firebug seems to have fixed the crashes here(not a single one in two days, vs 2-3 before)
(In reply to comment #17)
> Got the same crash under OS X 10.5 after installing Firebug 1.1b12, visited the
> following crashreporter site and clicked on Frames. Seems to be a simpler
> testcase as the one from comment 1.
> 
> bp-43687935-fdb7-11dc-8adb-001a4bd43ef6
> 

This one has Firebug on the stack.  Can you try with FF3pre? 
We've done some regression testing and it looks like the problem first appeared on 03-23 (03-21, 03-22 are ok, 03-23 onward crash -- 03-29 didn't seem to crash either (?)).
That would incriminate bug 424376, which has been backed out.  Recent builds should no longer exhibit this issue.  Is that the case?
2008032805 crashed for me
2008033105 did not.
This is for my version of this crash.
Marking fixed by the backout of bug 424376.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Status: RESOLVED → VERIFIED
Flags: blocking1.9?
Target Milestone: --- → mozilla1.9
a non-firebug test case would be greatly appreciated by all.
Flags: in-testsuite-
Flags: in-litmus-
No longer blocks: 411814
Crash Signature: [@ js_Invoke] [@ nsXPCWrappedJSClass::CallMethod]
You need to log in before you can comment on or make changes to this bug.