Those crash signatures first appeared in Fennec 11.0a1/20111217. As they are in libxul.so, they will move each day. With combined signatures, it's #1 top crasher in Fennec 11.0a1 over the last 3 days. Signature libxul.so@0xacbf90 More Reports Search UUID d7891757-1de5-4f3a-9335-9880e2111218 Date Processed 2011-12-18 02:28:14.923575 Uptime 756 Last Crash 12.9 minutes before submission Install Age 37.3 minutes since version was first installed. Install Time 2011-12-17 18:34:55 Product Fennec Version 11.0a1 Build ID 20111217031145 Release Channel nightly OS Linux OS Version 0.0.0 Linux 2.6.35.7-I9100XWKE7-CL215725 #2 SMP PREEMPT Wed May 18 16:22:30 KST 2011 armv7l Build Architecture arm Build Architecture Info Crash Reason SIGSEGV Crash Address 0x4d900008 App Notes EGL? EGL+ AdapterVendorID: smdkc210, AdapterDeviceID: GT-I9100. AdapterDescription: 'Android, Model: 'GT-I9100', Product: 'GT-I9100', Manufacturer: 'samsung', Hardware: 'smdkc210''. samsung GT-I9100 samsung/GT-I9100/GT-I9100:2.3.3/GINGERBREAD/XWKE7:user/release-keys EMCheckCompatibility True Frame Module Signature [Expand] Source 0 libxul.so libxul.so@0xacbf90 1 libxul.so neon_composite_over_8888_8888 gfx/cairo/libpixman/src/pixman-arm-neon.c:63 2 @0x55c00c7e 3 libxul.so _moz_pixman_image_composite32 gfx/cairo/libpixman/src/pixman.c:373 4 libxul.so _clip_and_composite_boxes gfx/cairo/cairo/src/cairo-image-surface.c:3002 5 libxul.so _cairo_image_surface_fill gfx/cairo/cairo/src/cairo-image-surface.c:3759 6 libxul.so _cairo_surface_fill gfx/cairo/cairo/src/cairo-surface.c:2348 7 libxul.so _cairo_gstate_fill gfx/cairo/cairo/src/cairo-gstate.c:1290 8 libxul.so _moz_cairo_fill_preserve gfx/cairo/cairo/src/cairo.c:2459 9 libxul.so gfxContext::Fill gfx/thebes/gfxContext.cpp:160 10 libxul.so mozilla::layers::ThebesLayerBuffer::DrawBufferQuadrant gfx/layers/ThebesLayerBuffer.cpp:111 11 libxul.so mozilla::layers::ThebesLayerBuffer::DrawBufferWithRotation gfx/layers/ThebesLayerBuffer.cpp:123 12 libxul.so mozilla::layers::BasicThebesLayerBuffer::DrawTo gfx/layers/basic/BasicLayers.cpp:807 13 libxul.so mozilla::layers::BasicThebesLayer::PaintThebes gfx/layers/basic/BasicLayers.cpp:759 14 libxul.so mozilla::layers::BasicLayerManager::PaintLayer gfx/layers/basic/BasicLayers.cpp:1900 15 libxul.so mozilla::layers::BasicLayerManager::PaintLayer gfx/layers/basic/BasicLayers.cpp:1915 16 libxul.so mozilla::layers::BasicLayerManager::PaintLayer gfx/layers/basic/BasicLayers.cpp:1915 17 libxul.so mozilla::layers::BasicLayerManager::PaintLayer gfx/layers/basic/BasicLayers.cpp:1915 18 libxul.so mozilla::layers::BasicLayerManager::EndTransactionInternal gfx/layers/basic/BasicLayers.cpp:1612 19 libxul.so mozilla::layers::BasicLayerManager::EndTransaction gfx/layers/basic/BasicLayers.cpp:1563 20 libxul.so mozilla::layers::BasicShadowLayerManager::EndTransaction gfx/layers/basic/BasicLayers.cpp:3326 21 libxul.so nsDisplayList::PaintForFrame layout/base/nsDisplayList.cpp:635 22 libxul.so nsDisplayList::PaintRoot layout/base/nsDisplayList.cpp:540 23 libxul.so nsLayoutUtils::PaintFrame layout/base/nsLayoutUtils.cpp:1701 24 libxul.so PresShell::Paint layout/base/nsPresShell.cpp:5496 25 libxul.so nsViewManager::RenderViews view/src/nsViewManager.cpp:418 26 libxul.so nsViewManager::Refresh view/src/nsViewManager.cpp:393 27 libxul.so nsViewManager::DispatchEvent view/src/nsViewManager.cpp:891 28 libxul.so HandleEvent view/src/nsView.cpp:159 ... More reports at: https://crash-stats.mozilla.com/query/query?product=Fennec&version=Fennec%3A11.0a1&range_value=1&range_unit=weeks&query_search=signature&query_type=startswith&query=libxul.so%400xac&reason=&build_id=&process_type=any&hang_type=any&do_query=1

