This bug was filed from the Socorro interface and is report bp-57939e30-e7b9-4d69-b1a9-38c5a2150408. ============================================================= Environment: Device: Asus Transformer Tab (Android 4.0.3); Build: Nightly 40.0a1 (2015-04-08); Steps to reproduce: 1. Load Fennec; 2. Go to Menu -> Tools -> New Guest Session; Expected result: Fennec is launched in guest mode. Actual result: Fennec crashes. Stack trace: 0 libmozglue.so ElfLoader::~ElfLoader() mozglue/linker/ElfLoader.cpp Ø 1 libc.so libc.so@0x1ebeb 2 libmozglue.so libmozglue.so@0x21343 3 libmozglue.so __udivdi3 4 libmozglue.so __udivdi3 Ø 5 dalvik-heap (deleted) dalvik-heap (deleted)@0x702c6 Ø 6 libc.so libc.so@0x1ef87 Ø 7 app_process app_process@0xcb7 Ø 8 libdvm.so libdvm.so@0xb7c56 Ø 9 libandroid_runtime.so libandroid_runtime.so@0x44d1d Ø 10 libdvm.so libdvm.so@0x72fd7 Ø 11 dalvik-LinearAlloc (deleted) dalvik-LinearAlloc (deleted)@0xbdbbe Ø 12 libdvm.so libdvm.so@0x72fb7 Ø 13 libdvm.so libdvm.so@0x5b0f9 Ø 14 dalvik-LinearAlloc (deleted) dalvik-LinearAlloc (deleted)@0xbdbbe Ø 15 core.odex core.odex@0xa25c4 Ø 16 dalvik-heap (deleted) dalvik-heap (deleted)@0x702c6 Ø 17 libdvm.so libdvm.so@0x1edbe Ø 18 libdvm.so libdvm.so@0x30a8e Ø 19 libdvm.so libdvm.so@0x74beb Ø 20 libdvm.so libdvm.so@0xb2f8e Ø 21 dalvik-LinearAlloc (deleted) dalvik-LinearAlloc (deleted)@0xa0a7e Ø 22 dalvik-heap (deleted) dalvik-heap (deleted)@0x66bd92 Ø 23 libdvm.so libdvm.so@0x342e6 Ø 24 libdvm.so libdvm.so@0x74beb Ø 25 libdvm.so libdvm.so@0xb7c56 Ø 26 libdvm.so libdvm.so@0xb7c56 Ø 27 dalvik-heap (deleted) dalvik-heap (deleted)@0x661016 Ø 28 framework.odex framework.odex@0x49ac36 Ø 29 dalvik-LinearAlloc (deleted) dalvik-LinearAlloc (deleted)@0xc2a6 Ø 30 dalvik-heap (deleted) dalvik-heap (deleted)@0x66bdd6 Ø 31 org.mozilla.fennec-2.apk org.mozilla.fennec-2.apk@0x44153c Ø 32 dalvik-LinearAlloc (deleted) dalvik-LinearAlloc (deleted)@0xa0a7e Ø 33 libdvm.so libdvm.so@0xb2f8e Ø 34 dalvik-heap (deleted) dalvik-heap (deleted)@0x66be82 Ø 35 dalvik-heap (deleted) dalvik-heap (deleted)@0x66bd92 Ø 36 libdvm.so libdvm.so@0x6cb63 Ø 37 dalvik-heap (deleted) dalvik-heap (deleted)@0x661016 Ø 38 dalvik-heap (deleted) dalvik-heap (deleted)@0x2a6 Ø 39 dalvik-heap (deleted) dalvik-heap (deleted)@0x66be6e Ø 40 libdvm.so libdvm.so@0x7b735 Ø 41 libdvm.so libdvm.so@0xb7c56 Ø 42 dalvik-heap (deleted) dalvik-heap (deleted)@0x66be6e Ø 43 libdvm.so libdvm.so@0xb7c56 Ø 44 libdvm.so libdvm.so@0x33a8a Ø 45 libdvm.so libdvm.so@0x4fda3 Ø 46 dalvik-heap (deleted) dalvik-heap (deleted)@0x936 Ø 47 org.mozilla.fennec-2.apk org.mozilla.fennec-2.apk@0x44153c Ø 48 dalvik-heap (deleted) dalvik-heap (deleted)@0xe8e Ø 49 dalvik-heap (deleted) dalvik-heap (deleted)@0x5681e Ø 50 dalvik-heap (deleted) dalvik-heap (deleted)@0x66bd7e Ø 51 dalvik-LinearAlloc (deleted) dalvik-LinearAlloc (deleted)@0xa0a7e Ø 52 dalvik-heap (deleted) dalvik-heap (deleted)@0x66be6e Ø 53 dalvik-heap (deleted) dalvik-heap (deleted)@0x2a6 Ø 54 libdvm.so libdvm.so@0x73fc1 Ø 55 dalvik-heap (deleted) dalvik-heap (deleted)@0x2a6 Ø 56 dalvik-LinearAlloc (deleted) dalvik-LinearAlloc (deleted)@0xbe3e Ø 57 core.odex core.odex@0xacbc4 Ø 58 dalvik-heap (deleted) dalvik-heap (deleted)@0x42de Ø 59 libdvm.so libdvm.so@0x1edbe Ø 60 libdvm.so libdvm.so@0x30a8e Ø 61 dalvik-LinearAlloc (deleted) dalvik-LinearAlloc (deleted)@0x2fa6 Ø 62 libdvm.so libdvm.so@0xb2f8e Ø 63 dalvik-LinearAlloc (deleted) dalvik-LinearAlloc (deleted)@0x8bad6 Ø 64 libdvm.so libdvm.so@0x342e6 Ø 65 libxul.so (deleted) libxul.so (deleted)@0x226ec59 Ø 66 dalvik-LinearAlloc (deleted) dalvik-LinearAlloc (deleted)@0x8bad6 Ø 67 framework.odex framework.odex@0x667ab8 Ø 68 libdvm.so libdvm.so@0x6ce33 Ø 69 dalvik-LinearAlloc (deleted) dalvik-LinearAlloc (deleted)@0x8bad6 Ø 70 dalvik-LinearAlloc (deleted) dalvik-LinearAlloc (deleted)@0x8bad6 Ø 71 libdvm.so libdvm.so@0x56f03 Ø 72 app_process app_process@0x103e Ø 73 app_process app_process@0x104e Ø 74 libdvm.so libdvm.so@0x553b9 Ø 75 libandroid_runtime.so libandroid_runtime.so@0x822ef Ø 76 libdvm.so libdvm.so@0x56f91 Ø 77 dalvik-heap (deleted) dalvik-heap (deleted)@0x153f6 Ø 78 libdvm.so libdvm.so@0x55397 Ø 79 app_process app_process@0x1094 Ø 80 libandroid_runtime.so libandroid_runtime.so@0x44d63 Ø 81 libandroid_runtime.so libandroid_runtime.so@0x9db6a Ø 82 libandroid_runtime.so libandroid_runtime.so@0x458cd Ø 83 dalvik-LinearAlloc (deleted) dalvik-LinearAlloc (deleted)@0x8bad6 Ø 84 app_process app_process@0x103e Ø 85 libcutils.so libcutils.so@0x6743 Ø 86 libcutils.so libcutils.so@0xf2d2 Ø 87 libcutils.so libcutils.so@0x664f Ø 88 libc.so libc.so@0x14c23 Ø 89 app_process app_process@0x8fe Ø 93 app_process app_process@0x213e Ø 94 app_process app_process@0x1047 Ø 95 app_process app_process@0xf0f Ø 96 app_process app_process@0x1064 Ø 97 app_process app_process@0x1072 Ø 98 app_process app_process@0x2026 Ø 99 libandroid_runtime.so libandroid_runtime.so@0x9c7ce Ø 100 libc.so libc.so@0x27c17 Ø 101 app_process app_process@0xbe2 Ø 102 libc.so libc.so@0x1672d

