Re: Problems with signals and object destruction

[Daniel Kasak <dkasak nusconsulting com au>]

muppet wrote:

> This sort of gymnastics should not be necessary.  GObject will  
> destroy all of its signal handlers in the base GObject::dispose()  
> method (part of the destruction process), and Glib::Object connects  
> those with closures so that we get proper destruction notification  
> for cleaning up the callback subroutine and user data references.   
> With that, and reference counting everywhere, everything should Just  
> Work.

Cool.

> The situations you want to watch out for are:
>
> - Any form of circular reference.  Avoid keeping references to yourself.

Doh! In Gtk2::Ex::Datasheet::DBI I'm creating circular references so 
that TreeViewColumns have access to the definition used to set them up. 
I was wondering if this would create problems ... certainly EPIC ( 
Eclipse Perl debugger ) doesn't like it. I'll come up with a less dodgy 
way of packing info into TreeViewColumns.

> > Am I  correct in assuming that it's my inability to cleanly destroy  
> > stuff
> > that's leading to crashes? Or maybe I'm exposing a Windows-only bug?
>
> I'm not convinced it's a cleanup issue, since a) it's supposed to  
> Just Work, and, b) as you say, it manifests only on windows.
>
> Now, can you *verify* that this stuff doesn't happen on windows?  Try  
> running your app under valgrind on linux, and watch for any bad  
> accesses.  Linux is often a little bit more forgiving about such  
> things than windows.

I just tried this. I didn't get any messages pop out that immediately 
pointed to a problem as such ( though this is my first time using 
valgrind ). I did get a leak summary:

==12183== LEAK SUMMARY:
==12183==    definitely lost: 36,401 bytes in 144 blocks.
==12183==    indirectly lost: 82,609 bytes in 3,955 blocks.
==12183==      possibly lost: 343,264 bytes in 355 blocks.
==12183==    still reachable: 11,344,600 bytes in 230,255 blocks.
==12183==         suppressed: 0 bytes in 0 blocks.

However I did notice that every time I closed and opened one of the 
forms that crashes under Windows, valgrind would report stuff like:

--12183-- memcheck GC: 8192 nodes, 7700 survivors ( 93.9%)
--12183-- memcheck GC: increase table size to 16384

so obviously there's stuff not being freed properly. Bummer.

Anyway, I'll look into getting rid of those circular references.

Thanks muppet :)

--
Daniel Kasak
IT Developer
NUS Consulting Group
Level 5, 77 Pacific Highway
North Sydney, NSW, Australia 2060
T: (+61) 2 9922-7676 / F: (+61) 2 9922 7989
email: dkasak nusconsulting com au
website: http://www.nusconsulting.com.au