Re: [sigc] Strange crashes in sigc::trackable on Mac OS X

[Michael Ekstrand <mekstran scl ameslab gov>]

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