This bug was filed from the Socorro interface and is report bp-268c548d-ebf2-49ef-b5e2-5c1732120516 . ============================================================= Frame Module Signature Source 0 libxul.so libxul.so@0xdeb112 More Reports : https://crash-stats.mozilla.com/report/list?signature=libxul.so%400xdeb112 Note: Not really actionable by dev. Need to figure out what's going on here STR, trends, etc.

It happens also in 14.0a2.

Here are the URLs that show up for the various signatures: http://support.mozilla.org/en-US/kb/configure-mobile-privacy-and-security-settin https://developers.google.com/events/io/sessions http://m.splol.com/videos/video.rbml?mgid=mgid:cms:item:comedycentral.com:412655 http://support.mozilla.org/en-US/kb/android-add-ons-controls-options-preferences http://www.rmi.org/ReinventingFire http://www.reddit.com/ https://www.google.com/m?ie=UTF-8&oe=UTF-8&sourceid=navclient&gfns=1&q=total+fil https://addons.mozilla.org/en-US/android/extensions/?sort=rating http://www.franceinfo.fr/football/chelsea-remporte-la-ligue-des-champions-victoi

It's #11 top crasher in the first day of 14.0b3. bug 758895 which is probably a dupe has STR.

It's #5 top crasher in 14.0b6.

STR of bug 758895: * Select [Menu]+Quit

All crashes in 0xd: https://crash-stats.mozilla.com/query/query?product=FennecAndroid&version=ALL%3AALL&range_value=1&range_unit=weeks&date=06%2F11%2F2012+18%3A36%3A00&query_search=signature&query_type=contains&query=libxul.so%400xd&reason=&build_id=&process_type=any&hang_type=any&do_query=1 Ali, can you valgrind quitting Firefox to see if there's anything that pops up?

