diff --git a/pdk/docs/guide/debugging_native.jd b/pdk/docs/guide/debugging_native.jd index 95ef6a7e0..435048bbc 100755 --- a/pdk/docs/guide/debugging_native.jd +++ b/pdk/docs/guide/debugging_native.jd @@ -14,7 +14,6 @@ pdk.version=1.0 -

Capturing logs

To capture log output:

@@ -34,10 +33,10 @@ pdk.version=1.0

Crash but no exit...stuck

-
->>> gtalk app crashed but did not actually exit or seems stuck
->>> let's check the debug logs and see if there's anything to see:
 
+
In this scenario, the GTalk app crashed but did not actually exit or seems stuck. Check the debug logs to see if there is anything unusual: 

+
+
 # logcat &
 
 ...
@@ -56,17 +55,23 @@ I/SurfaceFlinger.HW(  182): About to give-up screen
 I/SurfaceFlinger.HW(  182): screen given-up
 I/SurfaceFlinger.HW(  182): Screen about to return
 ...
+

 
->>> looks like the system launched a replacement gtalk process
->>> but it is stuck somehow
+

+The logs indicate that the system launched a replacement GTalk process but that it got stuck somehow:
+

 
+
 # ps
 PID   PPID  VSIZE RSS   WCHAN    PC         NAME
 257   181   45780 5292  ffffffff 53030cb4 S com.google.andr
+

 
->>> gtalk's PC is at 53030cb4
->>> look at the memory map to find out what lib is 0x53......
+

+GTalk's PC is at 53030cb4. Look at the memory map to find out what lib is 0x53......
+

 
+
 # cat /proc/257/maps
 ...
 51000000-5107c000 rwxp 00000000 1f:03 619        /android/lib/libutils.so
@@ -75,9 +80,13 @@ PID   PPID  VSIZE RSS   WCHAN    PC         NAME
 53039000-53042000 rw-p 53039000 00:00 0
 54000000-54002000 rwxp 00000000 1f:03 658        /android/lib/libstdc++.so
 ...
+

 
->>> let's disassemble libc and find out where we are?!
+

+Disassemble libc to figure out what is going on:
+

 
+
 % prebuilt/Linux/toolchain-eabi-4.2.1/bin/arm-elf-objdump -d out/target/product/sooner/symbols/android/lib/libc.so
 
 00030ca4 <__futex_wait>:
@@ -90,14 +99,20 @@ PID   PPID  VSIZE RSS   WCHAN    PC         NAME
 
 
Blocked in a syscall

 
+

+In this scenario, the system is blocked in a syscall. To debug using gdb, first tell adb to forward the gdb port:
+

+
 
->>> we're blocked in a syscall, let's see what gdb can show us
->>> (we could have done this first if we wanted to)
 
->>> tell adb to forward the GDB port
 % adb forward tcp:5039 tcp:5039
+

 
->>> start gdb server and attach to process 257 (from example above)
+

+Start the gdb server and attach to process 257 (as demonstrated in the previous example):
+

+
+
 # gdbserver :5039 --attach 257 &
 Attached; pid = 257
 Listening on port 5039
@@ -109,14 +124,23 @@ Listening on port 5039
 Remote debugging using :5039
 0x53030cb4 in ?? ()
 Current language:  auto; currently asm
+

 
->>> Don't let other threads get scheduled while we're debugging.
->>> You should "set scheduler-locking off" before issuing a "continue",
->>> or else your thread may get stuck on a futex or other
->>> spinlock because no other thread can release it.
+

+Don't let other threads get scheduled while we're debugging.
+You should "set scheduler-locking off" before issuing a "continue", or else your thread may get stuck on a futex or other
+spinlock because no other thread can release it.
+

+
+
 (gdb) set scheduler-locking on
+

 
->>> Ignore SIGUSR1 if you're using JamVM.  Shouldn't hurt if you're not.
+

+Ignore SIGUSR1 if you're using JamVM.  Shouldn't hurt if you're not.
+

+
+
 (gdb) handle SIGUSR1 noprint
 
 (gdb) where
@@ -282,5 +306,6 @@ pid: 373, tid: 401  >>> android.content.providers.pim <<<
 

 
 
Or you can run logcat without any parameters and it will read from stdin.  You can then paste output into the terminal or pipe it. Run logcat from the top of the tree in the environment in which you do builds so that the application can determine relative paths to the toolchain to use to decode the object files.
+