On Tue, Apr 13, 2021 at 8:09 AM Zbigniew Jędrzejewski-Szmek zbyszek@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@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.