The default bug view has changed. See this FAQ.

crash from MyWebSearch toolbar or WOT extension [@ nsStyleSet::FileRules(int (*)(nsIStyleRuleProcessor*, void*), RuleProcessorData*) ][@ nsStyleSet::FileRules(int (*)(nsIStyleRuleProcessor*, void*), RuleProcessorData*, nsRuleWalker*)]

RESOLVED FIXED in mozilla2.0

Status

()

Core
Layout
P2
critical
RESOLVED FIXED
8 years ago
5 years ago

People

(Reporter: chris hofmann, Assigned: dbaron)

Tracking

(Blocks: 1 bug, {crash, topcrash, user-doc-complete})

Trunk
mozilla2.0
x86
Windows XP
crash, topcrash, user-doc-complete
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.9.2 -

Firefox Tracking Flags

(blocking1.9.1 .6+, status1.9.1 .6-fixed)

Details

(Whiteboard: [crashkill][crashkill-fix][crashkill-outreach], crash signature)

Attachments

(4 attachments, 1 obsolete attachment)

(Reporter)

Description

8 years ago
#9 topcrash on firefox 3.5 b4.

I can't see where any of the code on the stack has changed in many months or years.

url's appear pretty randomly distributed with about 10% on startpages and then wide distribution of sites.

here is the stack for tracking until we figure out what to try and look at next.

0  	xul.dll  	nsStyleSet::FileRules  	layout/style/nsStyleSet.cpp:588
1 	xul.dll 	nsFrameManager::ReResolveStyleContext 	layout/base/nsFrameManager.cpp:1246
2 	xul.dll 	nsFrameManager::ReResolveStyleContext 	layout/base/nsFrameManager.cpp:1499
3 	xul.dll 	nsFrameManager::ReResolveStyleContext 	layout/base/nsFrameManager.cpp:1499
4 	xul.dll 	nsFrameManager::ComputeStyleChangeFor 	layout/base/nsFrameManager.cpp:1566
5 	xul.dll 	nsCSSFrameConstructor::RestyleElement 	layout/base/nsCSSFrameConstructor.cpp:9992
6 	xul.dll 	nsCSSFrameConstructor::ProcessOneRestyle 	layout/base/nsCSSFrameConstructor.cpp:13372
7 	xul.dll 	nsCSSFrameConstructor::ProcessPendingRestyles 	layout/base/nsCSSFrameConstructor.cpp:13480
8 	xul.dll 	PresShell::DoFlushPendingNotifications 	layout/base/nsPresShell.cpp:4686
9 	xul.dll 	PresShell::FlushPendingNotifications 	layout/base/nsPresShell.cpp:4644
10 	xul.dll 	nsCSSFrameConstructor::RestyleEvent::Run 	layout/base/nsCSSFrameConstructor.cpp:13564
11 	xul.dll 	nsThread::ProcessNextEvent 	xpcom/threads/nsThread.cpp:510
12 	xul.dll 	nsBaseAppShell::Run 	widget/src/xpwidgets/nsBaseAppShell.cpp:170
13 	xul.dll 	nsAppStartup::Run 	toolkit/components/startup/src/nsAppStartup.cpp:193
14 	nspr4.dll 	PR_GetEnv 	
15 	firefox.exe 	wmain 	toolkit/xre/nsWindowsWMain.cpp:110
16 	firefox.exe 	firefox.exe@0x2197 	
17 	kernel32.dll 	kernel32.dll@0x16fe6
(Reporter)

Comment 1

8 years ago
beta 3 reports show it ranks #24

http://crash-stats.mozilla.com/query/query?do_query=1&product=Firefox&version=Firefox%3A3.1b3&date=&range_value=1&range_unit=weeks&query_search=signature&query_type=exact&query=

beta 2 reports show it ranked #38 

but we don't have a good way to tell if the crash slides down the ranking as users drop or if its climbing because of some regression in beta4
(Assignee)

Comment 2

8 years ago
Most crashes seem to have NPMyWebS.dll in the module list; maybe duplicate of bug 466024?

I'd love to debug if somebody has a Windows vm that can be trashed with spyware and then rolled back / deleted.

Updated

8 years ago
Blocks: 503562

Comment 3

