I have an application that works fine on a device without a debugger attached. However, I have a problem while debugging in Eclipse:
When the main thread is suspended for 10 seconds or more (for example, after hitting a breakpoint), the main thread issues a SIGABRT, apparently coming from libc.
The only explanation I could think of is that the message queue in the main thread, when polling is not performed, is full of messages coming from another thread. However, I do not see how the heap grows when the main thread is suspended. Moreover, although my application has about 20 threads between all services, content providers, broadcast receivers, HTTP and map workflows, etc., I cannot really think about the source of any excessive messages.
So my question is: how do I fix this problem? What tools can I use and how can I find what causes my application to crash while waiting for a suspension in the debugger?
Change 1:
The only thing in logcat is:
02-05 22:23:54.861: I/dalvikvm(26795): threadid=3: reacting to signal 3 02-05 22:23:54.901: D/dalvikvm(26795): threadid=1: still suspended after undo (sc=1 dc=1) 02-05 22:23:54.901: I/dalvikvm(26795): Wrote stack traces to '/data/anr/traces.txt' 02-05 22:23:58.905: A/libc(26795): Fatal signal 6 (SIGABRT) at 0x000002f5 (code=0), thread 26795 (om.myapp)
Edit 2:
Further research leads me to believe that the android intentionally kills my process, because it mistakenly believes that the user interface thread is hanging. The problem is not in my application. So now my question is: how to stop Android from killing my process during debugging?
android eclipse sigabrt
zyamys Feb 06 '14 at 6:38 2014-02-06 06:38
source share