Closed Bug 504392 Opened 11 years ago Closed 11 years ago
topcrash: [@ ns
Global Window::cycle Collection::Unmark Purple(ns ISupports*)]
This is the #6 topcrash overall. nsGlobalWindow is dom, but this stack (from bp-20b3c0b0-ba2d-45e3-9b18-2dd802090714): Frame Module Signature Source 0 xul.dll nsGlobalWindow::cycleCollection::UnmarkPurple(nsISupports*) dom/src/base/nsGlobalWindow.h:433 1 xul.dll nsPurpleBuffer::SelectPointers(GCGraphBuilder&) xpcom/base/nsCycleCollector.cpp:860 2 xul.dll xul.dll@0x9b8e5b 3 xul.dll XPCCycleCollectGCCallback js/src/xpconnect/src/nsXPConnect.cpp:390 4 js3250.dll js_GC js/src/jsgc.cpp:3500 5 js3250.dll JS_GC js/src/jsapi.cpp:2458 6 xul.dll nsXPConnect::Collect() js/src/xpconnect/src/nsXPConnect.cpp:477 7 xul.dll nsCycleCollector::Collect(unsigned int) xpcom/base/nsCycleCollector.cpp:2340 8 xul.dll nsCycleCollector_collect() xpcom/base/nsCycleCollector.cpp:2999 9 xul.dll nsJSContext::CC() dom/src/base/nsJSEnvironment.cpp:3454 10 xul.dll xul.dll@0x320a54 ... then goes to xpcom and xpconnect. Let's try putting this in xpconnect for now?
Component: General → XPConnect
Product: Firefox → Core
QA Contact: general → xpconnect
Version: 3.5 Branch → 1.9.1 Branch
This is currently #3 overall for Firefox 3.5.2. Who wants to own it? (CCing xpconnect peers, except John Bandhauer since I doubt he's still around...)
this isn't xpconnect's fault.
Assignee: nobody → mrbkap
Component: XPConnect → DOM
QA Contact: xpconnect → general
jst: can you think of a good candidate for this? not sure if mrbkap is really the assignee here for a reason or just by default (if the latter, we should probably make him no longer be the default!)
I've looked at this a bit, but without a good testcase it's hard to figure out what's going wrong. It looks like we're trying to unmark an object that's already dead, which shouldn't happen. I looked at the cycle collection and nsISupports macros for nsGlobal*Window, I found one issue (filed as bug 508774) but I don't see how it could cause this crash. (In reply to comment #3) > this isn't xpconnect's fault. I think that's a premature conclusion.
Except that ToParticipant worked a few lines earlier. (Presumably AddPurpleRoot is missing from the stack.) Could there be something that aggregates nsGlobalWindow (i.e., forwards QI to it), but doesn't implement cycle collection itself before forwarding the QI?
er, never mind. Unless something aggregates nsGlobalWindow and implement QI to nsCycleCollectionISupports but forwards the QI for nsXPCOMCycleCollectionParticipant... which seems pretty unlikely.
Not sure how much it'll help if it's a cycle collector crash, but... Bob, Tomcat: Can you run URLs for this signature through your automation to see if they crash?
The analysis at http://dbaron.org/log/20090922-crashes shows: nsGlobalWindow::cycleCollection::UnmarkPurple(nsISupports*) (97 crashes) 65% (63/97) vs. 2% (158/7100) FFComm.dll 63% (61/97) vs. 2% (134/7100) bdGUICtl.dll 63% (61/97) vs. 2% (134/7100) BDUtils.dll 63% (61/97) vs. 2% (134/7100) BTCommon.dll 63% (61/97) vs. 2% (135/7100) BTCommon.ui 63% (61/97) vs. 2% (135/7100) BTCProxy.dll 63% (61/97) vs. 2% (141/7100) npcomm.dll 63% (61/97) vs. 2% (142/7100) txmlx.dll 63% (61/97) vs. 2% (142/7100) txmlutil.dll 63% (61/97) vs. 3% (181/7100) ProductInfo.dll 64% (62/97) vs. 4% (277/7100) mfc80u.dll 57% (55/97) vs. 2% (128/7100) bdguictl.ui so it seems likely that this crash is related to the presence of some of those libraries.
FFComm.dll and bdGUICtl.dll, at least, are part of BitDefender.
Can't ship 3.6 with this bug.
Priority: -- → P2
Who has BitDefender locally, and can understand when/why FFComm.dll and friends are being loaded, and what they hook into?
(In reply to comment #13) > Who has BitDefender locally, and can understand when/why FFComm.dll and friends > are being loaded, and what they hook into? will look into this with a bitdefender version during the weekend
(In reply to comment #13) > Who has BitDefender locally, and can understand when/why FFComm.dll and friends > are being loaded, and what they hook into? FFComm.dll is (Bidefender) Antiphishing - firefox 3 component - its installed by default and when installed its located in the Mozilla Firefox\components folder. (Its also visible as a kind of toolbar in Firefox) and also listed in the Extension Manager Its enabled by default and act like our Safe Browsing Feature. As example when you browse to a phishing url that is listed as Anti Phising you get a kind of Warning screen from Bitdefender that informs you that this site is blocked, etc
I propose that someone make the trek to their office to talk to someone there about the problem. Feel free to expense the elevator ride: http://www.google.com/search?q=bitdefender+castro+mountain+view
Unfortunately, their office at Castro only does global marketing and west coast sales. But I bet their marketing people would happily forward us to the devs.
I've contacted BitDefender's product manager for this toolbar. She says her devs are looking into it, but it's been a week now. They aren't updating bug 521752. Heating the verbage in my email a bit to get their attention again.
Duping against bug 500879 per todays crashkill meeting as this is due to the same reasons.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 500879
Whiteboard: [crashkill] → [crashkill][crashkill-thirdparty]
Crash Signature: [@ nsGlobalWindow::cycleCollection::UnmarkPurple(nsISupports*)]
You need to log in before you can comment on or make changes to this bug.