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

Status: RESOLVED WORKSFORME

(Core :: DOM: Core & HTML, defect)

Description

[Daniel de Wildt]

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

Call the url above (http://bclary.com/dom-ts/do-dom-html-1-tests.html)

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

[Olivier Cahagne]

wfm using build 2002092604 on Win2k (trunk).

-> DOM Level 0

Comment 2

[David Bradley]

Attachment: Stack from TB incident

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

Comment 3

[Olivier Cahagne]

related: bug 100273 ? (same stack)

Comment 4

[Boris Zbarsky [:bzbarsky]]

Is there a particular test that crashes us?  Is this reproducible if you run 
the testsuite multiple times?

Comment 5

[Daniel de Wildt]

I have tested it with 6 particular tests and it crashes every time at the same
point.
(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).

Comment 6

[[e-mail] (gone - use [e-mail] instead)]

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:
http://www.people.fas.harvard.edu/~dbaron/dom/test/bugs/17390b.html

Comment 7

[Boris Zbarsky [:bzbarsky]]

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/libgkcontent.so
(gdb) frame 1
#1  0x410cff8a in StyleSetImpl::ResolveStyleFor (this=0x87b9548,
aPresContext=0x877f3d8, 
    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.

Comment 8

[Peter Van der Beken [:peterv]]

I'm also seeing this on http://www.bclary.com/dom-ts/do-dom-html-2-tests.html.
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

Annoying.

Comment 9

[Peter Van der Beken [:peterv]]

Attachment: nsCSSLoader log excerpt

Bz: something odd is going on here, look at the log for loading
http://www.bclary.com/jsunit/jsunit/css/jsUnitStyle.css . At the end you'll see
the load fails.

Comment 10

[Boris Zbarsky [:bzbarsky]]

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
http://www.bclary.com/dom-ts/do-dom-html-2-tests.html with no crash.

Comment 11

[David Bradley]

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.

Comment 12

[Johnny Stenback (:jst)]

Mass-reassigning bugs to [e-mail]

Comment 13

[Daniel de Wildt]

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

[Daniel de Wildt]

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. 

=> WORKSFORME
Feel free to reopen this bug if it happens again.