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

Status: RESOLVED DUPLICATE of bug 500879

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

Description

[[:Cww]]

http://crash-stats.mozilla.com/report/list?product=Firefox&query_search=signature&date=&range_value=1&range_unit=weeks&do_query=1&signature=nsGlobalWindow%3A%3AcycleCollection%3A%3AUnmarkPurple%28nsISupports*%29

Windows only, 3.5 only.

Comment 1

[Samuel Sidler (old account; do not CC)]

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?

Comment 2

[Samuel Sidler (old account; do not CC)]

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...)

Comment 3

[timeless]

this isn't xpconnect's fault.

Comment 4

[Mike Shaver (:shaver emeritus)]

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!)

Comment 5

[Peter Van der Beken [:peterv]]

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.

Comment 6

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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?

Comment 7

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

er, never mind.  Unless something aggregates nsGlobalWindow and implement QI to nsCycleCollectionISupports but forwards the QI for nsXPCOMCycleCollectionParticipant... which seems pretty unlikely.

Comment 8

[Samuel Sidler (old account; do not CC)]

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?

Comment 10

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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.

Comment 11

[Jesse Ruderman]

FFComm.dll and bdGUICtl.dll, at least, are part of BitDefender.

Comment 12

[Mike Beltzner [:beltzner, not reading bugmail]]

Can't ship 3.6 with this bug.

Comment 13

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Who has BitDefender locally, and can understand when/why FFComm.dll and friends are being loaded, and what they hook into?

Comment 14

[Carsten Book [:Tomcat]]

(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

Comment 15

[Carsten Book [:Tomcat]]

(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

Comment 16

[Mike Shaver (:shaver emeritus)]

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

Comment 17

[Wilson Lee [:kourge]]

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.

Comment 18

[Damon Sicore (:damons)]

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.

Comment 19

[Johnny Stenback (:jst)]

Duping against bug 500879 per todays crashkill meeting as this is due to the same reasons.