how to debug "deep" crashes in Android?

Question

I've been trying to debug an android crash that is occurring without a Java Stack Trace... Java Stack Trace bugs are very easy for me to fix... but this bug I'm getting seems to be crashing inside the "NDK" or whatever it is the deep internals of Android are called... I've made no modifications to the NDK btw... I just dunno what else to call that layer hehe.

Anyway I'm mainly looking for advice on deep-debug methods, rather than help with this specific problem... because I doubt I can post all the source code involved... so really I just need to know how to set breakpoints at the deep layers or whatever other methods there are to trace deep-crashes to their source... so I will briefly describe the bug and then post a LogCat.

I have an app with 7 Activities

Activity_INTRO
Activity_EULA
Activity_MAIN
Activity_Contact
Activity_News
Activity_Library
Activity_More

INTRO is the initiating one... it fades in some company logos... after displaying them for a set time it jumps to the EULA activity... after the user accepts the EULA, it jumps to MAIN... MAIN then creates a TabHost and populates it with the 4 remaining activities

now heres the thing... when I click on say, the More tab of the TabHost, the app pauses for a few seconds and then hard-crashes... no java stack trace, but an actual ASM level trace with the registers and IP and stack... the same thing occurs no matter which tab I select, Contact, News, Library, More... all of them crash with the same hard-crash

if however I set the manifest to start the app at Activity_MAIN, bypassing the INTRO and EULA, then these crashes do not occur... so something is lingering from those opening activities that is somehow hosing the TabHost'ed Activities... and I'm wondering what the hell that could be... because I'm using finish() on those activites when they need to jump... in fact here is how I'm doing it let me know if you see any bugs:

when jumping from INTRO to EULA I do:

//Display the EULA

Intent newIntent = new Intent (avi, Activity_EULA.class);

startActivity (newIntent);

finish();



and EULA to MAIN:

Intent newIntent = new Intent (this, Activity_Main.class);

startActivity (newIntent);

finish();

anyway, here is the hard crash log... please let me know if there is some way I can reverse engineer either /system/lib/libcutils.so or /system/lib/libandroid_runtime.so, because I think the crash is happening in one of them... i think its happening in the libandroid_runtime in fact.... anyway on to the log:

12-25 00:56:07.322: INFO/DEBUG(551): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***

12-25 00:56:07.332: INFO/DEBUG(551): Build fingerprint: 'generic/sdk/generic/:1.5/CUPCAKE/150240:eng/test-keys'

12-25 00:56:07.362: INFO/DEBUG(551): pid: 722, tid: 723  >>> com.killerapps.chokes <<<

12-25 00:56:07.362: INFO/DEBUG(551): signal 11 (SIGSEGV), fault addr 00000004

12-25 00:56:07.362: INFO/DEBUG(551):  r0 00000004  r1 40021800  r2 00000004  r3 ad3296c5

12-25 00:56:07.372: INFO/DEBUG(551):  r4 00000000  r5 00000000  r6 ad342da5  r7 41039fb8

12-25 00:56:07.372: INFO/DEBUG(551):  r8 100ffcb0  r9 41039fb0  10 41e014a0  fp 00001071

12-25 00:56:07.382: INFO/DEBUG(551):  ip ad35b874  sp 100ffc98  lr ad3296cf  pc afb045a8  cpsr 00000010

12-25 00:56:07.552: INFO/DEBUG(551):          #00  pc 000045a8  /system/lib/libcutils.so

12-25 00:56:07.572: INFO/DEBUG(551):          #01  lr ad3296cf  /system/lib/libandroid_runtime.so

12-25 00:56:07.582: INFO/DEBUG(551): stack:

12-25 00:56:07.582: INFO/DEBUG(551):     100ffc58  00000000  

12-25 00:56:07.592: INFO/DEBUG(551):     100ffc5c  001c5278  [heap]

12-25 00:56:07.602: INFO/DEBUG(551):     100ffc60  000000da  

12-25 00:56:07.602: INFO/DEBUG(551):     100ffc64  0016c778  [heap]

12-25 00:56:07.602: INFO/DEBUG(551):     100ffc68  100ffcc8  

12-25 00:56:07.602: INFO/DEBUG(551):     100ffc6c  001c5278  [heap]

12-25 00:56:07.612: INFO/DEBUG(551):     100ffc70  427d1ac0  

