Converter fails to parse perf.data files with PERF_SAMPLE_REGS_USER & PERF_SAMPLE_STACK_USER sample types. about perf_data_converter HOT 13 CLOSED

The perf.data file is not parsed by the converter as the file contains the PERF_SAMPLE_REGS_USER and PERF_SAMPLE_STACK_USER perf sample types, which are not currently supported by quipper. We will address this error. Will update the issue once it is fixed.

FYI, the dwarf option to the --call-graph flag introduces the PERF_SAMPLE_REGS_USER and PERF_SAMPLE_STACK_USER sample types in the perf.data file. But the --call-graph flag options fp and lbr don't introduce these sample types in the perf.data file.

from perf_data_converter.

I'd like to ping this; more and more systems are compiling sans frame pointers (I disagree with that decision but I don't always get to make it.) Dwarf backtrace support would be of exceptional value.

from perf_data_converter.

@romange Can you attach an example perf.data file?

from perf_data_converter.

@aalexand Of course. Attached https://drive.google.com/file/d/1BeMmVjzDALt4jvdc8JtgEYFB9N5kHSDn/view?usp=sharing

from perf_data_converter.

@lannadorai PTAL

from perf_data_converter.

@lannadorai, should we change the error message in quipper to mention -g dwarf as the likely possible reason?

from perf_data_converter.

@aalexand The error message change would be welcomed; it's possible to work it out if you know perf but not obvious.

Is there any ETA for supporting these sample types (and better yet --call-graph dwarf stacktracing?)

from perf_data_converter.

@ahh No ETA.

from perf_data_converter.

Unlikely we'll work on this soon, but I can review a patch if someone wants to put it together. The support should be off by default to keep the current behavior unchanged.

from perf_data_converter.

from perf_data_converter.

The stack and the register data are potentially PII tainted, we have uses where I'd prefer to keep the current behavior.

from perf_data_converter.

I'm seeing something similar to this, I believe, but I'm unsure how to correct it. It looks like the issue is from PERF_RECORD_TIME_CONV; do you have any docs on which options need to be passed to perf to be compatible with this tool?

$ go tool pprof -web perf.data
Converting perf.data to a profile.proto... (May take a few minutes)
[WARNING:src/quipper/perf_reader.cc:1247] Skipping 104 bytes of metadata: HEADER_CPU_TOPOLOGY
[ERROR:src/quipper/perf_data_utils.cc:484] Non-zero remaining event size 24 received for event PERF_RECORD_TIME_CONV with no varaible payload event data or sample info data
[ERROR:src/quipper/perf_reader.cc:1095] Couldn't get variable payload size for event PERF_RECORD_TIME_CONV
[ERROR:src/quipper/perf_reader.cc:1023] Couldn't read event PERF_RECORD_TIME_CONV
[ERROR:src/perf_data_converter.cc:703] Could not read input perf.data
[FATAL:src/perf_to_profile.cc:33] Expected profile vector to have one element.
perf.data: failed to convert perf.data file. Try github.com/google/perf_data_converter: exit status 1
failed to fetch any source profiles

from perf_data_converter.

PERF_RECORD_TIME_CONV looks like a separate issue, let's not mix it into this one. This bug is about PERF_SAMPLE_REGS_USER and PERF_SAMPLE_STACK_USER which are present in the perf.data file when --call-graph=dwarf is used. This is a dupe of #105. To copy my note from there:

At Google we do not use collection modes that can result in user mode register values to be recorded in the perf.data file. Hence the priority for us to work on this issue is low and we don't anticipate addressing or triaging it further soon.

So I'm closing this bug.

from perf_data_converter.