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