On Tue, Apr 13, 2021 at 8:09 AM Zbigniew Jędrzejewski-Szmek
<zbyszek(a)in.waw.pl> wrote:
On Mon, Apr 12, 2021 at 10:57:30PM +0200, Lennart Poettering wrote:
> On Mo, 12.04.21 16:14, David Malcolm (dmalcolm(a)redhat.com) wrote:
>
> > So I want to push back on the idea that a single package can be
> > associated with a coredump, or be the one responsible for the crash:
> > any or all of the ELF objects linked into the process could be at
> > fault.
>
> The example in the feature page shows how we handle this: you'll see
> the packaging metadata of all involved ELF objects in coredumpctl's
> output. i.e. we should be nicely covered on this, and we are fully
> aware that the "main" ELF objects is the culprit of crashes only in a
> fraction of cases.
This is true.
OTOH, this new metadata doesn't really change the situation here.
Before, we already had build-ids for all the packages "involved" in
the stack trace. And our processing tools already could do the
conversion to package nevras. (They have to have network access to
create a report.) The only thing that changes is *how* this conversion
happens, but for online reports such conversion was always possible.
The new metadata guarantees that the ELF data churns, though. For
example, if I bump the Release in a spec file for something unrelated
to the build, all the ELF blobs change. The current state means that
this is deduplicated in RPM CoW and a very cheap upgrade, since the
binaries weren't all touched.
--
真実はいつも一つ!/ Always, there's only one truth!