public inbox for
 help / color / mirror / Atom feed
From: Christian Hergert <>
To: Serhei Makarov <>,
Subject: Re: eu-stacktrace: roadmap and discussion thread
Date: Mon, 8 May 2023 14:50:33 -0700	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

First off, this all sounds great!

I'm not on the mailing list, so apologies if this takes extra-effort to 
show up there.

On 5/8/23 5:33 AM, Serhei Makarov wrote:
> eu-stacktrace will be a utility to process a stream of raw stack
> samples (such as those obtained from the Linux kernel's
> PERF_SAMPLE_STACK facility) into a stream of stack traces (such as the
> ones obtained from PERF_SAMPLE_CALLCHAIN), freeing various profiling
> utilities from having to implement their own backtracing logic.

 From a consumption standpoint, it would be nice if Sysprof could get a 
perf stream where the PERF_SAMPLE_STACK are transparently converted to 
PERF_SAMPLE_CALLCHAIN. I don't think eu-stacktrace necessarily needs to 
speak Sysprof's capture API.

Sysprof already contains `sysprofd` which can open the Perf event stream 
for us via d-bus/CAP_SYS_ADMIN/polkit integration. After Sysprof gets 
the perf FD back from sysprofd we could spawn eu-stacktrace giving it 
the FD to consume and another FD to write the translated/passthrough events.

Sysprof can do offline symbolizing of frames which is somewhat important 
when trying to analyze profiles from an embedded device, a machine that 
is disk/network constrained, or end-user-system via bug reports. We can 
fairly trivially teach Sysprof to do symbolizing via debuginfod.

In the case you're describing, is it right that you may not be able to 
unwind stack frames without debuginfod because there was no way to 
locate the `.eh_frame` section for the binary?

The code to do the mount namespace conversion is quite terrible in 
Sysprof and even now I'm in the midst of cleaning it up. We have to both 
create a "view" of the namespace as it was to the PID as well as a way 
to convert that view into something the mount namespace analyzing the 
capture file might be able to open. Any of these may or may not be in a 
rootless container (toolbox/podman/flatpak/etc).

Whether or not this is something we can eventually contain inside of 
bubblewrap is another can of worms.

Thanks again for all your work on this, I'm very excited to see what we 
can come up with!

-- Christian

  reply	other threads:[~2023-05-08 21:50 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-08 12:33 Serhei Makarov
2023-05-08 21:50 ` Christian Hergert [this message]
2023-05-11 19:27   ` Serhei Makarov
2023-05-15 17:55     ` Christian Hergert
2023-05-09 18:02 ` Milian Wolff
2023-05-11 19:31   ` Serhei Makarov
2024-07-03 14:21 ` eu-stacktrace: roadmap update Serhei Makarov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).