Closed Bug 330563 Opened 19 years ago Closed 17 years ago

Crash with evil xbl testcase, using alert in constructor


(Core :: XBL, defect)

Windows XP
Not set





(Reporter: martijn.martijn, Assigned: sicking)



(Keywords: crash, testcase, verified1.8.1.8, Whiteboard: [sg:critical?] uses freed memory. fixed on trunk by bug 267833)


(2 files)

See upcoming testcase, which crash Mozilla after clicking for the second time on the alert.
Also crashes Mozilla1.7, so no (recent) regression.

Talkback ID: TB16399392W
nsCSSFrameConstructor::WipeContainingBlock   nsCSSFrameConstructor::ContentInserted  

Marking security sensitive, because the first line of the stack looks funny.
Please unmark the security flag, if this is not a security issue.
Attached file testcase
The testcase crashes for me after clicking for the second time on the alert.
Ok, online it's not crashing directly. But after the first time clicking back and then clicking another 2 times on the alert makes Mozilla crash.
Or you could test the testcase locally.
#0  0xdddddddd in ?? ()
#1  0x055ccc0b in nsCSSFrameConstructor::WipeContainingBlock(nsFrameConstructorS
tate&, nsIFrame*, nsIFrame*, nsIFrame*) (this=0xe7abf48, aState=@0x22f1e8,
    aContainingBlock=0xe82b82c, aFrame=0xe82b82c, aFrameList=0x0)
    at c:/mozilla/mozilla/layout/base/nsCSSFrameConstructor.cpp:13220
#2  0x055c5049 in nsCSSFrameConstructor::ContentInserted(nsIContent*, nsIContent
*, int, nsILayoutHistoryState*, int) (this=0xe7abf48, aContainer=0x3c10e50,
    aChild=0xe7ff698, aIndexInContainer=2, aFrameState=0x0,
    at c:/mozilla/mozilla/layout/base/nsCSSFrameConstructor.cpp:9659
#3  0x0561327c in PresShell::ContentInserted(nsIDocument*, nsIContent*, nsIConte
nt*, int) (this=0xe72fb38, aDocument=0xe80ddc0, aContainer=0x3c10e50,
    aChild=0xe7ff698, aIndexInContainer=2)
    at c:/mozilla/mozilla/layout/base/nsPresShell.cpp:5211
In a debug build clicking alert twice still did it. The crash was below WipeContainingBlock, but similarly used deleted-looking objects ('this' was 0xddddddf9)

Whiteboard: [sg:critical?] uses freed memory
Probably a manifestation of bug 267833, more or less.
Depends on: 267833
Critical security bugs must have owners. If you can't work on this bug please help us find another active owner for it.
Assignee: general → jonas
jonas, had a chance to look at this enough to figure out if its a bug you can take, or need to pass to others?
I haven't had a chance to look thoroughly yet, but like bz says, I strongly suspect this will get magically fixed when bug 267833 is fixed.
This seems to work fine now in current trunk build, but I have to test the testcase locally, because of bug 373536.
This one is fixed now, fixed by bug 267833.
Closed: 17 years ago
Flags: in-testsuite?
Resolution: --- → FIXED
doesn't look fixed on Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/2007030919 Firefox/ -  should we be considering getting the patches

I still crash on the test case using that build.  should we be considering the patch for 267833 on the 1.8 branch?
Flags: blocking1.8.1.4?
stack for my crash on looks like

Access violation
Source File, Line No.	c:/builds/tinderbox/Fx-Mozilla1.8-release/WINNT_5.2_Depend/mozilla/layout/base/nsCSSFrameConstructor.cpp, line 13566
Stack Trace 	
nsCSSFrameConstructor::WipeContainingBlock  [mozilla/layout/base/nsCSSFrameConstructor.cpp, line 13566]
nsCSSFrameConstructor::ContentInserted  [mozilla/layout/base/nsCSSFrameConstructor.cpp, line 9575]
PresShell::ContentInserted  [mozilla/layout/base/nsPresShell.cpp, line 5538]
nsXBLStreamListener::Load  [mozilla/content/xbl/src/nsXBLService.cpp, line 420]
DispatchToInterface  [mozilla/content/events/src/nsEventListenerManager.cpp, line 144]
nsEventListenerManager::HandleEvent  [mozilla/content/events/src/nsEventListenerManager.cpp, line 1752]
nsDocument::HandleDOMEvent  [mozilla/content/base/src/nsDocument.cpp, line 4075]
nsXMLDocument::EndLoad  [mozilla/content/xml/document/src/nsXMLDocument.cpp, line 657]
nsXMLContentSink::DidBuildModel  [mozilla/content/xml/document/src/nsXMLContentSink.cpp, line 353]
nsExpatDriver::DidBuildModel  [mozilla/parser/htmlparser/src/nsExpatDriver.cpp, line 1227]
Bug 267833 hasn't landed on branch yet (and lets discuss over there if it should or not).
Marking "wanted" to indicate this at least happens on the branch.
Flags: wanted1.8.1.x+
Flags: wanted1.8.0.x+
Blocking for now, will talk to Jonas about bug 267833 (and its regressions) for the branch when he's back, or whether there might be a smaller crash band-aide.
Flags: blocking1.8.1.4?
Flags: blocking1.8.1.4+
Flags: blocking1.8.0.12+
Whiteboard: [sg:critical?] uses freed memory → [sg:critical?] uses freed memory. fixed on trunk by bug 267833
Jonas: any thoughts re: comment 14? bug 267833 itself appears to still have open trunk regressions.
I don't think it's worth it trying to patch this one instead of bug 267833 on the branch. We could spend forever patching symptoms while leaving the real problem there.
Not going to land 267833 on the branches with open regressions, so not making this release.
Flags: blocking1.8.1.5?
Flags: blocking1.8.1.4+
Flags: blocking1.8.0.13?
Flags: blocking1.8.0.12+
Flags: blocking1.8.1.5?
Flags: blocking1.8.1.5+
Flags: blocking1.8.0.13?
Flags: blocking1.8.0.13+
Flags: blocking1.8.1.5+ → blocking1.8.1.6+
Flags: blocking1.8.0.13+ → blocking1.8.0.14?
bug 267833 landed on the 1.8 branch and fixed this.
Keywords: fixed1.8.1.8
Verified fix on Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv: Gecko/20071004 Firefox/ Firefox ID:2007100415.    No further crashes. 
Group: security
Flags: blocking1.8.0.14? → blocking1.8.0.15?
Flags: blocking1.8.0.15? → blocking1.8.0.15+
You need to log in before you can comment on or make changes to this bug.