Is there (going to be) an auto-retracer service for KDE?

Harald Sitter sitter at kde.org
Mon Apr 26 12:07:17 BST 2021


On Mon, Apr 26, 2021 at 12:34 PM Halla Rempt <boud at valdyas.org> wrote:
>
> On Monday, 26 April 2021 11:26:38 CEST Harald Sitter wrote:
> > * get a core instead of a trace - sounds simpler than it is because
> > cores can be huge and network speed may be limited. google's breakpad
> > has a special minidump format that seeks to deal with that, I think
> > apport also has its own reduction format.
>
> I've twice in my life integrated breakpad into software, and it was hell both times.

I did not mean to suggest  that we should use breakpad. In fact my
ephemeral plan, as far as desktop Linux goes, would be to rely on
systemd's coredumpd (drkonqi integration for that is actually what I'm
working on right now). Regardless of "how" the crash gets intercepted
we need a way to send cores over the wire and for that we may need a
better format. Plasma cores are upwards of 50MiB for me, even when
compressed.

> Generating and updating and managing the symbol files was a continuous chore, too.

Luckily distros have that sorted out already ;)

Also going off on a tangent: On windows I understand the store already
has crash tracking and all that stuff implemented, I expect the same
is true for OSX? No idea about android, flatpak and snap though. In
general I would argue that we should rely on the platform crash
tracking systems more. On desktop linux I'd let cores fall into
coredumpd and then fish them out of there. On freebsd and linuxes
without systemd we can simply do what we always did - to drkonqi it
makes no diff if it traces the process or generates a core. Of course
in either case we'd need a way to send and then trace crashes
server-side on our end.

HS


More information about the kde-core-devel mailing list