问题
I've got an android application using a shared object in the JNI (that I wrote myself) that is causing a segault. However, I'm having a rough time debugging it, because each time it crashes, my /dev/log/main is flooded with messages that look like this:
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
Is there a way to suppress the output of what appears to be every memory address on my phone so that I can find the relevant information in the stack trace?
(something more like this):
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!
I mostly use the DDMS perspective in eclipse, but have been having to use adb shell to catch direct dumps from the main log because the window in eclipse becomes overwhelmed quite quickly. This is an unacceptable workflow.
回答1:
Pipe logcat into a file on your development machine
adb logcat > logfile
Or if you have tee, do it this way so you also get to see it fly by
adb logcat | tee logfile
Then open the file in your favorite text editor and search for items of interest
You can also use various grep filters and pipe into a pager such as less or more, but storing to a file and examining in an editor where you can move around is better for problems which require serious study.
回答2:
Try to open console before the crash actually happens, and run
adb logcat -s DEBUG | grep -v ffffffff > debug.log
You can redirect logcat to a file on your host, and probably you will find a way to view this huge file after the crash.
来源：https://stackoverflow.com/questions/11088123/android-ndk-crash-log-too-big-to-find-error