On Mon, Apr 26, 2021 at 12:34 PM Halla Rempt <b...@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
