Как получить более длинный стек дамп (надгробная плита) с Android? - PullRequest
10 голосов
/ 24 февраля 2011

Как я заметил, logcat всегда возвращает 34 строки аварийного журнала, например:

4cf7c700  401c0000 
4cf7c704  48463ff0 
4cf7c708  44d11f7c  
4cf7c70c  afd0cd89 
4cf7c710  00000000  
4cf7c714  82ab29dc  libmyproject.so
4cf7c718  00000000  
4cf7c71c  4cf7c73c  
4cf7c720  836c44f0  libmyproject.so
4cf7c724  82f3a414  libmyproject.so
4cf7c728  4cf7c768  
4cf7c72c  0000008d  
4cf7c730  007ea0a8  [heap]
4cf7c734  00270100  [heap]
4cf7c738  e3a07077  
4cf7c73c  ef900077  
4cf7c740  00000000  
4cf7c744  4cf7c774  
4cf7c748  836c44f0  libmyproject.so
4cf7c74c  00000000  
4cf7c750  836c44f0  libmyproject.so
4cf7c754  82f63768  libmyproject.so
4cf7c758  00000000  
4cf7c75c  4cf7c7e4  
4cf7c760  00000000  
4cf7c764  00000001  
4cf7c768  00000000  
4cf7c76c  0badc0de  
4cf7c770  fffffff8  
4cf7c774  00000000  
4cf7c778  00000168  
4cf7c77c  00000009  
4cf7c780  00000200  
4cf7c784  00000000  

Однако я знаю, что стек также сохраняется в /date/tombstones/tombstone_0[0-9].Там я могу найти много других стеков (я не до конца понимаю, откуда они взялись), и некоторые из них в два раза длиннее, чем вышеупомянутый стек.

Ответы [ 2 ]

24 голосов
/ 08 декабря 2011

Программа обработки сбоев в Android, которая называется debuggerd, записывает только часть стека в журнал, но записывает полный стек в файл захоронения. Это жестко запрограммировано в system / core / debuggerd / debuggerd.c.

Посмотрите в подпрограмме debug_stack_and_code () вызовы _LOG (). Второй параметр _LOG контролирует, идет ли материал только к надгробной плите или к журналу и надгробной плите.

Где вы видите (sp_depth>2||only_in_tombstone), вы можете изменить 2 на что-то другое, чтобы получить более глубокие кадры стека, сообщаемые в журнале. Это предполагает, что вы можете перекомпилировать debuggerd и заменить его в своей системе. Если нет, то вы застряли в проверке самих файлов-захоронений для более длинных дампов стека.

Дампы создаются debuggerd при сбое программы под Linux. Когда это произойдет, ядро ​​отправит сигнал умирающей программе. Этот сигнал улавливается специальным обработчиком сигнала, установленным в каждом приложении Android. по бионической C-библиотеке. Обработчик сигнала связывается с debuggerd (через именованный канал), который затем подключается обратно к умирающей программе, используя ptrace для чтения регистров и памяти для создания надгробной плиты и записей журнала.

12 голосов
/ 16 сентября 2011

Я предлагаю отладку трассировки стека, найденной в файле tombstone, как в примере ниже.

Пример:

#00  pc 00010a20  /system/lib/libc.so
#01  pc 0000b332  /system/lib/libc.so
#02  pc 0000ca62  /system/lib/bluez-plugin/audio.so
#03  pc 0000d1ce  /system/lib/bluez-plugin/audio.so
#04  pc 0000e0ba  /system/lib/bluez-plugin/audio.so

Вы можете использовать команду ниже, чтобы узнать имя функции, имя файла и номер строки.

$(android-root)prebuilt/linux-x86/toolchain/arm-eabi-4.4.0/bin/addr2line -f -e /out/product/xxx/symbols/system/<SO filename> <PC address>

Пример:

$(android-root)prebuilt/linux-x86/toolchain/arm-eabi-4.4.0/bin/addr2line -f -e /out/product/xxx/symbols/system/libc.so 0x00010a20
...