Closed Bug 724129 Opened 11 years ago Closed 11 years ago

crash in nsXBLDocumentInfo::cycleCollection::Traverse (caused by addons?)


(Core :: XBL, defect)

10 Branch
Not set



Tracking Status
firefox10 + ---


(Reporter: mccr8, Unassigned)



(Keywords: crash, reproducible, topcrash)

Crash Data


(1 file)

NoteXPCOMChild is showing up as the top crash in 10, after the giant pile of empty stacks.  If I am reading this right, it is about 18.7% of crashes in 10.  It was about 2% of crashes in 10b3, 5% in 10 beta5 and 12% in beta 6.

All the ones I've looked at look like this:

1 	xul.dll 	GCGraphBuilder::NoteXPCOMChild 	xpcom/base/nsCycleCollector.cpp:1710
2 	xul.dll 	TraverseBinding 	content/xbl/src/nsXBLPrototypeBinding.cpp:389
3 	xul.dll 	hashEnumerate 	xpcom/ds/nsHashtable.cpp:130
4 	xul.dll 	PL_DHashTableEnumerate 	obj-firefox/xpcom/build/pldhash.cpp:755
5 	xul.dll 	TraverseProtos 	content/xbl/src/nsXBLDocumentInfo.cpp:435
6 	xul.dll 	hashEnumerate 	xpcom/ds/nsHashtable.cpp:130
7 	xul.dll 	PL_DHashTableEnumerate 	obj-firefox/xpcom/build/pldhash.cpp:755
8 	xul.dll 	nsXBLDocumentInfo::cycleCollection::Traverse 	content/xbl/src/nsXBLDocumentInfo.cpp:473

Correlations suggest it may be addon related.
Crash Signature: [@ GCGraphBuilder::NoteXPCOMChild(nsISupports*) ]
NoteXPCOMChild is only about 2% of crashes in 11, which kind of suggests it isn't a code change.  But who knows.
Looks like they are mostly happening within 15 seconds, so probably the first or second CC after startup.
Neal and bz: JST and I were looking over the XBL code, and it looks like Read/WritePrototypeBindings is new in 10 (bug 94199).  Is it possible that this could cause some kind of startup crash after upgrading from 9?
Possible, sure...

None of the crashes I see have the stack from comment 0, though.  I do see some crashing from the NoteXPCOMChild(mBinding) call in nsXBLPrototypeBinding::Traverse.

Andrew, were the crashes you were looking at with the stack from comment 0 null-derefs, or something else?
Also, is NoteXPCOMChild null-safe?
Most of the ones I see are like that, so maybe we're looking at different lists or something.  Here are 3 out of 5 reports I looked at:

The most common thing seems to be EXCEPTION_ACCESS_VIOLATION_EXEC on addresses that look kind of like 0x4246c83.  Hmm.  In fact, at least judging from the first page of crash reports, the bulk of the crashes are READs or EXECs of that exact address, 0x4246c83.  Mostly EXECs.  That seems... suspicious.

NoteXPCOMChild it should return right off the bat if it is passed null. is also a very common extension for these crashes.
I was just looking at the list a search for NodeXPCOMChild gave me on crash-stats, and looking at the crashes for 10.

The crash is on this line:

  if (!child || !(child = canonicalize(child)))

Does this involve a virtual function call, perhaps?  If we always pass in things with the same busted vtable that would explain EXEC on the same address...
Ah ok.  I clicked on the link it gave for NoteXPCOMChild that it gives when you go to top crashes for 10.

Canonicalize is basically just a wrapper around a QI:
1313 canonicalize(nsISupports *in)
1314 {
1315     nsISupports* child;
1316     in->QueryInterface(NS_GET_IID(nsCycleCollectionISupports),
1317                        reinterpret_cast<void**>(&child));
1318     return child;
1319 }

It probably gets inlined.  Does a QI involve a virtual call?  I'm not really sure how that all works.
Ah, right, the in->QI is a virtual method invocation...
That's my best guess so far, then, though having the same exact value there is still pretty odd....
Tomer Cohen posted the following over in bug 724267:
This bug was filed from the Socorro interface and is 
report bp-186ed3b4-f1df-49a3-a471-b99d02120204 .

Since the last upgrade (9.0.1→10.0), Windows Firefox users are reporting on our community forum about a startup crash every time the browser starts. While we could not easily reproduce it on our own machines, we've found that we could fix it by giving the following instructions to users: 

a. Start Firefox in Safe-Mode (Please note that the usual routine of restarting in safe mode from the Help menu won't help because the users can't access Firefox UI)
b. Tools→Addons
c. Uninstall Greasemonkey

My tests show that aftere re-installing Greasemonkey on the users machines, nothing wrong happened, so it is safe to remove and reinstall.

