David, 2011/4/8 David NeÄas <yeti@xxxxxxxxxxxxxxx>: > 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? You're genius. I was able to fix some other stuff. But this one still stands. Can you see anything wrong in this line: g_string_printf( m_data1, "<b><span foreground=\"black\"><span font=\"Sans Serif\"><span font=\"48\">%2.2f</span></span>V</span></b>", m_totalVoltagePack ); I'm getting from valgrind: ==24358== Invalid write of size 1 ==24358== at 0x4C7DC87: g_string_truncate (in /usr/lib/libglib-2.0.so.0.1800.4) ==24358== by 0x4C7DDB1: g_string_printf (in /usr/lib/libglib-2.0.so.0.1800.4) ==24358== by 0x8049395: CFrame::SetColoring() (main_window.cc:281) ==24358== by 0x80496D6: CFrame::UpdateData() (main_window.cc:267) ==24358== by 0x8049842: CFrame::ReadData(CFrame*) (main_window.cc:253) ==24358== by 0x804A3FC: main (mini2440.cc:37) And this might be the reason for the null pointer dereference... Thank you. > >> 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
