I have in my app an occasional and very hard to reproduce ANR event. Today it's happened, and I pulled out from the device the file trace.txt situated in /data/anr.
Unfortunately I can't understand the data in this file, here is the complete file content.
Can someone understand what is keeping my app's UI unresponsive?
I've already read similar questions but still can't read the file..
I've pasted the complete trace.txt file content to pastebin
EDIT
the file on pastebin is not available anymore and I do not have access to the trace.txt file anymore, so the answer can be closed.
thank you
You can use Strictmode to find out what calls delay a specific thread. The best way to use it is in the following form. In your application onCreate() you enable StrictMode. After that, (almost) all slow calls on that thread will be reported to your Log, with a full stacktrace of where it happened.
In your custom Application class:
public void onCreate() {
if (DEVELOPER_MODE) {
StrictMode.setThreadPolicy(new StrictMode.ThreadPolicy.Builder()
.detectAll() // detect everything potentially suspect
.penaltyLog() // penalty is to write to log
.build());
StrictMode.setVmPolicy(new StrictMode.VmPolicy.Builder()
.detectAll()
.penaltyLog()
.build());
}
super.onCreate();
}
As #Mohamed_AbdAllah has written on his comment "trace.txt is the situation of all running threads when the ANR occurred." Finding the reason of ANR from a thread while ANR occured seems impossible with a trace like you post. If you want to understand what those texts in trace mean, you may be interested in this. (You can get which thread is long running when the ANR occured from trace but this probably does not help you)
Alternatively, if you want to see what type of crashes/ANRs do you have with your andoid application(I assume that you are interested in applications that you developped and published on google play) you can use a crash report api. I use crashlytics for this purpose and it really helps me to fix my applications crashes. When you add this api to you application you can trace all Crashes/ANRs on a web page.
If your aim is understanding how to find reasons of ANRs from trace.txt then I have no idea. But if you need to find and fix your crashes/ANRs, then use a crash report api.
Edit: I assumed you are talking about an application which you've developed and published on google play. If you are talking about an application which is not published to google play yet, #Jeffrey Klardie's suggestion is just what you need. But it is not advised to enable Strictmode on applications at google play.
It's really hard to help on this without code to see what's going on, so instead I'll list what I would do to my own code should I be in this situation.
Run a Static Analysis tool on my code to identify some odd behavior (infinite loops, missing cases, etc.). Personally I use FindBugs.
Review the errors that pop-up from the Static Analysis tool, correct the ones that make sense for what you are doing.
Look through the code for any occurrences of "evil" code such as really long loops, synchronous activity that can be asynchronous, use of the sleep() function, asynchronous activity that is being treated synchronously, etc.
If none of the above made an impact start throwing in Log statements all over the place. Watch the output from a run and see where it gets to or what is repeating.
If none of the above worked, pop open a beer do a little yoga and then get back on the prowl and dig some more!
The most likely cause is the compiler is waiting for some interweb operation on the UI thread.
Related
During debugging of Android app, sometimes InterruptedException occurs and crashes the app. I've been able to set a break-point on default exception handler, but call stack is not informative.
at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.reportInterruptAfterWait(AbstractQueuedSynchronizer.java:1991)
at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2025)
at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1048)
at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:776)
at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1035)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1097)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:588)
at java.lang.Thread.run(Thread.java:820)
What is telling is that the interrupted thread is always RxCachedThreadScheduler-4 (or some other number)
What would be a systematic approach towards finding the root cause of the exception?
Set breakpoint at the method Thread::interrupt and catch the offender. If you think that this interruption should not happen, and you cannot switch off the call which interrupts your thread, then you can override Thread::interrupt in your thread implementation, and force the the thread pool to use your implementation by providing your own ThreadFactory.
It looks like the crash is happening from a third party code package, you should post your issue with the source project as well for additional help. Please post any code related to how you use this package to help troubleshoot too. Make sure you're using the latest version of this package in case they already fixed this issue. The stack trace isn't very helpful because the other project is launching threads and the crash happens from within one of their threads. Likely, you're not using the package as intended or there is a bug in it that they need to fix.
https://github.com/ReactiveX/RxJava
I'm getting following exception as soon as I want to show a widget and start listening:
// the relevant stack trace, the rest is comming from my code
// before the code line I posted below
java.lang.RuntimeException: system server dead?
at android.appwidget.AppWidgetHost.startListening(AppWidgetHost.java:189)
at com.my.app.utils.WidgetUtil.a(SourceFile:231)
...
android.os.DeadObjectException: Transaction failed on small parcel; remote process probably died
at android.os.BinderProxy.transactNative(Native Method)
at android.os.BinderProxy.transact(Binder.java:503)
at com.android.internal.appwidget.IAppWidgetService$Stub$Proxy.startListening(IAppWidgetService.java:481)
at android.appwidget.AppWidgetHost.startListening(AppWidgetHost.java:185)
at com.my.app.utils.WidgetUtil.a(SourceFile:231)
...
The source in my code is following code line:
mAppWidgetManager = AppWidgetManager.getInstance(context);
mAppWidgetHost = new AppWidgetHost(context, R.string.app_name);
mAppWidgetHost.startListening(); // <= this line leads to the crash
Observations
my app is working normally on a lot of phones (all but one actually)
above crash only happens on one users device (SM-N910C (Samsung Note 4), Android 6.0.1)
the user says, those widgets work fine in his launcher
Does anyone has an idea what could cause this? Is this something I can solve in my app? The user says widgets are working fine in his launcher...
So, a simple Google search led me to this definition of a DeadObjectException :-
The object you are calling has died, because its hosting process no longer exists.
From this, it is obvious that you're getting this error because the process that's hosting mAppWidgetHost has been killed off.
The question now is that why are you getting this error. Overriding and logging onDestroy() to monitor it could be useful, and definitely is worth a shot. But, since its working on all devices except for one, its more than likely that there's nothing wrong with the onDestroy() method. Instead, the OS is killing the process off before you can access the object.
So, now why is the OS doing that? This question had me balled up for the longest time. I still do not have a clear answer or solution to this despite a bevy of Google searches with all kinds of related to the problem. But, after spending a considerable amount of time searching, I noticed a peculiarity - most of the issues with this exception, such as this, this and yours happen with Samsung devices.
My guess is that Samsung's underlying architecture leads to this problem. And, while I do not have a reason why this happens or a plausible solution even after a lot more searching, this could still be a start to find a work around targeting Samsung devices.
UPDATE
I searched a bit more and came across this answer. Take a look at the last comment by the question author on the question :-
Finally it is working fine just by a line of code in manifest file, here it is android:hardwareAccelerated="false" If anybody get the following kind of errors please try by adding the above line signal 11 (SIGSEGV), code 1 (SEGV_MAPERR)
I don't know the logic behind this or if it would work or not. Just sharing it with the hope that it could help you - even in the minutest form.
DeadObjectException :
The object you are calling has died, because its hosting process no longer exists.
Possible Solutions:
1) Override your service's onDestroy() method and watch what event flow leads to it. If you catch DeadObjectException without going through this method, your service should have been killed by the OS.
2) by removing Typeface , this might be because of ttf which i was using from assets folder Please try comment the typeface and test it hope it will work for sure
3) put all your code inside the onCreate. From there you will see what is the culprit like a NullPointerException for example but your code will run smoothly already.
I'm building an app that sometimes crashes, I want to know that it crashed in the next time I opened it so I can suggest to the user some post-crash options.
How can I detect the crash?
Also I want to be able to save the user's work before it crashes, I means real time detection of crash, can I do it without knowing where it crashed?
You will need to know where it crashed in order to set the try/catch blocks in the right place to, er, catch the crash and save the data or whatever you have in mind.
This is known as "graceful" termination if you want to consider it in more detail.
Unfortunately neither Java destructor/finalize methods nor lifecycle methods such as onDestroy are anywhere near as robust as try/catch blocks so I'm afraid that is your only option, and how many of us deal with exception prevention. No-one would wittingly provide a user experience that crashes, much less with loss of their data.
Take a took at the ACRA library. You can configure it so whenever a crash happens you can control it and even send the crash log by email
You can use try/catch blocks, then send details on the Exception in your catch.
There are implement UncaughtExceptionHandler as mentioned in these answers and write crash report in some file or use it another way.
ACRA is already mentioned.
However for paid version, I found BugSnag is very good at this.
Or if you want to take the extra mile, try AppSee.
AppSee even has video recording session of how the crash happens. It is from tapping that button on the second list, the menu button or even when the user slides left in your viewpager.
My Android app uses the AWS Java SDK for uploading user photos to S3.
Whenever a user's phone's clock is 'skewed', this causes all transfers to fail. This is a well documented aspect of S3:
http://aws.amazon.com/articles/1109?_encoding=UTF8&jiveRedirect=1#04
It appears that the upstream S3 service reports this error quite clearly:
HTTP Status Code: 403 Forbidden
Error Code: RequestTimeToo-Skewed
Description: The difference between the request time and the server's
time is too large.
However when using the Java SDK, it seems as if the informative 403 code is lost ... and I have only an opaque "TransferState.Failed" to go by (which incidentally is the same error if internet connectivity is lost, if it times out, etc...).
As far as I can tell from the docs:
http://docs.aws.amazon.com/AWSJavaSDK/latest/javadoc/index.html
http://docs.aws.amazon.com/AWSJavaSDK/latest/javadoc/com/amazonaws/services/s3/transfer/TransferProgress.html
http://docs.aws.amazon.com/AWSJavaSDK/latest/javadoc/com/amazonaws/services/s3/transfer/Transfer.TransferState.html
http://docs.aws.amazon.com/AWSJavaSDK/latest/javadoc/com/amazonaws/services/s3/transfer/Upload.html
There is no way to get the additional "RequestTimeToo-Skewed" metadata about a transfer failure.
Am I missing it? Is there any way to get additional error information when an S3 transfer fails using Amazon's Java SDK?
UPDATE #1:
A commenter kindly highlighted that I should clarity two points:
I am actually using the AWS SDK for Android (which seems very similar to the Java SDK, but is nonetheless distinct)
I am using the TransferManager class to perform my upload. Apparently, this is a high-level class that wraps the lower-level AmazonS3Client ... and this lower-level class should expose the error reporting I need, but I am still investigating the exact tradeoffs involved between TransferManager and AmazonS3Client. As far as I can tell, there is no way to get progress information via the (synchronous) AmazonS3Client.putObjectRequest which would be a blocker for me...
UPDATE #2:
My sincere thanks to Jason (of the AWS SDK team) for stopping by and helping me out here. The important information is, indeed, available as properties on an AmazonS3Exception if you use certain methods. The docs had originally confused me and I thought that a manual Thread.sleep() loop was required to poll status (and thus I could not leverage waitForCompletion or waitForException), but if you use ProgressListener on PutObjectRequest you can get full progress callbacks and the error-fidelity of AmazonS3Exception.
these two methods should help you out:
Transfer.waitForCompletion()
Transfer.waitForException()
If you detect that your transfer has failed based on a transfer progress event, you can simply call Transfer.waitForException() to be returned the exception that occurred. That exception will be an AmazonServiceException in this case, with all of the info that you need to see that the real problem was a clock skew issue.
Alternatively, the Transfer.waitForCompletion() method will unwrap the original exception from an ExecutionException and directly throw the original exception, just as if it'd all been happening on one thread. This might be a more convenient approach if you want to use a catch blocks to catch different types of errors cleanly and elegantly.
I disagree that the "catch Exception" block is "brutally broad". The point of that code is to catch any error that happens, mark the transfer as failed and rethrow the error so that the application code can know about it. If it were less broad, then that's exactly the case where exceptions could sneak through and transfer progress wouldn't be updated correctly and would be out of sync with reality.
Give those two methods and shot and let us know if that helps!
Well, I have debugged Amazon's SDK and I'm sorry to say that this information is being swallowed internally. Perhaps I will try to submit a patch.
Details: an AmazonS3Exception is being thrown internally which does in fact accurately report this exact error scenario, but a brutally broad try catch ( Exception e ) consumes it and washes away the specificity.
Here is the guilty try-catch:
https://github.com/aws/aws-sdk-java/blob/master/src/main/java/com/amazonaws/services/s3/transfer/internal/UploadMonitor.java#L145
Here is a screenshot showing that an AmazonS3Exception is correctly thrown with the right info...
I've released my second game project on the Android Market this week, and immediately had multiple 1-star reports due to force closes. I tested it on many handsets and many emulators with zero issues. I'm completely at a loss for how to proceed and looking for advice.
I use Thread.setDefaultUncaughtExceptionHandler to intercept and report uncaught exceptions, then close gracefully. The people reporting force closes aren't getting to any of that, even though it is the first thing set in the application's main task constructor, and everything is wrapped in try/catches throughout. They are also reporting that there is no "Send Report" option in the force close popup (providing the Developer Console error reports), so I have absolutely no way of knowing what the problem is.
Uses Android 2.0, with android:minSdkVersion="5". Only Permission required is INTERNET.
(on Android market as 'Fortunes of War FREE' if you want to test)
I'm a bit surprised about the missing "Send report" button. What API level did you build the game with? I usually build the level with your minimum API level to make sure you're not using any API calls beyond that, but then switch back to the highest API level so you can use functionality like "install to SD".
I'm sure there's at least one user who wrote you a mail. Can you ask them to install LogCollector and mail you the log?
Btw, in general, I wouldn't use Thread.setDefaultUncaughtExceptionHandler so there IS the option to send a report. (It's ominously missing in your case, but normally, it should be there.)
Btw btw, the exception handler applies to the current thread. If you have an OpenGL app, maybe the crash happens in the GL thread?
I'm not sure if I understood you correctly, but as far as I know Android only shows that report dialog if you use its default UncaughtExceptionHandler.
Try this:
In your UncaughtExceptionHander's constructor, call Thread.getDefaultUncaughtExceptionHandler and save the returned object in a variable (let's call it defaultHandler). In your Handler's uncaughtException() do the things you want to do, and then call defaultHandler.uncaughtException() afterwards.
Maybe something you should know:
In my experience, your Context isn't functional anymore at uncaughtException(). So, you can't send broadcasts, etc anymore.
By the way, if you really wrapped everything in try/catch, that could be the reason why error reporting doesn't work as expected? :P
Good luck
Tom
Perhaps the force closes are caused by stalls, rather than exceptions. Users may not notice the difference. This kind of problem can occur more often if users have CPU hogging services running at the same time as your application, which explains why you're not seeing the issue in your testing.
Permission Internet sounds a lot like you try to transfer data from the net, which is very fast in your local LAN, but all of a sudden becomes slow (and time consuming) when people try this over their GSM connections.
If you then do the data transfer in the UI thread, this one is blocked and the system detects the block - but then this should end up in a "Did not respond" -- but then I've seen one user report an error with in the market on my app that was such a slow down cause.