addr2line 推得的代码行数与 trace 对不上

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

› Android Studio

这是一个创建于 32 天前的主题，其中的信息可能已经有所发展或是发生改变。

请教一个问题，楼主接到一些后台监控的 tombstone 报错。报错里面有大概这样一个信息

地址 1  func1..................
地址 2  func2..................
地址 3  func3..................
地址 4  func4..................

我用 addr2line 去根据地址反推报错位置的时候，地址 3 ，地址 4 还是能对的上的到地址 2 和地址 1 时，addr2line 给的代码位置已经到 std 的头文件里面去了，但是 tombstone 报错仍然是我们的业务函数。这种 addr2line 得到的代码位置与报错信息不对应，可能是什么原因造成的。

已做检查如下：

1 、用于推算地址的 symbol 文件与报问题的 ROM 是同一版本的。

9 条回复 • 2024-11-11 18:48:16 +08:00

calloc

32 天前 via Android

rom 是内部构建的吗？同一个版本也有可能有不同物料。符号地址对不上，更倾向于物料不是同一个

mxalbert1996

32 天前 via Android

因为 inline ？

HtPM

30 天前

这不是很正常嘛，比如 std 某个函数的形参你传递了错误的实参，比如 nullptr 。这个时候其中一个思路就是看堆栈中最新的那个业务函数的输入是否异常，再对比查看调用的 std 函数的输入边界。

SupperMary

21 天前

@calloc 如果构建系统出问题，导致物料不同的话，就难以排查了。

SupperMary

21 天前

@mxalbert1996 code 上没有显式 inline 的地方，应该不是这个原因。

SupperMary

21 天前

@HtPM 方便举个例子吗

HtPM

19 天前

