问题
I'm getting crashes from numerous devices for a native crash for my Android game, GeoGuess (https://play.google.com/store/apps/details?id=uk.co.quinny898.game.geoguess)
It's all Java, so I don't see why this crash is happening. The crash is on 34 unique devices (and counting) and is really causing problems for users (it appears to be on launch)
The stack trace is as follows:
*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
Build fingerprint: 'samsung/serranoltexx/serranolte:4.4.2/KOT49H/I9195XXUCNH5:user/release-keys'
Revision: '5'
pid: 23657, tid: 23704, name: AsyncTask #1 >>> uk.co.quinny898.game.geoguess <<<
signal 16 (SIGSTKFLT), code -6 (SI_TKILL), fault addr --------
r0 42049ee8 r1 00000000 r2 663c69c3 r3 00000000
r4 622a880e r5 64489e8c r6 6447ca98 r7 000020f4
r8 417bbf80 r9 622a8806 sl 00000000 fp 42b5f278
ip 65c49fec sp 64861c40 lr 00000000 pc 663c69d8 cpsr 600d0030
d0 0000000000000000 d1 0000000000000000
d2 0000000000000000 d3 0000000000000000
d4 0000000000000000 d5 0000000000000000
d6 0000000000000000 d7 4140000000000000
d8 0000000000000000 d9 0000000000000000
d10 0000000000000000 d11 0000000000000000
d12 0000000000000000 d13 0000000000000000
d14 0000000000000000 d15 0000000000000000
d16 6c2f6176616a4c5b d17 64696f562f676e61
d18 577fd198577fd160 d19 577fd208577fd1d0
d20 577fd278577fd240 d21 579b81c0577fd2b0
d22 579b8230579b81f8 d23 579b82a0579b8268
d24 be5777a5d80dadae d25 3cc135bdbf311355
d26 3cc135bdbd16946f d27 3cc135bdb6c717bc
d28 3ff0000000000000 d29 bef375cbdb605373
d30 be48c28772093484 d31 3fd5555555555563
scr 20000010
backtrace:
#00 pc 0000e9d8 /dev/ashmem/dalvik-jit-code-cache (deleted)
code around pc:
663c69b8 5897607c 65ce796c f85f0048 68010008
663c69c8 60013101 68a86829 f8d0b120 29001140
663c69d8 e001d0fa e0026029 e0056029 f8dfde00
663c69e8 6ef1003c 1c2d4788 4300e000 47806e70
663c69f8 622a8816 4300e000 47806e70 622a87b4
663c6a08 00000001 00000001 00000000 57be7128
663c6a18 002d0102 00000001 00000000 622a880e
663c6a28 65ce7970 f85f0030 68010008 60013101
663c6a38 68696928 f2c04288 1c2d8007 4300e000
663c6a48 47806e70 638d5004 f950e000 47806e70
663c6a58 638d5010 00000002 00000000 00000000
663c6a68 57c2e1f0 000a0101 00000001 00000000
663c6a78 65ce7974 f85f00bc 68010008 60013101
663c6a88 10fcf8df b1386828 f8df6800 428820f0
663c6a98 8002f000 b3984790 f8df6829 b39120d0
663c6aa8 429a680b 8009f040 8000f8d5 4008f8d8
code around lr:
00000000 ffffffff ffffffff ffffffff ffffffff
00000010 ffffffff ffffffff ffffffff ffffffff
00000020 ffffffff ffffffff ffffffff ffffffff
00000030 ffffffff ffffffff ffffffff ffffffff
00000040 ffffffff ffffffff ffffffff ffffffff
00000050 ffffffff ffffffff ffffffff ffffffff
00000060 ffffffff ffffffff ffffffff ffffffff
00000070 ffffffff ffffffff ffffffff ffffffff
00000080 ffffffff ffffffff ffffffff ffffffff
00000090 ffffffff ffffffff ffffffff ffffffff
000000a0 ffffffff ffffffff ffffffff ffffffff
000000b0 ffffffff ffffffff ffffffff ffffffff
000000c0 ffffffff ffffffff ffffffff ffffffff
000000d0 ffffffff ffffffff ffffffff ffffffff
000000e0 ffffffff ffffffff ffffffff ffffffff
000000f0 ffffffff ffffffff ffffffff ffffffff
Though the location and fingerprint change obviously.
It's not limited to Android version either, being reported on 4.3 and 4.4
The devices it's being reported on are as follows:
Xperia SP (C5303) 2 2.2%
LG Optimus L9 II (l9ii) 1 1.1%
Galaxy S3 (d2vmu) 1 1.1%
Galaxy S4 Mini (serranoltebmc) 2 2.2%
Galaxy S4 Active (jactivelteatt) 1 1.1%
Moto X (ghost) 6 6.6%
Droid Ultra (obake) 1 1.1%
Galaxy S3 (d2att) 1 1.1%
LG Optimus G (geehrc) 1 1.1%
Galaxy S4 Mini (serrano3g) 1 1.1%
Droid Mini (obakem) 1 1.1%
HTC One mini (htc_m4) 1 1.1%
Galaxy Express2 (wilcoxlte) 1 1.1%
Galaxy S4 (jfltespr) 1 1.1%
Galaxy S4 Mini (serranolte) 9 9.9%
Galaxy S4 (ks01lte) 2 2.2%
Galaxy S3 (d2vzw) 1 1.1%
Galaxy S4 (jfltevzw) 9 9.9%
Galaxy S4 (jfltecan) 1 1.1%
Galaxy S3 (d2usc) 1 1.1%
Galaxy S4 (jflteatt) 7 7.7%
Galaxy S4 Mini (serranoltevzw) 3 3.3%
HTC One (m7) 6 6.6%
Galaxy S3 (d2spr) 2 2.2%
Galaxy Note3 (hltecan) 1 1.1%
Xperia Z (C6603) 8 8.8%
Galaxy S4 Mini (serranolteusc) 3 3.3%
Galaxy Tab3 7.0 (lt02ltespr) 1 1.1%
Galaxy Note3 (hltevzw) 3 3.3%
Galaxy S4 (jflte) 6 6.6%
DROID RAZR M (scorpion_mini) 1 1.1%
Xperia Tablet Z (SGP321) 1 1.1%
Galaxy S4 (jflterefreshspr) 3 3.3%
Galaxy S4 (jfltetmo) 2 2.2%
Is this something I can fix?
回答1:
The Dalvik VM will throw a SIGSTKFLT at itself in certain circumstances. You can see the code here. One such call site is here. The goal was to get a stack trace from a spinning thread from debuggerd so you could see it in the logcat output. (This pre-dates the nice stack unwinding code that Android has now, and Dalvik went into low-maintenance mode before the unwinder was improved, so it continued to use this somewhat crude mechanism.)
You should see some diagnostics above the crash that complain about a spinning thread -- scroll up in the logcat output and see what you find.
Stack traces in the JIT code cache indicate that the thread was running JIT-compiled code at the time the signal arrived. In other words, this is a VM bug.
You may be seeing an instance of bug 58726, discussed a bit in this question. The specific circumstances of that bug were supposed to have been fixed by 4.4.2, but it's possible there's a different bug with similar failure characteristics. The basic issue is an OEM enhancement gone wrong... note in particular that you haven't seen any failures on stock Google Nexus devices. (I think all of the devices in your list are based on Qualcomm chips, which would point the finger at them. Again.)
As noted in my answer to the other question, the workaround is essentially to un-optimize your code so it doesn't hit the bad path in the JIT.
回答2:
This problem, or a similar one with Fatal signal 11 (SIGSEGV), can happen when running Instrumentation unit tests on ARM emulators, especially Android 4.1 emulator. You will also see this message in Logcat:
Test failed to run to completion. Reason: Instrumentation run failed due to Process crashed. Check device logcat for details.
It usually happens when tests are running in the background, with no Activity launched, for example ActivityUnitTestCase or SingleLaunchActivityTestCase.
The workaround is to launch an Activity while these tests are running, and ideally rewrite them to use ActivityTestRule.
来源：https://stackoverflow.com/questions/29545557/native-crash-at-dev-ashmem-dalvik-jit-code-cache