Closed Bug 466024 Opened 12 years ago Closed 11 years ago

topcrash [@ nsStyleSet::AddImportantRules(nsRuleNode*, nsRuleNode*)] due to ask toolbar or mywebsearch toolbar

Categories

(Core :: CSS Parsing and Computation, defect)

x86
Windows XP
defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 492675

People

(Reporter: dbaron, Unassigned)

References

Details

(Keywords: crash, topcrash)

Crash Data

Attachments

(1 file)

The #14 topcrash in Firefox 3.0.3 is a crash in nsStyleSet::AddImportantRules.

This is an access violation crash, not a stack overflow, so it is different from bug 439184.

However, this may well be the same crash as bug 319797.


It would be really useful to have steps to reproduce, or perhaps even a minidump (plus instructions for how to see that minidump in the debugger to get the values of variables).
Duplicate of this bug: 466021
OS: Linux → Windows XP
One thing that's interesting here:  almost all of the crashes seem to have one of the following plugins in the module list (I've never heard of any of these):

NPMyWebS.dll
NPAskSBar.dll
NPZoneSB.dll (only two occurrences of this one, mostly the other two)

I went through about 30 crashes, only two didn't have one of these: bp-fdcfbef8-cd2e-479a-a6b0-249820081119 & bp-67aff3b5-b7ea-4f2e-8729-be1020081119
I think the first (and maybe also the third) comes from http://download.mywebsearch.com/
In bug 466026, ted pointed me to https://wiki.mozilla.org/Manually_Parsing_Breakpad_Symbol_Files which leads to this disassembly of nsStyleSet::AddImportantRules, line-annotated.

According to the breakpad reports, the recursion is at line 434 + 0xb, and the crash is at line 439 + 0x1e (which doesn't even quite seem to add up).  It also gives two or three options for the crash location, which doesn't really help (line-relative offsets aren't very useful when a line ends up in 2 places, I think).
The Ask toolbar and the My Web Search toolbar are very close cousins. Compare http://dl.ask.com/toolbar/faq.html#na6 and http://help.mywebsearch.com/sbar2.html#q10 
npzonesb.dll is the Zone Alarm Spy Blocker, which according to this thread http://www.malwarebytes.org/forums/index.php?showtopic=3143 is another disguise for the same toolbar.

I'd say it's blocklist time.
Flags: wanted1.9.0.x+
Flags: blocking1.9.0.6+
Flags: blocking1.9.0.6+ → blocking1.9.0.7?
Flags: blocking1.9.0.7?
Summary: topcrash [@ nsStyleSet::AddImportantRules] → topcrash [@ nsStyleSet::AddImportantRules] due to ask toolbar or mywebsearch toolbar
Do we have any contacts at Ask that we can work with to get this fixed?
Summary: topcrash [@ nsStyleSet::AddImportantRules] due to ask toolbar or mywebsearch toolbar → topcrash [@ nsStyleSet::AddImportantRules(nsRuleNode*, nsRuleNode*)] due to ask toolbar or mywebsearch toolbar
Is this a confirmed cause?  Now that socorro links to SUMO, we can put together a knowledge base article suggesting that they uninstall these extensions.
The underlying cause of the crash is probably similar to bug 507457 - re-entry into style resolution.
Is it likely that the fix for bug 507457 also took care of the Ask Toolbar (etc) cases?
Very unlikely, since the toolbars have been crashing since before the cause of that bug was checked in.
Do you think this is a bug in the toolbars or a bug in Gecko?
Could be either.
It's possible the patch in bug 513741 might fix this.
No longer depends on: 513741
I think in Firefox 3.5.* this signature moved, so this bug got refiled as bug 492675.  (There are a bunch of older incarnations of it as well.)
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 492675
Crash Signature: [@ nsStyleSet::AddImportantRules(nsRuleNode*, nsRuleNode*)]
You need to log in before you can comment on or make changes to this bug.