GNOME Bugzilla – Bug 350221
Include assertion message in g_{assert,critical} bugs
Last modified: 2008-10-01 12:28:04 UTC
It would be useful if when reporting "crashes" caused by g_assert* or g_critical with the fatal option, bug-buddy would include the assertion message in the bug it files.
The asserting message is already present on the stack trace (a little hard to read because of the c-style formatting) and quite possible in the newly included .xsession-errors
Unfortunately the message is generally only present in the stack trace if the user had glib debug symbols available. Having the message available when they don't have debug symbols would be very nice, as the majority of the time when the message would be useful is for people without symbols. Of the recent assertions bugs I've seen filed, the .xsession-errors log very rarely contains the message.
I think this is a good idea and probably can be done playing with g_log_set_handler. I will try to come up with a patch soon.
Created attachment 119452 [details] [review] patch Here's the patch, it works fine. The only doubt I have is about the placement of the warnings in the report (right now they are placed before the stack trace) and about the usefulness of .xsession-errors. I will mail gnome-bugsquad to gather feedback for this before committing.
How does it look? Make sure we can process it so it's easy to hook it with simple dup search and similar. I can't honestly tell how correct the patch is, but looks good to me, visually at least :p.
> of the warnings in the report (right now they are placed before the stack > trace) and about the usefulness of .xsession-errors. Place them at the end, just before any .xsession-errors. Putting them at the beginning will make it harder to use simple-dup-finder.
I'd been meaning to play with doing something like this for a while. Is there anything that limits the size of the logged message buffer? It doesn't seem like there is, looking at your patch. You should consider using a ring buffer to log these messages, as suggested here: http://www.gnome.org/~federico/news-2006-10.html#05 With this change, you might want to consider logging all messages, not just the critical ones. It's more likely that you're going to care about a recent non critical message than an ancient critical one.
William, thanks for the suggestion; I implemented a ring buffer of 15 slots to handle the critical and fatal warnings. I'll leave the other messages out for now. Also, I moved the files included with the --include option down after the stacktrace. Closing as FIXED. 2008-10-01 Cosimo Cecchi <cosimoc@gnome.org> * gnome-breakpad/gnome-breakpad.cc: * src/bug-buddy.c: (unknown_app_finished), (fill_custom_info), (main): Implement a logger for critical and fatal warnings, which will be included in the bug report sent to bugzilla (#350221). This also moves the files included with the --include option down at the bottom of the stacktrace (if present). * src/gnome-crash.c: (main): Update the test to contain a critical warning.