On Jul 20, 2006, at 1:44 PM, Michael Ekstrand wrote: > On Jul 20, 2006, at 12:36 PM, Murray Cumming wrote: >> On Thu, 2006-07-20 at 10:19 -0500, Michael Ekstrand wrote: >>> Hello all, >>> >>> I am experiencing some strange crashes in sigc::trackable on Mac >>> OS X >>> 10.4, using Apple's GCC 4.0.1 and libsigc++-2.0.17 from Fink. >> >> Is that the same version of g++ that was used by the Fink package? > > Yes. > >> Have you tried using valgrind, or getting a gdb backtrace, or >> reducing >> it to a simpler test case? > > No, yes, no. I've stared at backtraces on Mac until I'm blue in the > face, and couldn't figure out what was going on. > > I finally have some insight, though, from dmalloc (and playing with > TotalView a little): using a memory debugger set to repaint freed > memory, I can force a segfault earlier (but still in the same > destructor sequence from my code's perspective) where it seems that a > slot is being destroyed twice. I'll work on assembling a simpler > test case this afternoon.
OK, I seem to have fixed (or worked around, depending on whether it's a bug in my application code or libsigc++) the bug. The problem was present on both Linux and Mac, but Linux just let me get away with it. What was happening: a slot was being destroyed twice. slot_rep::disconnect() was being invoked on an already-deallocated slot object. Now, with my reference-counting mechanism, I had bound reference pointer parameters with sigc::bind, so there were slots retaining references. As near as I can tell, there was an object the last reference to which was in the binding data of a slot connected to a signal in that object. So as the slot tears itself down (sigc::trackable disconnects it), the signal it's connected to gets destroyed. It seems that libsigc++ doesn't like that (at least in this case). I'm not sure if libsigc++ "should" handle this correctly, or if my code is errant. I could also be wrong, but replacing some bound RefPtr's with weak pointers cleared up the issue. I've tried to construct a simpler test case, but so far have had no success. - Michael _______________________________________________ libsigc-list mailing list libsigc-list@gnome.org http://mail.gnome.org/mailman/listinfo/libsigc-list
