Bug 202051

Summary:	perf OOMs very easily while processing a profile recorded with --call-graph dwarf
Product:	Tracing/Profiling	Reporter:	Emilio Cobos Álvarez (:emilio) (emilio)
Component:	Perf tool	Assignee:	Arnaldo Carvalho de Melo (acme)
Status:	NEW ---
Severity:	normal	CC:	emilio, jolsa
Priority:	P1
Hardware:	All
OS:	Linux
Kernel Version:	4.20.0-0.rc6.git2.1.fc30.x86_64	Subsystem:
Regression:	No	Bisected commit-id:

Description Emilio Cobos Álvarez (:emilio) 2018-12-23 20:51:34 UTC

Which is somewhat unfortunate, because the other call graphs end up being quite useless.

STR:

 * git clone https://github.com/rust-lang/rust-bindgen
 * cd rust-bindgen
 * RUSTFLAGS="-g" cargo build --release
 * perf record --call-graph dwarf ./target/release/bindgen tests/stylo.hpp --no-rustfmt-bindings >/dev/null 2>&1
 * (wait about five seconds or so)
 * perf report (or perf script, or anything else really)

Expected:

 * See a profile.

Actual:

 * OOM.

The only way I managed it to not OOM is using -F 5, which is obviously not enough resolution to get anything useful.

This may be a rust compiler bug, I guess, though I've tried with quite a few different Rust compiler versions, plus debugging the executable with GDB works just fine. Something seems to be blowing up very badly in perf itself.

As I write this, I tried with -i and it significantly reduces memory usage, to the point where I can actually take a profile with perf record -F 100 --call-graph dwarf.

Still I cannot get a profile without OOMing my 16GB of RAM with the default frequency.

I'm fine if the answer to this report is a WONTFIX, or a "you just need more RAM", or such, but maybe there's something to be improved on perf's side here?

Comment 1 Emilio Cobos Álvarez (:emilio) 2018-12-24 02:29:33 UTC

> Which is somewhat unfortunate, because the other call graphs end up being
> quite useless.

FWIW this is a bit of a lie, lbr seems to work fine.