Profiling with Ctrl-C

Post by dzaima » Wed, Sep 04, 2024, 9:38 PM UTC

dooglius wrote: post #40

dzaima wrote: post #6

Earlier quoted context omitted.

I believe this is essentially what linux perf's "--call-graph dwarf" does. On my system that ends up producing ~33MB/s of recording data for ~4000 samples/s.

There are still issues with perf being unable to parse the debug format for some stuff, e.g. code compiled with `-ggdb3` as touched on in TFA. The idea is more: can I take one of the stacks that perf captured, and hand that off to GDB for a stack trace, without perf trying to parse/interpret it itself?

perf's produced perf.data is a documented file format that you can parse manually if so desired, and does in fact directly store the 8KB of stack data (or whatever configured) & register values in the "dwarf" mode.

Post by roca » Sun, Sep 08, 2024, 8:07 AM UTC

bogdan-lab wrote: post #34

dzaima wrote: post #2

For something more systematic/reproducible, it's possible to use rr[1] to record the program, and in a replay run to the end (or whatever boundaries you care about), run "when-ticks", and do various "seek-ticks 123456789" below that number to seek to various points in the recording. I've made a thing[2] that can display that within a visual timeline (interpolated between ticks of the nearest syscalls/events, which do…

rr looks interesting. It should be useful for debugging race conditions or something "random based": once you record the issue it becomes 100% reproducible in your debugger. Will try it next time when I have such issue. Thank you!

If you do try doing that, use rr's "chaos mode".

Re: Profiling with Ctrl-C

Re: Profiling with Ctrl-C