Abort message: 'terminating with uncaught exception of type std::out_of_range: stoi: out of range'
backtrace:
#00 pc 000000000008d974 /apex/com.android.runtime/lib64/bionic/libc.so (abort+168) (BuildId: 8a2277585401a6103d671ea1f801ed52)
#01 pc 00000000004117e8 /data/app/~~-Ml3L8MsCzRmolEzS5T3YA==/com.stork.ultrasound.fusu-pgdHATtSuRuufWM9pv879Q==/lib/arm64/libtensorflowlite_gpu_delegate.so
#02 pc 0000000000411940 /data/app/~~-Ml3L8MsCzRmolEzS5T3YA==/com.stork.ultrasound.fusu-pgdHATtSuRuufWM9pv879Q==/lib/arm64/libtensorflowlite_gpu_delegate.so
#03 pc 000000000040ebc4 /data/app/~~-Ml3L8MsCzRmolEzS5T3YA==/com.stork.ultrasound.fusu-pgdHATtSuRuufWM9pv879Q==/lib/arm64/libtensorflowlite_gpu_delegate.so
#04 pc 000000000040e2c8 /data/app/~~-Ml3L8MsCzRmolEzS5T3YA==/com.stork.ultrasound.fusu-pgdHATtSuRuufWM9pv879Q==/lib/arm64/libtensorflowlite_gpu_delegate.so
#05 pc 000000000040e248 /data/app/~~-Ml3L8MsCzRmolEzS5T3YA==/com.stork.ultrasound.fusu-pgdHATtSuRuufWM9pv879Q==/lib/arm64/libtensorflowlite_gpu_delegate.so (__cxa_throw+120)
#06 pc 0000000000407e7c /data/app/~~-Ml3L8MsCzRmolEzS5T3YA==/com.stork.ultrasound.fusu-pgdHATtSuRuufWM9pv879Q==/lib/arm64/libtensorflowlite_gpu_delegate.so (std::__ndk1::stoi(std::__ndk1::basic_string<char, std::__ndk1::char_traits<char>, std::__ndk1::allocator<char> > const&, unsigned long*, int)+468)
#07 pc 000000000101dd84 /data/app/~~-Ml3L8MsCzRmolEzS5T3YA==/com.stork.ultrasound.fusu-pgdHATtSuRuufWM9pv879Q==/lib/arm64/libultrasoundGPU.so (stork_sqlite3_orm_impl::SQLite3ORMImpl::splitStr2ValArray(std::__ndk1::basic_string<char, std::__ndk1::char_traits<char>, std::__ndk1::allocator<char> > const&, char, unsigned long&, unsigned int&, bool&, bool, bool)+668) (BuildId: 5e80ef5828b4907af556f8f082053aedb6cf272c)
#08 pc 0000000000c738f4 /data/app/~~-Ml3L8MsCzRmolEzS5T3YA==/com.stork.ultrasound.fusu-pgdHATtSuRuufWM9pv879Q==/lib/arm64/libultrasoundGPU.so (stork_ui_param::BaseAppParamInfo::getModeParam(char, bool*)+3304) (BuildId: 5e80ef5828b4907af556f8f082053aedb6cf272c)
#09 pc 0000000000c4dc44 /data/app/~~-Ml3L8MsCzRmolEzS5T3YA==/com.stork.ultrasound.fusu-pgdHATtSuRuufWM9pv879Q==/lib/arm64/libultrasoundGPU.so (initDefaultBaseAppParamInfo(int)+452) (BuildId: 5e80ef5828b4907af556f8f082053aedb6cf272c)
#10 pc 0000000000b97cb8 /data/app/~~-Ml3L8MsCzRmolEzS5T3YA==/com.stork.ultrasound.fusu-pgdHATtSuRuufWM9pv879Q==/lib/arm64/libultrasoundGPU.so (connectProbe(char*, char*, char*, int, unsigned char)+388) (BuildId: 5e80ef5828b4907af556f8f082053aedb6cf272c)
#11 pc 0000000000bcddf4 /data/app/~~-Ml3L8MsCzRmolEzS5T3YA==/com.stork.ultrasound.fusu-pgdHATtSuRuufWM9pv879Q==/lib/arm64/libultrasoundGPU.so (BuildId: 5e80ef5828b4907af556f8f082053aedb6cf272c)
#12 pc 0000000000bcdcd4 /data/app/~~-Ml3L8MsCzRmolEzS5T3YA==/com.stork.ultrasound.fusu-pgdHATtSuRuufWM9pv879Q==/lib/arm64/libultrasoundGPU.so (BuildId: 5e80ef5828b4907af556f8f082053aedb6cf272c)
#13 pc 0000000000bcd334 /data/app/~~-Ml3L8MsCzRmolEzS5T3YA==/com.stork.ultrasound.fusu-pgdHATtSuRuufWM9pv879Q==/lib/arm64/libultrasoundGPU.so (BuildId: 5e80ef5828b4907af556f8f082053aedb6cf272c)
#14 pc 00000000000f57c8 /apex/com.android.runtime/lib64/bionic/libc.so (__pthread_start(void*)+208) (BuildId: 8a2277585401a6103d671ea1f801ed52)
#15 pc 000000000008f1bc /apex/com.android.runtime/lib64/bionic/libc.so (__start_thread+68) (BuildId: 8a2277585401a6103d671ea1f801ed52)

这是我们公司的 tombstones ，libultrasoundGPU.so 是我们的业务 so 库，可以看到最新的业务报错地址是#07 ， #00 是 libc.so 。找 bug 的时候只需要定位到我们业务的 libultrasoundGPU.so 库（#07 ）就行了,通过 addr2line convert #07 到具体的 line num

HtPM

19 天前

帮你查了一下，还有一些情况也可能导致你说的情况，比如编译器优化 -o2 -o3 ，还有上面有人说的内联优化，如果应用程序的堆栈被污染或者内存布局出现问题（例如，由于越界、栈溢出等问题），地址偏移可能会导致报错信息不准确地指向标准库或头文件，而不是实际的业务代码

SupperMary

19 天前

多谢解惑😀