Closed
Bug 430800
Opened 17 years ago
Closed 16 years ago
Crash [@ nsCSSFrameConstructor::InitAndRestoreFrame] with designMode and toggling iframe displays
Categories
(Core :: Layout, defect)
Core
Layout
Tracking
()
VERIFIED
FIXED
People
(Reporter: martijn.martijn, Assigned: smaug)
References
Details
(5 keywords, Whiteboard: [sg:dupe 436965])
Crash Data
Attachments
(2 files, 1 obsolete file)
|
(deleted),
text/html
|
Details | |
|
(deleted),
patch
|
Details | Diff | Splinter Review |
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
|
||
Comment 1•17 years ago
|
||
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?]
Flags: blocking1.9.1? → wanted1.9.1+
|
||
Comment 3•16 years ago
|
||
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
|
Assignee | |
Comment 4•16 years ago
|
||
I think there is a script blocker missing in DoFlushPendingNotifications,
just before ProcessPendingRestyles.
Testing ...
|
|
Assignee | |
Comment 5•16 years ago
|
||
Perhaps this is still better. Doesn't regress bug 284245.
|
|
Assignee | |
Comment 6•16 years ago
|
||
Comment on attachment 353876 [details] [diff] [review]
possible patch
Doesn't pass all the editor tests :(
Attachment #353876 -
Attachment is obsolete: true
|
|
Assignee | |
Comment 7•16 years ago
|
||
|
|
Assignee | |
Updated•16 years ago
|
Assignee: nobody → Olli.Pettay
|
|
Assignee | |
Comment 8•16 years ago
|
||
Fixed by the patch in bug 436965.
|
|
Assignee | |
Updated•16 years ago
|
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
|
Reporter | |
Comment 9•16 years ago
|
||
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
|
||
Comment 10•16 years ago
|
||
can/should this be moved to the 1.9.1 branch?
|
||
Comment 11•16 years ago
|
||
The patch in bug 436965 was landed on 1.9.1, so I'm guessing this is fixed on 1.9.1 too.
|
|
Reporter | |
Updated•16 years ago
|
Keywords: fixed1.9.1
|
||
Comment 12•16 years ago
|
||
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
|
|
||
Comment 13•16 years ago
|
||
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
|
|
||
Updated•16 years ago
|
Flags: wanted1.8.1.x+ → wanted1.8.1.x-
|
||
Comment 14•16 years ago
|
||
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
|
||
Comment 15•16 years ago
|
||
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.
|
|
||
Comment 16•16 years ago
|
||
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>
|
|
||
Updated•16 years ago
|
Whiteboard: [sg:critical?] fixed by 436965 → [sg:dupe 436965]
|
|
||
Updated•15 years ago
|
Group: core-security
|
||
Updated•13 years ago
|
Crash Signature: [@ nsCSSFrameConstructor::InitAndRestoreFrame]
You need to log in
before you can comment on or make changes to this bug.
Description
•