No data from the proto profile?

[jabley]

Thus far unable to get a nice small example. What I do have is at https://github.com/jabley/monkeyinterpreter/tree/feature/pprof

In jabley/monkeyinterpreter@fabd13c, I tried to add pprof-rs to see what it showed me. The current answer is: very little, and I'm not sure what I'm doing wrong.

I'm very new to Rust. That codebase is my first attempt to write something in Rust. I've added pprof-rs and when I run the binary, I don't get a lot of data.

> cargo run --bin vm-flamegraph --release -- -p profile.pb
        Finished release [optimized + debuginfo] target(s) in 0.38s
         Running `target/release/vm-flamegraph -p profile.pb`
    Result: 9227465
    report: THREAD: ThreadId(4437034432) 2763

That takes about 25 seconds to run on my hardware.

I was expecting to see more in the report which is dumped out by:

guard.and_then(|guard| -> Option<()> {
        if let Ok(report) = guard.report().build() {
            let mut file = File::create(matches.value_of("cpuprofile").unwrap()).unwrap();
            let profile = report.pprof().unwrap();

            let mut content = Vec::new();
            profile.encode(&mut content).unwrap();
            file.write_all(&content).unwrap();

            println!("report: {}", &report);
        };

        None
    });

I've tried with both debug and release builds and get the same output. This is on MacOS using cargo 1.44.1 (88ba85757 2020-06-11) and rustc 1.44.1 (c7087fe00 2020-06-17)

When I then try viewing the protobuf file using go tool pprof, there isn't the expected amount of data and call-stacks that I was hoping for.

What am I missing? Very happy to be pointed at how to get more information which would help you understand this.

Aside

I also occasionally get "Illegal instruction: 4". This could definitely be a bug in my code, but that string isn't in my code, and I'm not sure where it's coming from.

> cargo run --bin vm-flamegraph --release -- -p profile.pb 
    Finished release [optimized + debuginfo] target(s) in 0.24s
     Running `target/release/vm-flamegraph -p profile.pb`
Illegal instruction: 4
> echo $?
132

I'd never seen this behaviour until I added pprof-rs. Could just be I'm lucky like that!

[YangKeao]

I have tried to get the profile on my Linux machine. You can download it here and verity whether it's correct.

I belive the illegal instruction should be an issue in rust (though I don't know whether it has connection with existing bugs such as #58340) as I don't write any pure instructions or binary codes. To indentify this problem, a backtrace or coredump will help a lot.

However, pprof-rs is expected to work correctly on Mac. @Hexilee can you help me on this issue (as I don't have a mac 😿 ) ?

[Hexilee]

@jabley Hello, I cannot reproduce this issue on my macOS.

I get the profile on
cargo 1.44.1 (88ba85757 2020-06-11) and rustc 1.44.1 (c7087fe00 2020-06-17) by cargo run --bin vm-flamegraph --release -- -p profile.pb.

Are you sure your reproducing steps are correct?

[jabley]

On a different Mac, I've just done:

> git clone git@github.com:jabley/monkeyinterpreter.git
> pushd monkeyinterpreter
> git checkout feature/pprof
> pushd rust/rmonkey/
> cargo run --bin vm-flamegraph --release -- -p profile.pb
Result: 9227465
report: THREAD: ThreadId(4757824960) 2000

I get the same 26 byte profile.pb output file as described in my original report.

I can run the examples from pprof-rs and get usable profiles produced.

@Hexilee, your profile looks like what I'd expect.

[sticnarf]

I try your code on my 10.14.6 macOS with the same toolchain and can get the profile successfully. @Hexilee uses macOS 10.15.
We have no idea how to reproduce the issue.

[kjvalencik]

I'm having this same issue on macOS 11.0.1. Have you had any success identifying the issue? I appear to only have the issue with --release.

I'm on v1.50.0-nightly.

Edit: Compiling with --release and debug = true works.

[YangKeao]

@kjvalencik AFAIK, debug = false will also keep the symbol information, unless it has been stripped explicitly. Would you mind to check whether the symbol information exists in the binary compiled with debug = false?

nm ./target/release/examples/xxx could be used to print the symbol information. If it has been stripped, the output would be nm: ./target/release/examples/xxx: no symbols. (However, I don't know whether Mac OS has nm command).

I heard that @sticnarf has got a new Mac OS laptop 🍻 . Maybe he could help us to find the problem.

[kjvalencik]

@YangKeao I had symbols in both, but I had 7 more when compiling with debug = true.