12-25 00:56:07.612: INFO/DEBUG(551):     100ffc74  000000c1  

12-25 00:56:07.612: INFO/DEBUG(551):     100ffc78  40021800  

12-25 00:56:07.612: INFO/DEBUG(551):     100ffc7c  000000c2  

12-25 00:56:07.612: INFO/DEBUG(551):     100ffc80  00000000  

12-25 00:56:07.612: INFO/DEBUG(551):     100ffc84  00000000  

12-25 00:56:07.622: INFO/DEBUG(551):     100ffc88  00000000  

12-25 00:56:07.622: INFO/DEBUG(551):     100ffc8c  00000000  

12-25 00:56:07.622: INFO/DEBUG(551):     100ffc90  df002777  

12-25 00:56:07.632: INFO/DEBUG(551):     100ffc94  e3a070ad  

12-25 00:56:07.632: INFO/DEBUG(551): #00 100ffc98  00000000  

12-25 00:56:07.632: INFO/DEBUG(551):     100ffc9c  ad3296cf  /system/lib/libandroid_runtime.so

12-25 00:56:07.632: INFO/DEBUG(551):     100ffca0  100ffcd0  

12-25 00:56:07.642: INFO/DEBUG(551):     100ffca4  ad342db5  /system/lib/libandroid_runtime.so

12-25 00:56:07.642: INFO/DEBUG(551):     100ffca8  410a79d0  

12-25 00:56:07.642: INFO/DEBUG(551):     100ffcac  ad00e3b8  /system/lib/libdvm.so

12-25 00:56:07.652: INFO/DEBUG(551):     100ffcb0  410a79d0  

12-25 00:56:07.652: INFO/DEBUG(551):     100ffcb4  0016bac0  [heap]

12-25 00:56:07.662: INFO/DEBUG(551):     100ffcb8  ad342da5  /system/lib/libandroid_runtime.so

12-25 00:56:07.662: INFO/DEBUG(551):     100ffcbc  40021800  

12-25 00:56:07.662: INFO/DEBUG(551):     100ffcc0  410a79d0  

12-25 00:56:07.662: INFO/DEBUG(551):     100ffcc4  afe39dd0  

12-25 00:56:07.662: INFO/DEBUG(551):     100ffcc8  100ffcd0  

12-25 00:56:07.662: INFO/DEBUG(551):     100ffccc  ad040a8d  /system/lib/libdvm.so

12-25 00:56:07.672: INFO/DEBUG(551):     100ffcd0  41039fb0  

12-25 00:56:07.672: INFO/DEBUG(551):     100ffcd4  420000f8  

12-25 00:56:07.672: INFO/DEBUG(551):     100ffcd8  ad342da5  /system/lib/libandroid_runtime.so

12-25 00:56:07.672: INFO/DEBUG(551):     100ffcdc  100ffd48  

12-25 00:56:07.852: DEBUG/dalvikvm(722): GC freed 367 objects / 15144 bytes in 210ms

12-25 00:56:08.081: DEBUG/InetAddress(722): www.akillerapp.com: 74.86.47.202 (family 2, proto 6)

12-25 00:56:08.242: DEBUG/dalvikvm(722): GC freed 62 objects / 2328 bytes in 122ms

12-25 00:56:08.771: DEBUG/dalvikvm(722): GC freed 245 objects / 11744 bytes in 179ms

12-25 00:56:09.131: INFO/ActivityManager(577): Process com.killerapps.chokes (pid 722) has died.

12-25 00:56:09.171: INFO/WindowManager(577): WIN DEATH: Window{43719320 
com.killerapps.chokes/com.killerapps.chokes.Activity_Main paused=false}

12-25 00:56:09.251: INFO/DEBUG(551): debuggerd committing suicide to free the zombie!

12-25 00:56:09.291: DEBUG/Zygote(553): Process 722 terminated by signal (11)

12-25 00:56:09.311: INFO/DEBUG(781): debuggerd: Jun 30 2009 17:00:51

12-25 00:56:09.331: WARN/InputManagerService(577): Got RemoteException sending 
setActive(false) notification to pid 722 uid 10020

score 4 · Answer 1 · answered Dec 31 '10 at 11:40

That crash appears to be from the Android firmware. It should not be possible for an SDK developer to cause one of these, and so it means there is a bug either in Android or your device.

