1.Sometimes my app is running too slowly, and the log always print this error,although the app still continue running.
E/dalvikvm(17325): threadid=17: created from interp,name=auth
E/dalvikvm(17325): threadid=17: calling run(),name=auth
E/dalvikvm(17325): threadid=17: exiting,name=auth
E/dalvikvm(17325): threadid=17: created from interp,name=auth
2.The log prompted me this info:
I/Choreographer(17325): Skipped 227 frames! The application may be doing too much work on its main thread.
You'll have to profile your app to figure out where the slowdown is. Look at the running threads in the DDMS view and if that does not reveal anything, look into gathering a systrace.
As for your messages, the first group looks somewhat normal, you'll see the second fairly frequently if you're running on an emulator. On a real device, you'll see them also, but not as often. 227 frames does seem like an awful log though. Make sure you are doing all non-UI work on background threads. The systrace will help identify methods that are taking a long time.
Related
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 using DDMS to monitor threads in my app, and I see that my app has a bunch of native threads as shown in follow picture. And time to time, the number of native threads increased as user interact with my app, which cause my app sometime does not serve as I expect. Is there anyway to kill these native threads?
There is no such thing as a "native thread" on Android, although some people might use that to refer to threads that are not attached to the VM (which would also make them invisible to DDMS). The threads happen to be executing (or waiting) in native code at the time you did a thread dump, but may spend most of their time executing bytecode. (A list of Dalvik thread states is available here.)
The names of the threads suggests that they were created without being given an explicit name. The one thread with a name, NsdManager probably exists because you're using NsdManager, which "responses to requests from an application are on listener callbacks on a seperate thread" [sic].
It's possible that you can glean some useful information from a stack trace. In DDMS, double-click the thread to get a backtrace. On a rooted device, you can kill -3 <pid> to get a full dump, including native stack frames.
Killing arbitrary threads is not allowed, as they might be holding locks or other resources. If you can determine what is starting them, and that they are unnecessary, you can prevent them from being started in the first place.
I'm working in a application that I have a button to login, which checks if this account exists already in the database and if so, go to the next activity.
But nothing is showing in the layout screen.
The log cat is repeating the following message:
Skipped 48 frames! The application may be doing too much work on its main thread.
What is causing this?
I suggest you to take a look at http://developer.android.com/guide/components/processes-and-threads.html
Take some time studying how process and threads work on an Android system. It worth the effort.
Quoting a specific sentence related to your issue:
When your app performs intensive work in response to user interaction,
this single thread model can yield poor performance unless you
implement your application properly. Specifically, if everything is
happening in the UI thread, performing long operations such as network
access or database queries will block the whole UI. When the thread is
blocked, no events can be dispatched, including drawing events. From
the user's perspective, the application appears to hang. Even worse,
if the UI thread is blocked for more than a few seconds (about 5
seconds currently) the user is presented with the infamous
"application not responding" (ANR) dialog. The user might then decide
to quit your application and uninstall it if they are unhappy.
Good luck !
I am working on an Android app that displays a continuous custom-rendered animation on the title screen and thus doesn't really enter the idle state when it's done loading. On most devices I've tested, everything runs fine, but Samsung's Galaxy S2 kills the app after a few seconds. I don't get a stack trace or any output of the System.out output that I put into the onPause event handler and the default uncaught exception handler, so it doesn't seem to be a normal exit or an Exception in my code.
The only output I get in LogCat is the following:
Launch timeout has expired, giving up wake lock!
Sending signal. PID: 22344 SIG: 3
handleActivityTimeout pid=[22344] cnt=10
Process ... (pid 22344) has died.
There are several related posts here on SO (1, 2, 3, 4), but they all seem to trigger the issue slightly differently (alarm, recursive loops, network requests in the UI thread, ...). The last one links to a Google Groups discussion that says that this error message can simply be ignored. An approach I'd rather not take since it causes my app to actually crash on the Galaxy S2 (and maybe others?).
Basically what I did was to write a custom View that renders the next animation-frame in its onDraw() method and then calls postInvalidate() right before returning from onDraw(). In case it matters: My first postInvalidate() call happens during onCreate(...).
The rendering is very quick and runs at 40+ frames per second on that device and well over 60 fps on more modern phones. So control goes back to the event loop very frequently and the app is also very responsive. Yet, the Galaxy seems to think that it has crashed and kills it (if that is even the reason for my app dying there). The thing is: If I am quick enough to click on a menu-item in my app to end up on a screen without an animation to break out of the "tail-recursive" postInvalidate() once, everything runs fine. Even if I then go back to the title screen for a long time where the animation runs again.
So, of course, I could probably just use postInvalidateDelayed(...) once to break out of the start-up check, but that seems like a bit of a hacky solution and I don't know if there might be any other devices out there that might consider my app dead at a later stage (not just during start-up) and kill it.
Is there something fundamentally wrong with using postInvalidate() in the way I'm doing? Is there a way to fix it? I would like to avoid having to move to a separate thread since that opens a whole other can of worms as far as passing events back and forth between the UI and that thread. I know it wouldn't be the end of the world and using a SurfaceView, it might even lead to a slight performance improvement, but it's really just not necessary from a user experience point of view (everything runs perfectly smooth), so I'd like to avoid the involved additional opportunities for issues (multi-threading is notoriously difficult to debug).
I am running around ten AsyncTasks after my application starts. Sometimes the emulator takes a long time to start these tasks. When this occurs, I see the following message in the log cat:
D/dalvikvm(1983): threadid=8: still suspended after undo (sc=1 dc=1 s=Y)
When the emulator executes quickly this message doesn't appear. Strangely, this behavior changed today without any modifications. Since I have explicitly assigned 512mb ram to the emulator, it is no longer extremely slow ~5min, now ~5s. On a real device I never have execution that slow.
I would like to understand what this log cat message means. I understand that the thread with the specified id is suspended and not working while in this state. But why? After what undo? What does (sc=1 dc=1 s=Y) mean?
The message comes from dvmSuspendSelf(), which threads call when the debugger (via the JDWP thread) has asked them to suspend.
The way it's supposed to work is (where "we" are a thread):
JDWP asks us to suspend
we tell it we've suspended and go to sleep
eventually, debugger wakes us up and we resume
The message is logged when the condition variable the VM is waiting on signals, but for some reason we're still marked as suspended. The code notes:
/*
* The condition was signaled but we're still suspended. This
* can happen if the debugger lets go while a SIGQUIT thread
* dump event is pending (assuming SignalCatcher was resumed for
* just long enough to try to grab the thread-suspend lock).
*/
The expectation in this case is that we got woken up unexpectedly when a signal arrived (e.g. system_server thinks there's an ANR because the main thread isn't responding because the debugger has suspended it), and if we loop around again the debugger will get a chance to clean us up and set us on our way.
The log message is printing the values of self->suspendCount (how many times have we been told to suspend ourselves), self->dbgSuspendCount (how many of those suspend requests came from the debugger, so we can "undo" all those if the debugger disconnects), and the value of the self->isSuspended boolean.
Note the "s=Y" flag disappeared in gingerbread -- the way thread suspension works was changed.
This thread is old but this answer should provide useful for users stumbling across this question months later.
Quoting a user's reply on a google group thread
There's a weird interaction between the VM and your debugger. The
thread suspended itself and then waited to be woken. However, when it
was woken the thread was still marked as being suspended (s=1) by the
debugger (d=1).
I've come across this on the emulator and on the phone itself. If the debugger is disconnected from the device (be it emulated or real), this error condition is reset. I have found no other way of escaping the problem.
Another SO answer claims this is due to debug breakpoints being out of sync - DexFile.class error in eclipse
You can try that too.
HTH
Me too come across the problem.
Simply just because after I started a new Thread(), I tried to access the stuff in the thread that had already been suspended.
Removed that code, and the problem is resolved.
HTH