Open jonhoo opened 4 years ago
Some more symbols:
_ZN98_$LT$futures_util..future..either..Either$LT$A$C$B$GT$$u20$as$u20$core..future..future..Future$GT$4poll17h0645d1ee0292e6cfE+120
_ZN53_$LT$S$u20$as$u20$futures_core..stream..TryStream$GT$13try_poll_next17hdcf2fec9b9f35d76E+432
_ZN5tokio4task4core13Core$LT$T$GT$4poll17h7deeca20231cedd5E+87
_ZN3std10sys_common9backtrace28__rust_begin_short_backtrace17h8176c5ec09afcf4eE+310
Notably not all of them contain ..
, so maybe that's not the issue?
Thanks for the report! I think it's due to the +NN
at the end which doesn't typically show up with symbols. Do you know where that's coming from?
Ah, yes, it looks like you're right. Removing them causes the parsing to work correctly. The +NN
syntax at the end is commonly used in all sorts of debugging/profiling contexts to mean "NN
bytes past this symbol" (e.g., to highlight that a particular line of a function was sampled a lot). It might be a good idea to support symbols with that kind of suffix.
The
ustack
function frombpftrace
/bcc
produces symbols that for some reason cannot be parsed byrustc-demangle
, such as:To test this yourself, run a Rust program and then
bpftrace
with something like:And look at the resulting symbols. I suspect this is related to the
..
characters, but as far as I can tellbcc
just reads symbol names from/proc/kallsyms
.