The default bug view has changed. See this FAQ.

abort crash in nsIFrame::GetOffsetToCrossDoc with abort message: "trying to get the offset between frames in different document hierarchies?"

VERIFIED FIXED in Firefox 17

Status

()

Core
Layout
--
critical
VERIFIED FIXED
5 years ago
4 years ago

People

(Reporter: Scoobidiver (away), Assigned: johns)

Tracking

(4 keywords)

17 Branch
mozilla17
crash, regression, reproducible, topcrash
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox16 unaffected, firefox17+ verified, firefox-esr10 unaffected)

Details

(crash signature)

Attachments

(1 attachment)

(Reporter)

Description

5 years ago
Bug 719117 is back.
It's currently #1 top crasher in today's build. The regression range is:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=1bbc0b65dffb&tochange=e55638d4037a

Signature 	mozalloc_abort(char const* const) | NS_DebugBreak_P | nsIFrame::GetOffsetToCrossDoc(nsIFrame const*, int) More Reports Search
UUID	bbd78ede-cb3b-454f-a478-96ee92120808
Date Processed	2012-08-08 17:41:33
Uptime	39
Install Age	39 seconds since version was first installed.
Install Time	2012-08-08 17:40:37
Product	Firefox
Version	17.0a1
Build ID	20120808030529
Release Channel	nightly
OS	Windows NT
OS Version	6.1.7601 Service Pack 1
Build Architecture	x86
Build Architecture Info	AuthenticAMD family 16 model 4 stepping 3
Crash Reason	EXCEPTION_BREAKPOINT
Crash Address	0x67891999
App Notes 	
AdapterVendorID: 0x1002, AdapterDeviceID: 0x6739, AdapterSubsysID: 23041787, AdapterDriverVersion: 8.980.0.0
D2D? D2D+ DWrite? DWrite+ D3D10 Layers? D3D10 Layers+ xpcom_runtime_abort(###!!! ABORT: trying to get the offset between frames in different document hierarchies?: file e:/builds/moz2_slave/m-cen-w32-ntly/build/layout/generic/nsFrame.cpp, line 4351)
EMCheckCompatibility	True
Adapter Vendor ID	0x1002
Adapter Device ID	0x6739
Total Virtual Memory	4294836224
Available Virtual Memory	3575574528
System Memory Use Percentage	37
Available Page File	13462474752
Available Physical Memory	5353267200

Frame 	Module 	Signature 	Source
0 	mozalloc.dll 	mozalloc_abort 	memory/mozalloc/mozalloc_abort.cpp:23
1 	xul.dll 	NS_DebugBreak_P 	xpcom/base/nsDebugImpl.cpp:410
2 	xul.dll 	nsIFrame::GetOffsetToCrossDoc 	layout/generic/nsFrame.cpp:4351
3 	xul.dll 	nsIFrame::GetOffsetToCrossDoc 	layout/generic/nsFrame.cpp:4335
4 	xul.dll 	PluginBoundsEnumerator 	layout/base/nsPresContext.cpp:2504
5 	xul.dll 	nsTHashtable<nsCertOverrideEntry>::s_EnumStub 	obj-firefox/dist/include/nsTHashtable.h:486
6 	xul.dll 	PL_DHashTableEnumerate 	obj-firefox/xpcom/build/pldhash.cpp:715
7 	xul.dll 	nsTHashtable<nsPtrHashKey<JSObject> >::EnumerateEntries 	obj-firefox/dist/include/nsTHashtable.h:237
8 	xul.dll 	nsRootPresContext::GetPluginGeometryUpdates 	layout/base/nsPresContext.cpp:2600
9 	xul.dll 	nsRootPresContext::UpdatePluginGeometry 	layout/base/nsPresContext.cpp:2729
10 	xul.dll 	PresShell::DidPaint 	layout/base/nsPresShell.cpp:7068
11 	xul.dll 	nsViewManager::DispatchEvent 	view/src/nsViewManager.cpp:770
12 	xul.dll 	AttachedHandleEvent 	view/src/nsView.cpp:159
13 	xul.dll 	nsWindow::DispatchEvent 	widget/windows/nsWindow.cpp:3520
14 	xul.dll 	nsWindow::DispatchWindowEvent 	widget/windows/nsWindow.cpp:3546
15 	xul.dll 	nsWindow::OnPaint 	widget/windows/nsWindowGfx.cpp:606
16 	xul.dll 	nsWindow::ProcessMessage 	widget/windows/nsWindow.cpp:4754
17 	xul.dll 	nsWindow::WindowProcInternal 	widget/windows/nsWindow.cpp:4341
18 	xul.dll 	CallWindowProcCrashProtected 	xpcom/base/nsCrashOnException.cpp:32
19 	xul.dll 	nsWindow::WindowProc 	widget/windows/nsWindow.cpp:4283
...

More reports at:
https://crash-stats.mozilla.com/report/list?signature=mozalloc_abort%28char+const*+const%29+|+NS_DebugBreak_P+|+nsIFrame%3A%3AGetOffsetToCrossDoc%28nsIFrame+const*%2C+int%29
Most likely John Schoenick's changes.
(Assignee)

Comment 2

5 years ago
investigating
Assignee: nobody → jschoenick
(Reporter)

Comment 3

5 years ago
One comment talks about outlook.com like in bug 781272.
(Reporter)

Updated

5 years ago
Crash Signature: [@ mozalloc_abort(char const* const) | NS_DebugBreak_P | nsIFrame::GetOffsetToCrossDoc(nsIFrame const*, int)] [@ mozalloc_abort(char const* const) | NS_DebugBreak_P] → [@ mozalloc_abort(char const* const) | NS_DebugBreak_P | nsIFrame::GetOffsetToCrossDoc(nsIFrame const*, int)] [@ mozalloc_abort(char const* const) | NS_DebugBreak_P] [@ mozalloc_abort | NS_DebugBreak_P | nsIFrame::GetOffsetToCrossDoc]
OS: Windows 7 → All
(Reporter)

Updated

5 years ago
Crash Signature: [@ mozalloc_abort(char const* const) | NS_DebugBreak_P | nsIFrame::GetOffsetToCrossDoc(nsIFrame const*, int)] [@ mozalloc_abort(char const* const) | NS_DebugBreak_P] [@ mozalloc_abort | NS_DebugBreak_P | nsIFrame::GetOffsetToCrossDoc] → [@ mozalloc_abort(char const* const) | NS_DebugBreak_P | nsIFrame::GetOffsetToCrossDoc(nsIFrame const* int)] [@ mozalloc_abort(char const* const) | NS_DebugBreak_P] [@ mozalloc_abort | NS_DebugBreak_P | nsIFrame::GetOffsetToCrossDoc] [@ mozalloc&hellip;
(Reporter)

Updated

5 years ago
Duplicate of this bug: 781776

Comment 5

5 years ago
https://bugzilla.mozilla.org/show_bug.cgi?id=781776
ATI HD2400 graphic card with open source drivers on linux. Random crashes on hotmail. Disabling HWA fixes the issue.

[    25.381] 
X.Org X Server 1.12.3
Release Date: 2012-07-09
[    25.381] X Protocol Version 11, Revision 0
[    25.381] Build Operating System: Linux 3.4.4-3-ARCH x86_64 
[    25.381] Current Operating System: Linux arch 3.4.7-1-ARCH #1 SMP PREEMPT Sun Jul 29 22:02:56 CEST 2012 x86_64
(Reporter)

Updated

5 years ago
Crash Signature: [@ mozalloc_abort(char const* const) | NS_DebugBreak_P | nsIFrame::GetOffsetToCrossDoc(nsIFrame const* int)] [@ mozalloc_abort(char const* const) | NS_DebugBreak_P] [@ mozalloc_abort | NS_DebugBreak_P | nsIFrame::GetOffsetToCrossDoc] [@ mozalloc&hellip; → [@ mozalloc_abort(char const* const) | NS_DebugBreak_P | nsIFrame::GetOffsetToCrossDoc(nsIFrame const* int)] [@ mozalloc_abort(char const* const) | NS_DebugBreak_P] [@ mozalloc_abort | NS_DebugBreak_P | nsIFrame::GetOffsetToCrossDoc] [@ mozalloc&hellip;

Comment 6

5 years ago
bp-c3acac94-0967-493d-a4d3-7abef2120813

Browser crashes with the crash sig when I test Bug 782384

STR
1. Open http://www.zataz.com/news/22329/photobucket_-photo_-hack_-fusking.html
2. Wait

Comment 7

5 years ago
Regression window(m-c)
Good:
http://hg.mozilla.org/mozilla-central/rev/1bbc0b65dffb
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Firefox/17.0 ID:20120807030518
Crash:
http://hg.mozilla.org/mozilla-central/rev/2637d896de91
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Firefox/17.0 ID:20120807063927
Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=1bbc0b65dffb&tochange=2637d896de91

Regression window(m-c)
Good:
http://hg.mozilla.org/integration/mozilla-inbound/rev/b4a63a0b90c2
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Firefox/17.0 ID:20120806153305
Crash:
http://hg.mozilla.org/integration/mozilla-inbound/rev/89ea9764f9e9
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Firefox/17.0 ID:20120806140630
Pushlog:
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=b4a63a0b90c2&tochange=89ea9764f9e9

In local build:
Last Good:b4a63a0b90c2
First Bad: f3bd764deb31

Triggered by: Bug 745030
(Reporter)

Updated

5 years ago
Blocks: 745030
Keywords: reproducible
Crash Signature: [@ mozalloc_abort(char const* const) | NS_DebugBreak_P | nsIFrame::GetOffsetToCrossDoc(nsIFrame const* int)] [@ mozalloc_abort(char const* const) | NS_DebugBreak_P] [@ mozalloc_abort | NS_DebugBreak_P | nsIFrame::GetOffsetToCrossDoc] [@ mozalloc&hellip; → [@ mozalloc_abort(char const* const) | NS_DebugBreak_P | nsIFrame::GetOffsetToCrossDoc(nsIFrame const* int)] [@ mozalloc_abort(char const* const) | NS_DebugBreak_P] [@ mozalloc_abort | NS_DebugBreak_P | nsIFrame::GetOffsetToCrossDoc] [@ mozalloc&hellip;
(Assignee)

Updated

5 years ago
Blocks: 782384
(Assignee)

Comment 8

5 years ago
Created attachment 651827 [details] [diff] [review]
Remove old logic that double-creates frameloaders in nsObjectLoadingContent

So the issue here is a mis-ordering of logic - we need to create the frameloader before we notify, not after.
Additionally, the requirement to force-notify at all before starting the document load was only a workaround for Bug 300540, now fixed
Attachment #651827 - Flags: review?(joshmoz)

Updated

5 years ago
Attachment #651827 - Flags: review?(joshmoz) → review+
(Assignee)

Comment 9

5 years ago
I confirmed this fixes the issue on a few reproducible cases, waiting on try push to succeed before landing:
https://tbpl.mozilla.org/?tree=Try&rev=1e72e421e6b8
Status: NEW → ASSIGNED
(Assignee)

Comment 10

5 years ago
Comment on attachment 651827 [details] [diff] [review]
Remove old logic that double-creates frameloaders in nsObjectLoadingContent

https://hg.mozilla.org/integration/mozilla-inbound/rev/194bf5cfd25f

try run:
https://tbpl.mozilla.org/?tree=Try&rev=1e72e421e6b8
Attachment #651827 - Flags: checkin+
tracking-firefox17: ? → +
https://hg.mozilla.org/mozilla-central/rev/194bf5cfd25f
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla17
(Reporter)

Updated

5 years ago
status-firefox17: --- → fixed
(Reporter)

Updated

5 years ago
Duplicate of this bug: 781272
(Assignee)

Updated

5 years ago
status-firefox-esr10: --- → unaffected
status-firefox16: --- → unaffected
(Assignee)

Updated

5 years ago
Duplicate of this bug: 782384
(Reporter)

Updated

5 years ago
No longer blocks: 782384
(Reporter)

Comment 14

5 years ago
It's back from 17.0a1/20120818. The new regression range is:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=a79132ac2f05&tochange=812ea773f166
It might be a regression from bug 781126.
Blocks: 782384
Status: RESOLVED → REOPENED
status-firefox17: fixed → affected
Resolution: FIXED → ---
(Reporter)

Updated

5 years ago
No longer blocks: 782384
adding crash signatures for duplicate bug 781272 which just bit me (not repeatably) at the close of a tab.
Crash Signature: [@ mozalloc_abort(char const* const) | NS_DebugBreak_P | nsIFrame::GetOffsetToCrossDoc(nsIFrame const* int)] [@ mozalloc_abort(char const* const) | NS_DebugBreak_P] [@ mozalloc_abort | NS_DebugBreak_P | nsIFrame::GetOffsetToCrossDoc] [@ mozalloc&hellip; → [@ mozalloc_abort(char const* const) | NS_DebugBreak_P | nsIFrame::GetOffsetToCrossDoc(nsIFrame const* int)] [@ mozalloc_abort(char const* const) | NS_DebugBreak_P] [@ mozalloc_abort | NS_DebugBreak_P | nsIFrame::GetOffsetToCrossDoc] [@ mozalloc&hellip;
(Reporter)

Updated

5 years ago
Crash Signature: [@ mozalloc_abort(char const* const) | NS_DebugBreak_P | nsIFrame::GetOffsetToCrossDoc(nsIFrame const* int)] [@ mozalloc_abort(char const* const) | NS_DebugBreak_P] [@ mozalloc_abort | NS_DebugBreak_P | nsIFrame::GetOffsetToCrossDoc] [@ mozalloc&hellip; → [@ mozalloc_abort(char const* const) | NS_DebugBreak_P | nsIFrame::GetOffsetToCrossDoc(nsIFrame const* int)] [@ mozalloc_abort(char const* const) | NS_DebugBreak_P] [@ mozalloc_abort | NS_DebugBreak_P | nsIFrame::GetOffsetToCrossDoc] [@ mozalloc&hellip;
(Reporter)

Updated

5 years ago
Crash Signature: [@ mozalloc_abort(char const* const) | NS_DebugBreak_P | nsIFrame::GetOffsetToCrossDoc(nsIFrame const* int)] [@ mozalloc_abort(char const* const) | NS_DebugBreak_P] [@ mozalloc_abort | NS_DebugBreak_P | nsIFrame::GetOffsetToCrossDoc] [@ mozalloc&hellip; → [@ mozalloc_abort(char const* const) | NS_DebugBreak_P | nsIFrame::GetOffsetToCrossDoc(nsIFrame const* int)] [@ mozalloc_abort(char const* const) | NS_DebugBreak_P] [@ mozalloc_abort | NS_DebugBreak_P | nsIFrame::GetOffsetToCrossDoc] [@ mozalloc&hellip;
I happened across a way to reproduce this on the latest Nightly.

Clean profile with just Flash active.

1. open youtube.com, start playing a video
2. While the youtube video is still playing, go to rng.io and let it run.

It crashes quickly.

here are a few examples:
https://crash-stats.mozilla.com/report/index/bp-a588de12-8443-41e0-911c-1dd942120820
https://crash-stats.mozilla.com/report/index/bp-69f75b50-8a16-4b9c-9d44-65cb92120820
(specifically, a crash in nsRootPresContext::RequestUpdatePluginGeometry)

Comment 18

5 years ago
(In reply to Andrew McCreight [:mccr8] from comment #16)
> I happened across a way to reproduce this on the latest Nightly.
> 
> Clean profile with just Flash active.
> 
> 1. open youtube.com, start playing a video
> 2. While the youtube video is still playing, go to rng.io and let it run.
> 
> It crashes quickly.
> 
> here are a few examples:
> https://crash-stats.mozilla.com/report/index/bp-a588de12-8443-41e0-911c-
> 1dd942120820
> https://crash-stats.mozilla.com/report/index/bp-69f75b50-8a16-4b9c-9d44-
> 65cb92120820

Regression window(m-c)
Good:
http://hg.mozilla.org/mozilla-central/rev/a79132ac2f05
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Firefox/17.0 ID:20120816175051
Crash:
http://hg.mozilla.org/mozilla-central/rev/e1cd9fb39dd7
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Firefox/17.0 ID:20120817052252
Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=a79132ac2f05&tochange=e1cd9fb39dd7


Regression window(m-i)
Good:
http://hg.mozilla.org/integration/mozilla-inbound/rev/7fe1c2d3d1f4
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Firefox/17.0 ID:20120816212351
Crash:
http://hg.mozilla.org/integration/mozilla-inbound/rev/6f2c8195793c
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Firefox/17.0 ID:20120816212651
Pushlog:
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=7fe1c2d3d1f4&tochange=6f2c8195793c

Triggered by: Bug 775965
That also matches the window in Comment 14 from Scoobidiver.

Updated

5 years ago
Blocks: 775965
(Assignee)

Comment 20

5 years ago
This looks to be a separate issue from what bug 745030 introduced, but I don't know enough about the frame/presentation side of this to understand what's going wrong here :(
Assignee: jschoenick → cpearce
In that case we should file a new bug to handle that regression.

Comment 22

5 years ago
I filed bug 784365 as I thought that was a new unrelated regression in the build from 19th, but it looks like it might be the same thing. We can use that bug for the re-regression or we can file a completely new one.
Also, I guess we should put the authors of bug 781126 or bug 775965, whatever the real one that re-regressed this is, on the hook for this. We should really get this resolved before uplifting 17 to Aurora.
Let's use bug 781279, which is about the specific crash signature that is currently #6.
Assignee: cpearce → jschoenick
No longer blocks: 775965
Status: REOPENED → RESOLVED
Last Resolved: 5 years ago5 years ago
Resolution: --- → FIXED
(Reporter)

Updated

5 years ago
status-firefox17: affected → fixed
Keywords: verifyme
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Firefox/17.0 beta 2
20121017073013

Checked on Windows XP, Windows 7. No crashes when following steps to reproduce from comment 6 and 16.

However there are still 63 crashes in 17.0 beta 1. http://bit.ly/T4YpWL

Is this expected in any way or should I file a separate bug?

Comment 25

4 years ago
John, can you please answer Virgil's question (comment 24)?
Keywords: verifyme
Whiteboard: [qa?]
(Assignee)

Comment 26

4 years ago
(In reply to Virgil Dicu [:virgil] [QA] from comment #24)
> Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Firefox/17.0 beta 2
> 20121017073013
> 
> Checked on Windows XP, Windows 7. No crashes when following steps to
> reproduce from comment 6 and 16.
> 
> However there are still 63 crashes in 17.0 beta 1. http://bit.ly/T4YpWL
> 
> Is this expected in any way or should I file a separate bug?

This signature is fairly generic, I would guess it is more likely related to bug 785808, since the issue tracked in this bug was fairly specific and reproducible.
Based on comment 26, I think we can call this verified fixed for Firefox 17. Please correct me if I am wrong.
Status: RESOLVED → VERIFIED
status-firefox17: fixed → verified
Whiteboard: [qa?]

Updated

4 years ago
Depends on: 823039
You need to log in before you can comment on or make changes to this bug.