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 _______________________________________________ libsigc-list mailing list libsigc-list@gnome.org http://mail.gnome.org/mailman/listinfo/libsigc-list
