If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

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




10 years ago
6 years ago


(Reporter: Martijn Wargers (dead), Assigned: smaug)


(5 keywords)

crash, regression, testcase, verified1.9.0.7, verified1.9.1
Dependency tree / graph
Bug Flags:
wanted1.9.1 +
blocking1.9.0.7 +
wanted1.9.0.x +
wanted1.8.1.x -

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [sg:dupe 436965], crash signature)


(2 attachments, 1 obsolete attachment)



10 years ago
Created attachment 317704 [details]

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:
So I guess a regression from bug 326273 (threadmanager).

The iframe content consists of this:
<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>

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';

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

Comment 2

9 years ago
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


9 years ago
Depends on: 466057

Comment 4

9 years ago
I think there is a script blocker missing in DoFlushPendingNotifications,
just before ProcessPendingRestyles.
Testing ...


9 years ago
Blocks: 284245

Comment 5

9 years ago
Created attachment 353876 [details] [diff] [review]
possible patch

Perhaps this is still better. Doesn't regress bug 284245.

Comment 6

9 years ago
Comment on attachment 353876 [details] [diff] [review]
possible patch

Doesn't pass all the editor tests :(
Attachment #353876 - Attachment is obsolete: true

Comment 7

9 years ago
Created attachment 353881 [details] [diff] [review]
v2, requires the patch for bug 466057


9 years ago
Assignee: nobody → Olli.Pettay


9 years ago
Depends on: 436965

Comment 8

9 years ago
Fixed by the patch in bug 436965.


9 years ago
Last Resolved: 9 years ago
Resolution: --- → FIXED

Comment 9

9 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

Comment 10

9 years ago
can/should this be moved to the 1.9.1 branch?

Comment 11

9 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.


9 years ago
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 with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv: Gecko/2009021204 GranParadiso/3.0.7pre. Doesn't crash there but does crash the shipped build.
Keywords: fixed1.9.0.7 → verified1.9.0.7

Comment 15

9 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

9 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>
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.