If you can create a test project that reliably reproduces this crash, open an issue on http://b.android.com and attach it, along with your core dump trace shown above and any other useful information. Ordinarily, I would say you should search b.android.com first, but I don't know what bits of the trace are sufficiently distinctive to determine if your crash has been reported before or not.

score 0 · Answer 2 · answered Dec 31 '10 at 11:40

0

because I'm using finish() on those activites when they need to jump...

I'm not 100% certain, but I'm pretty sure you're not supposed to call finish() like that when you pass on control from one activity to another. Try removing the call to finish() and see if that makes it any better. It might not be this causing your error, but it's at least worth a shot.

answered Dec 31 '10 at 11:40

Julian

20,008
17
77
108

there seem to be 4 permutations: – eerok512 Jan 01 '11 at 17:14
1) if I remove the finish() from INTRO and EULA, there is no longer any crash in the later activities – eerok512 Jan 01 '11 at 17:15
2) if I remove the finish() from INTRO, but not from EULA, there is a "reset", where it normally would have crashed, it restarts at the INTRO... like the screen shifts over real quick like when activities transition, and there is the INTRO – eerok512 Jan 01 '11 at 17:17
3) if I remove the finish() from EULA, but not from INTRO, there is a "reset", but this time to the EULA – eerok512 Jan 01 '11 at 17:18
4) if I remove none of the finishes, well... nothing new to report there since that was the original code state i posted about... it crashes if both finish() calls are still present... so thats very interesting that I seemed to have some second sense about what might be causing this... since out of all my code I only pasted the calls to finish()... but I'm still not sure what is wrong with those calls... because the Android SDK pages describe it thus: – eerok512 Jan 01 '11 at 17:19
public void finish () - Call this when your activity is done and should be closed. The ActivityResult is propagated back to whoever launched you via onActivityResult(). – eerok512 Jan 01 '11 at 17:20
as far as I can see, thats exactly what I'm doing... my only hunch on this is perhaps because I'm calling finish() within milliseconds of calling startActivity (newIntent); that perhaps there isn't enough time for something to hook in? or backwards propogate? or something I dunno hehe... that is my only gut sense at this time, that my call to finish() is being done too quickly and that I should maybe wait for the child activity to spawn before I call it? Nailuj, what was your sense that it was being called wrong? – eerok512 Jan 01 '11 at 17:22
@eerok512: Well, remove your call to `finish()` then as I suggested, and you should be fine. And also as I said: you're not supposed to call `finishh()` that way when you pass on control to another activity. Let Android itself take care of when an activity should be closed (it is designed to do so in a good way when resources are needed, so just let it do its job). – Julian Jan 01 '11 at 17:23
ahh ok... ya I can do that... there is only one more aspect left, but this is definitely livable compared to the crashes hehe.. and that aspect is, when both the finishes() are removed... and I'm debugging the app using a USB cable hookup and the DDMS of Eclipse... and I click the STOP button to end the app on the device... where normally it would stop, a new instance of the app instantly springs open... in fact, I think according to the above permutations... like instantly opens at either EULA or INTRO... which i found odd... – eerok512 Jan 01 '11 at 17:25
but ultimately I care more about shipping this app to market, and even tho I find the way its now responding to DDMS with re-launching itself instantly to be very strange, its an abberation I can live with :-) – eerok512 Jan 01 '11 at 17:26
@eerok512: well, I'm glad if you fond a liveable solution :) If this answer was any help you should mark it as accepted. And if you encounter any more problems I recommend posting a _new_ questions, as these long discussions in the comment field seldom are of much help (not that many that read them). – Julian Jan 01 '11 at 17:34
hehe ya I may be flagging it as a found answer soon... I just want to run a few more tests before I'm sure... although I am still very curious what is the proper way to call finish()? if all Activities are best handled by the automatic garbage collector is there a reason they exposed the finish() API at all? can you give a text/code example of how to call it? hope I'm not being a burden but just am very curious :p – eerok512 Jan 01 '11 at 22:14
@eerok512: I'm not 100% sure on what's considered best practices here, but I'm pretty sure that there seldom are situations where you _need_ to call `finish()`. Just pass on control to your next activity, and let Android handle closing un-used activities. See for instance this question (http://stackoverflow.com/questions/2710470/calling-finish-after-starting-a-new-activity) which probably is related to what you're asking. – Julian Jan 05 '11 at 14:14

how to debug "deep" crashes in Android?

2 Answers2

Linked