crash with error: unable to generate a flamegraph from the collapsed stack data

[keepsimple1]

Hardware: Raspberry Pi 4
Flamegraph: 0.4.0

cargo flamegraph crashed when running with default options:

$ cargo flamegraph --bin my_program
<snip>
[ perf record: Woken up 105 times to write data ]
[ perf record: Captured and wrote 26.575 MB perf.data (3303 samples) ]
writing flamegraph to "flamegraph.svg"
thread 'main' panicked at 'unable to generate a flamegraph from the collapsed stack data: Io(Custom { kind: InvalidData, error: "No stack counts found" })', /home/pi/.cargo/registry/src/github.com-1285ae84e5963aae/flamegraph-0.4.0/src/lib.rs:315:6
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

$ ls -l flamegraph.svg
-rw-r--r-- 1 pi pi 611 Oct 11 16:44 flamegraph.svg

It seems to be similar to issue #62 , but I am not using VMs.

[djc]

Have you tried the suggestions mentioned in #62? Might also be worth trying this on the main branch, which has accumulated some fixes. Maybe this is also worth an issue in inferno which is the source of this error.

[keepsimple1]

Thanks! I tried the suggestions in issue #62 , yes no more crashes, although the output seems to be strange.

I used the following -c option:

$cargo flamegraph -c "record -e instructions -c 100 -g"

from perf help record, it seems that the default --call-graph is fp which runs, and if I changed it to --call-graph dwarf, it slows down the application greatly and eventually out of space.

And when I say the output was strange, I meant the flamegraph shows the time mainly consumed in:

in main thread:

• std::sys_common::backtrace::__rust_begin_short_backtrace. (42.72%)
  • nix::sys::select::FdSet::highest (22.90%)
  • <nix::sys::select::Fds as core::iter::traits::iterator::Iterator>::next (16.57%)

in a spawn thread (async runtime: smol-1)

• [perf-25351.map] (18.89%)

What is the [perf-25351.map] ? Is it because I didn't use the proper options and not able to record the actual call stack?

[djc]

I'm not sure I can be of much service here. :( While I'm happy to maintain the code in this crate, I do so mostly as a happy user and not as much as an expert in perf. @jonhoo do you have any suggestions/ideas?

[jonhoo]

Hmm, I would try enabling frame pointers with -C force-frame-pointers=y. It gives you many of the benefits of DWARF without quite as much slowdown during collection. I think what I would also do is collected the perf output into a file so that we can look at what actually gets fed to Inferno in case there's something weird happening there.