Android NDK崩潰日誌太大，找不到錯誤

我有一個android應用程序使用JNI中的共享對象（我自己寫的），導致一個癱瘓。但是，我有一個粗略的時間調試，因爲每次它崩潰的時候，我的/ dev /日誌主要是與像這樣的消息充斥/：Android NDK崩潰日誌太大，找不到錯誤

06-18 12:50:31.069 2863 2863 I DEBUG :  453b7608 ffffffff 
06-18 12:50:31.069 2863 2863 I DEBUG :  453b760c ffffffff 
06-18 12:50:31.069 2863 2863 I DEBUG :  453b7610 ffffffff 
06-18 12:50:31.069 2863 2863 I DEBUG :  453b7614 ffffffff 
06-18 12:50:31.069 2863 2863 I DEBUG :  453b7618 ffffffff 
06-18 12:50:31.069 2863 2863 I DEBUG :  453b761c ffffffff 
06-18 12:50:31.069 2863 2863 I DEBUG :  453b7620 ffffffff 
06-18 12:50:31.069 2863 2863 I DEBUG :  453b7624 ffffffff 
06-18 12:50:31.069 2863 2863 I DEBUG :  453b7628 ffffffff

有沒有辦法來抑制輸出我手機上的每個內存地址似乎都是這樣，以便我可以在堆棧跟蹤中找到相關信息？

（更多的東西像這樣）：

06-18 13:07:35.857 11350 11350 I DEBUG : signal 11 (SIGSEGV), code 2 (SEGV_ACCERR), fault addr 452c7000 
06-18 13:07:35.857 11350 11350 I DEBUG : r0 00000021 r1 452c66a0 r2 00000033 r3 0000003c 
06-18 13:07:35.857 11350 11350 I DEBUG : r4 000000a1 r5 452c7000 r6 002cf880 r7 453c6b08 
06-18 13:07:35.857 11350 11350 I DEBUG : r8 4051e618 r9 00020000 10 51eb851f fp 81f03700 
06-18 13:07:35.857 11350 11350 I DEBUG : ip 00000064 sp 452c6af8 lr 81f00e35 pc 81f00df8 cpsr 00000030 
06-18 13:07:35.857 11350 11350 I DEBUG : d0 0000000000000000 d1 0000002f00000000 
06-18 13:07:35.857 11350 11350 I DEBUG : d2 4da4480e423d3abc d3 006f1fe04a5247c0 
06-18 13:07:35.857 11350 11350 I DEBUG : d4 00000000003491f0 d5 0000000000000000 
06-18 13:07:35.857 11350 11350 I DEBUG : d6 3f80000000000000 d7 43200000000000a0 
06-18 13:07:35.857 11350 11350 I DEBUG : d8 0000000000000000 d9 0000000000000000 
06-18 13:07:35.857 11350 11350 I DEBUG : d10 0000000000000000 d11 0000000000000000 
06-18 13:07:35.857 11350 11350 I DEBUG : d12 0000000000000000 d13 0000000000000000 
06-18 13:07:35.857 11350 11350 I DEBUG : d14 0000000000000000 d15 0000000000000000 
06-18 13:07:35.857 11350 11350 I DEBUG : scr 60000012 
06-18 13:07:35.857 11350 11350 I DEBUG : 
06-18 13:07:35.887 11350 11350 I DEBUG : tid 11348 not responding!

我大多使用Eclipse中的DDMS透視圖，但一直有使用adb shell從主日誌趕上直接堆放因爲Eclipse中的窗口變得相當不堪重負很快。這是一個不可接受的工作流程。

來源

2012-06-18 sleepynate

你用什麼命令「adb shell」？ – gfour

我跳進shell中，然後將輸出重定向到一個文件，例如'logcat> ohnoweareallgoingtodie.log'，然後將其複製到我的開發機器中，以便在文本編輯器中查看它。 – sleepynate

作爲解決方法，您可以運行'logcat |尾-200 |更少「來直接在終端中查看日誌的最後200行。或者，您可以執行'grep -n SIGSEGV ohnoweareallgoingtodie.log'來查找信息開始的行N，然後執行'tail --lines = + N ohnoweareallgoingtodie.log'。 – gfour

管的logcat到開發計算機上的文件

adb logcat > logfile

或者，如果你有三通，做這種方式，所以你也能看到它飛過

adb logcat | tee logfile

然後打開該文件在你最喜歡的文本編輯器中搜索感興趣的項目

你也可以使用各種grep過濾器和管道進入諸如少或更多的尋呼機，但存儲到一個文件並在編輯中檢查或者你可以走動的地方對需要認真研究的問題更好。

來源

2012-06-20 15:11:04

這已經是我正在做的一部分，但不方便。這個問題是關於如何使堆棧跟蹤更少噪聲，而不是「我如何捕獲堆棧跟蹤」 – sleepynate

@sleepynate - 您的選擇正在部署自定義的android構建，使用可用的過濾工具（如grep）或使用可用像尋呼機或體面編輯器中的搜索工具，或製作自定義信號處理程序。就我個人而言，我會在這種情況下進行基於編輯器的搜索，因爲一旦我找到了我要找的東西，我可能需要查看周圍的細節以瞭解問題 - 如果我過濾掉了，我會有重新運行實驗而不過濾它。在一個更簡單的情況下，我會考慮過濾。兩者都將大幅度超越定製android。 –

因此，當存在SIGSEGV時，轉儲數千行非全部有用的順序存儲器地址是標準做法嗎？ – sleepynate

嘗試打開控制檯崩潰實際發生之前，並運行

adb logcat -s DEBUG | grep -v ffffffff > debug.log

您可以重定向的logcat到主機上的文件，也可能你會找到一個方法來查看崩潰後這個龐大的文件。

來源

2012-06-20 15:06:47

Android NDK崩潰日誌太大，找不到錯誤

回答

相關問題