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

[SupperMary]

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

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

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

已做检查如下：

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

[calloc]

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

[mxalbert1996]

因为 inline ？

[HtPM]

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

[SupperMary]

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

[SupperMary]

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

[SupperMary]

@HtPM 方便举个例子吗

[HtPM]

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]

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

[SupperMary]

多谢解惑😀