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