Closed Bug 430800 Opened 16 years ago Closed 16 years ago

Crash [@ nsCSSFrameConstructor::InitAndRestoreFrame] with designMode and toggling iframe displays

Categories

(Core :: Layout, defect)

Product:
Core
Component:
Layout
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: martijn.martijn, Assigned: smaug)

References

Details

(5 keywords, Whiteboard: [sg:dupe 436965])

Crash Data

Attachments

(2 files, 1 obsolete file)

testcase
(deleted), text/html
Details
v2, requires the patch for bug 466057
(deleted), patch
Details | Diff | Splinter Review
Attached file testcase (deleted) — 
See testcase, which crashes current trunk build within a few seconds, usually.

This seems to have regressed between 2006-05-09 and 2006-05-10:
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2006-05-09+03&maxdate=2006-05-10+15&cvsroot=%2Fcvsroot
So I guess a regression from bug 326273 (threadmanager).

The iframe content consists of this:
<html><head></head>
<body>
<iframe onload="this.contentDocument.designMode = 'on'"></iframe>
<iframe onload="this.contentDocument.designMode = 'on'"></iframe>
<iframe onload="this.contentDocument.designMode = 'on'"></iframe>
<iframe onload="this.contentDocument.designMode = 'on'"></iframe>

<script>
function removestyles(i){
var y=document.getElementsByTagName('iframe');
for (var i=0;i<y.length;i++) {
y[i].style.display = y[i].style.display == 'none' ? y[i].style.display = '' : y[i].style.display = 'none';
}
setTimeout(removestyles,10,i);
}
setTimeout(removestyles,100,0);
</script>
</body>
</html>

http://crash-stats.mozilla.com/report/index/be0d8311-12cb-11dd-93a1-001cc4e2bf68?p=1
0  	xul.dll  	xul.dll@0x2565dd  	
1 	xul.dll 	nsCSSFrameConstructor::InitAndRestoreFrame 	mozilla/layout/base/nsCSSFrameConstructor.cpp:6794
2 	xul.dll 	nsCSSFrameConstructor::ConstructHTMLFrame 	mozilla/layout/base/nsCSSFrameConstructor.cpp:5593
3 	xul.dll 	nsCSSFrameConstructor::ConstructFrameInternal 	mozilla/layout/base/nsCSSFrameConstructor.cpp:7707
4 	xul.dll 	nsCSSFrameConstructor::ConstructFrame 	mozilla/layout/base/nsCSSFrameConstructor.cpp:7580
5 	xul.dll 	nsCSSFrameConstructor::ContentInserted 	mozilla/layout/base/nsCSSFrameConstructor.cpp:9144
6 	xul.dll 	nsCSSFrameConstructor::RecreateFramesForContent 	mozilla/layout/base/nsCSSFrameConstructor.cpp:11258
7 	xul.dll 	xul.dll@0x2b4a6f 	
8 	xul.dll 	nsCSSFrameConstructor::ProcessOneRestyle 	mozilla/layout/base/nsCSSFrameConstructor.cpp:13377
9 	xul.dll 	nsCSSFrameConstructor::ProcessPendingRestyles 	mozilla/layout/base/nsCSSFrameConstructor.cpp:13471
10 	xul.dll 	PresShell::DoFlushPendingNotifications 	mozilla/layout/base/nsPresShell.cpp:4548
11 	xul.dll 	PresShell::ReflowEvent::Run 	mozilla/layout/base/nsPresShell.cpp:6145
12 	xul.dll 	nsThread::ProcessNextEvent 	mozilla/xpcom/threads/nsThread.cpp:510
13 	xul.dll 	nsBaseAppShell::Run 	mozilla/widget/src/xpwidgets/nsBaseAppShell.cpp:170
14 	nspr4.dll 	PR_GetEnv 	
15 	firefox.exe 	wmain 	mozilla/toolkit/xre/nsWindowsWMain.cpp:87
16 	firefox.exe 	firefox.exe@0x217f 	
17 	kernel32.dll 	BaseProcessStart
The threadmanager changes were trunk-only, on the 1.8 branch the testcase zombifies the browser (Chrome elements appear to respond, can close tabs, but I can't load new pages; had to kill it). Probably a different bug.

In a trunk debug build I crash on a deleted (0xdddddddd) nsCacheStyleData object

>nsCachedStyleData::GetStyleContent() Line 105	C++
 nsRuleNode::GetStyleContent() Line 105	C++
 nsStyleContext::GetStyleContent() Line 105	C++
 nsIFrame::GetStyleContent() Line 105	C++
 nsCounterManager::AddCounterResetsAndIncrements() Line 200	C++
 nsCSSFrameConstructor::InitAndRestoreFrame() Line 6794	C++
 nsCSSFrameConstructor::ConstructHTMLFrame() Line 5593	C++
 nsCSSFrameConstructor::ConstructFrameInternal() Line 7707	C++
 nsCSSFrameConstructor::ConstructFrame() Line 7580	C++
 nsCSSFrameConstructor::ContentInserted() Line 9145	C++
 nsCSSFrameConstructor::RecreateFramesForContent() Line 11258	C++
 nsCSSFrameConstructor::MaybeRecreateFramesForContent() Line 11132	C++
 nsCSSFrameConstructor::RestyleElement() Line 10073	C++
 nsCSSFrameConstructor::ProcessOneRestyle() Line 13378	C++
 nsCSSFrameConstructor::ProcessPendingRestyles() Line 13472	C++
 PresShell::DoFlushPendingNotifications() Line 4589	C++
 PresShell::ReflowEvent::Run() Line 6184	C++
 nsThread::ProcessNextEvent() Line 510	C++
 NS_ProcessNextEvent_P() Line 227	C++
 nsBaseAppShell::Run() Line 170	C++
 nsAppStartup::Run() Line 181	C++
Flags: wanted1.8.1.x+
Whiteboard: [sg:critical?]
Blocks: 430864
Still crashes in current trunk build.
Flags: blocking1.9.1?
Flags: blocking1.9.1? → wanted1.9.1+
Crashes on my linux nightly build, too.
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b2pre) Gecko/20081105 Minefield/3.1b2pre
Crash report: 1c61ab0a-af6d-11dd-908f-001cc45a2ce4

