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
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
soong/scripts/get_clang_version.py now prints the whole prebuilt dir
(e.g. clang-r416183b1) instead of just the version number.
Test: invoke FindClangDir from the interpreter
Change-Id: I17363e6bc4a48fe6be345f87006baa4590371dc1
Bug: http://b/187231324
Instead,
- For local development, invoke build/soong/scripts/get_clang_version.py
to find the current clang version.
- In CI, find llvm-cxxfilt using glob expansion.
Test: development/scripts/symbol.py unittest for local development
python-stack_core_test on presubmit
Change-Id: Id4258dd791626508520b6a478b8a1b54495ebb11
Ensure that the script works on buildbots.
Test: adb shell debuggerd -b <pid> | development/scripts/stack
Change-Id: I3fd4a0ed78ff3245d1ab2f6e842446888c5c7b8b
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
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
Bug: 112357697
Test: Verified that this doesn't cause any issues with a stack.
Test: Faked an exception and verified no crash.
Change-Id: I61982dbd44ac4f52b008bc35bbff2d9687f6ae25
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
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
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
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
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
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
This fixes the bug where we can't (currently) find the toolchain
for arm because it's at a different GCC version (4.8) from arm64 (4.9).
Change-Id: I22351af55298255f3ac4adfcae7e20080712fba4
The stack tool is not really proprietary, and is needed by vendors and
third-party developers working on native code.
Change-Id: I37f34b0681a0063ecf71f5a078d2c4a1ba622973
Signed-off-by: Iliyan Malchev <malchev@google.com>