[Tracking Requested - why for this release]: regression NI to glandium and jchen to see if they have any thoughts or settings to try.

The crash is happening here: http://hg.mozilla.org/mozilla-central/annotate/078128c2600a/mozglue/linker/ElfLoader.cpp#l514 So this is very likely to be the same kind of root cause as bug 1127464: an OOM-condition-induced exit(). Bug 1127464 is what added that "controlled" MOZ_CRASH, because it's better to MOZ_CRASH than to randomly crash in libxul shutdown code.

Seems odd that we are hitting oom code on basic functionality.

I can reproduce the crash on a Galaxy Note 1 running 4.0.3. Seems like the patch from bug 1062758 didn't do enough to ensure Gecko shuts down gracefully, and as a result, the patch from bug 1127464 is (correctly) catching the abnormal shutdown.

Tracking for 39+.

I'm rewriting the restart code to only restart after Gecko exits.

This patch turns the Restarter into a service, which is more suitable for its role. It controls the whole restart procedure including killing off the old GeckoApp and launching a new GeckoApp. This simplifies things because we don't need the old logic that waited for the running process to end.

Use the restarter service in GeckoApp. The new code initiates exit/restart by ending the GeckoApp activity. Then, we take the appropriate action in GeckoApp.onDestroy(). The Gecko thread is running the entire time and killed off at the end, similar to what currently happens during backgrounding. One exception is when Gecko initiates the shutdown. In that case, the Gecko thread exits first, and then we end the GeckoApp activity in the newly added "Gecko:Exited" handler.

