Users of gdbclient might not know that a new and improved version exist
in the form of gdbclient.py.
Change-Id: I65243a8d25a1ecbe8ff734d0be4dbe40b50db4b2
Signed-off-by: Kevin Rocard <krocard@google.com>
When using logwrapper, there is only a zygote heap. This caused
a divide by zero for the app heap.
Test: native_heapdump_viewer.py --html art/native_heap.txt > test.html
Change-Id: I7defd94935d72ee9c4cb6e53d7a1a308a1030eb3
Properties can include \n so get_props isn't sound, and it's not obvious how
to fix it (without adding something like cat's -v to getprop, which wouldn't
help the intended use case of working with arbitrary old devices).
Bug: https://issuetracker.google.com/37093233
Test: gdbclient -r /system/bin/date
Change-Id: I96042fd44f1de17974968954fab6c916a9d13b61
Switch from assuming that "root" meant su to an explicit prepended
argument, to allow things like `gdbclient.py --user shell`.
Test: gdbclient.py --user shell -r /system/bin/ls
Change-Id: I9d02eea7c6d79898ed8b13817e009630b0f9536a
If there are no bytes attributable to APP, then you get a divide
by zero. Modify the code to avoid doing a divide by zero.
This can happen when using logwrapper to enable malloc debug.
Test: Ran on a heap that had no APP bytest.
Change-Id: I48f0666a92b591e4537c493c56b136e517a36c25
Usage:
1. Collect a native heap dump from the device. For example:
$ adb shell stop
$ adb shell setprop libc.debug.malloc.program app_process
$ adb shell setprop libc.debug.malloc.options backtrace=64
$ adb shell start
(launch and use app)
$ adb shell am dumpheap -n <pid> /data/local/tmp/native_heap.txt
$ adb pull /data/local/tmp/native_heap.txt
2. Run the viewer:
$ python native_heapdump_viewer.py [options] native_heap.txt
[--verbose]: verbose output
[--html]: html output
[--symbols SYMBOL_DIR]: SYMBOL_DIR is the directory containing the
.so files with symbols. Defaults to $ANDROID_PRODUCT_OUT/symbols
This outputs a file with lines of the form:
5831776 29.09% 100.00% 10532 71b07bc0b0 /system/lib64/libandroid_runtime.so Typeface_createFromArray frameworks/base/core/jni/android/graphics/Typeface.cpp:68
5831776 is the total number of bytes allocated at this stack frame, which
is 29.09% of the total number of bytes allocated and 100.00% of the parent
frame's bytes allocated. 10532 is the total number of allocations at this
stack frame. 71b07bc0b0 is the address of the stack frame.
For generating interactive HTML output, use:
python native_heapdump_viewer.py --html [options] native_heap.txt > allocations.html
Then open allocations.html in a browser. Clicking on nodes will
expand the tree.
Test: Try script on an app following usage instructions.
Bug: 36457259
Change-Id: I18dfe9a00fc1d3e82673dbfb4b5be3dc10480cec
Add subprocess caching to the stack tool. This caches open pipes for
commands, improving symbolization speed for (sets of) stack traces with
duplicated libraries.
Bug: 38226236
Test: m
Test: manual tests
Change-Id: Iadbd74255b9a40c86939be3a1b172275a0b34d54
Add symbol caching to the stack tool. This caches resolved symbols,
improving symbolization speed for (sets of) stack traces with duplicated
symbols.
Bug: 38226236
Test: m
Test: manual tests
Change-Id: Ia579234ba1bf227b12af0c5af5fa3955d0eed4fe
This script analyses variables defined in BoardConfig*.mk and used
by framework modules.
Bug: 33122247
Test: run the script and check output
Change-Id: Ice533b4d59775eab1660214933393fb987786fdc
Signed-off-by: Po-Chien Hsueh <pchsueh@google.com>
If the value_line regex matches, and the symbol file happens to exist
as a directory, we'd call addr2line and crash. Fix this so that calling
addr2line on a directory doesn't happen.
There isn't an easy way to test this, but I added a single new unit test. The
real test was to use a tombstone file that used to crash, but no longer crashes.
Test: Wrote new unit test, ran over a tombstone file that used to crash.
Change-Id: I4331e3b032cee8d697d1b7f409638750c61971d6
Manually count input stack trace lines that match the regexps instead of
relying on the output of addr2line. Random changes to the libraries
listed in the test case could cause addr2line to land in an inlined
function and print multiple lines for each input stack frame.
Test: development/scripts/stack_core.py
Change-Id: I87f45466df4e814ec59a4c5f7e201fd1f3ee8419
To make the comparison meaningful, better compare integrals rather
than strings.
Test: ./stack_core.py
Change-Id: Ie24bea75d7c0bc57a1b7683b91e62fafead70341
Given a serial number, applies correct ioctl()
to reset the USB device with that serial number.
Useful to avoid having to unplug/replug after
flashall + wipe of device.
Change-Id: I7402e1e53cabc19c423ef912a5dc7ade8221b08b
The previous code used unzip to get the offsets of the files in
the zip file. This was an estimate, and it turns out to be wrong
in many cases. Replace that with zipinfo -v which gives the exact
offset of the files in the zip.
Also update the tmp files so that they are in a dictionary of their
own by apk, instead of embedded in the offset list.
Change-Id: I8f5efd95f2d2e39e20cc0b6b6571b799be21ef32
The CallStack function prints stacks to the log. Unfortunately, our
stack script defaults to arm, so if the data is actually arm64, we'll
do nothing. Modify the script to parse the input trying to determine
the abi before processing the rest of the lines. At the very least,
we'll be able to correctly choose between arm and arm64.
The only downside, is that, the old method could take dumps from different
abis, but no one I know does this.
Bug: 26569638
Change-Id: I5935b82fe0af1e788b0d3edc535b9f0cbb7d1b28
Some of the map names have spaces in them, but only the ones that look
like:
[anon:atexit handlers]
So allow spaces between a [ and a ].
Change-Id: I09f1b50533fcd2e79acda199dcc3fb99c6d8428f
Make sure gdb knows where the source files are, even when gdbclient.py
isn't being run from the root directory.
Change-Id: I8f604ba58f4c06b26f2a1f8e917e2a1c1c137ccd
gdbclient.py is always downloading the stripped version of executable
files from the device. This CL first tries to find the unstripped local
file before falling back to the stripped version.
Bug: http://b/24947939
Change-Id: I7a49d0d8b28590ee99ce892d3e3476921f4ae974
Python's subprocess.check_output() cwd argument does not change the PWD
environmental variable, which is what dumpvar.mk uses to turn relative
paths into absolute paths. This led to incorrect symbol paths when
gdbclient was not run from the root directory.
This CL fixes the bug by manually setting PWD before calling the
makefile. It's possible that dumpvar.mk should be using a different
method to get the current directory, but I was scared to change any
core build logic and this approach seems to work just fine.
Change-Id: Ibe3db0bef6694934c512918f7562029313b1deae
gdbclient.py can sometimes attempt to connect to the server before it's
ready, especially when debugging on an emulator. This CL adds
functionality to retry the connection for up to 5 seconds.
Bug: http://b/24671386
Change-Id: I65e77f918c3ea8433f992e67122cd48e3647c67b
The dlopen of a shared library within an apk is not handled by
the stack tool. Modify to understand and search through the apk to
find the shared library associated with the offset. Then unzip
that shared library to use as the target of addr2line.
Change-Id: I404302f68dff45c35a1dc2a55547f42ea04f02bf
Add trace parsing for sanitizer output. The output is different
from debuggerd output (and we do not have control over it). Use
two separate regexes and factor out the parsing into a method
returning a tuple of data.
Note: as we have no control over the prologue of the dump, we
cannot change it to include information like the ABI. Thus, this
functionality only works in a lunched tree, where the tool
implicitly uses the symbols directory.
Change-Id: Ic1189f4f65cf7728d1baec7055ecb549b0aa5f62
gdbclient got broken by:
https://android-review.googlesource.com/156974
To fix, check for special case when device is actually an emulator,
and set the $DEVICE variable accordingly.
Change-Id: I85d0d520ae1e2ea022aa3e2d08a10cd0b1cb491f
