Re: [gtkmm] Possible bug in SigC::Connection::disconnect()

[Ole André Vadla Ravnĺs <ole ravnas lyse net>]

On Tue, 2003-11-25 at 09:23, martin-ml hippogriff de wrote: 
> Yes, you can! This has been possible since the 1.0.x 
> times but a bug in early versions of 1.2.x made it 
> non-functional temporarily. I think I readded a test 
> case that makes sure this is working, myself. 
> By the way, the most recent version of the 1.2 series is 
> 1.2.5. 

I'm running libsigc++ 1.2.5 (and gtkmm 2.2.8, just for the record) and
my test-case (unfortunately using glibmm) seems to trigger some kind of
bug. I added a line sort of 'cerr << "one iteration" << endl;' to both
of the loops in sigc++/macros/signal.h.m4, something like:

    for (SignalConnectionNode* i = impl->begin_; i; i = i->next_)
      {
            cerr << "emit: one iteration" << endl;
            (...)
      }

And, I can clearly see how there are more iterations than currently
connected slots to that particular signal, and that could have been ok,
but valgrind reports at this particular point:

==669== Invalid read of size 1
==669==    at 0x804A558: SigC::ConnectionNode::blocked() const (in
/home/zole/testapp/a.out)
==669==    by 0x8049DC7: SigC::Signal1<void, std::string,
SigC::Marshal<void> >::emit(std::string const&) (in
/home/zole/testapp/a.out)
==669==    by 0x80499EA: client::recv_idler() (in
/home/zole/testapp/a.out)
==669==    by 0x804A2BF: SigC::ObjectSlot0_<bool, client>::proxy(void*)
(in /home/zole/testapp/a.out)
==669==    Address 0x415756A4 is 8 bytes inside a block of size 36
free'd
==669==    at 0x40028DED: __builtin_delete (in
/usr/lib/valgrind/vgskin_memcheck.so)
==669==    by 0x40028E18: operator delete(void*) (in
/usr/lib/valgrind/vgskin_memcheck.so)
==669==    by 0x402C7556:
SigC::SignalConnectionNode::~SignalConnectionNode() (in
/usr/lib/libsigc-1.2.so.5.0.5)
==669==    by 0x402C715E: SigC::SignalNode::cleanup() (in
/usr/lib/libsigc-1.2.so.5.0.5)

Meaning that some resources have been free()'d / delete'ed that are
still kept in the list, and when they're referenced, random things can
happen (in my case I got crashes when the openssl-related code was
involved -- but valgrind reported the same memory errors at the same
spots with/without openssl, but only crashed when using it (of course
only when not run through valgrind, which avoids these illegal/dangerous
calls)).

I'll try to change my test-case to only use libsigc++ and no glibmm
(gtkmm).

Regards
Ole André