See URL below for our forum thread and lists of crash ids.
Summary: crash in nsXBLDocumentInfo::cycleCollection::Traverse → crash in nsXBLDocumentInfo::cycleCollection::Traverse (caused by addons?)
Duplicate of this bug: 724267
Juan and I both tested the Oberon toolbar you get from their site by downloading a game, but I noted in my test results that it didn't seem to be the same version that some was in some individual reports. Also another thing I noted while combing through individual reports is a number of people had more than one toolbar installed in their extension list (Obernon and Yahoo, Oberon and MSN, etc)

(In reply to Andrew McCreight [:mccr8] from comment #7)
> is also a very common extension for these crashes.
Thanks, Tomer Cohen, that's very interesting!  So it sounds like it is not the addon per se that is causing the problem, but the browser has some information associated with it that is causing problems in 10.  Sounds like it could be related to bug 94199, but I don't know anything about how caching for addon-related information works.  What kinds of things does the browser save along with an addon that would be deleted when the addon is uninstalled?

Marcia, it sounds like it might be worth trying starting up the browser in 9 with some of these addons installed, using it for a little bit, then upgrading to 10.
Attaching some of the toolbar version correlations to help in the hunt.

Juan, Anthony and I were posting our testing results here:

So far we tried a number of combinations and have not been able to reproduce the crash. As I noted, I don't believe I had the version of the Oberon toolbar that seems to be highly correlated in the attached report. Will keep trying some combinations. In all cases I started with all the extensions in FF 9.0.1 and then moved to 10 via update.
Installing/unistalling an addon will invalidate the startup cache. If this is caused by 94199, you won't see the bug on the next startup (since there isn't anything cached any more) but you might see a crash on later startups.
Went back to my VM and I am now able to reproduce the issue consistently in a Win XP VM with the configuration I have - Neil was absolutely correct in that it did not show until later startups.  Here are the addons I have installed:

        Add-on Compatibility Reporter

        Ant Video Downloader
        true Community Toolbar

        freeride games Community Toolbar

        Music Player Minion 2

        Yahoo! Toolbar


        Microsoft .NET Framework Assistant

        ZoneAlarm Security Engine

(In reply to Neil Deakin from comment #17)
> Installing/unistalling an addon will invalidate the startup cache. If this
> is caused by 94199, you won't see the bug on the next startup (since there
> isn't anything cached any more) but you might see a crash on later startups.
I've backed up a profile directory of an affected computer, than run into uninstalling GreaseMonkey. After seeing everything went smooth, I reverted back to the old profile directory, and I am unable to reproduce the issue now.

(I was unable to reproduce it on my own computer(s), so I borrowed a computer with a crashing browser)
I will try to narrow down and see which addon is the truly problematic one. was one of my crash reports.

After the crash you can relaunch, but just trying to open a new tab or do something in the URL bar seems to generate a crash quite easily.
Keywords: reproducible
Adding Juan and Anthony so they can track what the status is.
I have done some additional testing with the set of addons in the attachment.  So far I tried doing the following:

1. Disabled Yahoo Toolbar - still crashed
2. Disabled Ant Community toolbar - still crashed
3. Disabled Music Minion Player - no crash yet

I will keep trying to see if getting to Step 3 really prevents the crash and will play around with some other combinations.

One additional note: Having zone alarm installed, it sometimes detects the browser as "unstable" and restarts it when you hit OK. So people that have that program installed may have less instances of the crash since it restarts the browser before the crash in some instances.
Please note that the issues I was facing was not involved these toolbars. It might be possible that it is caused by a common addons component, though.
Severity: normal → critical
Keywords: crash
I am still hearing about people facing this issue, including one who is saying that it appeared on 20 computers he is responsible for. Others are saying this is caused by Greasemonkey or Video Downloader. Should I publish here more user reports or we have enough of them?
As a workaround deleting the startupcache (wherever it is on Windows) should help.
> As a workaround deleting the startupcache (wherever it is on Windows)

On Windows 2000 and Windows XP:
%USERPROFILE%\Local Settings\Application Data\Mozilla\Firefox\Profiles\<ZZZZZZ>.default\startupCache\

On Windows Vista and later:

Note: Local profile folder rather than the main roaming one.
People are reporting on our forum (mozilla-il) that this issue disappeared to them after updating to 10.0.1, and their workaround on 10.0 was to disable the greasemonkey addon. I'm not sure if this is the case as they had to workaround the problem in order to update, and if they did it probably the workaround still in affect. 

We have a lot of crash-ids there for further investigations.
10.0.1 included a fix for this issue.  Thanks for the update!  Good to know that it helped.
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla10
You need to log in before you can comment on or make changes to this bug.