Replaced with ARCH_IS_32BIT since that's the only thing truly
necessary to work.
This also makes the register regex much more lenient, but it appears
to be strict enough that it doesn't seem to capture arbitrary lines
when run through logcat.
Removed the StripPC function and verified that an arm crash that
ends in 1 still works.
Removed the architecture.py script, it is old and I don't see anyone
using it.
Modify the reading of the lines to ignore any errors in the input.
Test: All unit tests pass.
Test: Symbolized arm and arm64 tombstones
Test: Symbolized x86 and x86_64 tombstones
Test: Ran through a logcat and verified it caught the bug but
Test: didn't print any extra information.
Change-Id: I6a65ecaad68da1d56864db32ff434512e4df0d89
I previously skipped directories, but that can still lead to problems.
So instead, only add paths that are files.
Test: Ran over a stack that failed when trying to run llvm-readelf
Test: on a directory. After this fix, everything get line numbers.
Change-Id: Ide39c5a118d78a822057cc3977d0f532595f798b
The current build id check uses the file utility. Unfortunately, it
doesn't work on all systems. Replace with a call to llvm-readelf and
get the bitness and build id using that data.
Other small modifications:
- Only attempt to get the full path for a library once for each library.
- Do not add directories into the symbol libraries.
Test: Unit tests pass.
Test: Running using a libart.so that file doesn't understand and
Test: verifying the line numbers are correct.
Change-Id: I12c3d3c4599d201c3c01feeb48448fee6c633d71
I had made this change if there was an offset on the line,
but I didn't make if there is no offset present. Add the
no offset present case.
Bug: 206463081
Test: Ran unit tests.
Test: Modified a normal stack line with libart.so to be
Test: libart.so!libart.so and verified the line numbers
Test: are still present.
Change-Id: I75e3fbe5eaa3a5419a2dca2c4542731c61c7b971
For some reason, apex directory structure in the symbols directory
is not the same as on device.
This means that a directory on device like:
/apex/com.android.art/lib64/libart.so
Is really found in symbols as:
/apex/com.google.android.art/lib64/libart.so
Modify the script to look in both places for libraries.
Bug: 206463081
Test: Verified that libart.so in a backtrace now finds the symbols
Test: libart.so.
Change-Id: I67610e3a236765cc92397c70a769c4aa705f13ce
Add a default return value in a call in the GetLibraryByBuildId()
function to avoid an exception if a file cannot be found in the
symbol directory.
Bug: 216232380
Test: Ran the input from the bug. Verified without the change, the
Test: exception occurs and with the fix, no exception.
Test: Ran unit tests of stack_core.py.
Change-Id: I015982eb835f5a3d7f03dcc3e0b1627b0c1a7cfe
The expanded parameters take a lot horizontal space
and almost always push the file:line of the screen,
or text-wrap generating multiple lines per frame.
This CL tries to make the output less cluttered by
removing parameters from the unmangled method names.
It is possible to add the parameters back using
the --verbose command line argument.
Test: Add unit tests, investigate crashes from logcat
Change-Id: I42d1e26dbc2fa9db8b7bd95ce449cb2bd93f93f8
Use lru_cache(maxsize=None) instead which is equivalent,
and is available on older python versions as well.
Also fix a bug where null "lib" variable was dereferenced.
Bug: 204507951
Bug: 171980804
Test: Run script with python3.7
Change-Id: I922ee48451ad3c60c2237fb0554e1838c1bf81af
If the parsed backtrace has ELF build-ids, use them to
brute-force search for files in the symbols directory.
The search only considers files with the same basename,
so the number of candidates to check is very small.
This fixes issues when compile time directory does not
match the runtime directory on device (e.g. for apex).
Bug: 171980804
Test: ART crashes can be symbolized again
Change-Id: I0311a10c1e2eab92ee44f1b32c523d4763a54ee1
Fix a problem with python3 and the zipinfo processing of an apk.
Add sorting of the zipinfo data since it's not guaranteed that
the zip entries will be in sorted order, so sort them.
Bug: https://github.com/android/ndk/issues/1587
Test: Ran a apk stack line through the script.
Test: Ran the stack core unit tests.
Change-Id: Ie5ea67ad54a6b2de077e53740c82265f6bf783c6
Modify the library lookup code to try and find the various places
that a library might really exist in the symbols directory. This
is for atest which can run executables in different locations
than the actual where the symbolized file exists.
Test: Ran using /data/local/tmp, /data/local/tests,
Test: /data/local/tests/vendor, /data/local/tests/unrestricted and
Test: verified the correct library was found.
Test: Used tombstones crash data and verified all libraries
Test: still found properly.
Test: Ran atest CtsBionicTestCases and verified the symbolized
Test: binary could be found using a real tombstone crash.
Test: Did the same as above, but changed the path in the tombstone
Test: crash data from /data/local/tmp to /data/local/tests and
Test: /data/local/tests/unrestricted.
Change-Id: Iaa121823ef6142eaf9f7de3232b147bd7389bea5
Also hook up the test to Android.bp.
Test: unit test
Test: Ran with a tombstone file as parameter.
Test: Ran pasting in stack to stdin.
Change-Id: I25f40569cc49b7487553611bcc25d061179bfa8d
The path where the tests are uploaded by atest differs from the
path to unstripped binaries in the out directory. As a result,
the script can't symbolize the parts of the stack trace that
correspond to code in the test binary. Add a fixup to use the
correct path.
Test: Used the script on example crashes in framework and vendor
device tests - appears to work and give correct line numbers.
Change-Id: I5470e6342afb801ac596cbc0c0bf067850b1e09a
Replace all references to gcc tools with llvm tools. This change still
uses c++filt until llvm-cxxfilt is put in the prebuilts.
Test: Ran a backtrace through this script and the old script and verified
Test: no major differences.
Test: Ran unittests for symbol.py and stack_core.py.
Change-Id: Ic31c1a0707dae11c5037f9637943cd7932badf46
When seeing a line like:
#01 pc 0012ea14 /system/lib/libart.so!libart.so (offset 0x134000)
Treat it like this line instead:
#01 pc 0012ea14 /system/lib/libart.so
This will allow the symbolizer to properly figure out the line numbers.
Bug: 148657674
Test: Ran lines with xxx.so!xxx.so lines and verified that they decode.
Change-Id: Ieea516b46a00b414c740d0b4302a5cc73da2b0a8
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
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
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
This is needed by the internal stack decoding website, which
will be pulling symbols from the build servers anyway (so doesn't
need to be correctly lunched).
Bug: 16734486
Change-Id: I9190065148c0d4bb4eacec28bcc062fa95798917
Left the default symbol.ARCH value intact and changed stack_core instead
so that it will assume the ABI is arm until it sees an ABI line. This
allows compatibility for people who are used to pasting portions of a
tombstone instead of the whole thing (assuming said tombstone is arm)
while additionally supporting other architectures if a whole tombstone
is pasted in.
Change-Id: Ib8b5754920d2e2aa5017c29daeca59abcf4b547d
Also take into account the fact that the arm pcsr register is the
fifth entry on its line, so the stack tool previously stripped that
off.
Change-Id: I1dd2d11060e572b4d8ffd8710cf1df4d970671e4
x86 uses the x86_64 toolchain. There's no separate 32-bit toolchain.
I started to refactor so we could add FindToolchain tests, but that doesn't
work because FindToolchain depends on environment variables set up by 'lunch'.
Change-Id: I264b95e1e83a7e795f8cac49bc9e1cf497514029
The value corresponds to whether or not the line has matched one of the
detected formats (registers, header, backtrace, etc.) and can be used to
identify what logcat lines don't correspond to one of these formats.
Change-Id: Ibd7bc5a211dcfe86ea2f92d7e7941091afff4fc4
Every architecture was at least slightly wrong. Rather than try to
tune the heuristics, let's just keep lists of all the registers.
Also start adding some unit tests.
Change-Id: I490dcc9855f7af1e3529734711400f366ffc4e0f
This includes the fairly large change of refactoring stack_core.py into
a class so that its behavior is compatible with adbs. Additionally, if
the ABI line does not come before lines that require it to determine
proper widths (registers, stack), then it will assume that the ABI is
32 bit and not 64.
Change-Id: I6ad84a55337d86d25f7f8197048dc93868b0a01a
