what are your build args? how did you run addr2line exactly?

incidentally today I used addr2line to symbolize a debuggerd stack correctly, but the stack script still didn't parse the debuggerd output correctly

also, this is not devtools, which refers to the thing to help web developers..

my gn args:

use_goma = true

target_os = "android"
target_cpu = "arm64"
is_debug = true
dcheck_always_on = true

is_clang = true

use_signing_keys = true

android_sdk_release = "p"

android_default_version_code = "999999999"


I am using addr2line as:
third_party/android_ndk/toolchains/aarch64-linux-android-4.9/prebuilt/linux-x86_64/bin/aarch64-linux-android-addr2line -C -f -e out/Debug/libcontent.cr.so 0x00f91a81

Which gives the same result with stack script.

Bo, what's the build target you are building? I am building system_webview_google_apk.

Sorry, missed lib.unstripped in #c4.

I was doing an official build:
target_os = "android"
target_cpu = "arm64"
is_debug = false
is_official_build = true
symbol_level = 1

I was building system_webview_google_apk as well. Main difference is probably not component build, and possibly symbol_level = 1.

Here's my addr2line command from earlier in the day:
third_party/android_ndk/toolchains/aarch64-linux-android-4.9/prebuilt/linux-x86_64/bin/aarch64-linux-android-addr2line -e out/arm64/lib.unstripped/libwebviewchromium.so 0x000000000196a98c

It turns out I am using a wrong *.so file.

I nuked my out/Debug directory, and did a clean build with my old gn args, I have the following *libcontent.cr.so* files:

out/Debug/libcontent.cr.so
out/Debug/android_clang_arm/libcontent.cr.so
out/Debug/android_clang_arm/lib.unstripped/libcontent.cr.so
out/Debug/android_clang_arm/libcontent.cr.so.TOC
out/Debug/lib.unstripped/libcontent.cr.so
out/Debug/libcontent.cr.so.TOC

It turns out I need to use out/Debug/android_clang_arm/lib.unstripped/libcontent.cr.so, maybe because of is_clang = true gn flag, but wondering why I am stilling building *.cr.so other than the ones inside of android_clang_arm directory.

stack has no awareness of is_clang flag, so it won't work.

so ignoring issue with stack, this was user error?

yeah that secondary abi thing is annoying, so I generally just use 32bit-only device whenever I can to avoid it..

I also don't understand why is_debug = false and is_official_build = true work. I tried it also, base::debug::StackTrace() will give 34 lines of the same function offset to me, addr2line gives me:

_Unwind_Backtrace
./../../buildtools/third_party/libunwind/trunk/src/UnwindLevel1-gcc-ext.c:112

Which is the _Unwind_Backtrace function itself, I assume we lose the offset table with these gn args.

ok, nvm then..

FWIW, if you like me seeing multiple so files in different directories, stack script has --output-directory option, so for the case I mentioned in #c8,

`third_party/android_platform/development/scripts/stack --output-directory=out/Debug/android_clang_arm/lib.unstripped <stacktrace_file>`

gives the stack.

one thing I noticed just now, on a base::debug::StackTrace output like this:
#04 0x9516584d /data/app/org.chromium.native_test-1/lib/arm/lib_android_webview_unittests__library.cr.so+0x004ef84d

The address after the lib is the relatively address into the library. 0x9 is way too big for the library. So in that case, using 0x004ef84d worked for me.

Now if someone could just go and fix the stack script, that would be wonderful...

Drew, are you interesting in this? I can help out.

stack script works for me if I passed the correct lib path, what's need to be fixed?

make sure it correctly handles both base::debug::StackTrace stack and debuggerd stack. pretty sure debuggerd parsing is broken right now.

Also I must be holding it wrong, this does not work for me for base::debug::StackTrace output. stack just piped everything back to me, which is annoying:
third_party/android_platform/development/scripts/stack --arch=arm --output-directory=out/Default

this is just a simple 32bit build in my case, no secondary abi shenanigans

 Issue 923098  has been merged into this issue.

This worked for standalone webview at last time (1-2 week ago) I checked, in the bug  crbug.com/923098 , what happened when base::debug::StackTrace().Print() didn't work.

Is there any output in logcat? or the output cant'b be symbolized?