0

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.

sleepynate
  • 7,926
  • 3
  • 27
  • 38
  • What command do you use with "adb shell"? – gfour Jun 19 '12 at 15:56
  • I hop into the shell, then redirect the output into a file, such as `logcat > ohnoweareallgoingtodie.log`, then copy that off to my development machine to view it in a text editor. – sleepynate Jun 19 '12 at 17:26
  • As a workaround, you could run `logcat | tail -200 | less` to view the last 200 lines of the log directly in a terminal. Or you can do `grep -n SIGSEGV ohnoweareallgoingtodie.log` to find line N where the information starts and then do a `tail --lines=+N ohnoweareallgoingtodie.log`. – gfour Jun 19 '12 at 18:37
  • The problem is that there is so much output (thousands of lines) with these debug addresses that output just flies past. Thus, watching a tail of the log messages or getting the "most recent" messages doesn't help. grepping for the SIGSEGV will show that line, but I need to do a `logcat | grep SIGSEGV -A10 -B10` to get the full stack trace, and even then, it can disappear in the blink of an eye. – sleepynate Jun 19 '12 at 22:16
  • If disappearing in a blink of an eye is your remaining problem, pipe the grep into more. – Chris Stratton Jun 20 '12 at 16:09

2 Answers2

0

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.

Alex Cohn
  • 56,089
  • 9
  • 113
  • 307
0

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.

Chris Stratton
  • 39,853
  • 6
  • 84
  • 117
  • This already part of what I'm doing, but not convenient. The question is about how to make the stack trace less noisy as opposed to "how do i capture the stack trace" – sleepynate Jun 20 '12 at 15:25
  • 1
    @sleepynate - well, your options are deploying a custom android build, using available filtering tools like grep, or using the available search tools like those in a pager or decent editor, or making a custom signal handler. Personally, I would go for the editor-based search in this case, because once I've found what I'm looking for I might need to look at surrounding detail to understand the problem - if I filtered that out, I'd have to rerun the experiment without filtering it. In a simpler case, I'd consider filtering. Both are going to beat customizing android by a huge margin. – Chris Stratton Jun 20 '12 at 15:37
  • So it is standard practice to dump thousands of lines of not-at-all-helpful sequential memory addresses when there's a SIGSEGV? – sleepynate Jun 20 '12 at 16:00
  • @sleepynate - There are some architecture limits with recovering precise arm backtraces, usually you do not get this excess, but apparently the algorithm is erring on the side of excess in your case. I'd much rather have useless extra information than be missing necessary information. Being able to sort through information overload is just another application of thinking like a programmer – Chris Stratton Jun 20 '12 at 16:07