Closed Bug 336960 Opened 14 years ago Closed 13 years ago

Crash when window gets destroyed when constructor of xbl is running

Categories

(Core :: XBL, defect, critical)

x86
Windows XP
defect
Not set
critical

Tracking

()

RESOLVED FIXED

People

(Reporter: martijn.martijn, Unassigned)

References

Details

(Keywords: crash, testcase, Whiteboard: [sg:nse?] probably null-deref)

Attachments

(2 files, 2 obsolete files)

This is probably another bug that is depending on bug 267833.
Marking security sensitive, just to be sure.
The testcase also crashes Mozilla1.7.

Talkback ID: TB18391641E
0x00000000
nsCSSFrameConstructor::WipeContainingBlock   nsCSSFrameConstructor::ContentInserted
Attached file html+xbl in iframe for testcase (obsolete) —
Attached file testcase (obsolete) —
Argh, the previous html+xbl in iframe for testcase was wrong, uploading correct files.
Attachment #221148 - Attachment is obsolete: true
Attachment #221149 - Attachment is obsolete: true
Attached file testcase
Yeah, this is definitely bug 267833 fodder...
The testcase doesn't work online anymore, I filed bug 373536 for that.
It seems to work offline, and there it doesn't crash anymore in current trunk builds, so this bug seems fixed by bug 267833, but I'd like to test this again as soon as bug 373536 is fixed.
Flags: in-testsuite?
Never mind, this bug is fixed by bug 267833.
I was able to test this locally, because when saving the testcase, it had become slightly (but significantly) different from the online version. So the offline test was a good test to see whether this was fixed.
Marking fixed now.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
looks like the test case still crashes Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.3) Gecko/2007030919 Firefox/2.0.0.3

should the patches in bug 267833 be consider for the branch?

http://talkback-reports.mozilla.org/search/private.jsp?search=2&type=iid&id=30500345
testing bug 336960 and bug 336960
Since Last Crash	3098 sec
Total Uptime	88999 sec
Trigger Reason	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]
Flags: blocking1.8.1.4?
Not clear this is exploitable, and the proposed fix in bug 267833 still has open regressions. Not blocking, wanted, will most likely consider for a later release.
Flags: wanted1.8.1.x+
Flags: wanted1.8.0.x?
Flags: blocking1.8.1.4?
The fix for bug 267833 depends on significant trunk work, and in its own right is not something that I'd consider safe to land on branches.  I fully expect it to take me months to shake out the regressions.
Flags: wanted1.8.1.x+ → wanted1.8.1.x?
Whiteboard: [sg:nse?] probably null-deref
WFM in Firefox 2.0.0.14, appears to have been fixed when we landed bug 267833
Flags: wanted1.8.1.x?
Flags: wanted1.8.0.x?
Group: core-security
crash test landed
http://hg.mozilla.org/mozilla-central/rev/6ad02f8a56ad
Flags: in-testsuite? → in-testsuite+
You need to log in before you can comment on or make changes to this bug.