I am debugging an Android application and one of the activities just failed silently; it popped off the back stack and I got the previous activity.
I've seen silent failures of this type that can be attributed to memory problems, but in this case I am testing without the debugger attached. The logcat shows virtually no information: after some output from our touch listeners, I get
I/DEBUG(85): debuggerd committing suicide to free the zombie!
I/DEBUG(24919): debuggerd: Jul 8 2011 06:16:01
I/ActivityManager(157): Process com.tse.newsreader (pid 24415) has died.
I/WindowManager(157): WIN DEATH: Window{4108f938 com.tse.newsreader/com.tse.newsreader.activities.StorefrontFragmentActivity paused=false}
com.tse.newsreader is our process.
I would like to know if this is caused by a memory leak somewhere and I was hoping to add an HPROF dump to a global exception handler, somewhat as described in Is there a way to take a memory dump on app crash? but if there is no exception or OutOfMemoryError to catch, I don't see how that will help.
Can anyone suggest how I can get at the cause of these silent failures?
I'm not sure if this is what you mean, but you could consider adding something like bugsense to your app. It will pick up uncaught exceptions.
Related
I'm pretty baffled by the ANR I'm getting from my application as I don't understand how it could happen.
I've got mutliple ANR for these codes:
File(applicationContext.filesDir).mkdirs()
File(applicationContext.filesDir).exists()
and I get the following ANR report:
1.
main (native): tid=1 systid=30195
#00 pc 0xc57c8 libc.so
#01 pc 0x21580 libopenjdk.so
at java.io.UnixFileSystem.createDirectory0(UnixFileSystem.java)
at java.io.UnixFileSystem.createDirectory(UnixFileSystem.java:354)
at java.io.File.mkdir(File.java:1325)
at java.io.File.mkdirs(File.java:1352)
#01 pc 0x21fc0 libjavacore.so
at libcore.io.Linux.access(Linux.java)
at libcore.io.ForwardingOs.access(ForwardingOs.java:131)
at libcore.io.BlockGuardOs.access(BlockGuardOs.java:76)
at libcore.io.ForwardingOs.access(ForwardingOs.java:131)
at android.app.ActivityThread$AndroidOs.access(ActivityThread.java:8068)
at java.io.UnixFileSystem.checkAccess(UnixFileSystem.java:281)
at java.io.File.exists(File.java:813)
My application targets from Android 5 to Android 12 and only Android 11 and Android 12 are getting these ANRs.
Do you guys have any idea how to solve this ? Should I File(applicationContext.filesDir).mkdirs() on a different an IO Thread to avoid blocking ?
You should definitely perform all file operations off the main thread, regardless of what else is happening. It's definitely not a permissions issue -- if it were, you would just get a permission denial, not an ANR.
Having said that, you generally wouldn't get an ANR from just checking your app's fileDir, even on the main thread. But my guess is that wherever this AND came from, either the device's internal storage is really slow, or it's likely that your app was moved to external storage. Checking external storage availability takes longer.
Either way, as I said earlier, it doesn't actually matter why it's happening. You should just be performing all the file IO on a separate thread
My application uses background thread to initialize some of the stuff required by main thread to load the hero activity. It has bunch of locks for synchronization. I am looking for a quick way to plot possible stack traces where main thread was waiting for lock held by background thread during app startup. I checked Thread Status Monitor. How do I debug this? What's causing it? but this is talking about point to time thread state where as I am looking for all such events that occurred during startup without knowing where those occured.
I do see that this information can be found by manually inspecting startup android profile trace and looking at various thread stacks to find these occurrences, but there is lot of data to go through. It would be great if the tool can just show me # of times main thread waited for lock held by other threads, total amount of time spent and places where it held those locks.
Q1) Do we know whether Android profiler can show this? I checked https://developer.android.com/studio/profile/cpu-profiler but couldn't find it.
Q2) If not, is there any other tool that can parse profiler exported trace and print this info?
Q3) If not, do you have any pointers on how to read exported trace file. It seems to be binary. I am going through https://github.com/JetBrains/android to figure it out. It seems to be using perfetto now, but I haven't been able to write any utility to read that data yet.
Update: I discovered that CPU profiling/Systrace option shows that my main thread does remain idle or waits for some resources, however it doesn't have information around what does it wait for or what methods run after it was idle for some time. Any pointers to how to marry java method traces and sys trace view?
Perfetto is able to show this information. Look for "Lock Contention" messages on the timeline for a given thread. It also prints the data which thread has obtained that lock.
I'm working on an app that is recording data via Bluetooth, but it intermittently crashes after hours of collecting data (making it hard to track down the bug).
The logcat output isn't very helpful:
http://i.imgur.com/EalnX.png
There are no exceptions thrown and no clues for what caused the process to be terminated.
How can I figure out what went wrong? Is there an exception being thrown that isn't being shown by logcat? How can I track this bug down?
Signal 9 is SIGKILL, which will terminate a process immediately (no handlers inside the process will run). From the log line, the process is killing itself, so its not an external agent that is issuing the SIGKILL.
My guess (and its really a guess) is that the memory management code running inside your process (as part of the infrastructure, not code that you wrote) is deciding that you've exhausted some resource and the only recourse is to die. I would expect there to be more messages before this point is reached in the log, so it may be worth browsing the log history to see if there are useful warnings from the process before this point.
The line immediately before this is a GC log, which implies that some sort of memory resource is running low. But it looks like the heaps are not full, so failing allocations seems unlikely. You can still get allocation failures if the object being allocated was too large to fit on the heap, or fragmentation prevented it from being allocated. I'd expect to see more relevant log messages in this case, though.
I think capturing more of the log (perhaps filtering it by your app's PID if necessary) will help you make progress.
In my case there was no warnings or any clues in the log.
Eventually I found that my problem was that one of the activities I was going into (lets say Activity X) was registering to a broadcast receiver but never unregistered from it.
Therefor by closing the activity (Activity X) and coming back to it caused registering Again to the same broadcast receiver - which caused the mess!
Simply adding unregisterReceiver(mybroadcast); (in Activity X) solved it.
(I added mine to onDestroy. make sure you unregister in the right location).
And if you are super desperate I recommend seeing this slide share which explains Android crash debugging your errors.
this problem happens when using RXjava and not implement the onError callback method
i playing live video from api in my app. when i click play video then Progress dialog will come in between progress when i press back button 2 or 3 times of device then after some times it will give this error
ERROR/ActivityManager(98): Reason: keyDispatchingTimedOut
so how i can handle this error plz give me solution.
Thnax in advace.
This happens due to many reasons. I can't diagnose without your stack traces.
The most common reason for this error is when you are doing an CPU intensive task in a UI thread. Use threading or AsyncTask to delegate such CPU intensive work.
Is any ANR thrown? If so go in DDMS->File Explorer -> data/anr/traces.txt and check at which point ANR occurred.
keyDispatchingTimedOut when you are doing heavy calculation on main thread. Move what you are doing in a new background thread (if possible)
I recently received complaint from a user that my app was crashing. I've extracted the following from the user's error logs and was able to see why issues where happening:
12-17 10:31:12.446 I/PLAYLIST( 3158): PreparePlaylist
12-17 10:31:12.446 I/PLAYLIST( 3158): URL: http://f69cbd7a-3d91-4bf5-b4c6-ddb1175cf9e9.d40f2093-2013-4ad9-aec2-e99b015d61ca.070305e7-a706-4626-9ecb-777835065841.groovera.com/listen.pls
12-17 10:31:12.456 F/unknown ( 3158): stack corruption detected: aborted
12-17 10:31:12.466 D/Zygote ( 2204): Process 3158 terminated by signal (6)
12-17 10:31:12.471 I/ActivityManager( 2256): Process com.android.Player:remote (pid 3158) has died.
There was a stack corruption detected. Great, so how do I find out why that's happening?
I think the issue is happening at this particular class since I was expecting more log output from it before it died. This class uses sockets to download playlist and parse it. How could I be corrupting the stack? I have dealt with stack overflows in C/C++, but how do I handle it in Java?
Thanks for your help!
The message indicates corruption of the native stack. Code to detect stack buffer overflows is inserted when the gcc flag "-fstack-protector" is used.
If your app doesn't have any JNI code, then this could very well be a bug in the Android platform.
If you have a way to reproduce this, please file a bug on b.android.com with the details.