Remove code made obsolete by the new exit/restart procedure.

Comment on attachment 8593072 [details] [diff] [review] Quit or restart after GeckoApp activity is destroyed (v1) Review of attachment 8593072 [details] [diff] [review]: ----------------------------------------------------------------- Really nice

Comment on attachment 8593072 [details] [diff] [review] Quit or restart after GeckoApp activity is destroyed (v1) Review of attachment 8593072 [details] [diff] [review]: ----------------------------------------------------------------- I guess I forgot to actually +?

https://hg.mozilla.org/integration/mozilla-inbound/rev/b4bf97300f2c https://hg.mozilla.org/integration/mozilla-inbound/rev/6c44cb179e88 https://hg.mozilla.org/integration/mozilla-inbound/rev/594d0fd874d9

https://hg.mozilla.org/mozilla-central/rev/b4bf97300f2c https://hg.mozilla.org/mozilla-central/rev/6c44cb179e88 https://hg.mozilla.org/mozilla-central/rev/594d0fd874d9

Verified as fixed in build 40.0a1 2015-04-19; Device: Asus Transformer Tab (Android 4.0.3).

39 is marked as affected. What do you think about uplifting this fix to Aurora?

This fix introduced a lot of new code that I think should ride the trains. Considering the crash is an intentional, diagnostic crash caused by bug 1127464, maybe we should backout bug 1127464 from aurora?

If we're not in any worse of a state with this crash then we were with bug 1127464, it's probably fine to leave the tree as it currently is. I take it this bug is really just a new signature for bug 1127464. Again, if this is the case, the crash has been around for several releases already. While I'd like to see a fix for this topcrash, I think we can let the fix ride the trains and take the safest option.

I think this crash (unintentionally) affects a few more scenarios than bug 1127464 originally did. For example, in current aurora, this crash is preventing Guest Mode from working at all in some versions of Android (e.g. 4.0), so we should definitely do something.

Backing out bug 1127464 is not going to achieve anything useful: the shutdown path will crash anyways. Bug 1127464 just made that shutdown crash more controlled.

AFAIU, shutting down did not always crash (just when there's OOM), but bug 1127464 made it so that shutting down almost always crashes (in Android 4.0 at least). That's why normal tasks like entering guest mode is crashing, even though it's not an OOM situation.

The OOM (for GPU memory) was triggering the shutdown, but the crash was not necessarily related to it. Specifically, it's our own shutdown that crashes, and it was likely related to how we don't handle shutdown properly (like not running things in the right order, etc.). Also note that the patch in bug 1127464 made it so that a shutdown initiated by our code (that is, GeckoStart returns) should *not* crash voluntarily (but is likely to crash anyways).

(In reply to Mike Hommey [:glandium] from comment #22) > (but is likely to crash anyways). Actually, let me retract that last comment. After GeckoStart returns, things are more likely to be okay.

Marking 39 as wontfix since it sounds like uplifting this will have an uncertain effect and may just move the crash sig around.