为什么android的logcat中不会显示运行时异常堆栈跟踪? [英] Why does android logcat not show the stack trace for a runtime exception?
问题描述
这是Android的应用程序,我目前正在开发中崩溃(固定的),原因是什么应该已经提出了一个IndexOutOfBoundsException异常。我在访问一个字符串在扩展AyncTask一类doInBackground方法,从可变参数的参数(如字符串...)。我却意外地访问一个元素变量参数字符串的索引1(而不是0)(轻度尴尬...)。当应用程序第一次坠毁我看了看我的logcat,(并重新多次,以确认我是不是疯了),而且对于被发现一个RuntimeException不具有堆栈跟踪。我崩溃我的手机经常和总有一款适合我看,并与修正一个不错的堆栈跟踪,但我很困惑这个。这里是我的logcat的相关部分(其中不包含堆栈跟踪一个RuntimeException),以下code,是造成飞机坠毁前行权的调试语句:
An android application that I am currently developing was crashing (fixed that), due to what should have raised an IndexOutOfBoundsException. I was accessing a string in the doInBackground method of a class that extends AyncTask, from the variable arguments parameter (ie String...). I was accidentally accessing index 1 (not 0) of a one element variable argument string (mildly embarrassing...). When the application first crashed I looked at my logcat, (and many times again to confirm that I wasn't insane) and there was no stack trace for a RuntimeException to be found. I crash my phone quite often and there is always a nice little stack trace for me to look at and fix with, but I was puzzled by this. Here is the pertinent section of my logcat (which contains no stack trace for a runtimeexception), following a debug statement right before the line of code that was causing the crash:
W/dalvikvm(25643): threadid=11: thread exiting with uncaught exception (group=0x40c281f8)
D/dalvikvm(25643): GC_CONCURRENT freed 1249K, 25% free 12433K/16455K, paused 2ms+6ms
W/dalvikvm(25643): threadid=15: thread exiting with uncaught exception (group=0x40c281f8)
I/Process (25643): Sending signal. PID: 25643 SIG: 9
I/ActivityManager( 5905): Process com.trade.nav.ges (pid 25643) has died.
W/ActivityManager( 5905): Force removing r: app died, no saved state
I/WindowManager( 5905): WIN DEATH: win
I/WindowManager( 5905): WIN DEATH: win
I/SurfaceFlinger( 1746): id=3848 Removed idx=2 Map Size=4
I/SurfaceFlinger( 1746): id=3848 Removed idx=-2 Map Size=4
I/WindowManager( 5905): WIN DEATH: win
I/power ( 5905): *** acquire_dvfs_lock : lockType : 1 freq : 1000000
D/PowerManagerService( 5905): acquireDVFSLockLocked : type : DVFS_MIN_LIMIT frequency : 1000000 uid : 1000 pid : 5905 tag : ActivityManager
W/ActivityManager( 5905): mDVFSLock.acquire()
在这之后,另一项活动启动。 作为参考,在这里是导致飞机坠毁的code:
And after that, another activity starts. For reference, here is the code that caused the crash:
private class LoadImage extends AsyncTask<String, Integer, Bitmap> {
String url = "";
//...
public LoadImage(ImageView iv, Context c) {
//...
}
protected Bitmap doInBackground(String... urls) {
// urls has one element
url = urls[1];
//...
}
//...
}
任何深入了解正在发生的事情会请我很大,因为我很好奇有没有见过这样的事情在互联网上。 谢谢你。
Any insight into what is happening would please me greatly, as I am curious about having never seen anything like this on the internet. Thanks.
编辑:我没有过滤器设置
I have no filter set
推荐答案
您线程都清楚地崩溃(注意螺纹未捕获异常
在两个不同的线程在同一退出处理)。这个过程本身后清理 - 发送信号
表示进程发出了一个致命的信号本身。所以,问题是,为什么你没有看到这两者之间的堆栈转储。
Your threads are clearly crashing (note the thread exiting with uncaught exception
on two different threads in the same process). The process is cleaning up after itself -- Sending signal
indicates the process is sending a fatal signal to itself. So the question is why you aren't seeing a stack dump between these two.
堆栈转储来自<一个href="https://android.googlesource.com/platform/frameworks/base/+/jb-mr1-release/core/java/com/android/internal/os/RuntimeInit.java">RuntimeInit$UncaughtHandler,这是该框架提供的全球未捕获的异常处理程序。这个过程自我毁灭发生在最后
块。这是很难看到的方式来摆脱这种无需登录致命异常,除非有在 Slog.e
失败并引发。
The stack dump comes from RuntimeInit$UncaughtHandler, which is the framework-provided global uncaught exception handler. The process self-annihilation happens in the finally
block. It's hard to see a way to get out of this without logging "FATAL EXCEPTION", unless something in Slog.e
fails and throws.
我猜想,无论是什么失败在 Slog.e
,或有人已经取代了框架的未捕获的异常处理程序。后者可能发生,如果您已经注册成立了一些外部的库到你的应用程序,如崩溃日志捕手或广告网络,以及新的处理程序没有记录异常,但并终止该进程。
I would guess that either something is failing in Slog.e
, or somebody has replaced the framework's uncaught exception handler. The latter could happen if you've incorporated some external library into your app, such as a crash log catcher or an ad network, and the new handler doesn't log the exception but does kill the process.
您可以通过将一个Java语言调试器(如Eclipse中)追查。默认情况下它会停在未捕获的异常。从那里,你可以围绕跟踪它,通过未捕获的异常处理程序设置断点和单步(如果你有充分的来源),等等。
You can track it down by attaching a Java-language debugger (e.g. Eclipse). By default it will stop on uncaught exceptions. From there you can trace it around, set breakpoints and single-step through the uncaught exception handler (if you have full sources), and so on.
这篇关于为什么android的logcat中不会显示运行时异常堆栈跟踪?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!