Lennart Poettering wrote:
> I understand you are not working with backtraces/coredumps every
> day.
For core dumps, this is true. (I have found those to not be of much use,
other than getting a backtrace, but I would rather just get the backtrace
directly.) For backtraces, it is not. I regularly look a backtraces. Often
my own ones, but sometimes also those submitted by users.
> But as someone who's at the upstream receiving end of bug reports of one
> major project I can tell you that MiniDebugInfo is literally the best
> thing since sliced bread: in systemd upstream the bug reports we get from
> Fedora are *ridiculously* more useful than bug reports from any other
> distro, since the default way how things are reported already carry
> backtraces that are quite useful.
This does not match my experience at all. I find MiniDebugInfo backtraces to
be only marginally more useful than backtraces with no debugging information
at all (and incidentally, at least last I checked, the backtrace quality
rating algorithms in both ABRT and DrKonqi happen(ed) to agree with me and
will (would?) ask the user to install the full -debuginfo anyway).
Those backtraces have:
* no line numbers and
* no function argument values
so there is little to no clue where exactly it crashed nor under what
conditions. (Are your functions so small that you can figure out the exact
location of the crash from the function name alone?)
And if the crash is in a shared library (which it often is), in an exported
function (which crashes in a shared library often are), then even the
backtraces with no debugging information will tell you the function in which
the crash happened. (Of course, this is not the case if the crash is in some
out-of-process systemd-foo executable.) So there are several cases where
MiniDebugInfo adds no value at all.
> It's a complete mess with other distros, since we have to ask people to
> come back with proper backtraces with debuginfo installed, and only a
> subset of people is willing to bother with that. Bug reports from
> ArchLinux, Debian, Gentoo and so on are total crap by default compared to
> Fedora.
Well, the issue on ArchLinux is that they do not ship -debuginfo packages at
all. So the user has to recompile the package with debugging information,
which unsurprisingly they will not be willing to do in most cases. And
Gentoo obviously requires recompilation as well because (almost) everything
gets compiled on the user's machine to begin with.
> So if you are going to dump shit on MiniDebugInfo like you are doing then
> what I hear is that you just have no clue with working and maintaining
> software upstream.
I take offense at this assertion.
> (And I understand that mrqonki or what's it called
DrKonqi:
* Dr as in Doctor (because it diagnoses programs just like a medical doctor
diagnoses patients),
* Konqi as in the mascot of KDE (a dragon named after the browser and file
manager Konqueror that used to be the flagship application of KDE).
> is your holy grail of crash reporting, but I find it entirely
> uninteresting since it's in no way set up for doing system-level
> backtraces, run during early boot or anything like that.
True, DrKonqi will only work if you have X11 or Wayland already running.
> It might be OK for app crash dumps if it actually works, but we are not
> just building apps here, we are first and foremost *OS* builders, and
> something that can't handle system level stuff properl is just not
> relevant then.
Now it is you who are assuming that everyone only works with what you are
familiar with. Large parts of our operating system are user-level
applications that either always run in or can be run in a desktop session.
> That said, running back trace processors in-process or even just with user
> creds like mrqonki is doing it apparently
The way DrKonqi works is that there are actually 2 separate components:
KCrash and DrKonqi:
* KCrash is the in-process crash handler. It is shipped in a shared library
(the "KDE Framework" KCrash, one of the several "KDE Frameworks"). It is
just a small signal handler that does not do much, basically just:
- fork,
- pause/halt the parent fork, waiting for GDB to attach,
- exec DrKonqi in the child fork, passing the PID for it to attach GDB to.
* DrKonqi is the out-of-process crash reporter. It gets launched by KCrash
as explained above. It brings up a GUI dialog showing what application
crashed and where to report bugs to. It also attaches GDB to the crashed
process and shows the backtrace in a text field in the GUI. It also offers
to install missing debugging information through a shell script shipped with
it. And it can automatically upload reports to the bugs.kde.org Bugzilla.
> is a really bad idea anyway: if an app has crashed, its memory is fucked
> then you don't want to run code inside it and you want to process its
> coredump tightly sandboxed with the least privs possible — something
> systemd-coredump does btw)
The vast majority of the KCrash/DrKonqi code actually runs out of process,
in the out-of-process DrKonqi executable (or in the again separate GDB
executable). The in-process KCrash is only the minimum needed to intercept
the crash and attach DrKonqi (technically, the GDB launched by DrKonqi) to
it. And the GUI application DrKonqi also does not process the crashed
application in process, but spawns a GDB process for it. So there are three
separate processes.
Sure, it is not the level of sandboxing you can get with core dumps, but it
is much more efficient because you do not have to copy (dump) the whole
process memory somewhere (assuming your fork() implementation has working
CoW, but that is a given on GNU/Linux).
> Software maintainability *matters*. And yes, a few 100K on a distro
> install are a very cheap price to pay for this.
Sorry, but I do not see those "MiniDebugInfo" and "package information"
features as helping me maintain software in any way.
Kevin Kofler
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
