请教一个问题，楼主接到一些后台监控的 tombstone 报错。 报错里面有大概这样一个信息
地址 1 func1................. 地址 2 func2.................. 地址 3 func3.................. 地址 4 func4.................. 我用 addr2line 去根据地址反推报错位置的时候，地址 3 ，地址 4 还是能对的上的 到地址 2 和地址 1 时，addr2line 给的代码位置已经到 std 的头文件里面去了，但是 tombstone 报错仍然是我们的业务函数。 这种 addr2line 得到的代码位置与报错信息不对应，可能是什么原因造成的。
已做检查如下：
1 、用于推算地址的 symbol 文件 与报问题的 ROM 是同一版本的。
 | 1 calloc Oct 30, 2024 via Android rom 是内部构建的吗？同一个版本也有可能有不同物料。符号地址对不上，更倾向于物料不是同一个 |
 | 2 mxalbert1996 Oct 30, 2024 via Android 因为 inline ？ |
 | 3 HtPM Nov 1, 2024 这不是很正常嘛，比如 std 某个函数的形参你传递了错误的实参，比如 nullptr 。这个时候其中一个思路就是看堆栈中最新的 那个业务函数 的 输入是否异常，再对比查看调用的 std 函数的输入边界。 |
 | 4 SupperMary OP @calloc 如果构建系统出问题，导致物料不同的话，就难以排查了。 |
| 5 SupperMary OP @mxalbert1996 code 上没有显式 inline 的地方，应该不是这个原因。 |
| 6 SupperMary OP @HtPM 方便举个例子吗 |
| 7 HtPM Nov 11, 2024  1 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 |
| 8 HtPM Nov 11, 2024  1 帮你查了一下，还有一些情况也可能导致你说的情况，比如编译器优化 -o2 -o3 ，还有上面有人说的内联优化，如果应用程序的堆栈被污染或者内存布局出现问题（例如，由于越界、栈溢出等问题），地址偏移可能会导致报错信息不准确地指向标准库或头文件，而不是实际的业务代码 |
| 9 SupperMary OP 多谢解惑 |
Select Language