Re: How many times can I call gtk_label_set_markup()?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Touch Screen Library]     [GIMP Users]     [Gnome]     [KDE]     [Yosemite News]     [Steve's Art]

  Powered by Linux