GNOME Bugzilla – Bug 388441
create minidump files for crashes
Last modified: 2008-08-31 21:38:00 UTC
If there is no gdb installed on the system, or the crashing program has not debug symbols, then libgnomeui should dump a minidump file and invoke bug-buddy with that file, so bug-buddy can send it to the debugserver, enrich it with a nice stacktrace and send it back to bugzilla.
Created attachment 78764 [details] gnome airbag C wrapper, 1st version Notice that google's airbag linux support has not yet landed, so you need to manually apply last patch in issue 100: http://code.google.com/p/airbag/issues/detail?id=100&can=2&q=
Created attachment 78765 [details] [review] Patch for libgnomeui to use gnome-airbag wrapper, 1st version
humm, maybe we could implement this as a GTK_MODULE instead...
Ok, much cleaner the GTK_MODULES approarch, and then libgnomeui is not depending on libstdc++/airbag. Now bug-buddy can itself install the .so file to be loaded though gnome-session Patch coming.
Created attachment 78767 [details] [review] support for the new directory in bug-buddy
Created attachment 78769 [details] libgnomeairbag.so GTK_MODULE implementation This module install an airbag seghandler. When something crashes it does: - Release keyboard/display grabs - If GNOME_HACKER and gdb --> run gnome-terminal with gdb and finish - If gdb && bug-buddy && debug_symbols --> run bug-buddy in the old (gdb) way - If none of above --> dump a minidump file TODO: invoke bug-buddy with the minidump file
After some comments from Olav and jrb we should not rely on gnome-session to set up the env variable GTK_MODULES. A better approach would be to hack gtk+ to support some special dirs containing modules that should be always loaded.
People are getting annoyed with the number of crash reports on Bugzilla, with many simply ignoring it in favour of mailing lists due to the sheer volume of noise. I think maybe crash reports should be directed elsewhere and "promoted" to bugzilla by some other means. This way, outdated software can continue to crash and be logged on the crash server, long after the bug is fixed. Perhaps we could reject the report if the user's software is so old it is unsupported, and the client software can report back to the user that this is the case. Pie in the sky.
Quoting Mattias: Whats the problem with using the Gtk/Modules XSetting that was invented especially for this purpose ? Can we apply this or #449733?
Done ;)
OK. So we have a mostly useless crash.gnome.org installation that is already in use and receives hundreds of bug reports, and nobody gives a fuck because it is mainly unusable, missing debug info for nearly every distribution, more or less unmaintained, and deployed in an untested state. I've at least ask for documentation a few times before GNOME 2.22.0 was released, and nothing has happened. Now either tell me how to switch off that feature in bug-buddy so we don't lose even more user information, or properly define a process how distros can submit debug info into the crash.gnome.org system and how to properly identify and check for major issues for showstopper reports. Having two systems in parallel is just crap from a QA/controlling POV. Thanks.
No reason for this to stay opened.