Welcome to Software Development on Codidact!

Will you help us build our independent community of developers helping developers? We're small and trying to grow. We welcome questions about all aspects of software development, from design to code to QA and more. Got questions? Got answers? Got code you'd like someone to review? Please join us.

Post History

60%

+1 −0

Q&A Identifying non-daemon threads in an Android ANR stack dump

One of "my" Android apps is showing a heavy frequency of "slow exit" application-not-responding (ANR) problems. The Play Console has the "insight": Slow exit Problem The main thread has finish...

0 answers · posted 3mo ago by Peter Taylor‭

Question android stacktrace

#2: Nominated for promotion by

Alexei‭ · 2024-09-07T06:04:45Z (3 months ago)

Copy Link

Raw

Markdown

#1: Initial revision by

Peter Taylor‭ · 2024-09-05T15:12:42Z (3 months ago)

Copy Link

Raw

Markdown

Identifying non-daemon threads in an Android ANR stack dump

One of "my" Android apps is showing a heavy frequency of "slow exit" application-not-responding (ANR) problems. The Play Console has the "insight":

> Slow exit
>
> Problem  
> The main thread has finished processing events and is shutting down the app. As part of this process, it waits for all other threads to finish.
>
> Recommendation  
> If there is a thread that does not finish, it is possible that the app will show an ANR as the system considers it to still be active. A common cause for this type of ANR is installing a new uncaught exception handler that does not delegate to the previous handler. Failure to call back into the previous handler will cause an ANR.

It highlights that the stack trace of the main thread shows that it is exiting, but needs to wait for other threads to finish:

    "id.ELIDED" tid=16387 Native
      #00  pc 0x000000000004f66c  /apex/com.android.runtime/lib64/bionic/libc.so (syscall+28)
      #01  pc 0x000000000023247c  /apex/com.android.art/lib64/libart.so (art::ConditionVariable::WaitHoldingLocks(art::Thread*)+140)
      #02  pc 0x00000000005a5174  /apex/com.android.art/lib64/libart.so (art::ThreadList::WaitForOtherNonDaemonThreadsToExit(bool)+216)
      #03  pc 0x000000000068bcbc  /apex/com.android.art/lib64/libart.so (art::JII::DestroyJavaVM(_JavaVM*)+32)
      #04  pc 0x00000000000c9d44  /system/lib64/libandroid_runtime.so (android::AndroidRuntime::start(char const*, android::Vector<android::String8> const&, bool)+1124)
      #05  pc 0x0000000000002560  /system/bin/app_process64 (main+1280)
      #06  pc 0x000000000004b630  /apex/com.android.runtime/lib64/bionic/libc.so (__libc_init+96)

I would like to fix this, but I can't see how to distinguish non-daemon from daemon threads in the other stack traces, so I don't know where to start looking for things which need fixing. I assume that threads which have `java.lang.Daemons$Daemon.run` in their stacks are daemons, but threads like the Mono garbage collector thread[^Mono] are presumably also daemons and don't give any hint of it:

    "SGen worker" tid=16451 Native
      #00  pc 0x000000000004f66c  /apex/com.android.runtime/lib64/bionic/libc.so (syscall+28)
      #01  pc 0x0000000000054060  /apex/com.android.runtime/lib64/bionic/libc.so (__futex_wait_ex(void volatile*, bool, int, bool, timespec const*)+144)
      #02  pc 0x00000000000c113c  /apex/com.android.runtime/lib64/bionic/libc.so (pthread_cond_wait+76)
      #03  pc 0x000000000026ca14  /data/app/~~O2JnhGJ-xVFkcN-SaR9jkw==/ELIDED-IwHY5g75HacdUoR09XT4vQ==/lib/arm64/libmonosgen-2.0.so (thread_func+464)

**How can I identify non-daemon threads?**


[^Mono]: The app is in C# compiled with Xamarin and targets `net8.0-android`. This may or may not be relevant.

android stacktrace

Communities

Post History