On Sat, Apr 10, 2021 at 9:55 AM Michael Catanzaro <mcatanzaro(a)gnome.org>
wrote:
On Sat, Apr 10 2021 at 08:03:09 AM -0400, Owen Taylor
<otaylor(a)redhat.com> wrote:
> Did you notice that it also works for the Fedora Flatpaks (thanks,
> Frank!) - basic proof of concept:
>
> $ flatpak run --command=sh --filesystem=home --share=network --devel
> org.gnome.Aisleriot
> [📦 org.gnome.Aisleriot ~]$
>
DEBUGINFOD_URLS=https://debuginfod.stg.fedoraproject.org/
> DEBUGINFOD_CACHE_PATH=~/.cache/debuginfod_client gdb /app/bin/sol
>
> (Without the --filesystem=home and DEBUGINFOD_CACHE_PATH, the cache
> ends up in ~/.var/app/org.gnome.Aisleriot/cache/debuginfod_client/)
I think that's OK for a manual debugging workflow, since it's pretty
rare to want to do that under flatpak in my experience. Normally what's
most important to me is being able to easily generate a backtrace for a
previous crash using 'flatpak-coredumpctl'. Ideally
'flatpak-coredumpctl' would handle setting the right environment
variables and executing flatpak with the right permissions to make it
work. (In the future, ABRT could do something similar.)
I think we could store the debuginfo urls in repository metadata (ostree
summary / oci json index) and have flatpak automatically set things up for
'flatpak run --devel'. This isn't Fedora specific - e.g. there's an
eventual goal to have a debuginfo server for Flathub as well.
For coredump+debuginfod you can actually do the backtrace with a system (or
toolbox) gdb instead of downloading the SDK ... if we want to deal with
that complexity, we could add a mode like that into flatpak-coredumpctl.
One gap here is that it's a little hard to figure out what exact revision
of the Flatpak and runtime coredumped - you can reverse-engineer that out
of COREDUMP_PROC_MOUNTINFO information in the journal.
As you say, the eventual goal would be ABRT support.
Regards,
Owen