Closed Bug 500879 Opened 11 years ago Closed 10 years ago

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

Categories

(Core :: XPCOM, defect, P2, critical)

1.9.1 Branch
All
Windows Vista
defect

Tracking

()

RESOLVED DUPLICATE of bug 521750

People

(Reporter: hastarin, Assigned: dbaron)

References

Details

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

Crash Data

Attachments

(1 file)

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
Version: unspecified → 3.5 Branch
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) ?
Component: General → XPCOM
Keywords: crash
Product: Firefox → Core
QA Contact: general → xpcom
Summary: Randomly crashes 12-15 secs after startup → Randomly crashes 12-15 secs after startup [@ nsCycleCollectingAutoRefCnt::decr(nsISupports*) ]
Version: 3.5 Branch → 1.9.1 Branch
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.
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.
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.
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.
OK, please reopen if it still happens.
Status: UNCONFIRMED → RESOLVED
Closed: 11 years ago
Resolution: --- → WORKSFORME
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
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: topcrash
Blocks: 507953
Is this the norton hotfix + roboform = crash stack?
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
Peter/Johnny: we can't ship with this bug. How can we get more insight into it?
Flags: blocking1.9.2+
Priority: -- → P2
Bug 517010 should help us get more information about what's going on here.
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
(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.*.
(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.
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.
Assignee: nobody → dbaron
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.
Keywords: qawanted
Hardware: x86_64 → All
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.
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.
(In reply to comment #20)
>   bug ??????, nsPresContext::Release

This is now bug 519878.
maybe bug 512486 is also related to this report ?
( I suspect a malware infection)
Whiteboard: [crashkill]
Duplicate of this bug: 513334
Duplicate of this bug: 504392
Duplicate of this bug: 519878
Duplicate of this bug: 519755
Summary: Randomly crashes 12-15 secs after startup [@ nsCycleCollectingAutoRefCnt::decr(nsISupports*) ] → Random thread-safety topcrash [@ nsCycleCollectingAutoRefCnt::decr(nsISupports*) ]
Summary: Random thread-safety topcrash [@ nsCycleCollectingAutoRefCnt::decr(nsISupports*) ] → Random thread-safety topcrash [@ nsCycleCollectingAutoRefCnt::decr(nsISupports*) ] and [@nsEventListenerManager::Release() ]
Whiteboard: [crashkill] → [crashkill][crashkill-thirdparty]
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.
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.
Status: NEW → RESOLVED
Closed: 11 years ago10 years ago
Keywords: qawanted
Resolution: --- → DUPLICATE
Duplicate of bug: 521750
Crash Signature: [@ nsCycleCollectingAutoRefCnt::decr(nsISupports*) ] [@nsEventListenerManager::Release() ]
You need to log in before you can comment on or make changes to this bug.