(In reply to Joe Drew (:JOEDREW!) from comment #6) > Ali, can you valgrind quitting Firefox to see if there's anything that pops > up? Nothing suspicious shows up.

It's probably a dupe of bug 765082.

Ali, did you try on a Cynogenmod device? I think the crash only happens on Cynogenmod.

(In reply to Naoki Hirata :nhirata from comment #9) > Ali, did you try on a Cynogenmod device? I think the crash only happens on > Cynogenmod. No, the device I have valgrind set up on has Android 2.3.7 from AOSP plus some patches needed for valgrind to work. I'll try again with Cyanogenmod (this will require making a custom build of Cyanogenmod with the patches needed for valgrind).

I tried again on a Nexus S with Cyanogenmod 9. This time, there were several invalid reads and writes. I've attached the complete valgrind log; this includes starting up, visiting about:config, and shutting down.

The shutdown crash seems relatively easy to reproduce on a Nexus S with Cyanogenmod 9; I reproduced the crash on cnn.com and on about:config. Here's the stack: #0 0x5514931a in ft_mem_free () from /home/ajuma/mozilla-central/objdir-android/dist/bin/libxul.so #1 0x551452f2 in Destroy_Module () from /home/ajuma/mozilla-central/objdir-android/dist/bin/libxul.so #2 0x551456f6 in FT_Remove_Module () from /home/ajuma/mozilla-central/objdir-android/dist/bin/libxul.so #3 0x55145972 in FT_Done_Library () from /home/ajuma/mozilla-central/objdir-android/dist/bin/libxul.so #4 0x5513fb9a in FT_Done_FreeType () from /home/ajuma/mozilla-central/objdir-android/dist/bin/libxul.so #5 0x548b8d48 in gfxAndroidPlatform::~gfxAndroidPlatform (this=0x5998fe80, __in_chrg=<optimized out>) at /home/ajuma/mozilla-central/gfx/thebes/gfxAndroidPlatform.cpp:45 #6 0x548b8d96 in gfxAndroidPlatform::~gfxAndroidPlatform (this=0x5998fe80, __in_chrg=<optimized out>) at /home/ajuma/mozilla-central/gfx/thebes/gfxAndroidPlatform.cpp:47 #7 0x548a6c7e in gfxPlatform::Shutdown () at /home/ajuma/mozilla-central/gfx/thebes/gfxPlatform.cpp:363 #8 0x53609f2c in nsThebesGfxModuleDtor () at /home/ajuma/mozilla-central/gfx/src/nsThebesGfxFactory.cpp:70 #9 0x547bcbaa in nsComponentManagerImpl::KnownModule::~KnownModule (this=0x52c57a00, __in_chrg=<optimized out>) at /home/ajuma/mozilla-central/xpcom/components/nsComponentManager.h:175 #10 0x547c3bda in nsAutoPtr<nsComponentManagerImpl::KnownModule>::~nsAutoPtr (this=0x52c4164c, __in_chrg=<optimized out>) at ../../dist/include/nsAutoPtr.h:71 #11 0x547c3a3e in nsTArrayElementTraits<nsAutoPtr<nsComponentManagerImpl::KnownModule> >::Destruct ( e=0x52c4164c) at ../../dist/include/nsTArray.h:348 #12 0x547c3306 in nsTArray<nsAutoPtr<nsComponentManagerImpl::KnownModule>, nsTArrayDefaultAllocator>::DestructRange (this=0x52c414b4, start=0, count=53) at ../../dist/include/nsTArray.h:1211 #13 0x547c2628 in nsTArray<nsAutoPtr<nsComponentManagerImpl::KnownModule>, nsTArrayDefaultAllocator>::RemoveElementsAt (this=0x52c414b4, start=0, count=53) at ../../dist/include/nsTArray.h:931 #14 0x547c18e6 in nsTArray<nsAutoPtr<nsComponentManagerImpl::KnownModule>, nsTArrayDefaultAllocator>::Clear (this=0x52c414b4) at ../../dist/include/nsTArray.h:942 #15 0x547be89a in nsComponentManagerImpl::Shutdown (this=0x52c41400) at /home/ajuma/mozilla-central/xpcom/components/nsComponentManager.cpp:737 #16 0x54762af0 in mozilla::ShutdownXPCOM (servMgr=0x0) at /home/ajuma/mozilla-central/xpcom/build/nsXPComInit.cpp:680 #17 0x5476261a in NS_ShutdownXPCOM_P (servMgr=0x52c41404) at /home/ajuma/mozilla-central/xpcom/build/nsXPComInit.cpp:542 #18 0x533cb270 in ScopedXPCOMStartup::~ScopedXPCOMStartup (this=0x52c480b0, __in_chrg=<optimized out>) at /home/ajuma/mozilla-central/toolkit/xre/nsAppRunner.cpp:1104 #19 0x533d230e in XREMain::XRE_main (this=0x51386a7c, argc=7, argv=0x52c6b048, aAppData=0x50aad344) at /home/ajuma/mozilla-central/toolkit/xre/nsAppRunner.cpp:3885 #20 0x533d2492 in XRE_main (argc=7, argv=0x52c6b048, aAppData=0x50aad344, aFlags=0) at /home/ajuma/mozilla-central/toolkit/xre/nsAppRunner.cpp:3939 #21 0x533dd91e in GeckoStart (data=0x79daa8, appData=0x50aad344) at /home/ajuma/mozilla-central/toolkit/xre/nsAndroidStartup.cpp:73 #22 0x50a8ca46 in Java_org_mozilla_gecko_GeckoAppShell_nativeRun (jenv=0x6d2810, jc=0x22a00001, jargs=0x20600005) at /home/ajuma/mozilla-central/mozglue/android/APKOpen.cpp:971 #23 0x40812db4 in dvmPlatformInvoke () from /home/ajuma/moz-gdb/lib/343364F76E0F00EC/system/lib/libdvm.so #24 0x4084cdd6 in dvmCallJNIMethod(unsigned int const*, JValue*, Method const*, Thread*) () from /home/ajuma/moz-gdb/lib/343364F76E0F00EC/system/lib/libdvm.so #25 0x4084eb06 in dvmResolveNativeMethod(unsigned int const*, JValue*, Method const*, Thread*) () from /home/ajuma/moz-gdb/lib/343364F76E0F00EC/system/lib/libdvm.so #26 0x40824bd0 in dvmJitToInterpNoChain () from /home/ajuma/moz-gdb/lib/343364F76E0F00EC/system/lib/libdvm.so #27 0x40824bd0 in dvmJitToInterpNoChain () from /home/ajuma/moz-gdb/lib/343364F76E0F00EC/system/lib/libdvm.so

Looking through the valgrind log, the invalid reads and write are happening in places where Cyanogenmod diverges from Android. The invalid reads are happening in adler32_vec in zlib. Cyanogenmod uses a fork of zlib (from https://github.com/kaffeemonster/zlib/tree/slhash); the function adler32_vec doesn't even exist in upstream zlib or in Android's zlib. The invalid writes are happening in FT_Library_SetLcdFilter in freetype. Unlike Android, Cyanogenmod builds freetype with subpixel rendering enabled (that is, with FT_CONFIG_OPTION_SUBPIXEL_RENDERING defined). This changes the implementation of FT_Library_SetLcdFilter from being (essentially) empty to being non-empty (see https://github.com/android/platform_external_freetype/blob/master/src/base/ftlcdfil.c).

It's #3 top crasher in 15.0b7.

It's #1 top crasher in 15.0 and 16.0b1.

Are any of these crashes *not* custom kernels? Most of the crashes are on custom kernels like CyanogenMod, TripNDroid, KangBang, and faux123.

(In reply to Chris Peterson (:cpeterson) from comment #16) > Are any of these crashes *not* custom kernels? There are some crashes on genuine Android according to the Linux version title, but crashes spiked with recent custom kernels. In recent nightlies, it accounts for around 25% of all crashes.

Tracking for Firefox 16, since this is a top crasher. Even if we don't support those releases officially, if we can find a simple fix, we should consider it. Let's see if we can resolve the STR in bug 758895, and what that does to our crash rate.

(In reply to Ali Juma [:ajuma] from comment #13) > Looking through the valgrind log, the invalid reads and write are happening > in places where Cyanogenmod diverges from Android. Is there some way we can fix this crash despite that divergence?

John and Jonathan, we're crashing in freetype during shutdown on these devices. Any thoughts? (stack in comment 12)

(In reply to Brad Lassey [:blassey] from comment #20) > John and Jonathan, we're crashing in freetype during shutdown on these > devices. Any thoughts? (stack in comment 12) Also see Comment 13 -- unlike Android, Cyanogenmod builds freetype with subpixel rendering enabled.

(In reply to Chris Peterson (:cpeterson) from comment #16) > Are any of these crashes *not* custom kernels? Near as I can tell after looking at 4 pages of crash stats for this crash all of the kernels are custom roms. Even ones that look generic such as bp-812cc14b-8cc4-432d-926b-e88592120910 with a kernel "0.0.0 Linux 3.0.31+ #1 SMP PREEMPT Wed Sep 5 13:54:15 EDT 2012 armv7l" looks to be a version of http://aokp.co/

Even though these are custom kernels, the fact that it's a top crash means that many of our users are using those kernels, having a poor experience, and rating us down regardless. We need to target a fix for FF16. If we need QA to test possible fixes, let's add qawanted here and run through the steps in comment 12.

Bug 790139 has also STR.

build.board: aries build.bootloader: unknown build.brand: samsung build.cpu_abi: armeabi-v7a build.cpu_abi2: armeabi build.device: GT-I9000 build.display: cm_galaxysmtd-userdebug 4.1.1 JRO03L eng..20120909.192301 test-keys build.fingerprint: samsung/GT-I9000/GT-I9000:2.3.5/GINGERBREAD/XXJVT:user/release-keys build.hardware: aries build.host: cyanogenmod build.id: JRO03L build.manufacturer: samsung build.model: GT-I9000 build.product: GT-I9000 build.radio: unknown build.serial: 39307058339800EC build.tags: test-keys build.time: 1347243800000 build.type: userdebug build.user: unknown version.codename: REL version.incremental: eng..20120909.192301 version.release: 4.1.1 version.sdk_int: 16

Is there any particular version of CM that is tickling this? I can't reproduce with CM7 on a GT-I9000

just installed CM9 on the same device, still not seeing the crash

(In reply to Brad Lassey [:blassey] from comment #26) > Is there any particular version of CM that is tickling this? I can't > reproduce with CM7 on a GT-I9000 We don't know if these crashes in xul are still reproducible by exit or if they are reproducible by the STR in bug 790139 or maybe other STR.

I've added a CM10 nightly to my TF-201 tablet and could not reproduce.

(In reply to Brad Lassey [:blassey] from comment #27) > just installed CM9 on the same device, still not seeing the crash With Nightly on CM9-10 I had crashes both on exit and during the use of the browser. So much so actually, that just because of that I have switched to the stock Jelly Beans on my Nexus S and now I haven't seen a crash for some time.

Not seeing a crash on exit and not seeing a crash when enabling reader 2mode on CM7, 9 or 10. I really need STR to move forward here.

(In reply to Matej Cepl from comment #30) > With Nightly on CM9-10 Can you post a link to a direct download of the build you are using? I had crashes both on exit and during the use of the > browser. So much so actually, that just because of that I have switched to > the stock Jelly Beans on my Nexus S and now I haven't seen a crash for some > time. I have a startup crash I filed yesterday with CM10 on my TF201; can you confirm if what you're seeing is bug 791781?

(In reply to Aaron Train [:aaronmt] from comment #32) > Can you post a link to a direct download of the build you are using? Not sure I have a link ... I was using ROM Manager and then downloaded CM Nightly from approx. a week ago. It could be http://oss.reflected.net/jenkins/8007/cm-10-20120914-NIGHTLY-crespo.zip but not completely sure about that. > I have a startup crash I filed yesterday with CM10 on my TF201; can you > confirm if what you're seeing is bug 791781? How would I know? It just crashed while browsing (not on exactly startup) ... and unfortunately while downgrading to the stock ROM I lost all app data including about:crashes.

I can reproduce this crash 100% of the time visiting mozilla.org on my TF201 running 09/18 CM10 Nightly by visiting http://www.mozilla.org How can I help debug further here?

(In reply to Ali Juma [:ajuma] from comment #13) > Looking through the valgrind log, the invalid reads and write are happening > in places where Cyanogenmod diverges from Android. Could/should we content the CyanogenMod people about this? If yes, who can do that?

(In reply to Robert Kaiser (:kairo@mozilla.com) from comment #35) > (In reply to Ali Juma [:ajuma] from comment #13) > > Looking through the valgrind log, the invalid reads and write are happening > > in places where Cyanogenmod diverges from Android. > > Could/should we content the CyanogenMod people about this? If yes, who can > do that? I'd like to first see if we can work around the issue, but feel free to reach out to community members here: http://wiki.cyanogenmod.com/wiki/Community_Members#Cyanogen

With CM9 Final on Galaxy Nexus (Maguro) I didn't experience any crashes (beta or nightly). On CM10 nightly 20120820 onwards I regularly keep experiencing crashing. Logcat shows nothing of note, but random webpages especially ones with javascript modifying page content cause crashes. As a result I've switched almost exclusively to Chrome :(.

(In reply to Aditya Sengupta from comment #37) > On CM10 nightly 20120820 onwards I regularly keep experiencing crashing. [...] > As a result I've switched almost exclusively to Chrome :(. The crash ratio in the latest Nightly is 68.5 crashes/100 ADU, the worst one I've ever seen, that makes it unusable. Nevertheless, this bug is not the culprit because it no longer happens in Nightly, hidden by other top crashers.

(In reply to Ali Juma [:ajuma] from comment #12) > The shutdown crash seems relatively easy to reproduce on a Nexus S with > Cyanogenmod 9; I reproduced the crash on cnn.com and on about:config. I get the same crash without needing to attempt to shutdown. I don't think this is a shutdown crash.

Am I correct here? Comment #12 sounds like this has to do with bug 790139.

Aaron can you still reproduce on your TF201?

Nope.

I am going to mark this as a dupe of 790139 then. If we see similar signatures a new bug would be best.

Clearing tracking, duped bug is already tracked & verified fixed on 17.