500879 - Random thread-safety topcrash [@ nsCycleCollectingAutoRefCnt::decr(nsISupports*) ] and [@nsEventListenerManager::Release() ]

Status: RESOLVED DUPLICATE of bug 521750

(Core :: XPCOM, defect, P2)

Description

[Jon]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1) Gecko/20090624 Firefox/3.5 GTB5 (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1) Gecko/20090624 Firefox/3.5 GTB5 (.NET CLR 3.5.30729)

I started using Firefox 3.5 Beta 4 (currently on RC3) due to a crash on startup which I had presumed would be fixed.  

See https://bugzilla.mozilla.org/show_bug.cgi?id=466850

I am however still getting crashes, again in xul.dll though this time at a different point.

See the following crash reports:
bp-31fc4c75-33a3-4430-bbf1-19c352090626
bp-dccbaf5b-a037-42d8-905b-a92352090625
bp-f78cd5f9-d577-4a58-87eb-5f7e42090621


Reproducible: Sometimes

Steps to Reproduce:
Unfortunately as this is random I'm unable to list steps.

I generally have a few tabs open and session restore is set to always which I am only guessing is related.

The URLs I had open last time were:
http://spreadsheets.google.com/ccc?key=rVvHpDLUsTAebMdYK0Pb4Rw&hl=en
http://battleforge.wikia.com/wiki/Mo_(Map)/Loot_Data
http://bfcards.info/search.php

Actual Results:  
Random crashes

Expected Results:  
Browser should start up.

Crashing thread in xul.dll

Comment 1

[Matthias Versen [:Matti]]

0 xul.dll nsCycleCollectingAutoRefCnt::decr obj-firefox/dist/include/xpcom/nsISupportsImpl.h:197  
1 xul.dll nsGenericElement::Release content/base/src/nsGenericElement.cpp:4124  
2 xul.dll nsCOMPtr_base::~nsCOMPtr_base obj-firefox/xpcom/build/nsCOMPtr.cpp:81  
3 xul.dll nsXBLBinding::GenerateAnonymousContent content/xbl/src/nsXBLBinding.cpp:800  

Do you have any addons installed / tested without addons (safemode) ?

Comment 2

[Jon]

First thanks for the prompt response.

I do have a number of addons installed.

I haven't tested without them all.  Disabling them all and waiting a number of days to see if this happens again isn't all that practical.

For now I'll disable all but the following (my "essential" list) and let you know if it happens again:
Google Toolbar
Vimperator
Net Usage Item

If I manage to reproduce this more readily I'll try disabling them all.

Comment 3

[Jon]

I've disabled all addons and plugins apart from Vimperator and still get the crash so I did a bit of Google work.

It may be related to a "debug" build of Firefox (which I can only assume the RC versions are) and Vimperator.
http://vimperator.org/trac/ticket/207

I've also just tried setting the nopreload option in my vimperatorrc file to see if that resolves this.

Comment 4

[Tyler Downer [He/Him]]

You can create a new profile, install the extension, and see if it happens there. Then we can rult out corruption. Also, try with out the extension.

Comment 5

[Jon]

I've tried all I can to cause the crash (frequent restarts of Firefox) since making the change to the vimperatorrc file but so far it's been good.  I suspect this is solved, though obviously won't know for a few days yet.

If it's possible to reopen this if it's mark resolved then perhaps mark it as such and I'll only reopen it if the crash recurs.

Thanks for the help folks.

Comment 6

[Tyler Downer [He/Him]]

OK, please reopen if it still happens.

Comment 7

[Matthew Middleton (:zzxc)]

This is the #6 topcrash in 3.5.1, reopening.

Some of these crash reports have a roboform module in the stack, such as bp-bb2adc55-acd9-4fb2-a8dc-947d82090720

Comment 8

[[:Cww]]

Is this the norton hotfix + roboform = crash stack?

Comment 9

[Stuart Bell]

I don't know whether this will help, but I was until recently also experiencing frequent crashes in FF 3.5.1 and FF 3.5.2. These crashes would occur even when I was not using the computer. The crash reports suggest that the crashes are related to this bug.