Platform --> All/All
OS: Windows XP → All
Hardware: PC → All
Version: unspecified → Trunk
Depends on: 466057
I think there is a script blocker missing in DoFlushPendingNotifications,
just before ProcessPendingRestyles.
Testing ...
Blocks: 284245
Attached patch possible patch (obsolete) (deleted) — — Splinter Review 
Perhaps this is still better. Doesn't regress bug 284245.
Comment on attachment 353876 [details] [diff] [review]
possible patch

Doesn't pass all the editor tests :(
Attachment #353876 - Attachment is obsolete: true
Assignee: nobody → Olli.Pettay
Depends on: 436965
Fixed by the patch in bug 436965.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Verified fixed, using:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090104 Minefield/3.2a1pre
Status: RESOLVED → VERIFIED
can/should this be moved to the 1.9.1 branch?
The patch in bug 436965 was landed on 1.9.1, so I'm guessing this is fixed on 1.9.1 too.
Keywords: fixed1.9.1
Verified fix on Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090130 Shiretoko/3.1b3pre Ubiquity/0.1.5
Keywords: fixed1.9.1 → verified1.9.1
Marking fixed1.9.0.7 because bug 436965 was fixed there, needs to be verified.
Flags: wanted1.9.0.x+
Flags: blocking1.9.0.7+
Keywords: fixed1.9.0.7
Whiteboard: [sg:critical?] → [sg:critical?] fixed by 436965
Flags: wanted1.8.1.x+ → wanted1.8.1.x-
Verified for 1.9.0.7 with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.7pre) Gecko/2009021204 GranParadiso/3.0.7pre. Doesn't crash there but does crash the 1.9.0.6 shipped build.
Keywords: fixed1.9.0.7 → verified1.9.0.7
The testcase breaks current 1.8.1 and 1.8.0 because of the already deleted object so we may want to nominate it here.
From 1.8.0:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1207363808 (LWP 4107)]
0x019f9769 in nsCachedStyleData::GetStyleData (this=0x973a7c0, aSID=@0xbfac1fd4) at nsRuleNode.h:217
217	      data = *NS_REINTERPRET_CAST(nsStyleStruct**, dataSlot);
(gdb) p dataSlot
$1 = 0xdddddded <Address 0xdddddded out of bounds>
Whiteboard: [sg:critical?] fixed by 436965 → [sg:dupe 436965]
Group: core-security
Crash Signature: [@ nsCSSFrameConstructor::InitAndRestoreFrame]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: