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.

investigating

One comment talks about outlook.com like in bug 781272.

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

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

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

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

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

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

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.

adding crash signatures for duplicate bug 781272 which just bit me (not repeatably) at the close of a tab.

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)

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

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 :(

In that case we should file a new bug to handle that regression.

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.

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?

John, can you please answer Virgil's question (comment 24)?

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