It first showed up in 24.0a1/20130622. The regression range is: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=7ba8c86f1a56&tochange=cea75ce9a559 It's likely a regression from bug 868919. Signature mozalloc_abort(char const*) | NS_DebugBreak | _ZZL11toHexStringPKhjR19nsACString_internalE6digits More Reports Search UUID 3c7e9364-5ea8-4d3d-8c70-e79b32130625 Date Processed 2013-06-25 16:50:20 Uptime 1 Last Crash 13 seconds before submission Install Age 19 seconds since version was first installed. Install Time 2013-06-25 16:49:39 Product Firefox Version 25.0a1 Build ID 20130625031238 Release Channel nightly OS Mac OS X OS Version 10.8.4 12E55 Build Architecture amd64 Build Architecture Info family 6 model 37 stepping 2 Crash Reason EXC_BAD_ACCESS / KERN_INVALID_ADDRESS Crash Address 0x0 App Notes AdapterVendorID: 0x15ad, AdapterDeviceID: 0x 405xpcom_runtime_abort(###!!! ABORT: constructor for actor failed: file PCompositorChild.cpp, line 403) Processor Notes sp-processor03_phx1_mozilla_com_3859:2012; exploitability tool: ERROR: unable to analyze dump EMCheckCompatibility True Adapter Vendor ID 0x15ad Adapter Device ID 0x 405 Frame Module Signature Source 0 libmozalloc.dylib mozalloc_abort mozalloc_abort.cpp:30 1 XUL NS_DebugBreak nsDebugImpl.cpp:387 2 XUL _ZZL11toHexStringPKhjR19nsACString_internalE6digits More reports at: https://crash-stats.mozilla.com/report/list?signature=mozalloc_abort%28char+const*%29+|+NS_DebugBreak+|+_ZZL11toHexStringPKhjR19nsACString_internalE6digits

I can confirm that. Nightly and UX crash on browser startup since 2013-06-22/23 builds. MacOSXx86 10.8.1. https://crash-stats.mozilla.com/report/index/f38a14c8-cab3-45f2-904f-c8f732130626

More tests show this happens on all recent Aurora (24.0a2), Nightly (25.0a1) and UX (25.0a1) builds. They can only be started with -safe-mode argument from terminal. Fx 23 beta build works fine atm. What went wrong on recent builds and how to bypass this crash?

I finally figured out how to bypass this bug. While in safe-mode 'hardware acceleration' option needs to be disabled. I don't know why ha worked before, but now on latest builds it has to be disabled at least on my system.

Here is the current list of affected devices: * AdapterVendorID: 0x80ee, AdapterDeviceID: 0xbeef VirtualBox Graphics Adapter * AdapterVendorID: 0x15ad, AdapterDeviceID: 0x0405 VMWare Player 3.1.6 Software Driver * AdapterVendorID: 0x10de, AdapterDeviceID: 0x0863 NVIDIA GeForce 9400M * AdapterVendorID: 0x8086, AdapterDeviceID: 0x0102 Intel HD Graphics 2000 * AdapterVendorID: 0x8086, AdapterDeviceID: 0x0166 Intel HD Graphics 4000 * AdapterVendorID: 0x1002, AdapterDeviceID: 0x9583 ATI RADEON HD 2600 XT

Here is a better stack trace: Frame Module Signature Source 0 libmozalloc.dylib mozalloc_abort(char const*) memory/mozalloc/mozalloc_abort.cpp 1 XUL NS_DebugBreak xpcom/base/nsDebugImpl.cpp 2 XUL mozilla::layers::PCompositorChild::SendPLayerTransactionConstructor(mozilla::layers::PLayerTransactionChild*, mozilla::layers::LayersBackend const&, unsigned long long const&, mozilla::layers::TextureFactoryIdentifier*) obj-firefox/x86_64/ipc/ipdl/PCompositorChild.cpp 3 XUL nsBaseWidget::CreateCompositor(int, int) widget/xpwidgets/nsBaseWidget.cpp 4 XUL nsBaseWidget::CreateCompositor() widget/xpwidgets/nsBaseWidget.cpp 5 XUL nsChildView::CreateCompositor() widget/cocoa/nsChildView.mm 6 XUL nsBaseWidget::GetLayerManager(mozilla::layers::PLayerTransactionChild*, mozilla::layers::LayersBackend, nsIWidget::LayerManagerPersistence, bool*) widget/xpwidgets/nsBaseWidget.cpp 7 XUL -[ChildView isUsingMainThreadOpenGL] widget/cocoa/nsChildView.mm 8 XUL -[ChildView isUsingOpenGL] widget/cocoa/nsChildView.mm 9 XUL -[ChildView viewWillDraw] widget/cocoa/nsChildView.mm More reports also at: https://crash-stats.mozilla.com/report/list?product=Firefox&signature=mozalloc_abort%28char+const*%29+|+NS_DebugBreak+|+mozilla%3A%3Alayers%3A%3APCompositorChild%3A%3ASendPLayerTransactionConstructor%28mozilla%3A%3Alayers%3A%3APLayerTransactionChild*%2C+mozilla%3A%3Alayers%3A%3ALayersBackend+const%26%2C+unsigned+long+long+const%26%2C+mozilla%3A%3Alayers%3A%3ATextureFactor%2E%2E%2E

