7

I have to debug a program which is heavily dependent on Gtk. The issue is that for some reason a lot of runtime warnings have started appearing when working with GtkWindow objects. The problem is, even though Gtk complains of critical errors, it does not abort on these errors. I don't have the change history for the code base so my only option seems to be to wade though all gtk calls which seem suspect and see where the problem is. If however, I can somehow cause Gtk to abort on this error, I can run it with gdb and try to get the backtrace and locate the exact position of the error. Any idea how this can be done?

GLib-GObject-WARNING **: invalid uninstantiatable type `<invalid>' in cast to `GObject'
GLib-GObject-CRITICAL **: g_object_get_data: assertion `G_IS_OBJECT (object)' failed
GLib-GObject-WARNING **: invalid uninstantiatable type `<invalid>' in cast to `GObject'
GLib-GObject-CRITICAL **: g_object_get_data: assertion `G_IS_OBJECT (object)' failed
GLib-GObject-WARNING **: invalid uninstantiatable type `<invalid>' in cast to `GObject'
GLib-GObject-CRITICAL **: g_object_get_data: assertion `G_IS_OBJECT (object)' failed
341008
  • 9,862
  • 11
  • 52
  • 84

2 Answers2

14

I am collecting the methods Matt mentioned and the one I found out to provide the complete answer here. I will mark it as the chosen answer and up-vote Matt's answer.

Three ways to force gtk to agort on error:

  1. G_DEBUG=fatal_warnings ./myprog ...
  2. ./myprog -prog-args --g-fatal-warnings
  3. Use g_log_set_handler, and/or g_log_default_handler and provide a GLogFunc of your own design that aborts based on the GLogLevelFlags passed to it for each message.

I should also mention g_log_set_always_fatal(G_LOG_LEVEL_CRITICAL|G_LOG_LEVEL_WARNING); to make the list complete even though "always fatal" is not what I was looking for.

341008
  • 9,862
  • 11
  • 52
  • 84
5

Use g_log_set_handler, and/or g_log_default_handler and provide a GLogFunc of your own design that aborts based on the GLogLevelFlags passed to it for each message.

void abort_on_g_log(
    const gchar *log_domain,
    GLogLevelFlags log_level,
    const gchar *message,
    gpointer user_data)
{
    if (log_level & G_LOG_LEVEL_CRITICAL) abort();
    g_log_default_handler(log_domain, log_level, message, user_data);
}

Update0

If you're happy having glib terminate for you, you can use:

g_log_set_always_fatal(G_LOG_LEVEL_CRITICAL|G_LOG_LEVEL_WARNING);

or run with G_DEBUG=fatal_warnings ./myprog ... if glib is correctly configured, see here for more.

Matt Joiner
  • 112,946
  • 110
  • 377
  • 526
  • Isn't there a command line switch which causes gtk to abort on critical failures? – 341008 Jan 10 '11 at 12:27
  • @341008: I was under the impression that glib's message logging allowed command line parameter overloads too, but I have never been able to find them. The short answer is no, it does provide some defaults regarding stdout and stderr through compile flags however, as well as glib's own fatality mask, which I'll add above. – Matt Joiner Jan 10 '11 at 12:35
  • Found the following `--g-fatal-warnings. Make GTK+ abort on all warnings.` in the gtk reference manual (http://library.gnome.org/devel/gtk/unstable/gtk-running.html). Will check if it does what I want. – 341008 Jan 10 '11 at 12:41
  • Hmm, well I was answered for Glib, I see that you have tagged Gtk+, the two are related but not the same thing. – Matt Joiner Jan 10 '11 at 14:29