On Fri, Apr 08, 2011 at 11:00:59AM -0700, Igor Korot wrote: > Program received signal SIGABRT, Aborted. > [Switching to Thread 0xb7106b40 (LWP 22539)] > 0xb805c424 in __kernel_vsyscall () > (gdb) bt > #0 0xb805c424 in __kernel_vsyscall () > #1 0xb7169660 in raise () from /lib/libc.so.6 > #2 0xb716ae98 in abort () from /lib/libc.so.6 > #3 0xb73d4a31 in g_logv () from /usr/lib/libglib-2.0.so.0 > #4 0xb73d4ace in g_log () from /usr/lib/libglib-2.0.so.0 > #5 0xb7477896 in g_type_check_instance_cast () from > /usr/lib/libgobject-2.0.so.0 > #6 0xb7a14e9c in gtk_label_set_markup () from /usr/lib/libgtk-x11-2.0.so.0 So the parameter of gtk_label_set_markup() is bogus, aparently NULL. Or, posssibly, something *very* weird happens inside gtk_label_set_markup(), maybe if things are already inconsistent at this point. Did you try valgrind? > Breakpoint 1, CFrame::UpdateData (this=0x94e1450) at > /home/igor/mini2440gtk/mini2440gtk/src/main_window.cc:282 > 282 gtk_label_set_markup( GTK_LABEL( data2 ), m_data2->str ); > (gdb) print data1 > $1 = (GtkWidget *) 0x94e80b0 But the argument is data2, not data1. Anyway, if everything seems right, the last resort is compiling Gtk+ from source, idealy with -O0 to get the line numbers precisely, and running the program with that to see the exact line where the bad typecast occurs. Yeti _______________________________________________ gtk-list mailing list gtk-list@xxxxxxxxx http://mail.gnome.org/mailman/listinfo/gtk-list
