3 ms·
This has been a fallback method for Google Breakpad's stackwalker for more than a decade. It generates basically useless stack traces, at least for stacks captu
by js2 4y ago
This has been a fallback method for Google Breakpad's stackwalker for more than a decade. It generates basically useless stack traces, at least for stacks captured from Android where you're trying to trace through NDK code invoked from the ART. Compounding the problem is a complete lack of available symbols for Android.
https://github.com/google/breakpad/blob/main/docs/stack_walking.md https://github.com/google/breakpad/blob/main/docs/stack_walk...
Also see recent discussion here:
https://news.ycombinator.com/item?id=35438171 https://news.ycombinator.com/item?id=35438171
- saagarjha 4y agoTo be fair, doing backtrackes through JNI calls is generally pretty complicated.
- userbinator 4y agoNot exactly. I dug around in that code a little, and although it contains a disassembler, it's not being used for inspecting the call chain. All it does is check that the address appears to be inside a code section. https://github.com/google/breakpad/blob/main/src/processor/stackwalker.cc#L330 https://github.com/google/breakpad/blob/main/src/processor/s...
- js2 4y agoTrue, but that's because all it has is a snapshot of the stack to work with. The code isn't available to it.