Re: Problems with signals and object destruction

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.


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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]