wfm using build 2002092604 on Win2k (trunk). -> DOM Level 0
Assignee: rogerl → jst
Keywords: crash, stackwanted
QA Contact: pschwartau → desale
Whiteboard: [has talkback ID]
Created attachment 100864 [details] Stack from TB incident Looks like RuleProcessorData::RuleProcessorData jumped to an invalid code address. Probably a dead or corrupt object.
related: bug 100273 ? (same stack)
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?
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).
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
Status: UNCONFIRMED → NEW
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/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.
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.
Created attachment 108361 [details] 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.
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.
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 firstname.lastname@example.org
Assignee: jst → dom_bugs
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?
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.
Status: NEW → RESOLVED
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.