我通过nm生成ELF文件发现TryFromIntError的Debug::fmt有被调用,无法确定是哪里调用产生的,请问有什么办法可以知道是调用哪个函数产生的。目前查看了所有的unwrap操作,没有涉及Result<T, TryFromIntError>。
080036c5 000000e8 t <core::num::error::TryFromIntError as core::fmt::Debug>::fmt
1
共 10 条评论, 1 页
评论区
写评论原因已找到:调用Result<(),()>::unwrap()导致,但是没有找到TryFromIntError产生的地方,()的Debug::fmt只是pad了一个"()":
unwrap的操作最终调用panic!,不清楚是否是编译器生成的代码搞的
实际运行并没有触发这个Error,我是通过nm查看ELF文件的符号表看到有这个函数依赖。
我已经通过注释代码找到了调用函数:Err(()).unwrap(),还没有具体看这个Error的Debug实现,把这个unwrap操作去掉TryFromIntError::fmt的依赖就没有了
--
👇
苦瓜小仔:
RUST_BACKTRACE=1 cargo r
看 stack backtrace 也不行吗RUST_BACKTRACE=1 cargo r
看 stack backtrace 也不行吗在我的代码里面没有发现直接生成TryFromIntError的地方
我是想找到是哪个函数调用了Debug::fmt(TryFromIntError),不是由我直接调用的,但是有可能是我间接调用某个函数引入的。目前已知Result<T,TryFroTryFromIntError>.unwrap会调用,但是这个Result是哪里产生的我就不知道了,有可能是core库里面调用的,也有可能不是unwrap引入的
--
👇
苦瓜小仔: 你需要自己做错误处理。
对于一个基础函数:
如果仅仅是转发错误,你只会得到最初的错误信息:
打印:
Error: out of range integral type conversion attempted
你觉得打印的错误没什么用处,因为没有你想看到的信息。如果你对错误发生的地点感兴趣,可以这样写:
那么会得到
嗯,你想要知道的任何错误信息,都需要类似地做错误处理。
此外你还可以直接使用
eyre
:那么直接得到:
你需要自己做错误处理。
对于一个基础函数:
如果仅仅是转发错误,你只会得到最初的错误信息:
打印:
Error: out of range integral type conversion attempted
你觉得打印的错误没什么用处,因为没有你想看到的信息。如果你对错误发生的地点感兴趣,可以这样写:
那么会得到
嗯,你想要知道的任何错误信息,都需要类似地做错误处理。
此外你还可以直接使用
eyre
:那么直接得到:
代码运行没有触发这个Error,我是想找到调用地方,删掉这个调用
--
👇
shanliu: 把调用堆栈打出来不就找到了
把调用堆栈打出来不就找到了
查找了core库的代码,涉及TryFromIntError的都是usize和其他基础int类型的转换,这些TryFrom操作不清楚会在什么操作下被调用到