Closed Bug 504392 Opened 11 years ago Closed 11 years ago

topcrash: [@ nsGlobalWindow::cycleCollection::UnmarkPurple(nsISupports*)]

Categories

(Core :: DOM: Core & HTML, defect, P2, critical)

1.9.1 Branch
x86
Windows XP
defect

Tracking

()

RESOLVED DUPLICATE of bug 500879
Tracking Status
blocking1.9.1 --- needed
status1.9.1 --- wanted

People

(Reporter: cww, Assigned: peterv)

References

Details

(Keywords: crash, topcrash, Whiteboard: [crashkill][crashkill-thirdparty])

Crash Data

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
Keywords: crash
Product: Firefox → Core
QA Contact: general → xpconnect
Version: 3.5 Branch → 1.9.1 Branch
Group: core-security
Blocks: 507951
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...)
blocking1.9.1: --- → .4+
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?
Depends on: 507985
Group: core-security
Flags: wanted1.9.0.x-
Keywords: testcase-wanted
blocking1.9.1: .4+ → needed
Assignee: mrbkap → peterv
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.
Flags: blocking1.9.2+
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.
Whiteboard: [crashkill]
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*)]
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.