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

[Michael Ekstrand <mekstran scl ameslab gov>]

On Jul 21, 2006, at 9:04 AM, Michael Ekstrand wrote:
> On Jul 21, 2006, at 1:11 AM, Murray Cumming wrote:
> > [snip]
> > > What was happening:  a slot was being destroyed twice.
> > > slot_rep::disconnect() was being invoked on an already-deallocated
> > > slot object.
> > [snip]
> >
> > This suggests that one of your own objects (which owned a slot) is
> > being
> > destroyed twice. Again, valgrind can help with this kind of thing.
>
> OK, I'll give Valgrind a shot sometime here (or at least look in to
> dmalloc's facilities for investigating such problems).  I've run
> Valgrind on it before, but haven't been able to make much sense of
> the output.  Didn't look at it for very long though.  So far dmalloc
> seems to make much more sense to me than valgrind.

FWIW, I just ran valgrind (default options) on my program, in its pre- 
fixed state.  Its messages make a lot more sense than I previously  
gave them credit for.  They also seem to confirm what I thought was  
happening - disconnect() is being invoked on an already-deleted  
slot_rep.  Before the long sequence of invalid reads and writes  
stemming from this, there is 1 other invalid write relevant to my  
code and the problem, which seems to be a minor suprious bookkeeping  
assignment in my reference counting mechanism and does not seem to be  
problematic in any way (and it's gone away with my fix yesterday).

More importantly, the only invalid free/delete messages are for a  
couple of slots - there doesn't seem to be anything indicating that  
one of my objects is actually being destroyed twice.

Since I did get the bug fixed/worked around yesterday, this is all  
post-mortem in hopes of gaining insight into what was going on and  
why, and whether there are problems with my design/implementation or  
obscure corner-case bugs in libsigc++.

- Michael