I got this crash on my Htc evo. I believe I may have been panning at the time of the crash. Builds from the 17th and 18th have been very crashy for me but I believe this is known.

I'm hitting this pretty regularly on my Galaxy SII: https://crash-stats.mozilla.com/report/index/52a8679f-b7ee-4e99-9610-4d4292111224 Also, can we get socorro to skip any frames like libxul.so@0xaeefc8? It would be much more useful if these crash reports had neon_composite_over_8888_8888 as their signature.

I believe this and bug 711853 to be the same issue, possibly related to gralloc.

(In reply to Brad Lassey [:blassey] from comment #3) > Also, can we get socorro to skip any frames like libxul.so@0xaeefc8? It's bug 711973.

About 69% of our crashes on nightly are due to this bug. Can we get it assigned to someone?

STR: on a neon instruction set device, 1. in settings-> display -> auto-rotate screen 2. launch fennec in portrait 3. once the about:home loads, rotate the phone to landscape Expected : no crash Actual: crash Note: Tested on : samsung Galaxy s II, Samsung Galaxy Nexus, Samsung Nexus S , HTC Thunderbolt

Occurs on 12/17/2011 central while rotating the phone rapidly during the time www.cnn.com is loading. Does not occur on 12/16/2011 central while doing the same. Still crashes with https://tbpl.mozilla.org/php/getParsedLog.php?id=7977773&tree=Firefox Does not crash with https://tbpl.mozilla.org/php/getParsedLog.php?id=7974692&tree=Firefox

Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=5efcb9c3b375&tochange=dcf6e5163e63 Could this be related to bug 708307?

We're tracking the rotation crash in bug 713774 which should be fixed as of today.

Doesn't crash anymore. Marking as verified dupe.

The patch of bug 713774 landed in 12.0a1/20120106 and has fixed most crashes, but there are still crashes in this build in low volume at startup: https://crash-stats.mozilla.com/report/list?signature=libxul.so%400xaf129c https://crash-stats.mozilla.com/report/list?signature=libxul.so%400xaf18d4

There are no more crash reports from yesterday. The last ones are from a build on January 6th. In which timezone are the times shown on crash-stats? Could it be that we suffer from it, or people build their own Firefox builds without this patch?

(In reply to Henrik Skupin (:whimboo) from comment #14) > There are no more crash reports from yesterday. There are still crashes in 12.0a1/20120108: https://crash-stats.mozilla.com/report/list?signature=libxul.so%400xade994 startup https://crash-stats.mozilla.com/report/list?signature=libxul.so%400xade52c

For information, with my personal debug build, I have this crash systematically on startup on a Nexus S and a SGS2.

(In reply to Mounir Lamouri (:volkmar) (:mounir) from comment #16) > For information, with my personal debug build, I have this crash > systematically on startup on a Nexus S and a SGS2. Neither phone is grallocable. When starting up, do you see "Using direct texture" or "Falling back to traditional texture upload" in your logcat? It should be the latter. If it's the former, our feature detection is failing, which will have disastrous results.

(In reply to Patrick Walton (:pcwalton) from comment #17) > (In reply to Mounir Lamouri (:volkmar) (:mounir) from comment #16) > > For information, with my personal debug build, I have this crash > > systematically on startup on a Nexus S and a SGS2. > > Neither phone is grallocable. When starting up, do you see "Using direct > texture" or "Falling back to traditional texture upload" in your logcat? It > should be the latter. If it's the former, our feature detection is failing, > which will have disastrous results. Nexus S is PowerVR which should definitely work (and has worked fine in the past). The SGS2 is more of a gray area (some work, some not).

mounir, are you crashing with the same stack trace as in this bug?

I'm running an GalaxyS2 with an alpha version of CM9 (Android 4.0.3). I was getting this one up until yesterday: https://crash-stats.mozilla.com/report/index/f5701a0f-6be8-4b52-a1b9-bea022120110 Now the app closes without the crash reporter showing up so I'm not sure what's happening. I will post an excerpt from a logcat I made during the launching of the app and during the crash. Hope this is useful. I wasn't certain if this was an issue with Fennec or the rom itself.

Do we think the remainder of this is still gralloc related or is it something else now?

I got this crash today on the LG Optimus Black, using the Native trunk build: https://crash-stats.mozilla.com/report/index/bp-21adf51a-4be7-4feb-870f-4b4b72120121 This was on a restart and session restore which opened 6 tabs.

(In reply to Martijn Wargers [:mw22] (QA - IRC nick: mw22) from comment #24) > https://crash-stats.mozilla.com/report/index/bp-21adf51a-4be7-4feb-870f- > 4b4b72120121 It's an old build, 12.0a1/20120104031035, before the patch of bug 713774 landed.

Ah yeah, sorry, I guess this was an unsubmitted report, that I accidentally submitted today.

I updated my Nightly today and am no longer experience a crash upon starting the app, but a similar experience is now occurring in the latest Aurora build.

I add the startupcrash keyword as almost all crashes have occurred on startup since the patch of bug 713774 landed. Nevertheless, there are some crashes that don't happen on startup: bp-45364f47-585c-4a32-894f-e0b1a2120117, bp-199d5fca-e4a0-497a-a490-ea1892120120.

https://bugzilla.mozilla.org/show_bug.cgi?id=713774#c20 shows that a fix was pushed on 1/19/2012 to Aurora. I could not reproduce this issue on Samsung Galaxy S II running 2.3.3; Linux localhost 2.6.35.7-I9100XWKI4-CL575468 #2 SMP PREEMPT Wed Sep 14 20:49:18 KST 2011 armv7l GNU/Linux running Aurora 1/22/2012. Michael, could you post the crash id from about:crashes for the crashes you are experiencing please? I am guessing the crashing at startup is actually occurring because of the tab restore feature after crashing/force quitting. Most likely it will not crash upon restart if you clear the data from the application first.

Found that I can crash on nightly by going to about:crashes and rotating the phone from portrait to landscape. Build 20120122

Ignore comment 30. Turned out that I was on the wrong build.

I cannot give you an id from about:crashes because I cannot get Auora to start without crashing, however, this is the crash that was submitted. https://crash-stats.mozilla.com/report/index/5f4f0586-2a80-490a-8238-ac7212120123

Michael, thanks for the crash report. Just wondering, have you gone to settings -> apps -> aurora -> clear data? If you haven't, could you try doing so and then trying to restart aurora please?

Yes, more than once. Crash every time.

https://crash-stats.mozilla.com/query/query?product=FennecAndroid&version=ALL%3AALL&range_value=30&range_unit=days&date=01%2F31%2F2012+15%3A00%3A59&query_search=signature&query_type=contains&query=arm_neon_fill&reason=&build_id=&process_type=any&hang_type=any&do_query=1 Still occurring; 2012-01-23 22:53:11; looks like a startup crash for this particular: https://crash-stats.mozilla.com/report/index/444b693b-60df-4b55-ad9e-5d7742120123

In 13.0a1, it happens only on Samsung Galaxy S2 (ARM Mali-400 graphical controller).

Having trouble finding any of these crashes. Are they still happening?

(In reply to Joe Drew (:JOEDREW!) from comment #37) > Having trouble finding any of these crashes. Are they still happening? There are only four crashes over the last four week. It happens on SC-02B or SGH-I897. Here is a recent crash report on Aurora: bp-e8c39464-fd11-45c3-8a29-6bda32120614.

:snorp, how do I find these crashes?

https://crash-stats.mozilla.com/search/?product=FennecAndroid&signature=~neon&_facets=signature&_columns=date&_columns=signature&_columns=product&_columns=version&_columns=build_id&_columns=platform#facet-signature https://crash-stats.mozilla.com/search/?product=FennecAndroid&signature=~8888&_facets=signature&_columns=date&_columns=signature&_columns=product&_columns=version&_columns=build_id&_columns=platform#facet-signature This should list the signatures in the signature field.

There doesn't seem to be a lot of these left.

Agreed most devices ship with neon support. The only significant neon crash is the [@ inflate_fast_copy_neon] which is all Gingerbread devices. The Gingerbread build will be EOL by the end of the year and even sooner on trunk. This is not worth working on.