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

VERIFIED FIXED

Status

()

Core
Layout
--
critical
VERIFIED FIXED
9 years ago
7 years ago

People

(Reporter: Martijn Wargers (zombie), Assigned: bz)

Tracking

({crash, testcase, verified1.9.1})

Trunk
x86
Windows XP
crash, testcase, verified1.9.1
Points:
---
Bug Flags:
wanted1.9.1 +
in-testsuite ?

Firefox Tracking Flags

(Not tracked)

Details

(crash signature)

Attachments

(2 attachments)

(Reporter)

Description

9 years ago
Created attachment 372330 [details]
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>
(Reporter)

Updated

9 years ago
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?
(Reporter)

Comment 2

9 years ago
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.
Created attachment 376935 [details] [diff] [review]
Possible fix

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)?
(Reporter)

Comment 5

9 years ago
(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+
Keywords: checkin-needed
Whiteboard: [needs landing]
Pushed http://hg.mozilla.org/mozilla-central/rev/699b32591a66
Status: NEW → RESOLVED
Last Resolved: 9 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.