Wie ich bemerkt habe, gibt logcat immer 34 Zeilen Crashlog zurück, wie folgt:
%Vor% Allerdings weiß ich, dass dieser Stapel auch in /date/tombstones/tombstone_0[0-9] gespeichert wird. Dort kann ich viele andere Stapel finden (ich verstehe nicht genau woher sie kommen) und einige von ihnen sind doppelt so lang wie oben erwähnt.
Wie bekomme ich einen so langen Stack-Dump vom Absturz meiner Anwendung?
Das Crash-Handling-Programm in Android, das debuggerd heißt, schreibt nur einen Teil des Stacks in das Log, schreibt aber den vollen Stack in die Tombstone-Datei. Dies ist in system / core / debuggerd / debuggerd.c fest programmiert.
Suchen Sie in der Routine debug_stack_and_code () nach den Aufrufen von _LOG (). Der zweite Parameter von _LOG steuert, ob das Material nur zum Tombstone oder zum Log und zum Tombstone geht.
Wo Sie (sp_depth>2||only_in_tombstone) sehen, können Sie die 2 in etwas anderes ändern, um tiefere Stack-Frames zu erhalten, die im Log gemeldet werden. Dies setzt voraus, dass Sie debuggerd erneut kompilieren und es auf Ihrem System ersetzen können. Wenn nicht, müssen Sie die Tombstone-Dateien selbst für die längeren Stack-Dumps untersuchen.
Die Dumps werden von debuggerd erstellt, wenn ein Programm unter Linux abstürzt. Wenn dies geschieht, sendet der Kernel ein Signal an das sterbende Programm. Dieses Signal wird von einem speziellen Signal-Handler erfasst, der in jeder nativen Android-App installiert ist. von der bionischen C-Bibliothek. Der Signal-Handler kontaktiert debuggerd (über eine Named Pipe), die dann mit ptrace zum Aussterben des Programms zurückkehrt, um Register und Speicher auszulesen, um die Tombstone- und Log-Einträge zu erzeugen.
Tags und Links android stack-trace logcat tombstoning