crash when running DOM-test suite [@ RuleProcessorData::RuleProcessorData ]




16 years ago
15 years ago


(Reporter: dewildt, Unassigned)



Windows 2000

Firefox Tracking Flags

(Not tracked)


(crash signature, URL)


(2 attachments)



16 years ago
Running Windows 2000, Mozilla 1.2a (Build ID: 2002091014)

Call the url above (

Run "alltest".
A new window with "JsUnit 1.3.2 TestRunner" opens.
Click "run".
In the third status-line appears "initializing" and after a few seconds a
javascript message appears with a "time out"-message.
After pressing OK a new javascript window with a "Retry or Cancel"-question
appears. Mozilla crashes when clicking "Cancel".

Talkback ID: TB11627528E

Comment 1

16 years ago
wfm using build 2002092604 on Win2k (trunk).

-> DOM Level 0
Assignee: rogerl → jst
Component: JavaScript Engine → DOM Level 0
Keywords: crash, stackwanted
QA Contact: pschwartau → desale
Whiteboard: [has talkback ID]

Comment 2

16 years ago
Created attachment 100864 [details]
Stack from TB incident

Looks like RuleProcessorData::RuleProcessorData jumped to an invalid code
address. Probably a dead or corrupt object.

Comment 3

16 years ago
related: bug 100273 ? (same stack)
Keywords: stackwanted
Summary: crash when running DOM-test suite → crash when running DOM-test suite [@ RuleProcessorData::RuleProcessorData ]
Whiteboard: [has talkback ID]
Is there a particular test that crashes us?  Is this reproducible if you run 
the testsuite multiple times?

Comment 5

16 years ago
I have tested it with 6 particular tests and it crashes every time at the same
(talkback ID TB11778777E for test "HTMLAnchorElement01")

It reproducible with build 2002091014 (Mozilla 1.2a) and NOT reproducible with
Mozilla 1.1 (other computer) or the nightly build 2002092617 (same computer).
Confirming with build 2002-11-24-08, on Windows 2000.

Prashant, I hope you don't mind me jumping in here, but I'm confirming this bug
based on my own experiences.

It's also crashing here, if you click the button on:
Ever confirmed: true
With debug build, on the testcase from comment 6, I get:

(gdb) frame 0
#0  0x413814a1 in nsXULAttribute::nsIDOM3Node virtual table ()
   from /home/bzbarsky/mozilla/profile/obj-debug/dist/bin/components/
(gdb) frame 1
#1  0x410cff8a in StyleSetImpl::ResolveStyleFor (this=0x87b9548,
    aContent=0x880def8, aParentContext=0x8811270)
    at /home/bzbarsky/mozilla/profile/mozilla/content/base/src/nsStyleSet.cpp:1166
1166      NS_ASSERTION(aContent->IsContentOfType(nsIContent::eELEMENT),
(gdb) p aContent
$7 = (nsIContent *) 0x880def8

The stack is from inside style context reresolution following a stylesheet
removal triggered by removing its linking element from the DOM.
I'm also seeing this on
Just before the crash I get these assertions:

###!!! ASSERTION: Should not have multiple parsers involved!: '!seenParser',
file nsCSSLoader.cpp, line 1779
###!!! ASSERTION: Found more undisplayed content data after removal: 'context ==
nsnull', file nsFrameManager.cpp, line 912

Created attachment 108361 [details]
nsCSSLoader log excerpt

Bz: something odd is going on here, look at the log for loading . At the end you'll see
the load fails.
Bug 183784 filed on the crash peterv is seeing, which is different from the
original crash reported here.

fwiw, with that fixed, I ran the whole test suite at with no crash.

Comment 11

16 years ago
Looks like this is probably the same as the topcrash
nsAString::UncheckedAssignFromReadable. Stacks are pretty similar. From what I
saw, the stack was corrupted, ebp was 0 in many of these crashes.
Mass-reassigning bugs to
Assignee: jst → dom_bugs

Comment 13

15 years ago
I'm not be able to reproduce this bug with Mozilla 1.6a
Could anybody reproduce this bug with an actual build?
If not, should we close this bug as FIXED or WORKSFORME?

Comment 14

15 years ago
I could not produce this with the actual Mozilla and the actual version of the
DOM1-test suite. I think this bug is fixed by a patch for an other bug or so. 

Feel free to reopen this bug if it happens again.
Last Resolved: 15 years ago
Resolution: --- → WORKSFORME
Crash Signature: [@ RuleProcessorData::RuleProcessorData ]
You need to log in before you can comment on or make changes to this bug.