In my case, the problem appeared to be the FingerAuth extension, which allows me to use a Microsoft Fingerprint Reader to fill in username/password fields on websites. The problem did not occur in FF 3.5.0: it first developed after upgrade to FF 3.5.1.

Four sample crash reports generated by my browser are:
624a6ec7-1e5e-4ce8-891a-580f32090812
c3f87116-a0bc-40b6-ab21-192882090812
ec983612-288a-44d6-ab4d-da3202090808
5ac0a255-94bb-46bb-8011-4a9042090806

In addition, I saw other crashes during this period (also fixed by disabling the FingerAuth extension). The reports for these didn't explicitly link to this bug, but say that the problem was due to the xul.dll thread crashing. E.g.:
4f7f9dfc-c16d-4871-a3a3-2cc042090812
786d4388-524c-497f-ae80-f74372090812
0b240654-e8d8-4aa4-bf76-a0cec2090811
bd621631-7732-4387-ac81-f5bc62090810

Comment 10

[[:Cww]]

Using the new system of linking forum posts to crash reports...

https://support.mozilla.com/tiki-view_forum_thread.php?comments_parentId=408567&forumId=1

https://support.mozilla.com/tiki-view_forum_thread.php?comments_parentId=408987&forumId=1

https://support.mozilla.com/tiki-view_forum_thread.php?comments_parentId=402257&forumId=1

and

https://support.mozilla.com/tiki-view_forum_thread.php?comments_parentId=397163&forumId=1

are recent reports of this crash.  Maybe we could get someone to follow up with users?

Comment 11

[Tobias (:Tobbi) Markus]

I just had one user crashing with
http://crash-stats.mozilla.com/report/index/cc932afe-cb14-4e81-996d-1b07e2090903?p=1

Comment 12

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

Peter/Johnny: we can't ship with this bug. How can we get more insight into it?

Comment 13

[Jeff Muizelaar [:jrmuizel]]

Bug 517010 should help us get more information about what's going on here.

Comment 14

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

So, looking at the data in http://dbaron.org/log/20090922-crashes , it seems like this crash might be correlated with a number of pieces of software hooking into Mozilla.  I'd particularly point out:

     42% (49/118) vs.   5% (366/7100) McFFPlg.dll
     39% (46/118) vs.   3% (243/7100) mcbrwctl.dll
     40% (47/118) vs.   5% (347/7100) McSACorePS.dll
     31% (36/118) vs.   4% (305/7100) sahook.dll