It's #1 top browser crasher in 24.0a2 and 25.0a1 on Mac OS X.

Passing this on the :mattwoodrow for help with investigation of this start-up topcrash as this is a suspected regression form Bug 868919.

This happens every startup in my OSX VM. Additional debug messages printed are: == 2013-07-11 11:12:01.132 firefox[88161:920f] invalid pixel format 2013-07-11 11:12:01.133 firefox[88161:920f] invalid context 2013-07-11 11:12:01.133 firefox[88161:920f] invalid pixel format 2013-07-11 11:12:01.134 firefox[88161:920f] invalid context ###!!! [Parent][SyncChannel] Error: Value error: message was deserialized, but contained an illegal value ###!!! ABORT: constructor for actor failed: file /Users/skip/src/central/obj-release/ipc/ipdl/PCompositorChild.cpp, line 403 ###!!! ABORT: constructor for actor failed: file /Users/skip/src/central/obj-release/ipc/ipdl/PCompositorChild.cpp, line 403 ==

CC'ing nrc since I think he was fixing the same bug for d3d9. I guess this is because we don't have your VM's video card/drivers blacklisted, so we attempt OpenGL via OMTC. We don't have a graceful fallback path for this, and we abort when GL initialization fails.

(In reply to Matt Woodrow (:mattwoodrow) from comment #9) > CC'ing nrc since I think he was fixing the same bug for d3d9. > > I guess this is because we don't have your VM's video card/drivers > blacklisted, so we attempt OpenGL via OMTC. > > We don't have a graceful fallback path for this, and we abort when GL > initialization fails. I have added a more graceful fallback when the compositor fails to initialise. It is part of this patch: https://bugzilla.mozilla.org/attachment.cgi?id=772923. You probably want to check that it will address this issue and work with OpenGL. I hope to land that early next week. If this is more urgent it is probably not too hard to pull out the functionality from that patch.

(In reply to Nick Cameron [:nrc] from comment #10) > I have added a more graceful fallback when the compositor fails to > initialise. It is part of this patch: > https://bugzilla.mozilla.org/attachment.cgi?id=772923. You probably want to > check that it will address this issue and work with OpenGL. I tried to apply that patch, but it alone fails to apply as it patches gfx/layers/d3d9/TextureD3D9.cpp which doesn't exist yet, and the earlier patches in that bug have > 10 chunks failing to apply. However, I'll keep my eye on that bug and if I see new attachments or see it land, I'll try again.

(In reply to Mark Hammond (:markh) from comment #11) > (In reply to Nick Cameron [:nrc] from comment #10) > > I have added a more graceful fallback when the compositor fails to > > initialise. It is part of this patch: > > https://bugzilla.mozilla.org/attachment.cgi?id=772923. You probably want to > > check that it will address this issue and work with OpenGL. > > I tried to apply that patch, but it alone fails to apply as it patches > gfx/layers/d3d9/TextureD3D9.cpp which doesn't exist yet, and the earlier > patches in that bug have > 10 chunks failing to apply. > > However, I'll keep my eye on that bug and if I see new attachments or see it > land, I'll try again. Yeah, there is a whole bunch of related and un-related stuff in that patch. It will probably work without those chunks, but you would have to do a pretty detailed check for what it the compositor fallback and what isn't. Probably just better to wait till it lands :-)

Nick, we are going to need this fixed before the next uplift. Are you confident that it will land within that time frame? I can extract the necessary pieces if not.

(In reply to Matt Woodrow (:mattwoodrow) from comment #13) > Nick, we are going to need this fixed before the next uplift. Are you > confident that it will land within that time frame? > > I can extract the necessary pieces if not. Yeah, definitely. I talked to roc about it yesterday and I'll land it pref'ed off even if it is not passing all the tests. So, it'll land this week.

Hmmm. https://tbpl.mozilla.org/php/getParsedLog.php?id=25484701&tree=UX

Fixed in Aurora 24 by disabling OMTC on Mac OS X.

This is now working for me - can anyone else confirm?

(In reply to Mark Hammond (:markh) from comment #17) > This is now working for me - can anyone else confirm? I haven't seen crashes with this abort message after 25.0a1/20130805. The working range is: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=482b9d04974a&tochange=ad0ae007aa9e It's fixed by some patches of bug 874721.

Marking this verified since I'm not seeing this in crash-stats for Firefox 25 in the last week.