On Mon, 2010-08-09 at 11:21 +0200, Murray Cumming wrote: > On Sun, 2010-08-08 at 17:10 -0700, Matej Urbas wrote: > > Hi, everyone, > > > > I am trying to fix a strange segmentation fault in Referencer > > ( http://icculus.org/referencer/ ). > > Have you tried valgrind? Have you tried gdb? I have tried gbd and like I said it tells me that it sigfaults in different places (so for different indices in the for-loop), however it invariably sigfaults when displaying the message box (if I don't comment it out). Also, I have tried running valgrind as you suggested, but I cannot reproduce the bug in this case -- it just doesn't sigfault under valgrind. However, this is probably unrelated, but I have caught some strange memory leaks in GTKMM. Are they false alarms? Here are some of them: ==13729== 14 bytes in 1 blocks are definitely lost in loss record 4,150 of 15,405 ==13729== at 0x4025BDC: malloc (vg_replace_malloc.c:195) ==13729== by 0x47EE554: g_malloc (in /lib/libglib-2.0.so.0.2200.5) ==13729== by 0x48071F9: g_strdup (in /lib/libglib-2.0.so.0.2200.5) ==13729== by 0x2E580A5: Gtk::TargetEntry::set_target(Glib::ustring const&) (in /usr/lib/libgtkmm-2.4.so.1.1.0) ==13729== by 0x8097DA8: DocumentView::DocumentView(RefWindow&, Library&, bool) (DocumentView.C:444) ==13729== by 0x80D1781: RefWindow::constructUI() (RefWindow.C:171) ==13729== by 0x80DF2B9: RefWindow::RefWindow() (RefWindow.C:50) ==13729== by 0x80A8123: main (main.C:89) ==13729== 25 bytes in 1 blocks are definitely lost in loss record 8,063 of 15,405 ==13729== at 0x4025BDC: malloc (vg_replace_malloc.c:195) ==13729== by 0x47EE554: g_malloc (in /lib/libglib-2.0.so.0.2200.5) ==13729== by 0x45E177C: gnome_vfs_unescape_string_for_display (in /usr/lib/libgnomevfs-2.so.0.2400.2) ==13729== by 0x2F5CF5D: Gnome::Vfs::unescape_string_for_display(Glib::ustring const&) (in /usr/lib/libgnomevfsmm-2.6.so.1.0.9) ==13729== by 0x80BFB9C: RefWindow::updateTitle() (RefWindow.C:2603) ==13729== by 0x80DF33E: RefWindow::RefWindow() (RefWindow.C:57) ==13729== by 0x80A8123: main (main.C:89) Thanks for your help, but I could not find more info on the bug. Cheers, --- Matej > > > The segfault happens predictably in one particular function, but not at > > the same spot. However, I managed to isolate the culprit to GTKMM API > > calls. > > > > So, the error happens in a function called 'load'. However, it works > > fine if I simply remove all UI code from it (comment it out, or just > > make sure the UI bits don't get executed). Note that the UI code just > > asks the user a simple question and updates the progress bar. > > > > Please find the (abridged) code of the 'load' function attached in > > 'load.C', I will refer to it now: > > > > So, if I comment out lines 3, 5, 8, 32 and also make sure the execution > > never goes into the 'if' in line 10 (that is, if I make sure 'something' > > is always false), then things will work fine. However, if I don't > > comment out the above lines, it will segfault randomly within the > > for-loop (because of calls to 'progress'). Also, if I don't ensure that > > 'something' is always false, then the code will segfault exactly when we > > want show the message box. > > > > The above 'load' function is called within 'onOpenLibrary', which is > > registered to an action group like this: > > > > actiongroup_->add( Gtk::Action::create("OpenLibrary", > > Gtk::Stock::OPEN, _("_Open...")), > > sigc::mem_fun(*this, &RefWindow::onOpenLibrary)); > > > > Thank you very much, > > --- > > Matej > > _______________________________________________ > > gtkmm-list mailing list > > gtkmm-list gnome org > > http://mail.gnome.org/mailman/listinfo/gtkmm-list >
Attachment:
signature.asc
Description: This is a digitally signed message part