GNOME Bugzilla – Bug 362855
Need more information in bug-buddy reports
Last modified: 2007-02-25 10:33:04 UTC
I've been going through a load of nautilus crash reports, and its a pain for me that I can't see the stderr output of the crashed process, as that would show things like assert and warning output. I've written a patch to bug-buddy that displays some more information of the crashing app, including uname output, x server info, selinux status, accessibility on/off and the last lines of ~/.xsession-errors (which typically has the stderr output for apps started outside the terminal).
Created attachment 74867 [details] [review] Output more information about the crashing system
Distribution: Fedora Core release 5 (Bordeaux) Gnome Release: 2.15.90 2006-08-07 (JHBuild) BugBuddy Version: 2.16.0 System: Linux 2.6.16-1.2129_FC5 #1 Thu Jun 1 10:59:33 EDT 2006 i686 X Vendor: The X.Org Foundation X Vendor Release: 70000000 Selinux: Permissive Accessibility: Disabled ----------- .xsession-errors (6 sec old) --------------------- localuser:alex being added to access control list No profile for user 'alex' found SESSION_MANAGER=local/localhost.localdomain:/tmp/.ICE-unix/4104 Window manager warning: "f12" found in configuration database is not a valid value for keybinding "run_command_1" Debug: Loading Beagle.Util.Conf+IndexingConfig from indexing.xml Debug: Loading Beagle.Util.Conf+DaemonConfig from daemon.xml Debug: Loading Beagle.Util.Conf+SearchingConfig from searching.xml ** (eggcups:4197): WARNING **: IPP request failed with status 1030 Debug: Loading Beagle.Util.Conf+NetworkingConfig from networking.xml Debug: Loading Beagle.Util.Conf+WebServicesConfig from webservices.xml Introspect error: The name edu.duke.linux.yum was not provided by any .service files Unable to connect to yum-updatesd... Initializing nautilus-open-terminal extension -------------------------------------------------- Memory status: size: 131596288 vsize: 0 resident: 131596288 share: 0 rss: 36655104 rss_rlim: 0 CPU usage: start_time: 1161091178 rtime: 0 utime: 550 stime: 0 cutime:470 cstime: 0 timeout: 80 it_real_value: 0 frequency: 0 Backtrace was generated from '/gnome/head/INSTALL/bin/nautilus' Using host libthread_db library "/lib/libthread_db.so.1". `shared object read from target memory' has disappeared; keeping its symbols. [Thread debugging using libthread_db enabled] [New Thread -1208961344 (LWP 24952)] 0x00970402 in __kernel_vsyscall ()
+ Trace 76787
Comment on attachment 74867 [details] [review] Output more information about the crashing system <snip> >+ /* Selinux checks */ >+ has_selinux = FALSE; >+ if (g_file_get_contents ("/proc/filesystems", &str, NULL, NULL)) { >+ has_selinux = strstr (str, "selinuxfs") != NULL; >+ g_free (str); >+ } >+ if (has_selinux) { >+ enforcing = TRUE; >+ if (g_file_get_contents ("/selinux/enforce", &str, NULL, NULL)) { >+ enforcing = strcmp (str, "0") != 0; >+ g_free (str); >+ } >+ g_string_append_printf (system_info, "Selinux: %s\n", enforcing?"Enforcing":"Permissive"); >+ } else { >+ g_string_append_printf (system_info, "Selinux: No\n"); >+ } <snip> >+ if (g_file_get_contents ("/proc/filesystems", &str, NULL, NULL)) { >+ has_selinux = strstr (str, "selinuxfs") != NULL; >+ g_free (str); >+ } You check twice for has_selinux. The second one isn't used.
Created attachment 74868 [details] [review] Fixed selinux check
a major issue to improve the speed of getting required information and of fixing bugs, as with some of the current nautilus showstoppers...
Will this addition to bugbuddy still allow people to view the data before it is sent? .xsession-errors may contain sensitive information for some people.
One thing that came to my mind while reading this bug: If some part of .xsession-errors contains sensitive information, then I would regard this as a bug of the corresponding product. So if you show the output to the user (which is good IMHO), there could just as well be a little button to create a report for it, where the user can strip off the sensitive parts and complain. But that should not stop you to get that change in ASAP :-D
Sure, all the data will be in the (expandable) details textview in the bug-buddy UI. This is the same text field that has the backtrace info, which has similar problems (i.e. it can also contain sensitive information).
There is one partially related bug 346779 on marking error and warning messages translatable. Your input (as maintaners) would be valuable ;)
I added this patch to a Fedora Core 6 update, since i really need this info for some bugs. Any chance Ubuntu could do the same?
I'll do the same for Ubuntu
humm, so you guys think that I should commit it to bug-buddy before branching to gnome-2-16?. My plan was committing it after branching.
anything that provides more and better information to fix bugs quicker is most welcome, as this reduces the amount of time that needs to be spent for triaging. i vote for getting this in as quickly as possible, since it does not introduce any new user-visible strings or UI breakage.
Comment on attachment 74868 [details] [review] Fixed selinux check >+ gconf_client = gconf_client_get_default (); >+ a11y = gconf_client_get_bool (gconf_client, ACCESSIBILITY_KEY, NULL); >+ g_object_unref (gconf_client); >+ g_string_append_printf (system_info, "Accessibility: %s\n", a11y?"Enabled":"Disabled"); After GNOME 2.17 this is not true anymore, because if the user has not set the key (ignoring the schema default) we should have a11y enabled in every odd minor version of the desktop. We should check that here too, or maybe getting the env variable GTK_MODULES
Fernando: There were other problems with that a11y enabling change, so it might be changed. See desktop-devel-list.
yes I am aware of it, I wrote the patch for libgnomeui changin the schema :) So I think the patch is ok now :)
The current patch must limit the length of a line. Mplayer uses '\r' as a line separator and prints a line per (IIRC) frame. Meaning that this patch causes bugreports with >100KB of useless crap. Separating lines on '\r' as well as '\n' probably is also a good thing, but the patch should still be very careful with how much data is attached. Further, I think the stack trace should be one of the first things in a bugreport; not stderr output.
Created attachment 76258 [details] [review] New version This version has stderr on end and limits line lenghts. Look ok?
Thanks a lot for the patch. Applied to HEAD before branching for gnome-2-16, so it would be included on bug-buddy 2.16.1 2006-11-11 Fernando Herrera <fherrera@onirica.com> * src/bug-buddy.c: (known_app_finished), (unknown_app_finished), (fill_system_info), (fill_stderr_info), (main): Add more info to bug-buddy reports, including: - A11y enabled or not - uname full info - selinux enabled or not - .xsession-errors last lines Patch by Alexander Larsson. Fixes bug #362855
@fer: <andre> seb128: feisty traces (e.g. bug 410892) seem to have the .xsession-errors output in front of the trace, which is bad - bug 362855 comment 18/19 fixes this and should have been part of bug-buddy since 2.16.1, that's why i wonder why this happens on feisty? <seb128> andre: we have bug-buddy 2.17.3, maybe that was not fixed to 2.17 or no 2.17 tarball has been rolled since? <andre> (and bug-buddy 2.17.3 was released after 2.16.1) <seb128> dunno then <seb128> we don't patch bug-buddy <seb128> must be bugged <andre> according to fer: "Applied to HEAD before branching for gnome-2-16, so it would be included on bug-buddy 2.16.1" <seb128> feel free to open a bug on bug-buddy bugzilla <seb128> might be a problem witht python bug-buddy integration maybe <seb128> some for the gnome-python-* got bug-buddy glue <seb128> and it seems to work differently from the standard bug-buddy signal handler <seb128> because feisty doesn't use bug-buddy, we use apport
bug 346106 explains that gnome-python-desktop-2.17.2 includes a fix for better bug-buddy integration for python apps, but feisty already ships python-gnome2-desktop-2.17.3-0ubuntu3. so we still don't exactly know...
It is not that .xsession-errors are in top of the report, it's that included files at at the bottom of the report. python execeptions are reported to bug-buddy using --include option, so that info comes at the end of the report. Maybe what you want is that "--include" information should be in some specific place. I have open bug #411840 for this, please, comment on that one