8 years ago
can we get some eyes on this? QA?
Keywords: qawanted, topcrash
OS: Mac OS X → Windows XP
(In reply to comment #3)
> can we get some eyes on this? QA?

We can! But if it's caused by malware, it might be hard to reproduce...

Also, we should probably get a list of URLs this crashes on as it might be needed to reproduce, even with the .dll file.
(Assignee)

Comment 5

8 years ago
From bug 466024 it sounds more like somewhat-aggressive toolbars, not total malware.

If somebody has a non-development environment where they can test this stuff I can also make a try server build of something that would crash at a more useful stack... if we can get crash report stacks for try server builds, that is.
Keywords: qawanted
Summary: fx3.5b4 Crash Report [@ nsStyleSet::FileRules(int (*)(nsIStyleRuleProcessor*, void*), RuleProcessorData*) ] → fx3.5b4 Crash Report [@ nsStyleSet::FileRules(int (*)(nsIStyleRuleProcessor*, void*), RuleProcessorData*) ] due to MyWebSearch toolbar
Whiteboard: [needs debugging in a throwaway Windows VM]
(Reporter)

Updated

8 years ago
Blocks: 518287
(Assignee)

Comment 6

8 years ago
http://dbaron.org/log/20090922-crashes shows:

  nsStyleSet::FileRules(int (*)(nsIStyleRuleProcessor*, void*), RuleProcessorData*) (79 crashes)
     52% (41/79) vs.   3% (243/7100) M3PLUGIN.DLL
     52% (41/79) vs.   4% (249/7100) NPMyWebS.dll
     51% (40/79) vs.   3% (246/7100) MWSBAR.DLL
     48% (38/79) vs.   4% (275/7100) MWSOESTB.DLL
     47% (37/79) vs.   3% (223/7100) F3HTMLMU.DLL
     29% (23/79) vs.   2% (175/7100) F3HKSTUB.DLL
(Reporter)

Comment 7

8 years ago
spybuster and other malware removal sites says they find and remove most of the .dlls associated with MyTotalSearchBar that are on the list in comment 6.

http://www.spy-buster.com/spyware-database/MyTotalSearchBar-spyware.htm
http://www.bleepingcomputer.com/startups/M3PLUGIN.DLL-23933.html
Blocks: 512788
Keywords: user-doc-needed
Need to fix this before we ship Firefox 3.6, either in our code or by blocklisting the toolbars causing it.
Flags: blocking1.9.2+
Priority: -- → P2
(Assignee)

Updated

8 years ago
Assignee: nobody → dbaron
(Assignee)

Comment 9

8 years ago
It's possible the patch in bug 513741 might fix this.
Depends on: 513741

Updated

8 years ago
Whiteboard: [needs debugging in a throwaway Windows VM] → [waiting to see whether bug 513741 fixes this | needs debugging in a throwaway Windows VM]
(Assignee)

Comment 10

8 years ago
I installed the mywebsearch toolbar to try and test to see if that fixes this, but I haven't gotten it to crash yet.

I wonder if a list of URLs on which this crash was observed would help.
(Assignee)

Updated

8 years ago
No longer depends on: 513741
(Reporter)

Comment 11

8 years ago
here are a few on youtube

  12 http://www.youtube.com
   2 http://www.youtube.com/
   1 http://www.youtube.com/watch?v=rNCPDLoPbd0&NR=1
   1 http://www.youtube.com/watch?v=egEdS2QGKCE&feature=related
   1 http://www.youtube.com/watch?v=aDTq3I8V0R0&feature=channel
   1 http://www.youtube.com/watch?v=WB1iJwIL6OI
   1 http://www.youtube.com/watch?v=LDYyv-iLmRY&feature=rec-HM-r2
   1 http://www.youtube.com/watch?v=Jdb--Uded5w
   1 http://www.youtube.com/watch?v=JHtwwJ4cKtg
   1 http://www.youtube.com/watch?gl=GB&feature=related&v=6kTTPir17fk
   1 http://www.youtube.com/watch?gl=BR&v=DOZM3L-bkzw
   1 http://www.youtube.com/videos?r=1

other crashes with this signature show facebook profile pages, and facebook apps.

here are the domains of sites
  89 //
  46 http://www.facebook.com
  44 http://www.google.com
  31 about:blank//
  31 \N//
  19 http://apps.facebook.com
  19 about:sessionrestore//
  18 http://mail.live.com
  18 http://login.live.com
  12 http://www.youtube.com
  12 http://www.google.co.uk
  11 https://www.google.com
  10 http://www.alot.com
   8 http://www.orkut.com.br
   8 http://www.microsoft.com
   8 http://www.google.pl
   8 http://www.google.com.br
[and a very long tail follows]

that pretty much maps to general browsing behavior, so I'm not sure we will find any particular site or pate that triggers the crash.

tomcat could builds with and without the patch, then grab a days worth of 900 urls associated with this signature and run them on automation if we think that might be a good approach to testing.
(Assignee)

Comment 12

8 years ago
I've installed the MyWebSearch toolbar, and still couldn't get any of those URLs to crash, or get anything to crash by playing around with the toolbar's UI a bit.

Getting steps to reproduce here would be helpful.
Keywords: qawanted
(In reply to comment #11)
> 
> that pretty much maps to general browsing behavior, so I'm not sure we will
> find any particular site or pate that triggers the crash.
> 
> tomcat could builds with and without the patch, then grab a days worth of 900
> urls associated with this signature and run them on automation if we think that
> might be a good approach to testing.

will do !
Keywords: qawanted
(Assignee)

Comment 14

8 years ago
Created attachment 404106 [details] [diff] [review]
patch 1: fix missing SetLevel call

This is pretty much unrelated to this bug, except the bug this fixes causes assertions once patch 2 is applied.
Attachment #404106 - Flags: review?(bzbarsky)
(Assignee)

Comment 15

8 years ago
Created attachment 404107 [details] [diff] [review]
patch 2: use nsRuleWalker on the stack

This applies on top of bug 492675 and on top of patch 1, and I think should fix this bug, although I'm not sure, since I haven't been able to reproduce this bug.
Attachment #404107 - Flags: review?(bzbarsky)
(Assignee)

Comment 16

8 years ago
er, I meant on top of bug 513741

Comment 17

8 years ago
Does patch 2 at least fix *a* bug?  Hopefully something that we could create an automated test for?
(Assignee)

Comment 18

8 years ago
It should be an alternate fix for bug 507457, such that we could back that fix out and it would still be fixed, but I haven't tested that yet.
(Assignee)

Comment 19

8 years ago
(In reply to comment #18)
> It should be an alternate fix for bug 507457, such that we could back that fix
> out and it would still be fixed, but I haven't tested that yet.

It does, in fact, fix bug 507457 with that bug's patch removed.
Attachment #404106 - Flags: review?(bzbarsky) → review+
Attachment #404107 - Flags: review?(bzbarsky) → review+
(Assignee)

Comment 20

8 years ago
http://hg.mozilla.org/mozilla-central/rev/3f5ac794879f
http://hg.mozilla.org/mozilla-central/rev/b080434f9dd4
(Assignee)

Comment 21

8 years ago
http://hg.mozilla.org/releases/mozilla-1.9.2/rev/4a4504e6581d
http://hg.mozilla.org/releases/mozilla-1.9.2/rev/b5ff73121753

The latter patch had the warning fix that I threw in dropped (since it doesn't apply there), and was no longer on top of bug 513741 (by merging the two patches, since patch 2 here removed what was added there).
(Assignee)

Comment 22

8 years ago
Created attachment 404355 [details] [diff] [review]
patch 2 for 1.9.1 branch

The patch as landed on 1.9.2, plus a little simple merging to deal with the differences from http://hg.mozilla.org/mozilla-central/rev/929ccf186103
Attachment #404355 - Flags: approval1.9.1.4?
(Assignee)

Updated

8 years ago
Attachment #404106 - Flags: approval1.9.1.4?
(Assignee)

Comment 23

8 years ago
Created attachment 404372 [details] [diff] [review]
patch 2 for 1.9.1 branch

Oops, made a simple mistake in the merging.
Attachment #404355 - Attachment is obsolete: true
Attachment #404372 - Flags: approval1.9.1.4?
Attachment #404355 - Flags: approval1.9.1.4?
This will not make 1.9.1.4. Do we need both patches for 1.9.1.5 or does the second include the first?
blocking1.9.1: --- → .5+
status1.9.1: --- → wanted
Attachment #404106 - Flags: approval1.9.1.4? → approval1.9.1.5?
Attachment #404372 - Flags: approval1.9.1.4? → approval1.9.1.5?
(Assignee)

Comment 26

8 years ago
Both patches are needed.
Comment on attachment 404106 [details] [diff] [review]
patch 1: fix missing SetLevel call

Approved for 1.9.1.5, a=dveditz for release-drivers
Attachment #404106 - Flags: approval1.9.1.5? → approval1.9.1.5+
Comment on attachment 404372 [details] [diff] [review]
patch 2 for 1.9.1 branch

Approved for 1.9.1.5, a=dveditz for release-drivers
Attachment #404372 - Flags: approval1.9.1.5? → approval1.9.1.5+
(Assignee)

Comment 30

8 years ago
Landed on 1.9.1:
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/6d3cc605d44e
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/709168428034
status1.9.1: wanted → .5-fixed

Updated

8 years ago
Whiteboard: [waiting to see whether bug 513741 fixes this | needs debugging in a throwaway Windows VM] → [waiting to see whether bug 513741 fixes this | needs debugging in a throwaway Windows VM][crashkill]
user-doc-complete
<https://support.mozilla.com/en-US/kb/Crash+signature+-+nsStyleSet+FileRules?bl=n>

Updated

8 years ago
Keywords: user-doc-needed → user-doc-complete
This looks to be FIXED on trunk and 1.9.2, marking.
Status: NEW → RESOLVED
Last Resolved: 8 years ago
status1.9.2: --- → final-fixed
Resolution: --- → FIXED
(Assignee)

Comment 33

8 years ago
We have no idea whether it's fixed and won't know until we ship 3.5.5.
(Assignee)

Updated

8 years ago
status1.9.2: final-fixed → beta1-fixed
(Assignee)

Comment 34

8 years ago
Then again, it's showing up as topcrash #59 for 3.6b1; I'm not sure if that means part of it is fixed and part isn't, or that none of it is fixed.
(Assignee)

Updated

8 years ago
Status: RESOLVED → REOPENED
status1.9.2: beta1-fixed → ---
Resolution: FIXED → ---
Whiteboard: [waiting to see whether bug 513741 fixes this | needs debugging in a throwaway Windows VM][crashkill] → [crashkill]

Updated

8 years ago
Whiteboard: [crashkill] → [crashkill][crashkill-fix]
Can we get a percentage of crashes that we think this will fix?
(Reporter)

Comment 36

8 years ago
re: comment 35

this will fix about 1000 crashes per day incoming on various releases.

distribution of all versions where the nsStyleSet::FileRules crash was found on 20091101-crashdata.csv
 834 Firefox 3.5.4
 193 Firefox 3.5.3
  23 Firefox 3.5.2
  14 Firefox 3.5
   5 Firefox 3.5.1
   4 Firefox 3.0.15
   2 Firefox 3.6b1
   2 Firefox 3.1b3
   1 Firefox 3.5b99
   1 Firefox 3.5b4
   1 Firefox 3.1b1
   1 Firefox 3.0.3
(Assignee)

Comment 37

8 years ago
(In reply to comment #34)
> Then again, it's showing up as topcrash #59 for 3.6b1; I'm not sure if that
> means part of it is fixed and part isn't, or that none of it is fixed.

Though there have been very few crashes since we actually shipped 3.6b1, though.  There were more on the early builds than on the build we actually shipped as beta:

http://crash-stats.mozilla.com/report/list?product=Firefox&version=Firefox%3A3.5.4&query_search=signature&query_type=exact&query=&date=&range_value=1&range_unit=weeks&do_query=1&signature=nsStyleSet%3A%3AFileRules%28int%20%28*%29%28nsIStyleRuleProcessor*%2C%20void*%29%2C%20RuleProcessorData*%29
(Assignee)

Comment 38

8 years ago
Oops, those were the 3.5.4 crashes; the right link was:
http://crash-stats.mozilla.com/report/list?product=Firefox&version=Firefox%3A3.6b1&query_search=signature&query_type=startswith&query=nsStyleSet%3A%3AFileRules&date=&range_value=2&range_unit=weeks&do_query=1&signature=nsStyleSet%3A%3AFileRules%28int%20%28*%29%28nsIStyleRuleProcessor*%2C%20void*%29%2C%20RuleProcessorData*%2C%20nsRuleWalker*%29
(Assignee)

Comment 39

8 years ago
Notes from debugging the minidump:
http://crash-stats.mozilla.com/report/index/e964d5e5-efc3-4a37-b99e-c2a0e2091107

It looks like the disassembly is really for the guts of AddImportantRules... actually GetImportantRule inlined within AddImportantRules (with a check for whether the vtable entry matches the expected CSSStyleRuleImpl::GetImportantRule).

The 0x1c offset is the mImportantData of a null nsCSSDeclaration.  The CSSStyleRuleImpl is 0x53480e0, which seems pretty likely to be a good pointer given that it just passed a test against one of its vtable entries.
(Assignee)

Comment 40

8 years ago
(In reply to comment #39)
> The 0x1c offset is the mImportantData of a null nsCSSDeclaration.  The
> CSSStyleRuleImpl is 0x53480e0, which seems pretty likely to be a good pointer
> given that it just passed a test against one of its vtable entries.

To be clear, mDeclaration->mImportantData is being loaded as part of the inlined HasImportantData call in CSSStyleRuleImpl::GetImportantRule; the fast-path is for when it's null.  (However, the crash is because mDeclaration is null.)
(Reporter)

Comment 42

8 years ago
(In reply to comment #37)
> (In reply to comment #34)
> > Then again, it's showing up as topcrash #59 for 3.6b1; I'm not sure if that
> > means part of it is fixed and part isn't, or that none of it is fixed.
> 
> Though there have been very few crashes since we actually shipped 3.6b1,
> though.  There were more on the early builds than on the build we actually
> shipped as beta:
> 

We might have hit some threshold of 

-general 3.6b1 usage, 
-or some pocket of users joining the beta, 
-or some new outbreak of the externally driven crash problem 

that changed the beta volume on this shortly after you made  comment 37.   we have gone from 1-3 3.6b1 crash per day to 12-31 crashes per day the last few days.

3.6b1
active
daily
users                         #crash  #tl-sigs    #nsStyleSet::FileRules crashes

89,724	20091101-crashdata.csv	 1,468	  500     2
123,763	20091102-crashdata.csv	 1,939	  601     3
158,496	20091103-crashdata.csv	 2,177	  645     3
180,255	20091104-crashdata.csv	 2,321	  729     1
195,912	20091105-crashdata.csv	 5,962	1,364    12
213,475	20091106-crashdata.csv	14,917	2,537    24
198,588	20091107-crashdata.csv 	15,187	2,685    31
(Reporter)

Comment 43

8 years ago
there is some wrapping on that last comment.  
left column is adu's on the beta.  
right column is  #nsStyleSet::FileRules crashes
Should we keep blocking 1.9.2 on this? It seems like we don't have a good idea of what could be causing the remaining crashes.
(Assignee)

Comment 46

8 years ago
The extension correlations for this crash that look likely to be statistically significant to me, from last night's run at http://people.mozilla.com/crash_analysis/ are:

Firefox 3.6b1:

  nsStyleSet::FileRules(int (*)(nsIStyleRuleProcessor*, void*), RuleProcessorData*, nsRuleWalker*)|EXCEPTION_ACCESS_VIOLATION (34 crashes)
     26% (9/34) vs.   3% (331/13234) {a0d7ccb3-214d-498b-b4aa-0e8fda9a7bf7} (WOT, https://addons.mozilla.org/addon/3456)
     29% (10/34) vs.  10% (1310/13234) {ABDE892B-13A8-4d1b-88E6-365A6E755758}

Firefox 3.5.5:

  nsStyleSet::FileRules(int (*)(nsIStyleRuleProcessor*, void*), RuleProcessorData*)|EXCEPTION_ACCESS_VIOLATION (808 crashes)
     18% (148/808) vs.   2% (1592/79833) {a0d7ccb3-214d-498b-b4aa-0e8fda9a7bf7} (WOT, https://addons.mozilla.org/addon/3456)
     23% (186/808) vs.  13% (10240/79833) {635abd67-4fe9-1b23-4f01-e679fa7484c1} (Yahoo! Toolbar, https://addons.mozilla.org/addon/2032)
     14% (110/808) vs.   5% (4064/79833) avg@igeared
     17% (140/808) vs.   9% (7109/79833) {3f963a5b-e555-4543-90e2-c3908898db71}
     14% (110/808) vs.   6% (4947/79833) {E2883E8F-472F-4fb0-9522-AC9BF37916A7} (Adobe Flash Extension, https://addons.mozilla.org/addon/13845)
      9% (73/808) vs.   2% (1534/79833) browserhighlighter@ebay.com (The Browser Highlighter, https://addons.mozilla.org/addon/11808)
     16% (132/808) vs.  10% (8006/79833) {d10d0bf8-f5b5-c8b4-a8b2-2b9879e08c5d} (Adblock Plus, https://addons.mozilla.org/addon/1865)
     13% (101/808) vs.   7% (5375/79833) {B13721C7-F507-4982-B2E5-502A71474FED} (Skype Toolbar for Firefox, https://addons.mozilla.org/addon/4938)


https://addons.mozilla.org/addon/3456 is probably the most clearly related.
(Assignee)

Comment 47

8 years ago
And the URL list for this crash looks pretty much like a "most visited pages on the Web" list.
(Reporter)

Comment 48

8 years ago
anyone know a contact for the web of trust folks?
Whiteboard: [crashkill][crashkill-fix] → [crashkill][crashkill-fix][crashkill-outreach]
(Assignee)

Comment 49

8 years ago
How would a contact help?
(Assignee)

Comment 50

8 years ago
The WOT extension also seems to be causing crashes in:
  RuleHash_ClassTable_GetKey
  ContentEnumFunc
  RuleHash::EnumerateAllRules(int, nsIAtom*, nsIAtom*, nsAttrValue const*, void (*)(nsICSSStyleRule*, nsCSSSelector*, void*), void*)

Those might be related.
(Assignee)

Comment 51

8 years ago
(In reply to comment #46)
> https://addons.mozilla.org/addon/3456 is probably the most clearly related.

That said, the MyWebSearch toolbar is responsible for a larger portion of the crashes (probably 2/3 on 3.6b1 and 1/2 on 3.5.5), but it only shows up in the module correlations and not the addons list.

NPMyWebS.dll also shows up in the correlations (I'm looking at 3.5.5) for the three crashes above (though not quite at those percentages).
(In reply to comment #49)
> How would a contact help?

David, are you saying that this crash cannot be fixed by the addons mentioned here?
(Assignee)

Comment 53

8 years ago
Looking at 6 3.5.5 RuleHash_ClassTable_GetKey crashes:

The disassembly is really simple:
  RuleHashTableEntry::mRules is at offset 0x4
  RuleValue::mSelector is at offset 0x4
  nsCSSSelector::mClassList is at offset 0xc
  nsAtomList::mAtom is at offset 0x0

http://crash-stats.mozilla.com/report/index/7d8624df-a602-438e-be00-5c43f2091108

The crash is trying to dereference ->mAtom (the dereference at offset 0x0), so
mClassList is a bad pointer (0x0f100c11).

http://crash-stats.mozilla.com/report/index/509b0d0c-da2e-4162-a9fd-3458d2091108

The crash is trying to dereference ->mAtom (the dereference at offset 0x0), so
mClassList is a bad pointer (0x006c0061).  (That's "al" in UTF-16.)

http://crash-stats.mozilla.com/report/index/643fecb1-b5de-4245-b880-12d262091108

The crash is trying to dereference ->mAtom (the dereference at offset 0x0);
this time mClassList is null.  And in the FileRules frame we're doing
eDocSheet rule processors.

http://crash-stats.mozilla.com/report/index/a8b5d21f-2812-467e-ac71-10a802091108

Exactly like the previous one.

http://crash-stats.mozilla.com/report/index/c5c5a7ce-3f28-48d5-8371-78adb2091108

Exactly like the previous two.

http://crash-stats.mozilla.com/report/index/cc18f999-95f3-4af0-9f2b-ca5fd2091108

The crash is trying to dereference ->mAtom (the dereference at offset 0x0), so
mClassList is a bad pointer (0x70697263).  (That's "crip" in UTF-8/ASCII.)



Now, I'll look at six 3.5.5 ContentEnumFunc crashes:

http://crash-stats.mozilla.com/report/index/40a9f15b-4bef-480e-81db-781502091108

Claims to be crashing on the line data->mRuleWalker->Forward(aRule).
Presumably that's because nsRuleWalker::Forward and nsRuleNode::Transition
are inlined.  In particular, it's in a chunk of code representing this bit
at the end of nsRuleNode::Transition:

    // Create the new entry in our list.
    next = new (mPresContext)
      nsRuleNode(mPresContext, this, aRule, aLevel, aIsImportantRule);
    if (!next) {
      return nsnull;
    }
    next->mNextSibling = ChildrenList();
    SetChildrenList(next);

With nsRuleNode::nsRuleNode inlined into this.

And, in particular, the crash is on the line (EIP 0x10074134):
  NS_IF_ADDREF(aRule)
in nsRuleNode::nsRuleNode.  aRule (ECX) is 0x0200fc80.  aRule's vtable
(EDX), however, is null.  And, for the record, |this| in
nsRuleNode::nsRuleNode (ESI) is 0x022da37c.  And mDependentBits was
just set from (EDI) to 0x40000000 (i.e., eDocSheet level, not important).
And mParent was set to EAX, 0x024bce5c.

http://crash-stats.mozilla.com/report/index/72acd167-2dc5-4a36-b8b5-918352091108

In this case, it's SelectorMatchesTree inlined into ContentEnumFunc,
and it's the variable |content| (EAX, 0x64b7e80) that has a bad vtable
(EDX, 0x400).  Probably not related to the crash in this bug.

http://crash-stats.mozilla.com/report/index/88bb6665-0eba-4115-a791-071cf2091108

Looks like a bad rule node in the list near the start of
nsRuleNode::Transition, in this loop:
    while (curr && curr->GetKey() != key) {
      curr = curr->mNextSibling;
      ++numKids;
    }
Again, not related.

http://crash-stats.mozilla.com/report/index/a1da412a-f82c-4954-8fa3-852512091108

Like the one before the previous:  a bad vtable on |content|, I think.
(0x00001000).

http://crash-stats.mozilla.com/report/index/ad97299e-9b71-4be5-9332-6c5da2091108

At a quick glance, this looks like a bad rule node inside the inlined
nsRuleNode::Transition (i.e., nsRuleWalker::mCurrentNode ended up bad).

http://crash-stats.mozilla.com/report/index/cfa3e704-5245-4d47-9c15-e300d2091108

This one looks like the first of the six (the only other one related
to this bug).  Like that, the crash is on the line (EIP 0x10074134):
  NS_IF_ADDREF(aRule)
in nsRuleNode::nsRuleNode.  aRule (ECX) is 0x02f8ace0.  aRule's vtable
(EDX), however, is null.  And, for the record, |this| in
nsRuleNode::nsRuleNode (ESI) is 0x05b1edd0.  And mDependentBits was
just set from (EDI) to 0x40000000 (i.e., eDocSheet level, not important).
And mParent was set to EAX, 0x0547b350.




(In reply to comment #52)
> (In reply to comment #49)
> > How would a contact help?
> 
> David, are you saying that this crash cannot be fixed by the addons mentioned
> here?

It's probably related to something that those addons are doing, but we don't know what.

So, if we had a contact, what would we tell them?  I don't currently have anything to say, but if somebody else does, then it could be useful.
(Assignee)

Updated

8 years ago
Summary: fx3.5b4 Crash Report [@ nsStyleSet::FileRules(int (*)(nsIStyleRuleProcessor*, void*), RuleProcessorData*) ] due to MyWebSearch toolbar → crash from MyWebSearch toolbar or WOT extension [@ nsStyleSet::FileRules(int (*)(nsIStyleRuleProcessor*, void*), RuleProcessorData*) ][@ nsStyleSet::FileRules(int (*)(nsIStyleRuleProcessor*, void*), RuleProcessorData*, nsRuleWalker*)]
also now in the Firefox 3.6 Beta 1 TopCrash List :

http://crash-stats.mozilla.com/report/list?product=Firefox&version=Firefox%3A3.6b1&query_search=signature&query_type=exact&query=&date=&range_value=1&range_unit=weeks&do_query=1&signature=nsStyleSet%3A%3AFileRules%28int%20%28*%29%28nsIStyleRuleProcessor*%2C%20void*%29%2C%20RuleProcessorData*%2C%20nsRuleWalker*%29
Summary: crash from MyWebSearch toolbar or WOT extension [@ nsStyleSet::FileRules(int (*)(nsIStyleRuleProcessor*, void*), RuleProcessorData*) ][@ nsStyleSet::FileRules(int (*)(nsIStyleRuleProcessor*, void*), RuleProcessorData*, nsRuleWalker*)] → nsRuleWalker*)] [@nsStyleSet::FileR crash from MyWebSearch toolbar or WOT extension [@ nsStyleSet::FileRules(int (*)(nsIStyleRuleProcessor*, void*), RuleProcessorData*) ][@ nsStyleSet::FileRules(int (*)(nsIStyleRuleProcessor*, void*), RuleProcessorData*
(Assignee)

Updated

8 years ago
Summary: crash from MyWebSearch toolbar or WOT extension [@ nsStyleSet::FileRules(int (*)(nsIStyleRuleProcessor*, void*), RuleProcessorData*) ][@ nsStyleSet::FileRules(int (*)(nsIStyleRuleProcessor*, void*), RuleProcessorData* nsRuleWalker*)] [@nsStyleSet::FileR → crash from MyWebSearch toolbar or WOT extension [@ nsStyleSet::FileRules(int (*)(nsIStyleRuleProcessor*, void*), RuleProcessorData*) ][@ nsStyleSet::FileRules(int (*)(nsIStyleRuleProcessor*, void*), RuleProcessorData*, nsRuleWalker*)]
(Assignee)

Comment 55

8 years ago
(In reply to comment #49)
> How would a contact help?

Two things we could ask:

 (1) Do they have steps to reproduce the crash?

 (2) Do they have any ideas of what their code might be doing related to CSS rules that might be causing the crash?
Can we ask for a look at (parts of) their source code?
(Assignee)

Comment 57

8 years ago
I just took a look at WOT:  it's GPL, has no binary components, and does some stuff with the CSS object model (pretty trivial, except they're holding their own cache of style rules).
So the reason I asked about extensions is because I wanted to see whether any of them were using the inspector APIs for messing with style rules.  WOT doesn't seem to be doing that...  Their css.js code should be pretty safe.  They hold DOM rules, but if the underlying style rule dies the DOM rule should just end up with a null mRule and handle that safely; in such cases the nsIStyleRule shouldn't be reachable via rulenodes anyway...
So what I can see after running both of those extensions a bit is that WOT overlays the content area with a warning all the time you search for something inside the mywebsearch toolbar or click a button. All those referenced web pages have a poor reputation. Could that be related?
Boris or David, was that information helpful for you?
I don't know.  Nothing in the comment 59 file jumped out at me...  :(
Not blocking.  We can't repro.
Flags: blocking1.9.2+ → blocking1.9.2-
(Reporter)

Comment 65

7 years ago
The RuleProcessor singature seems spread across 3.0* 3.5* 3.6* .  The RuleWalker signature seems exclusive to 3.6*

chofmann$ grep 'nsStyleSet::FileRules' 20091122*  | grep RuleProcessorData | awk -F\t '{print $8}' | sort | uniq -c | sort -nr
 915 3.5.5
  52 3.5.3
  43 3.6b3
  19 3.5.4
  16 3.5.2
  12 3.5
  11 3.6b1
   9 3.1b3
   8 3.5.1
   5 3.5b4
   4 3.6b2
   3 3.0.15
   2 3.1b2
   1 3.7a1pre
   1 3.5b99
   1 3.0.4

chofmann$ grep 'nsStyleSet::FileRules' 20091122*  | grep RuleWalker| awk -F\t '{print $8}' | sort | uniq -c | sort -nr
  43 3.6b3
  11 3.6b1
   4 3.6b2
   1 3.7a1pre
(Reporter)

Comment 66

7 years ago
so if I read things right the RuleWalker crashes are only 3.6x 

 and

the RuleWalker crashes are the ones strongly correlated to MyWebSearch toolbar

     58% (22/38) vs.   2% (244/11946) NPMyWebS.dll
     58% (22/38) vs.   2% (244/11946) M3PLUGIN.DLL
     58% (22/38) vs.   2% (236/11946) MWSBAR.DLL
     55% (21/38) vs.   3% (375/11946) MWSOESTB.DLL
     55% (21/38) vs.   2% (229/11946) F3HTMLMU.DLL
     42% (16/38) vs.   2% (280/11946) F3HKSTUB.DLL

Then blocking these might be an option to reduce the 3.6x side of these crashes.

Sounds like spybuster and maybe other anti-virus packages might be disabling or removing.
http://www.spy-buster.com/spyware-database/MyTotalSearchBar-spyware.htm

http://www.dslreports.com/forum/remark,15313228 says NPMyWebS.dll gets put in plugins

Program Files\Mozilla Firefox\plugins\NPMyWebS.dll

Some more research is probably needed to figure out the exact blocking strategy and test and confirm it.  maybe that could get sorted out by an addition to the blocklist and another 36beta.

Sounds like Henrik as an installation of the toolbar set up to test a block entry.

renom to see if we want to try the MyWebSearch toolbar block to help 3.6 to reduce at least a few of these crashes; although this wouldn't address other  bugs that might be getting tickled by addons/plugins poking at CSS rule code.
Flags: blocking1.9.2- → blocking1.9.2?
(Reporter)

Comment 67

7 years ago
or maybe we should just spin of another bug for the suggestion in comment 66
(Assignee)

Comment 68

7 years ago
Yes, please file a separate bug for extension blocks.

Comment 69

7 years ago
We'd rather not block these extensions, since we've looked at their code and determined they're not doing anything wrong.  We could suggest alternative ways for these extensions to work (as a workaround), but blocking wouldn't be nice.
Blocking based on the fact that this was fixed for 1.9.1.6 - can we get it ported to 1.9.2 and central?
Flags: blocking1.9.2? → blocking1.9.2+
This landed on m-c and 1.9.2 (comment 20 and comment 21).

See also comment #34:
> Then again, it's showing up as topcrash #59 for 3.6b1; I'm not sure if that
> means part of it is fixed and part isn't, or that none of it is fixed.
(Assignee)

Comment 72

7 years ago
The patch in question landed on all relevant branches, but didn't fix the bug.

I think the patches in bug 522595 might either fix this or move the crash to a different location that might tell us more information.

But I don't think this should block.
(Assignee)

Updated

7 years ago
Flags: blocking1.9.2+ → blocking1.9.2-
(Reporter)

Comment 73

7 years ago
the signature 

nsStyleSet::FileRules(int (*)(nsIStyleRuleProcessor*, void*), RuleProcessorData*, nsRuleWalker*) 

is showing up as new/morfed inearly beta testing of firefox 3.5.6

http://people.mozilla.com/~jst/new-crashes/Firefox/latest/3.5.6-3.5.html
(Assignee)

Comment 74

7 years ago
(In reply to comment #72)
> I think the patches in bug 522595 might either fix this or move the crash to a
> different location that might tell us more information.

These patches landed on mozilla-central today.
(Assignee)

Comment 75

7 years ago
There haven't been any nsStyleSet::FileRules crashes from mozilla-central builds since those patches landed, or, for that matter, any crashes in any nsStyleSet methods.

The histogram prior to landing was:

0  Dec 2
2  Dec 3
0  Dec 4
2  Dec 5
0  Dec 6
1  Dec 7
1  Dec 8    (though that crash was recorded a week after the build date)
0  Dec 9
0  Dec 10
(Assignee)

Updated

7 years ago
Depends on: 522595
(Assignee)

Comment 76

7 years ago
Once bug 536379 has baked on trunk, I think we should consider taking bug 522595 and bug 536379 for a 1.9.2.* release.
(Assignee)

Comment 77

7 years ago
I have a merge of both of those bugs to 1.9.2 in my 1.9.2 patch queue at http://hg.mozilla.org/users/dbaron_mozilla.com/patches-1.9.2/

(I'm currently waiting on try server results from that merge.)
(Assignee)

Comment 78

7 years ago
Created attachment 419722 [details]
patch queue containing relevant parts of bug 522595 and bug 536379

This is the output of "hg outgoing -p" with the patch queue for what I think we'd need to land to fix this.  It passes tests on try (modulo random orange in make check on Windows).
Attachment #419722 - Flags: approval1.9.2.1?
(Assignee)

Updated

7 years ago
Duplicate of this bug: 466024
(Assignee)

Updated

7 years ago
Duplicate of this bug: 319797
Comment on attachment 419722 [details]
patch queue containing relevant parts of bug 522595 and bug 536379

This is in the top 100 crashes, but not the top 20. Do we still fell it's worth the risk?

The reason I ask is that this is a pretty big patch, and that usually causes driver concern.
Attachment #419722 - Flags: approval1.9.2.2? → approval1.9.2.2-

Updated

7 years ago
Duplicate of this bug: 565319
Crash Signature: [@ nsStyleSet::FileRules(int (*)(nsIStyleRuleProcessor*, void*), RuleProcessorData*) ] [@ nsStyleSet::FileRules(int (*)(nsIStyleRuleProcessor*, void*), RuleProcessorData*, nsRuleWalker*)]

Updated

5 years ago
Severity: normal → critical
Crash Signature: [@ nsStyleSet::FileRules(int (*)(nsIStyleRuleProcessor*, void*), RuleProcessorData*) ] [@ nsStyleSet::FileRules(int (*)(nsIStyleRuleProcessor*, void*), RuleProcessorData*, nsRuleWalker*)] → [@ nsStyleSet::FileRules(int (*)(nsIStyleRuleProcessor*, void*), RuleProcessorData*) ] [@ nsStyleSet::FileRules(int (*)(nsIStyleRuleProcessor*, void*), RuleProcessorData*, nsRuleWalker*)]
Keywords: crash

Comment 83

5 years ago
All of these appear to be on 3.0, 3.5 and 3.6. Resolving as works for me.
Status: REOPENED → RESOLVED
Last Resolved: 8 years ago5 years ago
Resolution: --- → WORKSFORME
(Assignee)

Updated

5 years ago
Resolution: WORKSFORME → FIXED
Target Milestone: --- → mozilla2.0
You need to log in before you can comment on or make changes to this bug.