(McAfee SiteAdvisor, per search field on http://www.xraymypc.com/process/A/)

     31% (36/118) vs.   3% (227/7100) rlxg.dll
     31% (36/118) vs.   3% (228/7100) rlls.dll
      9% (11/118) vs.   1% (70/7100) pmls.dll
      9% (11/118) vs.   1% (72/7100) pmxg.dll
(see bug 513334 comment 10; related sets of adware/spyware)

and perhaps even:
     17% (20/118) vs.   8% (535/7100) GoogleDesktopNetwork3.dll
     14% (17/118) vs.   6% (428/7100) GoogleDesktopCommon.dll
     15% (18/118) vs.   8% (544/7100) googletoolbar-ff3.dll
     15% (18/118) vs.   8% (544/7100) googletoolbarloader.dll

Comment 15

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

(In reply to comment #14)
>      42% (49/118) vs.   5% (366/7100) McFFPlg.dll
>      39% (46/118) vs.   3% (243/7100) mcbrwctl.dll
>      40% (47/118) vs.   5% (347/7100) McSACorePS.dll
>      31% (36/118) vs.   4% (305/7100) sahook.dll
> (McAfee SiteAdvisor, per search field on http://www.xraymypc.com/process/A/)

In the module version analysis now on 
http://dbaron.org/mozilla/topcrash-modules (specifically, at http://dbaron.org/log/20090922-crashes-data/interesting-modules-windows-versions ) it's clear that these problems are only correlated with the 3.0.* versions of the libraries.  When I download SiteAdvisor from McAfee's Web page, I get the 2.9.* versions, so I'm not sure where to get the 3.0.* versions.

> and perhaps even:
>      17% (20/118) vs.   8% (535/7100) GoogleDesktopNetwork3.dll
>      14% (17/118) vs.   6% (428/7100) GoogleDesktopCommon.dll
>      15% (18/118) vs.   8% (544/7100) googletoolbar-ff3.dll
>      15% (18/118) vs.   8% (544/7100) googletoolbarloader.dll

These seem spread across 5.1.*-5.8.* versions, but possibly fixed in 5.9.*.

Comment 16

[Peter Van der Beken [:peterv]]

(In reply to comment #15)
> In the module version analysis now on 
> http://dbaron.org/mozilla/topcrash-modules (specifically, at
> http://dbaron.org/log/20090922-crashes-data/interesting-modules-windows-versions
> ) it's clear that these problems are only correlated with the 3.0.* versions of
> the libraries.  When I download SiteAdvisor from McAfee's Web page, I get the
> 2.9.* versions, so I'm not sure where to get the 3.0.* versions.

http://community.mcafee.com/showthread.php?p=576988 seems to say this is a beta version.

Comment 17

[Peter Van der Beken [:peterv]]

Installing the McAfee Total Protection 4.0 beta gets me the same DLL versions as the ones that are mostly implicated in this crash in http://dbaron.org/log/20090922-crashes-data/interesting-modules-windows-versions Didn't crash yet though, could we get the most common URLs that this crashes on?

(In reply to comment #15)
> These seem spread across 5.1.*-5.8.* versions, but possibly fixed in 5.9.*.

No idea how to get these.

Comment 18

[Tom]

I used to have my FireFox crash multiple times per day.  Then someone suggested that I disable some kind of .NET Framework plugin that Microsoft installed and then all the crashes went away.  I've not had this type of crash in over three weeks.

Comment 19

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

Attachment: stacks showing threadsafety assertions

So I installed the McAfee Total Protection 4.0 beta, and ran it in a 1.9.1 branch debug build.  When I did a google search for "Mozilla" (from the search bar) -- I chose that since one of the things SiteAdvisor does is put red/green icons in search results -- I got a whole bunch of threadsafety assertions.  The first few of them are attached, and they're all resulting from code in McFFPlg.dll.  I think threadsafety assertions like these would explain cycle collection crashes like the ones we're seeing.

Comment 20

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

In response to the discovery in the previous comment, I generated a new topcrash report at http://dbaron.org/mozilla/crash-stats/core-counts that shows relationships of crash signatures to number of cores, on the expectation that crashes due to threadsafety problems would pop out because they have low counts on 1-core machines.  (The number-of-cores data in the crash statistics looks pretty good, but not completely reliable; a few machines report as 0-core!)

This shows that the four related cycle collection crashes:
  bug 500879, nsCycleCollectingAutoRefCnt::decr
  bug 504392, nsGlobalWindow::cycleCollection::UnmarkPurple
  bug 513334, nsEventListenerManager::Release
  bug ??????, nsPresContext::Release
a relationship already known because they tended to be correlated with the same sets of extensions -- are probably all due to threadsafety problems.  (In other words, it's not just threadsafety problems with McAfee, but also with the other binary components that seem to be causing them).

This also suggests a reasonable explanation for why these crashes are more common in 3.5 than 3.0 (even without the possibility of binary compatibility changes breaking extensions designed against 3.0):  we've added a bunch of classes to cycle collection since 3.0, including pres contexts and event listener managers.

Comment 21

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

(In reply to comment #20)
>   bug ??????, nsPresContext::Release

This is now bug 519878.

Comment 22

[Matthias Versen [:Matti]]

maybe bug 512486 is also related to this report ?
( I suspect a malware infection)

Comment 27

[Tim Riley [:timr]]

Whimboo and Tomcat: this is a fairly new crashkill bug, but an old "qawanted" bug.  dbaron thinks it is thread safty related. (see comment #20)  Can you guys do more investigation on this one.  I am thinking of Tomcat's beefy machine with multiple cores.  Comment #17 talks about McAfee Total Protection 4.0. Let's get a copy of that and try it out.

Comment 28

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

Additional investigation isn't needed here; see bug 521750 and bug 527339 for fixing on our end and bug 521745, bug 521748, bug 521752, and bug 521753 for fixing on the extension ends for the top extensions that were causing this.