Android 应用程序仅在 Eclipse 调试时因 SIGABRT Signal 6 崩溃
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/21595778/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Android app crashes with SIGABRT Signal 6 only while Eclipse debugging
提问by zyamys
I have an app that runs perfectly fine on a device without a debugger attached. However, I have a problem when debugging in Eclipse:
我有一个应用程序，它在没有连接调试器的设备上运行得非常好。但是，我在 Eclipse 中调试时遇到了一个问题：
When the main thread is suspended for about 10 seconds or more (for example after hitting a breakpoint), the main thread throws a SIGABRT, apparently coming from libc.
当主线程挂起大约 10 秒或更长时间（例如在遇到断点之后），主线程抛出一个 SIGABRT，显然来自 libc。
The only explanation I could think of is that the message queue on the main thread, when not being polled, is overflowing with messages coming from another thread. However, I don't see the heap growing when the main thread is suspended. Moreover, while my app has about 20 threads between all services, content providers, broadcast receivers, http and map worker threads, etc., I can't really think of a source of any excessive messages.
我能想到的唯一解释是主线程上的消息队列在未被轮询时被来自另一个线程的消息溢出。但是，当主线程暂停时，我没有看到堆在增长。此外，虽然我的应用程序在所有服务、内容提供者、广播接收器、http 和地图工作线程等之间有大约 20 个线程，但我真的想不出任何过多消息的来源。
So my question is: How do I fix this problem? What tools can I use and how do I go about finding what is causing my app to crash while sitting suspended in the debugger?
所以我的问题是：我该如何解决这个问题？我可以使用哪些工具以及如何在调试器中暂停时查找导致我的应用程序崩溃的原因？
Edit 1:
编辑1：
The only thing in logcat is:
logcat 中唯一的东西是：
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:
编辑2：
Further investigation leads me to believe it is android intentionally killing my process because it mistakenly thinks the UI thread is hung. The problem is NOT in my app. So now my question is: How do I stop Android from killing my process while debugging?
进一步的调查使我相信这是 android 故意杀死我的进程，因为它错误地认为 UI 线程已挂起。问题不在我的应用程序中。所以现在我的问题是：如何在调试时阻止 Android 杀死我的进程？
采纳答案by Aditya P
android intentionally kills the process because it thinks the UI thread is hung, so its a ANR right. for debugging purposes you can,
android 故意杀死进程，因为它认为 UI 线程已挂起，因此它是 ANR 权限。出于调试目的，您可以，
Go to Settings -> Developer options and check Show all ANRs.
转到设置 -> 开发人员选项并选中显示所有 ANR。
This will show an App Not Responding dialog for apps running in the background. You can click the Wait button in the dialog to prevent the system from killing your process until the debugger attaches. Note that the dialog is opened automatically for apps running in the foreground. For background apps, you have to enable this option
这将为在后台运行的应用程序显示一个应用程序无响应对话框。您可以单击对话框中的“等待”按钮以防止系统在调试器连接之前终止您的进程。请注意，对于在前台运行的应用程序，该对话框会自动打开。对于后台应用程序，您必须启用此选项
回答by sam
This started happening to me in android 7.1.1
这在 android 7.1.1 中开始发生在我身上
When attaching debugger my app always crashed, same when starting app in debug mode.
附加调试器时，我的应用程序总是崩溃，在调试模式下启动应用程序时也是如此。
What fixed it for me is simply:
为我解决的问题很简单：
- Run your app
- Click on "Mute Breakpoints" in Debug
- Attach the debugger
- Re-Click on "Mute Breakpoints" to unmute
- Done, debugging works again
- 运行你的应用
- 在调试中单击“静音断点”
- 连接调试器
- 重新单击“静音断点”以取消静音
- 完成，调试再次工作
回答by DustinB
I had similar issues, but what Sam suggested didn't help - I had to actually REMOVE the breakpoints and then it worked for me.
我有类似的问题，但 Sam 的建议没有帮助 - 我必须实际删除断点，然后它对我有用。
回答by Kingsley Mitchell
I had to reinstall android studio one time and the second time it happened it just went away by its self
我不得不重新安装 android studio 一次，第二次它发生时它自己消失了
