6

When a C/C++ application fails with the following CRITICAL, can you please tell me how can I find out where is the code causing the error?

I have tried to run it in the debugger, trying to do a 'bt when the program fails. But it does not show where is the code causing the CRITICAL:

(process:3155): GLib-GObject-CRITICAL **: /build/buildd/glib2.0-2.22.3/gobject/gtype.c:2458: initialization assertion failed, use IA__g_type_init() prior to this function

(process:3155): GLib-CRITICAL **: g_once_init_leave: assertion `initialization_value != 0' failed

(process:3155): GLib-GObject-CRITICAL **: /build/buildd/glib2.0-2.22.3/gobject/gtype.c:2458: initialization assertion failed, use IA__g_type_init() prior to this function

(process:3155): GLib-GObject-CRITICAL **: /build/buildd/glib2.0-2.22.3/gobject/gtype.c:2458: initialization assertion failed, use IA__g_type_init() prior to this function

(process:3155): GLib-GObject-CRITICAL **: /build/buildd/glib2.0-2.22.3/gobject/gtype.c:2458: initialization assertion failed, use IA__g_type_init() prior to this function

(process:3155): GLib-GObject-CRITICAL **: g_type_add_interface_static: assertion `G_TYPE_IS_INSTANTIATABLE (instance_type)' failed

(process:3155): GLib-GObject-CRITICAL **: /build/buildd/glib2.0-2.22.3/gobject/gtype.c:2458: initialization assertion failed, use IA__g_type_init() prior to this function
Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
michael
  • 106,540
  • 116
  • 246
  • 346
  • possible duplicate of [how to get GDB to break on a glib assertion failure?](http://stackoverflow.com/questions/5785902/how-to-get-gdb-to-break-on-a-glib-assertion-failure) – ptomato Apr 26 '11 at 08:14

3 Answers3

7

You should pass --g-fatal-warnings to your application when you run it inside gdb.

bratsche
  • 2,666
  • 20
  • 23
  • 1
    Yes it does. With fatal warnings enabled the first call to g_warning() or g_critical() will abort, allowing you to debug using gdb or lldb. – bratsche May 23 '15 at 18:17
  • 1
    I tried it just before sending the comment. I was having a lot of problems in glib. It didn't halt. I have corrected those errors now, and it's not easy to test again. If I can find a situation where it returns, I'll post the results. I would really be happy if I could get it working - it is a very practical option. – jcoppens May 23 '15 at 19:29
  • 2
    Try setting the environment `G_DEBUG=fatal_warnings` when you run your program instead. – bratsche May 26 '15 at 14:20
6

You can break on g_log and then do a backtrace from there.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
ptomato
  • 56,175
  • 13
  • 112
  • 165
  • how can I break on g_log? I don't know what file/line number of g_log since I did not compile gtk/glib library myself? Thank you. – michael Mar 15 '10 at 20:28
  • 2
    Your debugger should allow you to break on a function name. For example, in gdb, type `break g_log`. Depending on your system, you may need to install some "debug" package, for example `glib-debuginfo` on Fedora. Often it is already installed automatically. – ptomato Mar 15 '10 at 21:56
2

I think it does show where it is causing the problem (deeper in the stack trace):

(gdb) bt
#0  0x00da5422 in __kernel_vsyscall ()
#1  0x00c70e15 in pthread_cond_wait@@GLIBC_2.3.2 ()
    at ../nptl/sysdeps/unix/sysv/linux/i386/i686/../i486/pthread_cond_wait.S:122
#2  0x008a5800 in g_once_init_enter_impl () from /lib/libglib-2.0.so.0
#3  0x00800e36 in g_initially_unowned_get_type ()
   from /usr/lib/libgobject-2.0.so.0
#4  0x00271f15 in gtk_object_get_type () from /usr/lib/libgtk-x11-2.0.so.0
#5  0x0036aa4c in gtk_widget_get_type () from /usr/lib/libgtk-x11-2.0.so.0
#6  0x001b8485 in gtk_container_get_type () from /usr/lib/libgtk-x11-2.0.so.0
#7  0x0031b3b5 in gtk_toolbar_get_type () from /usr/lib/libgtk-x11-2.0.so.0
#8  0x0031d717 in gtk_toolbar_new () from /usr/lib/libgtk-x11-2.0.so.0
Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
michael
  • 106,540
  • 116
  • 246
  • 346