Re[2]: Does GTK leak memory
- From: Lothar Scholz <llothar web de>
- To: Michael Torrie <torriem gmail com>
- Cc: gtk-list gnome org
- Subject: Re[2]: Does GTK leak memory
- Date: Sat, 5 Jun 2010 21:18:53 +0200
Hello Michael,
Saturday, June 5, 2010, 7:48:55 AM, you wrote:
MT> On 06/02/2010 02:33 PM, Lothar Scholz wrote:
>> Why? GLIB/GTK is clearly using its own heap so there is no reason to
>> go into libs.
MT> Umm, GTK *is* a lib. It's dynamically loaded at runtime by the binary.
MT> So the at_exit() problems would definitely apply here. And as folks
Well i don't want some "at_exit()" magic. Using an explicit
gkt_exit(); or glib_exit(); should do it. I'm not Harry Potter i don't
like magic happening.
MT> have been trying to tell you, if you do leak detection on a GTK app
MT> without a suppression file, you'll see apparent leaks from the entire
MT> set of dependent libraries which each do their own heap allocations.
First my main development platform is windows.
And second unfortunately using valgrind is just not really useable as
it slows down the application to a point where you simply can't use it
during normal test runs. Especially you can't use it for test runs on
customer systems.
MT> A suppression file suppresses reports of memory leaks in a leak detector
MT> utility such as valgrind. You claim to have programmed in C for 25
MT> years, but I'm very surprised you have never used a leak detection tool
MT> before.
I've used different ones but never valgrind. This was always way to
heavy.
But this doesn't tell me why we have g_free and g_malloc but can't add
our own simple simple Heap dumper?
MT> What I do is build debug version of GTK, then use an environment
MT> variable (google it) to disable the gslice allocator, and then do the
MT> leak tests. Sometimes I'll unit test parts of my app and run something
MT> part in a loop thousands of time and watch the memory usage in a
MT> profiler. As long as it doesn't grow beyond a certain bound I know I'm
MT> good.
Yeah thats the poor mans solution. But it seems stupid to me to waste
time with this approach if it could be build in instead of 1000 times by GTK users.
It's such a shame that people really recommend this way. Unless people
like you are not changing behaviour and demand quality in every
sentence there will only be fucked up "it works for me" ad hock
implementations but no real software quality.
I just want a dammed proof it it leaks, not a guess.
Sorry but this is exactly what i mean with "its a toy toolkit".
This is just unforgiveable. Well after discovering the
broken-beyond-repair gtk_file_chooser stuff i wonder why i ask myself
why i think that GTK is professional.
--
Best regards,
Lothar mailto:llothar web de
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]