GNOME Bugzilla – Bug 648423
Support G_DEBUG=trap-warnings
Last modified: 2011-04-28 18:55:48 UTC
This is a much nicer facility than fatal-warnings for the interactive debugging case, because it allows you to step through all warnings, rather than having the process abort() on the first one. Particularly useful for the case where your app emits a warning you don't care about from code you don't want to change right now.
Created attachment 186453 [details] [review] Support G_DEBUG=trap-warnings
So to work around this deficiency in fatal-warnings, i've traditionally done break g_logv if log_level != G_LOG_LEVEL_DEBUG but this seems nicer than that. On the other hand, SIGTRAP is a fatal signal by default, I believe. So, I guess, if the app isn't running in a debugger, this new feature is largely equivalent to fatal-warnings. Maybe it would make sense to change fatal-warnings to G_BREAKPOINT() instead of abort() ?
(In reply to comment #2) > Maybe it would make sense to change > fatal-warnings to G_BREAKPOINT() instead of abort() ? I think I agree largely - except one detail is that crash catchers will need to know to handle SIGTRAP too (ABRT didn't, I submitted a patch that only recently got added). The only other thing I can think of is that if some insane app was catching SIGABRT (emacs is known to do this) it will no longer be getting it here. That's probably OK.
Yeah, I think I would prefer to make fatal-warnings work as we want it over adding yet another variant.
Created attachment 186672 [details] [review] Use SIGTRAP (via G_BREAKPOINT()) if G_DEBUG=fatal-warnings On Linux with gdb, it's much more convenient to debug programs using G_DEBUG=fatal-warnings if we send SIGTRAP instead of abort() by default. The default handler for both is to terminate the process. In particular this makes it more easily possible to debug a warning that's not the first in a program; you can skip past it and go to the warning you care about. The "aborting..." message is removed since it's no longer accurate, and anyways was never very useful; crashes should show up in ABRT/apport type crash catching systems.
Looks ok to me. Looking at G_BREAKPOINT, I wonder why we not always just raise SIGTRAP - any idea ?
Review of attachment 186672 [details] [review]: splinter-required filler text
(In reply to comment #6) > Looks ok to me. Looking at G_BREAKPOINT, I wonder why we not always just > raise SIGTRAP - any idea ? maybe so it still breaks if the program does signal (SIGTRAP, SIG_IGN) or something? not sure actually. I thought it did just raise(SIGTRAP) under the covers.
(In reply to comment #8) > I thought it did just raise(SIGTRAP) under the > covers. Nope, look at the implementation - e.g. it's asm ("int $03") on intel.
Comment on attachment 186672 [details] [review] Use SIGTRAP (via G_BREAKPOINT()) if G_DEBUG=fatal-warnings Anyway, the question of fixing G_BREAKPOINT doesn't have to delay this
Attachment 186672 [details] pushed as a04efe6 - Use SIGTRAP (via G_BREAKPOINT()) if G_DEBUG=fatal-warnings