views:

118

answers:

2

I am writing a plugin for audacious, and I am experiencing random segfaults. I looked around and I found that I can process the program's core dumps with gdb.

So I did that, and I got this output:

http://pastebin.com/m7d0d663d

As you can see, it says no debugging symbols where found anywhere. I want to compile audacious with debugging symbols, but I am not sure how. I tried editing configure, which only includes a file named buildsys.mk, so I edited that and removed the -s flag from the linker, and made sure that the -g flag is passed to the compiler. The gdb output above is after I did that, so apparently what I did had no effect.

So how can I retain debugging symbols when compiling audacious? The problem is that I am only writing a small plugin, and haven't got a grasp of the while audacious code.

UPDATE: I added debugging symbols for gtk+ and glib (and also tried the CFLAGS=-g option), and I got a couple of coredumps analyzed. The bottom line is this:

(gdb) bt
#0  gtk_text_iter_make_real (_iter=<value optimized out>) at /build/buildd/gtk+2.0-2.16.1/gtk/gtktextiter.c:202
#1  0xb7c1cf5e in _gtk_text_iter_get_any_segment (iter=0x0) at /build/buildd/gtk+2.0-2.16.1/gtk/gtktextiter.c:474
#2  0xb7c24cd6 in IA__gtk_text_layout_get_line_display (layout=0x93a4318, line=0x9af6270, size_only=1) at /build/buildd/gtk+2.0-2.16.1/gtk/gtktextlayout.c:2196
#3  0xb7c29172 in gtk_text_layout_real_wrap (layout=0x93a4318, line=0x9af6270, line_data=0xb10036b8) at /build/buildd/gtk+2.0-2.16.1/gtk/gtktextlayout.c:1147
#4  0xb7c2358f in IA__gtk_text_layout_wrap (layout=0x93a4318, line=0x9af6270, line_data=0x0) at /build/buildd/gtk+2.0-2.16.1/gtk/gtktextlayout.c:693
#5  0xb7c060a1 in _gtk_text_btree_validate_line (tree=0x9407370, line=0x9af6270, view_id=0x93a4318) at /build/buildd/gtk+2.0-2.16.1/gtk/gtktextbtree.c:5422
#6  0xb7c27dc1 in IA__gtk_text_layout_validate_yrange (layout=0x93a4318, anchor=0xbfb0e624, y0=0, y1=635) at /build/buildd/gtk+2.0-2.16.1/gtk/gtktextlayout.c:1062
#7  0xb7c34999 in gtk_text_view_validate_onscreen (text_view=0x9406000) at /build/buildd/gtk+2.0-2.16.1/gtk/gtktextview.c:3502
#8  0xb7c35f85 in gtk_text_view_flush_first_validate (text_view=0x9406000) at /build/buildd/gtk+2.0-2.16.1/gtk/gtktextview.c:3558
#9  0xb7c35fde in first_validate_callback (data=0x9406000) at /build/buildd/gtk+2.0-2.16.1/gtk/gtktextview.c:3577
#10 0xb79c88fb in gdk_threads_dispatch (data=0x9bce910) at /build/buildd/gtk+2.0-2.16.1/gdk/gdk.c:498
#11 0xb7e38c81 in g_idle_dispatch (source=0x938a400, callback=0, user_data=0x9bce910) at /build/buildd/glib2.0-2.20.1/glib/gmain.c:3922
#12 0xb7e3ab88 in IA__g_main_context_dispatch (context=0x9250760) at /build/buildd/glib2.0-2.20.1/glib/gmain.c:1814
#13 0xb7e3e0eb in g_main_context_iterate (context=0x9250760, block=1, dispatch=1, self=0x92333e8) at /build/buildd/glib2.0-2.20.1/glib/gmain.c:2448
#14 0xb7e3e5ba in IA__g_main_loop_run (loop=0x9a92c88) at /build/buildd/glib2.0-2.20.1/glib/gmain.c:2656
#15 0xb7b707d9 in IA__gtk_main () at /build/buildd/gtk+2.0-2.16.1/gtk/gtkmain.c:1205
#16 0xb268d56a in skins_init () from /usr/local/lib/audacious/General/skins.so
#17 0x0805b42a in ?? ()
#18 0xb7540775 in __libc_start_main () from /lib/tls/i686/cmov/libc.so.6
#19 0x08055361 in ?? ()
(gdb)

And the exact error is:

#0  gtk_text_iter_make_real (_iter=<value optimized out>) at /build/buildd/gtk+2.0-2.16.1/gtk/gtktextiter.c:202
202 /build/buildd/gtk+2.0-2.16.1/gtk/gtktextiter.c: No such file or directory.
in /build/buildd/gtk+2.0-2.16.1/gtk/gtktextiter.c

The exact line is this:

if (iter->segments_changed_stamp !=

Can anyone make anything out of this? :-\

A: 

As far as I know, audacious uses autotools. No need to modify anything, just configure with:

CFLAGS="-g $CFLAGS" ./configure

followed by the usual steps to install it. The flags are stored (in config.status I think), so any subsequent call to make will build a debug-enabled audacious.

ntd
+1  A: 

While it's true that doing either:

./configure CFLAGS=-g && make && make install

or

make CFLAGS=-g

will get you a build with debug symbols, this is quite unlikely to help you solve the problem.

You program crashed in /usr/lib/libgtk-x11-2.0.so.0, not in audacious2 (whatever that is). You are also analyzing the core incorrectly: list doesn't make sense at that stage. Your very first (gdb) command when analyzing a core should almost always be where, followed by thread apply all where.

You might also get better results from installing libgtk2-debuginfo or some such package, which should provide debug info for libgtk-x11-2.0.so.0, and may allow you to see the source and variables in libgtk at crash point.

Employed Russian
Thanks, that sounds very logical, I will try it. Also, @veryone, I can't be sure, but I believe audacious is already compiled with -g, as I already said in my question.
FrontierPsycho
In my opinion this is a wrong approach: GTK+ has a large user base, it very unlikely would have such bug, debugging its internals is a waste of time (in this case). After the segmentation fault I'd do a backtrace ("bt" in gdb) and check my plugin calls _first_, debugging audacious only when I'm sure the plugin works properly. GTK+ debugging should be left only as a last resource.
ntd
Which is the wrong approach? We seem to agree that the very first GDB command should be "where" (aka "bt"). It is true that the bug is likely not in libgtk, but in its caller. Still, installing libgdtk2-debuginfo may immediately reveal just what bad parameter the caller passed in.
Employed Russian
My suggestion was to not try to find the problem inside GTK+, but carefully check the calls in the plugin against the documentation. Debugging a beast like GTK+ means (always in my opionion) looking for troubles: it is not a trivial project and if the core dump is in the type system... good luck.
ntd
I think Employed Russian is right: I am not going to debug GTK+, only see which GTK+ function fails, and thus see to which GTK+ function I am passing illegal parameters :)
FrontierPsycho