Closed Bug 488057 Opened 15 years ago Closed 15 years ago

Crash [@ nsPresContext::GetContainerInternal] with font-face and frames removing window on focus

Categories

(Core :: Layout, defect)

Product:
Core
Component:
Layout
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: martijn.martijn, Assigned: bzbarsky)

Details

(Keywords: crash, testcase, verified1.9.1)

Crash Data

Attachments

(2 files)

testcase
3.40 KB, text/html
Details
Possible fix
1.79 KB, patch
roc
: review+
roc
: superreview+
roc
: approval1.9.1+
Details | Diff | Splinter Review
Attached file testcase — 
See testcase, it usually crashes within 10 seconds or so with current trunk build.

Breakpad stack:
http://crash-stats.mozilla.com/report/index/49926410-9c24-4a8d-9fa8-f3c0e2090412?p=1

0  	xul.dll  	nsPresContext::GetContainerInternal  	 layout/base/nsPresContext.cpp:1296
1 	xul.dll 	nsPresContext::GetContainer 	obj-firefox/dist/include/layout/nsPresContext.h:430
2 	xul.dll 	PresShell::UnsuppressAndInvalidate 	layout/base/nsPresShell.cpp:4452
3 	xul.dll 	PresShell::UnsuppressPainting 	layout/base/nsPresShell.cpp:4485
4 	xul.dll 	PresShell::sPaintSuppressionCallback 	layout/base/nsPresShell.cpp:2646
5 	xul.dll 	nsTimerImpl::Fire 	xpcom/threads/nsTimerImpl.cpp:427
6 	nspr4.dll 	_PR_MD_UNLOCK 	nsprpub/pr/src/md/windows/w95cv.c:344
7 	xul.dll 	nsTimerEvent::Run 	xpcom/threads/nsTimerImpl.cpp:519
8 	xul.dll 	nsThread::ProcessNextEvent 	xpcom/threads/nsThread.cpp:510
9 	xul.dll 	nsBaseAppShell::Run 	widget/src/xpwidgets/nsBaseAppShell.cpp:170
10 	xul.dll 	nsAppStartup::Run 	toolkit/components/startup/src/nsAppStartup.cpp:192
11 	nspr4.dll 	PR_GetEnv 	
12 	firefox.exe 	wmain 	toolkit/xre/nsWindowsWMain.cpp:107
13 	firefox.exe 	firefox.exe@0x21a7 	
14 	kernel32.dll 	BaseProcessStart 

The contents of the iframes are this:
<html>
<head>
</head>
<body>
<iframe></iframe>
<style>
@font-face {
  font-family: "aaa";
  src: url("http://martijn.martijn.googlepages.com/CODE2000.TTF");
}
* { font-family: "aaa"; }
</style>

<script>
window.addEventListener('focus', function(e) {window.frameElement.parentNode.removeChild(window.frameElement);}, true)
setTimeout(function() {window.focus()}, 500);
</script>
</body>
</html>
Flags: blocking1.9.2?
Flags: blocking1.9.1?
Flags: blocking1.9.1? → wanted1.9.1+
I think this should be blocking.  Over here, we're crashing because the mViewManager of the presshell is garbage in UnsuppressAndInvalidate.  Its frame manager mostly garbage too:

(gdb) frame
#0  0x11c44500 in PresShell::UnsuppressAndInvalidate (this=0x146b200) at /Users/bzbarsky/mozilla/vanilla/mozilla/layout/base/nsPresShell.cpp:4541
4541        mViewManager->SynthesizeMouseMove(PR_FALSE);
(gdb) p mFrameManager->mRootFrame
$8 = (Cannot access memory at address 0x4333252c
(gdb) p mFrameManager->mIsDestroying
$9 = 114 'r'
(gdb) p mFrameManager->mPresShell == this
$10 = false
(gdb) p mViewManager
$11 = (Cannot access memory at address 0x633b6c6d

We set up the paint suppression timer in PresShell::InitialReflow.  We cancel it in PresShell::Destroy.  So I don't see how we can end up firing on a dead presshell, offhand.

I suppose it's possible that UnsuppressAndInvalidate kills us.

I have no idea what @font-face has to do with this whole situation.
Flags: blocking1.9.1?
The font at http://martijn.martijn.googlepages.com/CODE2000.TTF is a very large font in size, that has something to do with the crash, afaict, because I didn't get the crash with a font that was small in size.
Attached patch Possible fix — — Splinter Review 
Martijn, do you mind testing this?  I only managed to reproduce the crash once in 20+ minutes of running the testcase without this patch, so I can't really be sure that it actually fixes the problem....
As far as comment 2 goes, is it just a matter of the unsuppress timer actually firing (and hence the load needing to take > 250ms)?
(In reply to comment #3)
> Created an attachment (id=376935) [details]
> Possible fix
> 
> Martijn, do you mind testing this?  

Yeah, that patch seems to fix the crash.
Attachment #376935 - Flags: superreview?(roc)
Attachment #376935 - Flags: review?(roc)
Assignee: nobody → bzbarsky
Attachment #376935 - Flags: superreview?(roc)
Attachment #376935 - Flags: superreview+
Attachment #376935 - Flags: review?(roc)
Attachment #376935 - Flags: review+
Pushed http://hg.mozilla.org/mozilla-central/rev/699b32591a66
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Attachment #376935 - Flags: approval1.9.1?
Attachment #376935 - Flags: approval1.9.1? → approval1.9.1+
Pushed http://hg.mozilla.org/releases/mozilla-1.9.1/rev/8ee098a4a140
Keywords: fixed1.9.1
Whiteboard: [needs landing]
Flags: blocking1.9.2?
Flags: blocking1.9.1?
Verified fixed on trunk and 1.9.1 with following builds:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090525 Minefield/3.6a1pre ID:20090525042828

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1pre) Gecko/20090525 Shiretoko/3.5pre (.NET CLR 3.5.30729) ID:20090525041408
Status: RESOLVED → VERIFIED
Flags: in-testsuite?
Keywords: fixed1.9.1 → verified1.9.1
Crash Signature: [@ nsPresContext::GetContainerInternal]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: