diff options
Diffstat (limited to 'en/devices/tech/debug')
| -rw-r--r-- | en/devices/tech/debug/asan.html | 34 | ||||
| -rw-r--r-- | en/devices/tech/debug/dumpsys.html | 12 | ||||
| -rw-r--r-- | en/devices/tech/debug/eval_perf.html | 6 | ||||
| -rw-r--r-- | en/devices/tech/debug/ftrace.html | 109 | ||||
| -rw-r--r-- | en/devices/tech/debug/gdb.html | 141 | ||||
| -rw-r--r-- | en/devices/tech/debug/index.html | 104 | ||||
| -rw-r--r-- | en/devices/tech/debug/native-crash.html | 55 | ||||
| -rw-r--r-- | en/devices/tech/debug/netstats.html | 18 | ||||
| -rw-r--r-- | en/devices/tech/debug/procstats.html | 6 | ||||
| -rw-r--r-- | en/devices/tech/debug/strace.html | 32 | ||||
| -rw-r--r-- | en/devices/tech/debug/systrace.html | 38 | ||||
| -rw-r--r-- | en/devices/tech/debug/valgrind.html | 26 |
12 files changed, 364 insertions, 217 deletions
diff --git a/en/devices/tech/debug/asan.html b/en/devices/tech/debug/asan.html index 0ab286dc..353aa4bd 100644 --- a/en/devices/tech/debug/asan.html +++ b/en/devices/tech/debug/asan.html @@ -62,7 +62,7 @@ to the build rules. Clang may find bugs in your code that GCC missed.</p> <p>Add <code>LOCAL_SANITIZE:=address</code> to the build rule of the executable.</p> -<pre> +<pre class="devsite-click-to-copy"> LOCAL_SANITIZE:=address </pre> @@ -83,7 +83,7 @@ which are built with ASan, you'll need two copies of the library. The recommended way to do this is to add the following to <code>Android.mk</code> for the module in question:</p> -<pre> +<pre class="devsite-click-to-copy"> LOCAL_SANITIZE:=address LOCAL_MODULE_RELATIVE_PATH := asan </pre> @@ -95,7 +95,7 @@ LOCAL_MODULE_RELATIVE_PATH := asan <p>For system daemons, add the following to the appropriate section of <code>/init.rc</code> or <code>/init.$device$.rc</code>.</p> -<pre> +<pre class="devsite-click-to-copy"> setenv LD_LIBRARY_PATH /system/lib/asan </pre> @@ -111,9 +111,9 @@ sync</code>.</p> when present by reading <code>/proc/$PID/maps</code>. If it's not, you may need to disable SELinux, like so:</p> -<pre> -$ adb root -$ adb shell setenforce 0 +<pre class="devsite-click-to-copy"> +<code class="devsite-terminal">adb root</code> +<code class="devsite-terminal">adb shell setenforce 0</code> # restart the process with adb shell kill $PID # if it is a system service, or may be adb shell stop; adb shell start. </pre> @@ -126,7 +126,7 @@ of Android is built without frame pointers. As a result, you will often get only one or two meaningful frames. To fix this, either rebuild the library with ASan (recommended!), or with:</p> -<pre> +<pre class="devsite-click-to-copy"> LOCAL_CFLAGS:=-fno-omit-frame-pointer LOCAL_ARM_MODE:=arm </pre> @@ -167,7 +167,7 @@ this). Edit the Zygote record in <code>system/core/rootdir/init.zygote(<em>32|64</em>).rc</code> to add the following lines:</p> -<pre> +<pre class="devsite-click-to-copy"> setenv LD_LIBRARY_PATH /system/lib/asan:/system/lib setenv ASAN_OPTIONS allow_user_segv_handler=true @@ -186,10 +186,10 @@ trading some memory overhead for slower application startup.</p> that’s used to run apps under Valgrind. The following example runs the Gmail app under ASan:</p> -<pre> -$ adb root -$ adb shell setenforce 0 # disable SELinux -$ adb shell setprop wrap.com.google.android.gm "asanwrapper" +<pre class="devsite-click-to-copy"> +<code class="devsite-terminal">adb root</code> +<code class="devsite-terminal">adb shell setenforce 0 # disable SELinux</code> +<code class="devsite-terminal">adb shell setprop wrap.com.google.android.gm "asanwrapper"</code> </pre> <p>In this context, asanwrapper rewrites <code>/system/bin/app_process</code> @@ -209,16 +209,16 @@ AddressSanitizer at once.</p> <p>Run the following commands in the same build tree.</p> -<pre> -$ make -j42 -$ SANITIZE_TARGET=address make -j42 +<pre class="devsite-click-to-copy"> +<code class="devsite-terminal">make -j42</code> +<code class="devsite-terminal">SANITIZE_TARGET=address make -j42</code> </pre> <p>In this mode, <code>userdata.img</code> contains extra libraries and must be flashed to the device as well. Use the following command line:</p> -<pre> -$ fastboot flash userdata && fastboot flashall +<pre class="devsite-terminal devsite-click-to-copy"> +fastboot flash userdata && fastboot flashall </pre> <p>At the moment of this writing, modern Nexus and Pixel devices boot to the UI in this mode.</p> diff --git a/en/devices/tech/debug/dumpsys.html b/en/devices/tech/debug/dumpsys.html index 80f93e54..e87722ba 100644 --- a/en/devices/tech/debug/dumpsys.html +++ b/en/devices/tech/debug/dumpsys.html @@ -34,8 +34,8 @@ output, specify the service you would like to examine. </p> <p>For example, the following command:</p> -<pre> -$ adb shell dumpsys input +<pre class="devsite-terminal devsite-click-to-copy"> +adb shell dumpsys input </pre> <p>provides system data for input components such as touchscreens or built-in @@ -47,8 +47,12 @@ keyboards.</p> <p>For a complete list of system services that you can use with dumpsys, try the following command:</p> -<pre class="no-pretty-print"> -$ adb shell dumpsys -l +<pre class="devsite-terminal devsite-click-to-copy"> +adb shell dumpsys -l +</pre> + +<p>Example output:</p> +<pre class="devsite-click-to-copy"> Currently running services: DockObserver SurfaceFlinger diff --git a/en/devices/tech/debug/eval_perf.html b/en/devices/tech/debug/eval_perf.html index 44173fe0..79c77de9 100644 --- a/en/devices/tech/debug/eval_perf.html +++ b/en/devices/tech/debug/eval_perf.html @@ -169,8 +169,10 @@ thread enters uninterruptible sleep. It is critical for performance analysis because uninterruptible sleep is a very common indicator of jitter.</li> <li>Ensure you have sufficient tracing for the GPU and display pipelines. On recent Qualcomm SOCs, tracepoints are enabled using:</li> -<pre>$ adb shell "echo 1 > /d/tracing/events/kgsl/enable" -$ adb shell "echo 1 > /d/tracing/events/mdss/enable"</pre> +<pre class="devsite-click-to-copy"> +<code class="devsite-terminal">adb shell "echo 1 > /d/tracing/events/kgsl/enable"</code> +<code class="devsite-terminal">adb shell "echo 1 > /d/tracing/events/mdss/enable"</code> +</pre> <p>These events remain enabled when you run systrace so you can see additional information in the trace about the display pipeline (MDSS) in the diff --git a/en/devices/tech/debug/ftrace.html b/en/devices/tech/debug/ftrace.html index e48362df..2fbaba4b 100644 --- a/en/devices/tech/debug/ftrace.html +++ b/en/devices/tech/debug/ftrace.html @@ -55,10 +55,14 @@ way to determine the correct values other than looking at the appropriate header divided into categories in <code>/d/tracing/events</code>. <p>To enable events on a per-category basis, use: -<pre>$ echo 1 > /d/tracing/events/irq/enable</pre> +<pre class="devsite-terminal devsite-click-to-copy"> +echo 1 > /d/tracing/events/irq/enable +</pre> <p>To enable events on per-event basis, use: -<pre>$ echo 1 > /d/tracing/events/sched/sched_wakeup/enable</pre> +<pre class="devsite-terminal devsite-click-to-copy"> +echo 1 > /d/tracing/events/sched/sched_wakeup/enable +</pre> <p>If extra events have been enabled by writing to sysfs nodes, they will <strong>not</strong> be reset by atrace. A common pattern @@ -66,9 +70,11 @@ for Qualcomm device bringup is to enable <code>kgsl</code> (GPU) and <code>mdss</code> (display pipeline) tracepoints and then use atrace or <a href="/devices/tech/debug/systrace.html">systrace</a>:</p> -<pre>$ adb shell "echo 1 > /d/tracing/events/mdss/enable" -$ adb shell "echo 1 > /d/tracing/events/kgsl/enable" -$ ./systrace.py sched freq idle am wm gfx view binder_driver irq workq ss sync -t 10 -b 96000 -o full_trace.html</pre> +<pre class="devsite-click-to-copy"> +<code class="devsite-terminal">adb shell "echo 1 > /d/tracing/events/mdss/enable"</code> +<code class="devsite-terminal">adb shell "echo 1 > /d/tracing/events/kgsl/enable"</code> +<code class="devsite-terminal">./systrace.py sched freq idle am wm gfx view binder_driver irq workq ss sync -t 10 -b 96000 -o full_trace.html</code> +</pre> <p>You can also use ftrace without atrace or systrace, which is useful when you want kernel-only traces (or if you've taken the time to write @@ -76,13 +82,25 @@ the user-mode tracing property by hand). To run just ftrace:</p> <ol> <li>Set the buffer size to a value large enough for your trace: -<pre>$ echo 96000 > /d/tracing/buffer_size_kb</pre></li> +<pre class="devsite-terminal devsite-click-to-copy"> +echo 96000 > /d/tracing/buffer_size_kb +</pre> +</li> <li>Enable tracing: -<pre>$ echo 1 > /d/tracing/tracing_on</pre></li> +<pre class="devsite-terminal devsite-click-to-copy"> +echo 1 > /d/tracing/tracing_on +</pre> +</li> <li>Run your test, then disable tracing: -<pre>$ echo 0 > /d/tracing/tracing_on</pre></li> +<pre class="devsite-terminal devsite-click-to-copy"> +echo 0 > /d/tracing/tracing_on +</pre> +</li> <li>Dump the trace: -<pre>$ cat /d/tracing/trace > /data/local/tmp/trace_output</pre> +<pre class="devsite-terminal devsite-click-to-copy"> +cat /d/tracing/trace > /data/local/tmp/trace_output +</pre> +</li> </ol> <p>The trace_output gives the trace in text form. To visualize it using @@ -90,7 +108,9 @@ Catapult, get the <a href="https://github.com/catapult-project/catapult/tree/master/">Catapult repository</a> from Github and run trace2html:</p> -<pre>$ catapult/tracing/bin/trace2html ~/path/to/trace_file</pre> +<pre class="devsite-terminal devsite-click-to-copy"> +catapult/tracing/bin/trace2html ~/path/to/trace_file +</pre> <p>By default, this writes <code>trace_file.html</code> in the same directory.</p> @@ -120,7 +140,9 @@ tree</a> (<code>tracing/bin/html2trace</code>) to uncompress the trace.</li> <li>Find a line at the beginning of the trace containing <code>tracing_mark_sync</code>. It should look something like this: -<pre><5134>-5134 (-----) [003] ...1 68.104349: tracing_mark_write: trace_event_clock_sync: parent_ts=68.104286</pre> +<pre class="devsite-click-to-copy"> +<5134>-5134 (-----) [003] ...1 68.104349: tracing_mark_write: trace_event_clock_sync: parent_ts=68.104286 +</pre> <br>If this line does not exist (or if you used ftrace without atrace), then timings will be relative from the first event in the ftrace log. @@ -154,11 +176,16 @@ CONFIG_IRQSOFF_TRACER=y, CONFIG_FUNCTION_PROFILER=y, and CONFIG_PREEMPT_TRACER=y </li> <li>Rebuild and boot the new kernel.</li> <li>Run the following to check for available tracers: -<pre>$ cat /d/tracing/available_tracers</pre></li> +<pre class="devsite-terminal devsite-click-to-copy"> +cat /d/tracing/available_tracers +</pre> +</li> <li>Confirm the command returns <code>function</code>, <code>irqsoff</code>, <code>preemptoff</code>, and <code>preemptirqsoff</code>.</li> <li>Run the following to ensure dynamic ftrace is working: -<pre>$ cat /d/tracing/available_filter_functions | grep <a function you care about></pre> +<pre class="devsite-terminal devsite-click-to-copy"> +cat /d/tracing/available_filter_functions | grep <a function you care about> +</pre> </li> </ol> @@ -195,22 +222,43 @@ so it's time to use the function profiler:</p> <ol> <li>As functions are sometimes renamed by the compiler, confirm <code>ion_client_destroy</code> is there by using: -<pre>$ cat /d/tracing/available_filter_functions | grep ion_client_destroy</pre> +<pre class="devsite-terminal devsite-click-to-copy"> +cat /d/tracing/available_filter_functions | grep ion_client_destroy +</pre> </li> <li>After confirming it is there, use it as the ftrace filter: -<pre>$ echo ion_client_destroy > /d/tracing/set_ftrace_filter</pre></li> +<pre class="devsite-terminal devsite-click-to-copy"> +echo ion_client_destroy > /d/tracing/set_ftrace_filter +</pre> +</li> <li>Turn on the function profiler: -<pre>$ echo function > /d/tracing/current_tracer</pre></li> +<pre class="devsite-terminal devsite-click-to-copy"> +echo function > /d/tracing/current_tracer +</pre> +</li> <li>Turn on stack traces whenever a filter function is called: -<pre>$ echo func_stack_trace > /d/tracing/trace_options</pre></li> +<pre class="devsite-terminal devsite-click-to-copy"> +echo func_stack_trace > /d/tracing/trace_options +</pre> +</li> <li>Increase the buffer size: -<pre>$ echo 64000 > /d/tracing/buffer_size_kb</pre></li> +<pre class="devsite-terminal devsite-click-to-copy"> +echo 64000 > /d/tracing/buffer_size_kb +</pre> +</li> <li>Turn on tracing: -<pre>$ echo 1 > /d/tracing/trace_on</pre></li> +<pre class="devsite-terminal devsite-click-to-copy"> +echo 1 > /d/tracing/trace_on +</pre> +</li> <li>Run the test and get the trace: -<pre>$ cat /d/tracing/trace > /data/local/tmp/trace</pre></li> +<pre class="devsite-terminal devsite-click-to-copy"> +cat /d/tracing/trace > /data/local/tmp/trace +</pre> +</li> <li>View the trace to see lots and lots of stack traces: -<pre> cameraserver-643 [003] ...1 94.192991: ion_client_destroy <-ion_release +<pre class="devsite-click-to-copy"> + cameraserver-643 [003] ...1 94.192991: ion_client_destroy <-ion_release cameraserver-643 [003] ...1 94.192997: <stack trace> => ftrace_ops_no_ops => ftrace_graph_call @@ -220,7 +268,9 @@ so it's time to use the function profiler:</p> => ____fput => task_work_run => do_notify_resume - => work_pending</pre></li> + => work_pending + </pre> +</li> </ol> <p>Based on inspection of the ion driver, we can see that @@ -286,12 +336,21 @@ the lock trace when ftrace was not running.</p> ftrace:</p> <ol> <li>Enable tracing: -<pre>$ echo 1 > /proc/sys/kernel/lock_stat</pre></li> +<pre class="devsite-terminal devsite-click-to-copy"> +echo 1 > /proc/sys/kernel/lock_stat +</pre> +</li> <li>Run your test.</li> <li>Disable tracing: -<pre>$ echo 0 > /proc/sys/kernel/lock_stat</pre></li> +<pre class="devsite-terminal devsite-click-to-copy"> +echo 0 > /proc/sys/kernel/lock_stat +</pre> +</li> <li>Dump your trace: -<pre>$ cat /proc/lock_stat > /data/local/tmp/lock_stat</pre></li> +<pre class="devsite-terminal devsite-click-to-copy"> +cat /proc/lock_stat > /data/local/tmp/lock_stat +</pre> +</li> </ol> <p>For help interpreting the resulting output, refer to lockstat documentation diff --git a/en/devices/tech/debug/gdb.html b/en/devices/tech/debug/gdb.html new file mode 100644 index 00000000..27c99328 --- /dev/null +++ b/en/devices/tech/debug/gdb.html @@ -0,0 +1,141 @@ +<html devsite> + <head> + <title>Using GDB</title> + <meta name="project_path" value="/_project.yaml" /> + <meta name="book_path" value="/_book.yaml" /> + </head> + <body> + <!-- + Copyright 2017 The Android Open Source Project + + Licensed under the Apache License, Version 2.0 (the "License"); + you may not use this file except in compliance with the License. + You may obtain a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 + + Unless required by applicable law or agreed to in writing, software + distributed under the License is distributed on an "AS IS" BASIS, + WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + See the License for the specific language governing permissions and + limitations under the License. + --> + + +<p>The GNU Project debugger (GDB) is a commonly used Unix debugger. This page +details using <code>gdb</code> to debug Android apps and processes.</p> + +<h2 id=running>Debugging running apps or processes</h2> + +<p>To connect to an already-running app or native daemon, use +<code>gdbclient</code> with a PID. For example, to debug the process with PID +1234, run:</p> + +<pre class="devsite-terminal devsite-click-to-copy"> +gdbclient 1234 +</pre> + +<p>The script sets up port forwarding, starts the appropriate +<code>gdbserver</code> on the device, starts the appropriate <code>gdb</code> on +the host, configures <code>gdb</code> to find symbols, and connects +<code>gdb</code> to the remote <code>gdbserver</code>.</p> + +<h2 id=starts>Debugging native process startup</h2> + +<p>To debug a process as it starts, use <code>gdbserver</code> or +<code>gdbserver64</code> (for 64-bit processes). For example:</p> + +<pre class="devsite-terminal devsite-click-to-copy"> +adb shell gdbserver :5039 /system/bin/<var>MY_TEST_APP</var> +</pre> + +<p>Example output:</p> +<pre class="devsite-click-to-copy"> +Process <var>MY_TEST_APP</var> created; pid = 3460 +Listening on port 5039 +</pre> + +<p>Next, identify the application PID from the <code>gdbserver</code> output and +use it in another terminal window:</p> + +<pre class="devsite-terminal devsite-click-to-copy"> +gdbclient <var>APP_PID</var> +</pre> + +<p>Finally, enter <strong>continue</strong> at the <code>gdb</code> prompt.</p> + +<p class="note"><strong>Note:</strong> If you specify the wrong +<code>gdbserver</code>, you'll get an unhelpful error message (such as +"<code>Reply contains invalid hex digit 59</code>").</p> + +<h2 id="app-startup">Debugging app startup</h2> + +<p>Sometimes you want to debug an app as it starts, such as when there's a crash +and you want to step through code to see what happens <em>before</em> the crash. +<a href="#running">Attaching</a> works in some cases, but in other cases is +impossible because the app crashes before you can attach. The +<code>logwrapper</code> approach (used for <code>strace</code> and +<code>valgrind</code>) does not always work because the app might not have +permissions to open a port, and <code>gdbserver</code> inherits that +restriction.</p> + +<p>To debug app startup, use the developer options in Settings to instruct +the app to wait for a Java debugger to attach:</p> + +<ol> +<li>Go to <em>Settings > Developer options > Select debug app</em> and choose +your app from the list, then press <strong>Wait for debugger</strong>.</li> + +<li>Start the app, either from the launcher or by using the command line to run: +<pre class="devsite-terminal devsite-click-to-copy"> +am start -a android.intent.action.MAIN -n <var>APP_NAME</var>/.<var>APP_ACTIVITY</var> +</pre></li> + +<li>Wait for the app to load and a dialog to appear telling you the app is +waiting for a debugger.</li> + +<li>Attach <code>gdbserver</code>/<code>gdbclient</code> normally, set +breakpoints, then continue the process.</li></ol> + +<p>To let the app actually run, attach a Java Debug Wire Protocol (JDWP) +debugger such as Java Debugger (jdb):</p> +<pre class="devsite-click-to-copy"> +<code class="devsite-terminal">adb forward tcp:12345 jdwp:<var>XXX</var> # (Where XXX is the pid of the debugged process.)</code> +<code class="devsite-terminal">jdb -attach localhost:12345</code> +</pre> + +<h2 id=crash>Debugging apps or processes that crash</h2> + +<p>If you want <code>debuggerd</code> to suspend crashed processes so you can +attach <code>gdb</code>, set the appropriate property:</p> + +<pre class="devsite-click-to-copy"> +# Android 7.0 Nougat and later. +<code class="devsite-terminal">adb shell setprop debug.debuggerd.wait_for_gdb true</code> +</pre> + +<pre class="devsite-click-to-copy"> +# Android 6.0 Marshmallow and earlier. +<code class="devsite-terminal">adb shell setprop debug.db.uid 999999</code> +</pre> + +<p>At the end of the usual crash output, <code>debuggerd</code> provides +instructions on how to connect <code>gdb</code> using the command: +<pre class="devsite-terminal devsite-click-to-copy"> +gdbclient <var>PID</var> +</pre> + + +<h2 id=symbols>Debugging without symbols</h2> + +<p>For 32-bit ARM, if you don’t have symbols, <code>gdb</code> can get confused +about the instruction set it is disassembling (ARM or Thumb). To specify the +instruction set chosen as the default when symbol information is missing, set +the following property:</p> + +<pre class="devsite-terminal devsite-click-to-copy"> +set arm fallback-mode arm # or thumb +</pre> + + </body> +</html> diff --git a/en/devices/tech/debug/index.html b/en/devices/tech/debug/index.html index b2f4c140..268f24ee 100644 --- a/en/devices/tech/debug/index.html +++ b/en/devices/tech/debug/index.html @@ -25,11 +25,11 @@ <p>This section summarizes useful tools and related commands for debugging, tracing, and profiling native Android platform code when developing -platform-level features. This page covers use of <code>debuggerd</code>, a -daemon process for collecting error information after applications crash, and -the GNU Project debugger (GDB).</p> +platform-level features.</p> -<p>Other pages in this section explore system services with +<p>This page covers use of <code>debuggerd</code>, a daemon process for +collecting error information after applications crash. Other pages in this +section explore system services with <a href="/devices/tech/debug/dumpsys.html">Dumpsys</a>, viewing <a href="/devices/tech/debug/native-memory.html">native memory</a>, <a href="/devices/tech/debug/netstats.html">network</a>, and @@ -37,8 +37,9 @@ the GNU Project debugger (GDB).</p> <a href="/devices/tech/debug/asan.html">AddressSanitizer</a> to detect memory bugs in native code, evaluating <a href="/devices/tech/debug/eval_perf.html"> performance issues</a> (includes -<a href="/devices/tech/debug/systrace">systrace</a>), and several other -debugging tools.</p> +<a href="/devices/tech/debug/systrace">systrace</a>), and using +<a href="/devices/tech/debug/gdb.html">GNU Project debugger (GDB)</a> and +other debugging tools.</p> <h2 id=debuggerd>Using debuggerd</h2> @@ -57,7 +58,7 @@ opt out of crash reporting.</p> <p>Example <code>debuggerd</code> output (with timestamps and extraneous information removed):</p> -<pre class="no-pretty-print"> +<pre class="devsite-click-to-copy"> *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** Build fingerprint: 'Android/aosp_angler/angler:7.1.1/NYC/enh12211018:eng/test-keys' Revision: '0' @@ -95,8 +96,12 @@ unwind with line number information by pasting the above example into <code>stack</code> will be on your $PATH already so you don't need to give the full path.</p> -<pre> -$ development/tools/stack +<pre class="devsite-terminal devsite-click-to-copy"> +development/tools/stack +</pre> + +<p>Example output:</p> +<pre class="devsite-click-to-copy"> Reading native crash info from stdin 03-02 23:53:49.477 17951 17951 F DEBUG : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** 03-02 23:53:49.477 17951 17951 F DEBUG : Build fingerprint: 'Android/aosp_angler/angler:7.1.1/NYC/enh12211018:eng/test-keys' @@ -146,93 +151,20 @@ directly from <code>debuggerd</code> without taking up anywhere near as much space as an unstripped version.</p> <p>You can also <code>stack</code> an entire tombstone. Example:</p> -<pre> -$ stack < FS/data/tombstones/tombstone_05 +<pre class="devsite-terminal devsite-click-to-copy"> +stack < FS/data/tombstones/tombstone_05</code> </pre> <p>This is useful if you've just unzipped a bugreport in the current directory. For more information about diagnosing native crashes and tombstones, see <a href="/devices/tech/debug/native-crash.html">Diagnosing Native Crashes</a>. </p> -<h3>Getting a stack trace/tombstone from a running process</h3> +<h2 id="tombstone">Getting a stack trace/tombstone from a running process</h2> <p>You can also use <code>debuggerd</code> on a running process. From the command line, invoke <code>debuggerd</code> using a process ID (PID) to dump the full tombstone to <code>stdout</code>. To get just the stack for every thread in -the process, include the <code>-b</code> or <code>--backtrace</code> flag. - -<h2 id=native>Using GDB</h2> - -<p>The GNU Project debugger (GDB) is a commonly used Unix debugger.</p> - -<h3 id=running>Debugging a running app</h3> - -<p>To connect to an already-running app or native daemon, use -<code>gdbclient</code> with a PID. For example, to debug the process with PID -1234, run:</p> - -<pre class="no-pretty-print"> -$ gdbclient 1234 -</pre> - -<p>The script sets up port forwarding, starts the appropriate -<code>gdbserver</code> on the device, starts the appropriate <code>gdb</code> on -the host, configures <code>gdb</code> to find symbols, and connects -<code>gdb</code> to the remote <code>gdbserver</code>.</p> - -<h3 id=starts>Debugging a native process as it starts</h3> - -<p>To debug a process as it starts, use <code>gdbserver</code> or -<code>gdbserver64</code> (for 64-bit processes). For example:</p> - -<pre class="no-pretty-print"> -$ adb shell gdbserver :5039 /system/bin/<em>my_test_app</em> -Process my_test_app created; pid = 3460 -Listening on port 5039 -</pre> - -<p>Next, identify the application PID from the <code>gdbserver</code> output and -use it in another terminal window:</p> - -<pre class="no-pretty-print"> -$ gdbclient <em><app pid></em> -</pre> - -<p>Finally, enter <strong>continue</strong> at the <code>gdb</code> prompt.</p> - -<p class="note"><strong>Note:</strong> If you use the wrong -<code>gdbserver</code>, you'll get an unhelpful error message (such as -"<code>Reply contains invalid hex digit 59</code>").</p> - -<h3 id=crash>Debugging processes that crash</h3> - -<p>If you want <code>debuggerd</code> to suspend crashed processes so you can -attach <code>gdb</code>, set the appropriate property:</p> - -<pre class="no-pretty-print"> -# Android 7.0 Nougat and later. -$ adb shell setprop debug.debuggerd.wait_for_gdb true - -# Android 6.0 Marshmallow and earlier. -$ adb shell setprop debug.db.uid 999999 -</pre> - -<p>At the end of the usual crash output, <code>debuggerd</code> provides -instructions on how to connect <code>gdb</code> using the command: -<pre class="no-pretty-print"> -$ gdbclient <pid> -</pre> - -<h3 id=symbols>Debugging without symbols</h3> - -<p>For 32-bit ARM, if you don’t have symbols, <code>gdb</code> can get confused -about the instruction set it is disassembling (ARM or Thumb). To specify the -instruction set chosen as the default when symbol information is missing, set -the following property:</p> - -<pre class="no-pretty-print"> -$ set arm fallback-mode arm # or thumb -</pre> +the process, include the <code>-b</code> or <code>--backtrace</code> flag.</p> </body> </html> diff --git a/en/devices/tech/debug/native-crash.html b/en/devices/tech/debug/native-crash.html index fec60690..c1658cc5 100644 --- a/en/devices/tech/debug/native-crash.html +++ b/en/devices/tech/debug/native-crash.html @@ -59,7 +59,7 @@ Older versions of Android (especially on 32-bit ARM) followed a convoluted path between the original abort call (frame 4 here) and the actual sending of the signal (frame 0 here): </p> -<pre class="no-pretty-print"> +<pre class="devsite-click-to-copy"> pid: 1656, tid: 1656, name: crasher >>> crasher <<< signal 6 (<i style="color:Orange">SIGABRT</i>), code -6 (SI_TKILL), fault addr -------- <i style="color:Orange">Abort message</i>: 'some_file.c:123: some_function: assertion "false" failed' @@ -85,7 +85,8 @@ href="http://man7.org/linux/man-pages/man2/tgkill.2.html">tgkill(2)</a></code> directly from <code>abort</code>, so there are fewer stack frames for you to skip over before you get to the interesting frames: -<pre class="no-pretty-print">pid: 25301, tid: 25301, name: crasher >>> crasher <<< +<pre class="devsite-click-to-copy"> +pid: 25301, tid: 25301, name: crasher >>> crasher <<< signal 6 (SIGABRT), code -6 (SI_TKILL), fault addr -------- r0 00000000 r1 000062d5 r2 00000006 r3 00000008 r4 ffa09dd8 r5 000062d5 r6 000062d5 r7 0000010c @@ -119,7 +120,8 @@ was called with a null pointer; and this crash should go straight to the author of the calling code. In this case, frame #01 is the bad caller. </p> -<pre class="no-pretty-print">pid: 25326, tid: 25326, name: crasher >>> crasher <<< +<pre class="devsite-click-to-copy"> +pid: 25326, tid: 25326, name: crasher >>> crasher <<< signal 11 (<i style="color:Orange">SIGSEGV</i>), code 1 (SEGV_MAPERR), <i style="color:Orange">fault addr 0x0</i> r0 00000000 r1 00000000 r2 00004c00 r3 00000000 r4 ab088071 r5 fff92b34 r6 00000002 r7 fff92b40 @@ -157,7 +159,9 @@ call actually succeeded first. <p> Here's an example of <code>readdir</code>: </p> -<pre class="no-pretty-print">pid: 25405, tid: 25405, name: crasher >>> crasher <<< + +<pre class="devsite-click-to-copy"> +pid: 25405, tid: 25405, name: crasher >>> crasher <<< signal 11 (<i style="color:Orange">SIGSEGV</i>), code 1 (SEGV_MAPERR), <i style="color:Orange">fault addr 0xc</i> r0 0000000c r1 00000000 r2 00000000 r3 3d5f0000 r4 00000000 r5 0000000c r6 00000002 r7 ff8618f0 @@ -190,7 +194,7 @@ you found the bug: <code>readdir</code> was passed a null pointer by the caller. At this point you can paste the stack into the stack tool to find out <em>where</em> in logcat this happened. -<pre class="no-pretty-print"> +<pre class="prettyprint"> struct DIR { int fd_; size_t available_bytes_; @@ -220,7 +224,8 @@ to perform actually fits. Here's an example where the code tries to <code>read(fd, buf, 32)</code> into a buffer that's actually only 10 bytes long... </p> -<pre class="no-pretty-print">pid: 25579, tid: 25579, name: crasher >>> crasher <<< +<pre class="devsite-click-to-copy"> +pid: 25579, tid: 25579, name: crasher >>> crasher <<< signal 6 (SIGABRT), code -6 (SI_TKILL), fault addr -------- Abort message: '<i style="color:Orange">FORTIFY: read: prevented 32-byte write into 10-byte buffer'</i> r0 00000000 r1 000063eb r2 00000006 r3 00000008 @@ -254,7 +259,8 @@ epilogue to read it back and check that it's not changed. If that value changed, it was overwritten by a buffer overrun, so the epilogue calls <code>__stack_chk_fail</code> to log a message and abort. </p> -<pre class="no-pretty-print">pid: 26717, tid: 26717, name: crasher >>> crasher <<< +<pre class="devsite-click-to-copy"> +pid: 26717, tid: 26717, name: crasher >>> crasher <<< signal 6 (SIGABRT), code -6 (SI_TKILL), fault addr -------- <i style="color:Orange">Abort message: 'stack corruption detected'</i> r0 00000000 r1 0000685d r2 00000006 r3 00000008 @@ -294,7 +300,7 @@ to see the currently supported selection.</p> <p>To introduce the different pieces in a crash dump, let's work through this example crash dump:</p> -<pre class="no-pretty-print"> +<pre class="devsite-click-to-copy"> *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** Build fingerprint: 'Android/aosp_flounder/flounder:5.1.51/AOSP/enh08201009:eng/test-keys' Revision: '0' @@ -318,15 +324,14 @@ backtrace: #08 pc 00016795 /system/lib/libc.so (__libc_init+44) #09 pc 00000abc /system/xbin/crasher Tombstone written to: /data/tombstones/tombstone_06 +*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** </pre> -<pre class="no-pretty-print">*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***</pre> - <p>The line of asterisks with spaces is helpful if you're searching a log for native crashes. The string "*** ***" rarely shows up in logs other than at the beginning of a native crash.</p> -<pre class="no-pretty-print"> +<pre class="devsite-click-to-copy"> Build fingerprint: 'Android/aosp_flounder/flounder:5.1.51/AOSP/enh08201009:eng/test-keys' </pre> @@ -334,7 +339,7 @@ Build fingerprint: <p>The fingerprint lets you identify exactly which build the crash occurred on. This is exactly the same as the <code>ro.build.fingerprint</code> system property.</p> -<pre class="no-pretty-print"> +<pre class="devsite-click-to-copy"> Revision: '0' </pre> @@ -343,7 +348,7 @@ usually unused but can be useful to help you automatically ignore bugs known to be caused by bad hardware. This is exactly the same as the <code>ro.revision</code> system property.</p> -<pre class="no-pretty-print"> +<pre class="devsite-click-to-copy"> ABI: 'arm' </pre> @@ -351,7 +356,7 @@ ABI: 'arm' mostly useful for the <code>stack</code> script mentioned above, so that it knows what toolchain to use.</p> -<pre class="no-pretty-print"> +<pre class="devsite-click-to-copy"> pid: 1656, tid: 1656, name: crasher >>> crasher <<< </pre> @@ -364,7 +369,7 @@ which is useful when filing bugs or trying to find the app in Google Play. The pid and tid can also be useful in finding the relevant log lines preceding the crash.</p> -<pre class="no-pretty-print"> +<pre class="devsite-click-to-copy"> signal 6 (SIGABRT), code -6 (SI_TKILL), fault addr -------- </pre> @@ -373,7 +378,7 @@ how it was received (SI_TKILL). The signals reported by <code>debuggerd</code> a SIGBUS, SIGFPE, SIGILL, SIGSEGV, and SIGTRAP. The signal-specific codes vary based on the specific signal.</p> -<pre class="no-pretty-print"> +<pre class="devsite-click-to-copy"> Abort message: 'some_file.c:123: some_function: assertion "false" failed' </pre> @@ -382,7 +387,7 @@ is automatically gathered from the last line of fatal logcat output for this pid/tid, and in the case of a deliberate abort is likely to give an explanation of why the program killed itself.</p> -<pre class="no-pretty-print"> +<pre class="devsite-click-to-copy"> r0 00000000 r1 00000678 r2 00000006 r3 f70b6dc8 r4 f70b6dd0 r5 f70b6d80 r6 00000002 r7 0000010c r8 ffffffed r9 00000000 sl 00000000 fp ff96ae1c @@ -393,7 +398,7 @@ ip 00000006 sp ff96ad18 lr f700ced5 pc f700dc98 cpsr 400b0010 signal was received. (This section varies wildly between ABIs.) How useful these are will depend on the exact crash.<p> -<pre class="no-pretty-print"> +<pre class="devsite-click-to-copy"> backtrace: #00 pc 00042c98 /system/lib/libc.so (tgkill+12) #01 pc 00041ed1 /system/lib/libc.so (pthread_kill+32) @@ -419,7 +424,7 @@ to find the corresponding assembler instruction.</p> <h2 id=tombstones>Tombstones</h2> -<pre class="no-pretty-print"> +<pre class="devsite-click-to-copy"> Tombstone written to: /data/tombstones/tombstone_06 </pre> @@ -434,7 +439,7 @@ and memory dumps around the addresses in registers. Most usefully it also includes a full memory map (similar to <code>/proc/<i>pid</i>/maps</code>). Here's an annotated example from a 32-bit ARM process crash:</p> -<pre class="no-pretty-print"> +<pre class="devsite-click-to-copy"> memory map: (fault address prefixed with --->) --->ab15f000-ab162fff r-x 0 4000 /system/xbin/crasher (BuildId: b9527db01b5cf8f5402f899f64b9b121) @@ -461,7 +466,7 @@ exactly which version of your code crashed. (Platform binaries include a BuildId by default since Android M. NDK r12 and later automatically pass <code>-Wl,--build-id</code> to the linker too.)<p> -<pre class="no-pretty-print"> +<pre class="devsite-click-to-copy"> ab163000-ab163fff r-- 3000 1000 /system/xbin/crasher ab164000-ab164fff rw- 0 1000 f6c80000-f6d7ffff rw- 0 100000 [anon:libc_malloc] @@ -470,7 +475,7 @@ f6c80000-f6d7ffff rw- 0 100000 [anon:libc_malloc] <p>On Android the heap isn't necessarily a single region. Heap regions will be labeled <code>[anon:libc_malloc]</code>.</p> -<pre class="no-pretty-print"> +<pre class="devsite-click-to-copy"> f6d82000-f6da1fff r-- 0 20000 /dev/__properties__/u:object_r:logd_prop:s0 f6da2000-f6dc1fff r-- 0 20000 /dev/__properties__/u:object_r:default_prop:s0 f6dc2000-f6de1fff r-- 0 20000 /dev/__properties__/u:object_r:logd_prop:s0 @@ -504,7 +509,7 @@ shows the address ranges for the mapping, the second column the permissions (in hex), the fourth column the size of the region (in hex), and the fifth column the file (or other region name).</p> -<pre class="no-pretty-print"> +<pre class="devsite-click-to-copy"> f6f34000-f6f53fff r-x 0 20000 /system/lib/libm.so (BuildId: 76ba45dcd9247e60227200976a02c69b) f6f54000-f6f54fff --- 0 1000 f6f55000-f6f55fff r-- 20000 1000 /system/lib/libm.so @@ -537,7 +542,7 @@ Note that since Android 5.0 (Lollipop), the C library names most of its anonymou regions so there are fewer mystery regions. </p> -<pre class="no-pretty-print"> +<pre class="devsite-click-to-copy"> f6fcb000-f6fccfff rw- 0 2000 [stack:5081] </pre> @@ -545,7 +550,7 @@ f6fcb000-f6fccfff rw- 0 2000 [stack:5081] Regions named <code>[stack:<i>tid</i>]</code> are the stacks for the given threads. </p> -<pre class="no-pretty-print"> +<pre class="devsite-click-to-copy"> f6fcd000-f702afff r-x 0 5e000 /system/bin/linker (BuildId: 84f1316198deee0591c8ac7f158f28b7) f702b000-f702cfff r-- 5d000 2000 /system/bin/linker f702d000-f702dfff rw- 5f000 1000 /system/bin/linker diff --git a/en/devices/tech/debug/netstats.html b/en/devices/tech/debug/netstats.html index a396700d..78ddef02 100644 --- a/en/devices/tech/debug/netstats.html +++ b/en/devices/tech/debug/netstats.html @@ -31,8 +31,8 @@ network usage statistics collected since the device booted up.</p> <p>To view network usage statistics, run the following command:</p> -<pre class=prettyprint> -$ adb shell dumpsys netstats detail +<pre class="devsite-terminal devsite-click-to-copy"> +adb shell dumpsys netstats detail </pre> @@ -56,7 +56,7 @@ consists of several sections: </p> <p>Here is sample output for the active interfaces and active UID interfaces sections:</p> -<pre> +<pre class="devsite-click-to-copy"> Active interfaces: iface=wlan0 ident=[{type=WIFI, subType=COMBINED, networkId="GoogleGuest"}] Active UID interfaces: @@ -72,7 +72,7 @@ information in these two section is the same.</p> <p>Here is sample output for the Dev statistics section:</p> -<pre> +<pre class="devsite-click-to-copy"> Dev stats: Pending bytes: 170775 Complete history: @@ -94,7 +94,7 @@ Dev stats: <h3 id=uid_stats>UID stats</h3> -<pre> +<pre class="devsite-click-to-copy"> UID stats: Pending bytes: 744 Complete history: @@ -120,9 +120,11 @@ Then look for the line labeled <code>userId</code>.</p> <p>In our example, suppose we are trying to find network usage for our app “com.example.myapp”. We would run the following command:</p> -<pre> -$ adb shell dumpsys package com.example.myapp | grep userId - +<pre class="devsite-terminal devsite-click-to-copy"> +adb shell dumpsys package com.example.myapp | grep userId +</pre> +<p>This returns the following output:</p> +<pre class="devsite-click-to-copy"> userId=10007 gids=[3003, 1028, 1015] </pre> diff --git a/en/devices/tech/debug/procstats.html b/en/devices/tech/debug/procstats.html index 07250168..285ea7e0 100644 --- a/en/devices/tech/debug/procstats.html +++ b/en/devices/tech/debug/procstats.html @@ -33,8 +33,8 @@ proportional set size (PSS) and unique set size (USS).</p> <p>To get application memory usage stats for the last three hours, in human-readable form, run the following command:</p> -<pre class=prettyprint> -$ adb shell dumpsys procstats --hours 3 +<pre class="devsite-terminal devsite-click-to-copy"> +adb shell dumpsys procstats --hours 3 </pre> @@ -46,7 +46,7 @@ $ adb shell dumpsys procstats --hours 3 time the application was running, while the numbers following show PSS and USS as minPSS-avgPSS-maxPSS/minUSS-avgUSS-maxUSS over samples.</p> -<pre class="no-pretty-print"> +<pre class="devsite-click-to-copy"> AGGREGATED OVER LAST 3 HOURS: * com.android.systemui / u0a20 / v22: TOTAL: 100% (109MB-126MB-159MB/108MB-125MB-157MB over 18) diff --git a/en/devices/tech/debug/strace.html b/en/devices/tech/debug/strace.html index a69a64b4..5f2affb2 100644 --- a/en/devices/tech/debug/strace.html +++ b/en/devices/tech/debug/strace.html @@ -30,16 +30,16 @@ to learn how to collect only data you're actually interested in.</p> <h2 id=build-strace>Building strace</h2> <p>To build strace, run the following: -<pre> -$ mmma -j6 external/strace +<pre class="devsite-terminal devsite-click-to-copy"> +mmma -j6 external/strace </pre> <h2 id=attach-strace>Attaching to a running process</h2> <p>The simplest and most common use case for strace is to attach it to a running process, which you can do with:</p> -<pre> -$ adb shell strace -f -p PID +<pre class="devsite-terminal devsite-click-to-copy"> +adb shell strace -f -p PID </pre> <p>The <code>-f</code> flag tells strace to attach to all the threads in the process, plus any new threads spawned later.</p> @@ -49,16 +49,16 @@ process, plus any new threads spawned later.</p> <ol> <li>Set up a directory for strace logs: -<pre> -$ adb shell setenforce 0 -$ adb shell mkdir /data/local/tmp/strace -$ adb shell chmod 777 /data/local/tmp/strace +<pre class="devsite-click-to-copy"> +<code class="devsite-terminal">adb shell setenforce 0</code> +<code class="devsite-terminal">adb shell mkdir /data/local/tmp/strace</code> +<code class="devsite-terminal">adb shell chmod 777 /data/local/tmp/strace</code> </pre> </li> <li>Choose the process to trace before launching it: -<pre> -$ adb shell setprop wrap.com.google.android.browser "logwrapper strace -f -o /data/local/tmp/strace/strace.com.google.android.browser.txt" +<pre class="devsite-terminal devsite-click-to-copy"> +adb shell setprop wrap.com.google.android.browser "logwrapper strace -f -o /data/local/tmp/strace/strace.com.google.android.browser.txt" </pre> </li> <li>Launch the process normally.</li> @@ -69,9 +69,9 @@ $ adb shell setprop wrap.com.google.android.browser "logwrapper strace -f -o /da line (requires <code>adb shell setenforce 0</code>): </p> -<pre> -$ cd system/core/ -$ patch -p1 <<EOF +<pre class="devsite-click-to-copy"> +<code class="devsite-terminal">cd system/core/</code> +<code class="devsite-terminal">patch -p1 <<EOF --- a/rootdir/init.zygote32.rc +++ b/rootdir/init.zygote32.rc @@ -1,4 +1,4 @@ @@ -80,7 +80,7 @@ $ patch -p1 <<EOF class main socket zygote stream 660 root system onrestart write /sys/android_power/request_state wake -EOF +EOF</code> </pre> <h2 id=get-logs-boot>Getting strace logs during Android boot</h2> @@ -93,7 +93,7 @@ EOF SELinux <code>file_context</code> for <code>strace</code>. The solution is to add a new line for strace in <code>system/sepolicy/private/file_contexts</code> and copy the original file context over. Example: -<pre> +<pre class="devsite-click-to-copy"> /dev/socket/zygote u:object_r:zygote_socket:s0 + /system/xbin/strace u:object_r:zygote_socket:s0 </pre> @@ -108,7 +108,7 @@ do this by adding <code>androidboot.selinux=permissive</code>to <br> <br>Example for the Pixel (sailfish) device in <code>/device/google/marlin/sailfish/BoardConfig.mk</code>: -<pre> +<pre class="devsite-click-to-copy"> - BOARD_KERNEL_CMDLINE := .... androidboot.hardware=sailfish ... +BOARD_KERNEL_CMDLINE := .... androidboot.hardware=sailfish ... androidboot.selinux=permissive </pre> diff --git a/en/devices/tech/debug/systrace.html b/en/devices/tech/debug/systrace.html index 4334f9d9..036bd6da 100644 --- a/en/devices/tech/debug/systrace.html +++ b/en/devices/tech/debug/systrace.html @@ -49,7 +49,9 @@ problems. (These features require root access and often a new kernel.)</p> <p>When debugging jitter on Pixel/Pixel XL, start with the following command:</p> -<pre>$ ./systrace.py sched freq idle am wm gfx view sync binder_driver irq workq input -b 96000</pre> +<pre class="devsite-terminal devsite-click-to-copy"> +./systrace.py sched freq idle am wm gfx view sync binder_driver irq workq input -b 96000 +</pre> <p>When combined with the additional tracepoints required for GPU and display pipeline activity, this gives you the ability to trace from user input to frame @@ -106,7 +108,7 @@ back to sleep, waiting for EventThread wakeup.</li> <p>Let's walk through the frame beginning at 15409ms:</p> -<p><img src="images/perf_trace_normal_pipeline.png"></p> +<p><img src="/devices/tech/debug/images/perf_trace_normal_pipeline.png"></p> <p class="img-caption"><strong>Figure 1.</strong> Normal UI pipeline, EventThread running.</p> @@ -139,14 +141,14 @@ sleep slice.</p> <p>While EventThread is running, the UI thread for TouchLatency becomes runnable. To see what woke it, click the blue section:</p> -<p><img src="images/perf_trace_tl.png"></p> +<p><img src="/devices/tech/debug/images/perf_trace_tl.png"></p> <p class="img-caption"><strong>Figure 2.</strong> UI thread for TouchLatency.</p> <p>Figure 2 shows the TouchLatency UI thread was woken by tid 6843, which corresponds to EventThread. The UI thread wakes:</p> -<p><img src="images/perf_trace_wake_render_enqueue.png"></p> +<p><img src="/devices/tech/debug/images/perf_trace_wake_render_enqueue.png"></p> <p class="img-caption"><strong>Figure 3.</strong> UI thread wakes, renders a frame, and enqueues it for SurfaceFlinger to consume.</p> @@ -154,7 +156,7 @@ frame, and enqueues it for SurfaceFlinger to consume.</p> binder transaction to view information on all of the processes involved in that transaction:</p> -<p><img src="images/perf_trace_binder_trans.png"></p> +<p><img src="/devices/tech/debug/images/perf_trace_binder_trans.png"></p> <p class="img-caption"><strong>Figure 4.</strong> Binder transaction.</p> <p>Figure 4 shows that, at 15,423.65ms, Binder:6832_1 in SurfaceFlinger becomes @@ -164,7 +166,7 @@ see queueBuffer on both sides of the binder transaction.</p> <p>During the queueBuffer on the SurfaceFlinger side, the number of pending frames from TouchLatency goes from 1 to 2:</p> -<p><img src="images/perf_trace_pending_frames.png"></p> +<p><img src="/devices/tech/debug/images/perf_trace_pending_frames.png"></p> <p class="img-caption"><strong>Figure 5.</strong> Pending frames goes from 1 to 2.</p> @@ -176,14 +178,14 @@ further dropped frames.</p> <p>Soon after, SurfaceFlinger's main thread is woken by a second EventThread so it can output the older pending frame to the display:</p> -<p><img src="images/perf_trace_sf_woken_et.png"></p> +<p><img src="/devices/tech/debug/images/perf_trace_sf_woken_et.png"></p> <p class="img-caption"><strong>Figure 6.</strong> SurfaceFlinger's main thread is woken by a second EventThread.</p> <p>SurfaceFlinger first latches the older pending buffer, which causes the pending buffer count to decrease from 2 to 1:</p> -<p><img src="images/perf_trace_sf_latches_pend.png"></p> +<p><img src="/devices/tech/debug/images/perf_trace_sf_latches_pend.png"></p> <p class="img-caption"><strong>Figure 7.</strong> SurfaceFlinger first latches the older pending buffer.</p> @@ -191,7 +193,7 @@ the older pending buffer.</p> final frame to the display. (Some of these sections are enabled as part of the <code>mdss</code> tracepoint, so they may not be there on your SOC.)</p> -<p><img src="images/perf_trace_sf_comp_submit.png"></p> +<p><img src="/devices/tech/debug/images/perf_trace_sf_comp_submit.png"></p> <p class="img-caption"><strong>Figure 8.</strong> SurfaceFlinger sets up composition and submits the final frame.</p> @@ -200,7 +202,7 @@ display pipeline's kernel thread for outputting a rendered frame to the display. We can see <code>mdss_fb0</code> as its own row in the trace (scroll down to view).</p> -<p><img src="images/perf_trace_wake_cpu0.png"></p> +<p><img src="/devices/tech/debug/images/perf_trace_wake_cpu0.png"></p> <p class="img-caption"><strong>Figure 9.</strong> <code>mdss_fb0</code> wakes on CPU 0.</p> @@ -215,14 +217,14 @@ the Pixel XL might not be useful to you).</p> <h2 id="example_2">Example: Non-working frame</h2> <p>This example describes a systrace used to debug Pixel/Pixel XL jitter. To -follow along with the example, <a href="perf_traces.zip">download the zip +follow along with the example, <a href="/devices/tech/debug/perf_traces.zip">download the zip file</a> of traces (which also includes other traces referred to in this section), upzip the file, and open the systrace_tutorial.html file in your browser.</p> <p>When you first open the systrace, you'll see something like this:</p> -<p><img src="images/perf_trace_tl_pxl.png"></p> +<p><img src="/devices/tech/debug/images/perf_trace_tl_pxl.png"></p> <p class="img-caption"><strong>Figure 10</strong>. TouchLatency running on Pixel XL (most options enabled, including mdss and kgsl tracepoints).</p> @@ -234,7 +236,7 @@ case, FrameMissed is correlated with SurfaceFlinger missing one of its extremely-regular runtimes and an unchanged pending-buffer count for the app (<code>com.prefabulated.touchlatency</code>) at a vsync:</p> -<p><img src="images/perf_trace_fm_sf.png"></p> +<p><img src="/devices/tech/debug/images/perf_trace_fm_sf.png"></p> <p class="img-caption"><strong>Figure 11</strong>. FrameMissed correlation with SurfaceFlinger.</p> @@ -250,7 +252,7 @@ SurfaceFlinger wakes and immediately goes to sleep. When viewing the number of pending frames from TouchLatency, there are two frames (a good clue to help figure out what's going on).</p> -<p><img src="images/perf_trace_sf_wake_sleep.png"></p> +<p><img src="/devices/tech/debug/images/perf_trace_sf_wake_sleep.png"></p> <p class="img-caption"><strong>Figure 12.</strong> SurfaceFlinger wakes and immediately goes to sleep.</p> @@ -269,7 +271,7 @@ particular events in SurfaceFlinger depends on your SOC and driver stack, so work with your SOC vendor to understand the meaning of fence categories in your traces.</p> -<p><img src="images/perf_traces_fences.png"></p> +<p><img src="/devices/tech/debug/images/perf_traces_fences.png"></p> <p class="img-caption"><strong>Figure 13.</strong> <code>mdss_fb0_retire</code> fences.</p> @@ -277,7 +279,7 @@ fences.</p> Halfway through that slice, that frame should have been replaced by a new one but wasn't. View the previous frame and look for anything interesting:</p> -<p><img src="images/perf_trace_frame_previous.png"></p> +<p><img src="/devices/tech/debug/images/perf_trace_frame_previous.png"></p> <p class="img-caption"><strong>Figure 14.</strong> Frame previous to busted frame.</p> @@ -288,7 +290,7 @@ suggests that something is very wrong with the display pipe.</p> <p>Investigate exactly where that fence ends to determine what controls it:</p> -<p><img src="images/perf_trace_fence_end.png"></p> +<p><img src="/devices/tech/debug/images/perf_trace_fence_end.png"></p> <p class="img-caption"><strong>Figure 15.</strong> Investigate fence end.</p> <p>A workqueue contains a <code>__vsync_retire_work_handler</code> that is @@ -301,7 +303,7 @@ might not get scheduled accurately.</p> <p>Check the previous frame to determine if that contributed; sometimes jitter can add up over time and eventually cause us to miss a deadline.</p> -<p><img src="images/perf_trace_previous_frame.png"></p> +<p><img src="/devices/tech/debug/images/perf_trace_previous_frame.png"></p> <p class="img-caption"><strong>Figure 16.</strong> Previous frame.</p> <p>The runnable line on the kworker isn't visible because the viewer turns it diff --git a/en/devices/tech/debug/valgrind.html b/en/devices/tech/debug/valgrind.html index d8f1e42b..9ae0f088 100644 --- a/en/devices/tech/debug/valgrind.html +++ b/en/devices/tech/debug/valgrind.html @@ -31,16 +31,16 @@ debugging, most Android platform developers use <h2 id=build-valgrind>Building Valgrind</h2> <p>To build Valgrind:</p> -<pre class="no-pretty-print"> -$ mmma -j6 external/valgrind +<pre class="devsite-terminal devsite-click-to-copy"> +mmma -j6 external/valgrind </pre> <h2 id=app-valgrind>Using on an application</h2> <p>To use Valgrind on an application:</p> -<pre class="no-pretty-print"> -$ adb shell setprop wrap.<em>app_name</em> "logwrapper valgrind" -$ adb shell am start -a android.intent.action.MAIN -n <em>app_name</em>/.MainActivity +<pre class="devsite-click-to-copy"> +<code class="devsite-terminal">adb shell setprop wrap.<em>app_name</em> "logwrapper valgrind"</code> +<code class="devsite-terminal">adb shell am start -a android.intent.action.MAIN -n <em>app_name</em>/.MainActivity</code> </pre> <code><em>app_name</em></code> must be a fully-qualified name such as @@ -49,25 +49,25 @@ $ adb shell am start -a android.intent.action.MAIN -n <em>app_name</em>/.MainAct <h2 id=server-valgrind>Using on the system server</h2> <p>To run the system server with Valgrind:</p> -<pre class="no-pretty-print"> -$ adb shell setprop wrap.system_server "logwrapper valgrind" -$ adb shell stop && adb shell start +<pre class="devsite-click-to-copy"> +<code class="devsite-terminal">adb shell setprop wrap.system_server "logwrapper valgrind"</code> +<code class="devsite-terminal">adb shell stop && adb shell start</code> </pre> <h2 id=symbols-valgrind>Getting debug symbols</h2> <p>For debug symbols, push unstripped libraries to <code>/data/local/symbols</code>:</p> -<pre class="no-pretty-print"> -$ adb shell mkdir /data/local/symbols -$ adb push $OUT/symbols /data/local/symbols +<pre class="devsite-click-to-copy"> +<code class="devsite-terminal">adb shell mkdir /data/local/symbols</code> +<code class="devsite-terminal">adb push $OUT/symbols /data/local/symbols</code> </pre> <h2 id=boot-valgrind>Using during boot up</h2> <p>To use Valgrind during boot up, edit <code>out/target/product/XXXX/root/init.rc</code> by changing</p> -<p><code>service example /system/bin/foo --arg1 --arg2</code></p> +<pre class="devsite-click-to-copy">service example /system/bin/foo --arg1 --arg2</pre> <p>to:</p> -<p><code>service example /system/bin/logwrapper /system/bin/valgrind /system/bin/foo --arg1 --arg2</code></p> +<pre class="devsite-click-to-copy">>service example /system/bin/logwrapper /system/bin/valgrind /system/bin/foo --arg1 --arg2</pre> <p>To see the effects, create a <code>boot.img</code> and reflash the device.</p> |