Почему андроидный logcat не показывает трассировку стека для исключения во время выполнения?

Приложение Android, которое я сейчас разрабатываю, сбой (исправлено), из-за того, что должно было вызвать исключение IndexOutOfBoundsException. Я обращался к строке в методе doInBackground класса, который расширяет AyncTask, из параметра переменных аргументов (например, String...). Я случайно обратился к индексу 1 (не 0) строки аргумента с одной переменной элемента (слегка смущающе...). Когда приложение сначала разбилось, я посмотрел на свой логарифм (и много раз снова, чтобы подтвердить, что я не был сумасшедшим), и не было трассировки стека для найденного RuntimeException. Я довольно часто разбиваю свой телефон, и для меня всегда есть приятная небольшая трассировка, чтобы посмотреть и исправить ситуацию, но я был озадачен этим. Ниже приведен соответствующий раздел моего логарифма (который не содержит трассировки стека для выполнения runtimeexception), следуя оператору отладки прямо перед строкой кода, которая вызывала сбой:

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()

И после этого начинается другое действие. Для справки, вот код, который вызвал сбой:

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];
        //...
    }
    //...
}

Любое понимание того, что происходит, очень понравилось бы мне, так как мне любопытно, что в интернете не было ничего подобного. Спасибо.

Изменить: у меня нет набора фильтров

Ответы

Ответ 1

Ваши потоки явно сбой (обратите внимание на thread exiting with uncaught exception на два разных потока в одном процессе). Процесс очищается после себя - Sending signal указывает, что процесс отправляет фатальный сигнал самому себе. Поэтому возникает вопрос, почему вы не видите дамп стека между этими двумя.

Дамп стека происходит от RuntimeInit $UncaughtHandler, который является глобальным обработчиком исключенных исключений, предоставляемым инфраструктурой. Самоаннигиляция процесса происходит в блоке finally. Трудно понять, как выйти из этого без регистрации "FATAL EXCEPTION", если только что-то в Slog.e не сработает и выбрасывает.

Я бы предположил, что либо что-то потерпит неудачу в Slog.e, либо кто-то заменил обработчик исключенного обработчика рамки. Последнее может произойти, если вы включили в свое приложение внешнюю библиотеку, такую ​​как ловушка аварийного лога или рекламная сеть, а новый обработчик не регистрирует исключение, а убивает процесс.

Вы можете отследить его, добавив отладчик на языке Java (например, Eclipse). По умолчанию он остановится на неперехваченных исключениях. Оттуда вы можете проследить его, установить точки останова и выполнить одно шаг через обработчик исключенных исключений (если у вас есть полные источники) и т.д.

Ответ 2

В соответствии с fadden подозревают, что внешняя библиотека может переопределить обработчик неперехваченных исключений, я начал исследовать любые возможные libs. Оказалось, что дроссели GoogleAnalytics выходят из строя и предотвращают отображение трассировки стека в logcat, если вы включите enableExceptionReporting. Я удаляю эту строку кода, а потом все возвращается! Это может быть первый раз, когда я был так счастлив увидеть аварии!