On Wed, May 06, 2015 at 01:01:08PM +0600, Konstantin P. wrote:
Why this causes memory usage increases in htop?
if (connect_build_object != NULL) {
g_object_unref (G_OBJECT ( connect_build_object ));
object = NULL;
}
connect_build_object = gtk_builder_new();
The following code spawns a window --
if (connect_build_object != NULL) {
g_object_unref (G_OBJECT ( connect_build_object ));
object = NULL;
}
connect_build_object = gtk_builder_new();
gtk_builder_add_from_file ( connect_build_object,
main_window.glade, NULL );
On 05/09/2011 01:36 PM, Gabriele Greco wrote:
just a note on your example code: use the GPOINTER_TO_INT and
GINT_TO_POINTER macro's to avoid 64bit portability problems:
gboolean mycbk(gpointer data)
{
gint val = GPOINTER_TO_INT(data);
char buffer[16];
sprintf(buffer, %09d,
If I use g_idle_add to send to my main thread that does the GTK rendering
some notifications I have to free the source handle that the function
returns to me every time or not to avoid a memory leak?
Here is a simple code example, that seems not to leak on linux (ps gives
constant resource
FWIW I tracked sown the mechanism for suppressing leak detections in MSVC.
Basically, you can set checkpoints and only display the leaks between two
specified points. It might not be as flexible as the method used in Valgrind
but it's one helluva lot easier. Here's how I modified my original
On 13/02/11 04:43, John Emmas wrote:
FWIW I tracked sown the mechanism for suppressing leak detections in MSVC.
Basically, you can set checkpoints and only display the leaks between two
specified points. It might not be as flexible as the method used in Valgrind
but it's one helluva lot
I posted this the last time this subject came up (twice last year, I
think), but I made this valgrind suppression file for my project:
http://www.vips.ecs.soton.ac.uk/development/nip2.supp
With this, I get no reported leaks in my huge (200,000 lines of C)
application on Ubuntu with current
Because malloc() implementations generally kept a linear linked list of
free space, and traversed the list on a free() in case they found
adjacent memory areas to the one you were freeing, which they could join
together and make into a single larger area.
I'm sorry, I now understand what you
Hi All
On 10/02/11 18:26, John Emmas wrote:
On 9 Feb 2011, at 17:01, James Morris wrote:
Not only do we have to write our own code, we have to put work into
making other peoples code ignore the errors in other peoples code so
we can see the errors in our own code. It's a bloody outrage!
From: Carlos Pereira [jose.carlos.pere...@ist.utl.pt], Date: 10/02/2011 09:10:
something), but aside from that it's a pure waste of CPU cycles.
I am sorry, I totally disagree.
I can only see two cases. Either fixing these hundreds and hundreds of
mem leaks is easy or difficult.
In the first
The basic idea that one must understand about programming is that of
paradigms and concepts. They are really stressed for C++ and higher
level stuff (scripting languages notwithstanding ofcourse). But if
you're gonna use C you're gonna write paradigms and concepts that
you'll really have to be
On 10/02/11 19:50, Costin Chirvasuta wrote:
I'm sorry, I now understand what you mean. If what you say is true
(which I don't doubt) it's a really boneheaded mechanism in my
opinion. Defragmenting memory in realtime is a performance nightmare.
But that's irrelevant. Your point is well taken.
+. However, I've
come to realise that the rewards of working with gtk+ are well worth
persevering with the steep (and sometimes not very intuitive) learning curve.
I'd have to say though that the difficulty of tracking my memory leaks is the
first thing that's seriously made me question my move
To describe the standard mechanism of garbage collection as a boneheaded
idea shows a total lack of awareness of first year Computer Science course
principles. That garbage collection has been refined and highly optimised
over the years is true; however it is a very necessary thing with
On 02/10/2011 12:19 AM, Costin Chirvasuta wrote:
I find not cleaning up explicitly quite ugly. I shudder at the thought
and maybe I'm not the only one. Not only that, but cleaning up
explicitly is obviously useful for some people.
I guess we're at an impasse then. The discussion has now moved
On 10 Feb 2011, at 17:48, Michael Torrie wrote:
I guess we're at an impasse then. The discussion has now moved from the
definition of leak to some personal idea of what beauty is.
In which case, maybe we should agree to use the word leak for the simple
purpose of identifying the
On Thu, Feb 10, 2011 at 07:28:40PM +, John Emmas wrote:
To me, the debate has become something very simple when a program
needs to allocate a block of memory only once, does the programmer
necessarily have to release it programmatically or can he defer it to
the OS? Remember we
On Thu, 2011-02-10 at 10:50 +0200, Costin Chirvasuta wrote:
Because malloc() implementations generally kept a linear linked list of
free space, and traversed the list on a free() in case they found
adjacent memory areas to the one you were freeing, which they could join
together and make
On 11/02/11 09:13, David Nečas wrote:
While I agree having a clean-up function could be useful in some cases
(dynamical modules with GUI) this ‘widespread expectation in C++’ stuff
is just rubbish.
Yeti
___
gtk-app-devel-list mailing list
On 10 Feb 2011, at 22:13, David Nečas wrote:
And others, Gtk+ devs probably including, consider this a useful
optimisation – and in many cases a necessity. You still do not seem to
accept even the existence of this point of view.
I would say quite the reverse. Every single person here
On 8 Feb 2011, at 09:36, John Emmas wrote:
int main (int argc, char *argv[])
{
Gtk::Main *app = new Gtk::Main (argc, argv);
delete app;
return 0;
}
The above code causes hundreds of memory leaks.
I spent a few minutes on this (literally just a few) this morning
It's just a question of definition. Many people, me included, don't
consider once-only allocations of memory that stays accessible and
aren't freed before the program exits leaks. GTK+ and GLib isn't the
kind of libraries that you could load dynamically, use a bit, and then
unload, and expect to
On Wed, 2011-02-09 at 10:44 +0200, Tor Lillqvist wrote:
And anyway, this OMG GTK+ leaks memory discussion has been had
several times already over the years. This parrot is dead.
True.
But it is a shame that there isn't a
gtk_unload_no_I_mean_really_unload_honest() function that we could use -
On Wed, Feb 9, 2011 at 4:44 PM, Tor Lillqvist t...@iki.fi wrote:
It's just a question of definition. Many people, me included, don't
consider once-only allocations of memory that stays accessible and
aren't freed before the program exits leaks. GTK+ and GLib isn't the
kind of libraries that
and I could (almost) agree with it if we were
referring specifically to program initialisation - but let me cite my earlier
example of g_warning(). A call to g_warning() results in 16 memory leaks but
when I re-tested it after reading your comment, I realised that 2 calls still
only produce 16
On 2/9/2011 3:44 AM, Tor Lillqvist wrote:
several times already over the years. This parrot is dead.
No he isn't, he's pining for the fjords...
Sorry, couldn't resist
Damon Register
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
Each time you call _CrtDumpMemoryLeaks() it dumps all the memory that's been
allocated but not yet released.
So it doesn't take into consideration at all whether the memory in
question is / can be used or not, i.e. whether there is any pointer to
it in local variables, etc. All memory that has
of unreachable memory to grow
continuously.
It's an interesting argument and I could (almost) agree with it if we were
referring specifically to program initialisation - but let me cite my earlier
example of g_warning(). A call to g_warning() results in 16 memory leaks but
when I re-tested
to free memory, that
will be truly freed by the OS anyway
If there's a benefit, yes. In this case the benefit is that it would make it
easier to find genuine memory leaks.
With the right tool there is no problem at all in finding such true
leaks. On Windows, I guess it could be Purify?
It's
On 9 February 2011 11:13, Tor Lillqvist t...@iki.fi wrote:
With the right tool there is no problem at all in finding such true
leaks.
How does one gain this mysterious tool for Linux?
I have used Valgrind but as mentioned by numerous souls at numerous
times in the past, a suppressions file is
On Wed, Feb 09, 2011 at 04:02:01PM +, James Morris wrote:
I have used Valgrind but as mentioned by numerous souls at numerous
times in the past, a suppressions file is needed for GTK/GLIB. And
creating a suppressions file is more work than actually writing the
code of the program I'm
James Morris wrote:
How does one gain this mysterious tool for Linux?
It's called Google. There's a web page[1] that details how to setup
valgrind to debug gtk/glib apps and even a preliminary suppression file.
[1] http://live.gnome.org/Valgrind
On 9 February 2011 16:10, Michael Cronenworth m...@cchtml.com wrote:
James Morris wrote:
How does one gain this mysterious tool for Linux?
It's called Google. There's a web page[1] that details how to setup valgrind
to debug gtk/glib apps and even a preliminary suppression file.
[1]
blanche for them to delay fixing their memory leaks
or even not to bother fixing them at all, or (as we have here) to reclassify
them as not being genuine leaks.
Which brings us neatly back to where we all started off.
John
P.S I will say though that in all my life I don't think I've ever
for
them to delay fixing their memory leaks or even not to bother fixing them at all, or (as
we have here) to reclassify them as not being genuine leaks.
Which brings us neatly back to where we all started off.
John
P.S I will say though that in all my life I don't think I've ever written
missing Tor's point. Yes, all memory leaks are bad, but
most (all?) of the instances of not-explicitly-released memory
in the GTK stack are _not_ leaks. If you still have a pointer to
it, it ain't a leak, even if a dumb debugger says so.
Allin Cottrell
On 9 Feb 2011, at 20:06, Allin Cottrell wrote:
You're missing Tor's point. Yes, all memory leaks are bad, but
most (all?) of the instances of not-explicitly-released memory
in the GTK stack are _not_ leaks. If you still have a pointer to
it, it ain't a leak, even if a dumb debugger says so
On Wed, 9 Feb 2011, John Emmas wrote:
On 9 Feb 2011, at 20:06, Allin Cottrell wrote:
You're missing Tor's point. Yes, all memory leaks are bad, but
most (all?) of the instances of not-explicitly-released memory
in the GTK stack are _not_ leaks. If you still have a pointer
but aside from that it's a pure waste of CPU cycles.
I hate to throw fuel in the fire but this is just absurd!
How complex is freeing 200 pointers? O(1)?
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
something), but aside from that it's a pure waste of CPU cycles.
Dear Allin,
I am sorry, I totally disagree.
I can only see two cases. Either fixing these hundreds and hundreds of
mem leaks is easy or difficult.
In the first case, is just a question of plain laziness and bad
programming
On 9 Feb 2011, at 23:41, Carlos Pereira wrote:
something), but aside from that it's a pure waste of CPU cycles.
Dear Allin,
I am sorry, I totally disagree.
I can only see two cases. Either fixing these hundreds and hundreds of mem
leaks is easy or difficult.
In the first case, is
On 10/02/11 04:01, James Morris wrote:
On 9 February 2011 16:10, Michael Cronenworthm...@cchtml.com wrote:
That's called patronising. I have been there already. What good is a
work in progress when the progress stopped over two years ago?
Not only do we have to write our own code, we have to
I think Allin's point is that even though I deleted the object in my example
app, the gtk shared library code is still technically available to be used by
some other part of my program (without needing to be re-initialized). In my
example, I just happened to not use it.
Yes, I accept
There is already gtk_init(). It's only logical it should have a counterpart.
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
On Wed, 2011-02-09 at 17:22 -0500, Allin Cottrell wrote:
I'm afraid you're talking through your hat here. Have your ever
worked through the code for even a simple shared library that
saves state? Freeing all memory on exit can be useful as a
debugging exercise (e.g. if you get a segfault
On 02/09/2011 04:39 PM, Bill C wrote:
My experience with valgrind and GTK is that it is easy to fix leaks.
Simply look for leaked memory that you allocated. Then determine where
you should have released it. If it was not allocated by you its not
your problem so ignore it.
Right. And if
On 02/09/2011 05:05 PM, Jeff Clough wrote:
And the fact that so many shared library hackers have this view is the
reason modern desktops need to ship with four gigs of RAM minimum and
still can't stay up for more than a week.
Rubbish. What an absurd and fallacious argument. Whether GTK+
On Wed, 9 Feb 2011, Carlos Pereira wrote:
something), but aside from that it's a pure waste of CPU cycles.
Dear Allin,
I am sorry, I totally disagree.
I can only see two cases. Either fixing these hundreds and hundreds of
mem leaks is easy or difficult.
Easy or difficult, if the OS is
How times have changed:
http://www.folklore.org/StoryView.py?story=Were_Not_Hackers!.txt
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Some people really don't get this but it's a fact that people like to
work with a Bill Atkinson. Not so much with hackers (if you read the
above link).
Childish? Maybe. Just hope some people get my point.
___
gtk-app-devel-list mailing list
On 02/09/2011 05:34 PM, Costin Chirvasuta wrote:
How times have changed:
http://www.folklore.org/StoryView.py?story=Were_Not_Hackers!.txt
Nothing to do with the issue at hand. Nothing at all. The issue is
whether a library intended for one-time loading should clean up after
itself. Whether
I think it's worth pointing out that these normally harmless leaks would
become a problem if gtk was repeatedly loaded and unloaded with
dlopen()+dlclose(). Each dlopen() results in a fresh state, so Gtk would
allocate new instances of these global structures each time.
Not exactly a prominent
So it's better to use suppresion with Valgrind then to add a
gtk_cleanup() counterpart to gtk_init()?
It's better to print something to the display and then put electrical
tape over it?
Tip: (regarding whether or not that link is relevant) Intelligence
means analogy. Being able to make
I'm not saying this is really important and it should be done soon.
I'm merely stating that the value of having gtk_cleanup() would be
greater than zero. That is, regardless of how much trouble it would be
for someone to write, if it would end up in the codebase it's value
would be greater than
On Thu, 10 Feb 2011, Costin Chirvasuta wrote:
So it's better to use suppresion with Valgrind then to add a
gtk_cleanup() counterpart to gtk_init()?
That's debatable, of course, but Yes, it's more efficient for the
ordinary use case of the GTK stack -- let the OS reclaim memory on
exit --
On 02/09/2011 06:08 PM, Costin Chirvasuta wrote:
Tip: (regarding whether or not that link is relevant) Intelligence
means analogy. Being able to make connections. If you understood my
meaning and thought it wrong you should have said You analogy is
incorrect. Not point out that you didn't find
On Thu, 2011-02-10 at 00:43 +0200, Costin Chirvasuta wrote:
but aside from that it's a pure waste of CPU cycles.
I hate to throw fuel in the fire but this is just absurd!
How complex is freeing 200 pointers? O(1)?
Years ago my text retrieval package had an option to call free() for all
the
My analogy had nothing to do with memory use. It had something to do
with code beauty which was all that Bill Atkinson was about. It was
all that article was about. You got it exactly the other way around.
Efficient use of memory at the expense of ugliness was the thing to
avoid in that article.
On 10 Feb 2011, at 01:19, Costin Chirvasuta wrote:
I'm not saying this is really important and it should be done soon.
I'm merely stating that the value of having gtk_cleanup() would be
greater than zero. That is, regardless of how much trouble it would be
for someone to write, if it would
First of all, sorry if this is not the adecuate list to ask about
GLib, but I haven't found the list about GLib.
Yes, this is the proper list also for GLib related questions.
valgrind --leak-check=full ./memptr
In order to have some proper results with Valgrind, you always need to tell
GLib
Hello,
First of all, sorry if this is not the adecuate list to ask about
GLib, but I haven't found the list about GLib.
I'm newbie with GLib and I have some problems about memory leaks. I'm
testing the simple code:
#includeglib.h
int main(){
GPtrArray* dataArray=g_ptr_array_new
, you
yourself, or your distro, or whoever, is free to continue to maintain
the 2.10 branch in a separate fork.)
Even with the suppressions, I'm getting lots of memory leaks reported.
You should contemplate what you mean with memory leak. If they are
once-only allocations that appear to leak after
and find all the memory leaks.
IMHO that should have been always high on the priority list of the gtk
developers. Howerver how long do the typical applications run? Are
there very long running GTK applications around?
It would be nice if someone in the gtk+/gnome projects were to produce
On 11 March 2010 10:32, Chris Vine ch...@cvine.freeserve.co.uk wrote:
It would be nice if someone in the gtk+/gnome projects were to produce
a suppression file (there was work on one for gtk+-2.12) but the
I posted this the last time this subject came up, but I made this for
my project:
--- On Thu, 3/11/10, Chris Vine ch...@cvine.freeserve.co.uk wrote:
From: Chris Vine ch...@cvine.freeserve.co.uk
Subject: Re: Memory leaks?
To: Friedrich Dominicus fr...@q-software-solutions.de
Cc: gtk-list@gnome.org
Date: Thursday, March 11, 2010, 2:32 AM
On Thu, 11 Mar 2010 08:08:51
I've got a GTK+ based program and I'm trying to clean up the memory leaks. I'm
running it through valgrind using the instructions here:
http://live.gnome.org/Valgrind
I'm building against GTK 2.10.4.
Even with the suppressions, I'm getting lots of memory leaks reported.
First question: If I
--- On Wed, 3/10/10, Lindley M French lfren...@gmu.edu wrote:
From: Lindley M French lfren...@gmu.edu
Subject: Memory leaks?
To: gtk-list@gnome.org
Date: Wednesday, March 10, 2010, 2:16 PM
[snip]
Any ideas?
___
Yes, on the one hand, gtk
Sergei Steshenko wrote:
--- On Wed, 3/10/10, Lindley M French lfren...@gmu.edu wrote:
From: Lindley M French lfren...@gmu.edu
Subject: Memory leaks?
To: gtk-list@gnome.org
Date: Wednesday, March 10, 2010, 2:16 PM
[snip]
Any ideas
Vikram Noel Ambrose noel.ambr...@gmail.com writes:
I just suppress everything not coming out of my source files and leave
it at that. GTK is not something any single person could go through
and find all the memory leaks.
IMHO that should have been always high on the priority list of the gtk
it in Debian.
(Jonny: any progress on this, or have you been too busy since you last tried?
Also, is your not-yet-working packaging available anywhere as a starting
point?)
valgrind is a generically applicable way to find *memory* leaks, but what
you're often interested in with GLib (or Python or any
Simon McVittie wrote:
Debian's GLib packages compile GLib twice; the normal copy with
the recommended hidden-visibility settings ends up in /usr/lib in the normal
libglib2.0-0 binary package (which other packages depend on), but the package
also builds extra copy that is refdbg'able, and
On Thu, Jan 7, 2010 at 4:10 PM, Erik de Castro Lopo
mle+...@mega-nerd.com wrote:
Simon McVittie wrote:
Debian's GLib packages compile GLib twice; the normal copy with
the recommended hidden-visibility settings ends up in /usr/lib in the normal
libglib2.0-0 binary package (which other packages
Paul Davis wrote:
On Thu, Jan 7, 2010 at 4:10 PM, Erik de Castro Lopo
mle+...@mega-nerd.com wrote:
Simon McVittie wrote:
Debian's GLib packages compile GLib twice; the normal copy with
the recommended hidden-visibility settings ends up in /usr/lib in the
normal
libglib2.0-0 binary
Tomeu Vizoso wrote:
RefDbg is useful in these cases.
I've had a look at RefDbg. On configure I get:
***
* WARNING: glib = 2.6 found. refdbg will not work *
* WARNING: unless you use it with glib compiled with *
*
On Wed, Jan 6, 2010 at 22:59, Erik de Castro Lopo mle+...@mega-nerd.com wrote:
Tomeu Vizoso wrote:
RefDbg is useful in these cases.
I've had a look at RefDbg. On configure I get:
***
* WARNING: glib = 2.6 found. refdbg will not
Tomeu Vizoso wrote:
While I agree that would be good to have something with a lower
barrier,
Indeed.
Currently, to debug memory leaks in code that uses GTK+ we have the
widely known and used tool Valgrind which throws up many thousands of
false positives or a GTK+ specific tool like RefDbg
Hi all,
I have written a small test program that can create independent toplevel
windows based on a command line parameter. Currently these top level
windows contain nothing more than a GtkLabel widget and destroy
themselves using a g_timeout after 30 seconds. When all the toplevel
windows have
You probably need to end with something like this
(from Gnumeric):
{
GSList *displays;
gdk_flush();
while (g_main_context_iteration (NULL, FALSE))
;/* nothing */
displays =
On Tue, Jan 5, 2010 at 13:32, Erik de Castro Lopo mle+...@mega-nerd.com wrote:
Hi all,
I have written a small test program that can create independent toplevel
windows based on a command line parameter. Currently these top level
windows contain nothing more than a GtkLabel widget and destroy
On Tue, Jan 5, 2010 at 8:51 AM, Morten Welinder mort...@gnome.org wrote:
You probably need to end with something like this
useful, but that doesn't explain the dependency on the number of
GtkWindows created, does it?
___
gtk-devel-list mailing list
Hi Erik,
Am Dienstag, den 05.01.2010, 23:32 +1100 schrieb Erik de Castro Lopo:
I have written a small test program that can create independent toplevel
windows based on a command line parameter. Currently these top level
windows contain nothing more than a GtkLabel widget and destroy
On Tue, 2010-01-05 at 09:57 -0500, Paul Davis wrote:
On Tue, Jan 5, 2010 at 8:51 AM, Morten Welinder mort...@gnome.org wrote:
You probably need to end with something like this
useful, but that doesn't explain the dependency on the number of
GtkWindows created, does it?
Generally, GdkWindow
Sven Herzberg wrote:
Can you please post this program, so people can proofread/reproduce what
you post?
I now have two separate small programs which display this behaviour.
The code can be retrieved use the Bzr revision control tool using:
bzr get
Tomeu Vizoso wrote:
RefDbg is useful in these cases.
Where can I get some more info on that?
Erik
--
--
Erik de Castro Lopo
http://www.mega-nerd.com/
___
gtk-devel-list mailing list
On Jan 5, 2010, at 4:45 PM, Erik de Castro Lopo wrote:
Tomeu Vizoso wrote:
RefDbg is useful in these cases.
Where can I get some more info on that?
Google knows all:
http://www.google.com/search?q=refdbg
first hit:
http://refdbg.sourceforge.net/
--
Doing a good job around here is
hi,
I'm trying to debug some of my code (which is based on the example
code provided by pango), and came across a bunch of memory leaks.
I'm still new to valgrind, so can anyone explain to me why there are
leaks with:
valgrind --leak-check
On 08/06/2009 08:04 AM, august wrote:
hi,
I'm trying to debug some of my code (which is based on the example
code provided by pango), and came across a bunch of memory leaks.
I'm still new to valgrind, so can anyone explain to me why there are
leaks
I might be a bit of a puritan but I am puzzled about the following.
Running
valgrind over my program I noticed a lot of unfreed block on application
close. I decided to run a basic GTK program and see what happened.
I do this a lot on Chrome. First, as described in
On Mon, Jul 13, 2009 at 7:15 AM, Aleksander
Morgadogtk-l...@aleksander.es wrote:
You just need to get used to Glib/GTK's memleaks, which usually are
still-reachable when app ends.
Oh, right, that's the other thing: I currently ignore any
valgrind reported leak that isn't marked definitely lost.
BTW, if anyone has a better way of tracing memleaks in glib/gtk based apps,
without valgrind or using it in another way, steps are welcome!
Here is some info on purify that someone may find useful:
I have been using Purify for a few years to test gtk apps. Purify also gets
very
On Mon, Jul 13, 2009 at 7:43 AM, Vallone,
Anthonyanthony.vall...@lmco.com wrote:
I created a simple gtk app that uses all the widgets and
functions that we use across our many GUIs. I ran that app with purify, and
created a suppression file to suppress all of the reported errors from this
BTW, if anyone has a better way of tracing memleaks in glib/gtk based
apps, without valgrind or using it in another way, steps are welcome!
Here is some info on purify that someone may find useful:
Oh, non-free software... discarded... but thanks for the info :-)
I created a simple gtk app that uses all the widgets and
functions that we use across our many GUIs. I ran that app with purify, and
created a suppression file to suppress all of the reported errors from this
simple app. I use that same suppression file when running the production
GUIs, so
Hello,
I have tested Deleaker tool (www.deleaker.com) for my application and I have
seen some problems with Gdi objects and user objects.
My actual version of GTK is gtk+-bundle_2.16.0-20090317_win32.
Gdi objects :
0x97011704 (Device context)
GDI32.dll!CreateDCA
Please file a bug report at bugzilla.gnome.org and attach a *minimal*
and *complete* sample program (as a single source file, in C or
Python) that reproduces the leak. (I.e., a program which shows a
continuously growing amount of GDI resources consumed without any
clear reason.)
--tml
Ok, I am sorry.
I report the bug as soon as possible.
Cyril
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Hi All,
I found out the reason for leak. It was from GTK+ DirectFB backend and
not from DirectFB library. Functions which were responsible for
de-allocating memory in DirectFB were not called. This resulted in
accumulation of memory.
The functions for deallocating memory was under an
#if
On Thu, May 15, 2008 at 2:03 PM, [EMAIL PROTECTED] wrote:
2008/5/15 Harinandan S [EMAIL PROTECTED]:
On DirectFB backend i used DirectFB 1.1.1 with GTK+ 2.12.2. Is there
any issues with using these versions since i am able to observe huge
leaks on DirectFB backend. Is there any possibility
2008/5/19 Harinandan S [EMAIL PROTECTED]:
Anyway, I digged some more details about the leak. When i stepped
through the code i found that gdk_window_destroy_notify function in
gdkwindow-directfb.c which is called when the window is really gone is
not being called.
I also found a quite old
' is not supported on arm-linux platform so i am not
able to get more details. I'll try to run it on a x86 linux PC with
valgrind.
Neither top nor free is that useful in determining memory leaks. As
Paul alluded to, calling free() on a block that was malloc()ed does not
automatically return memory
1 - 100 of 154 matches
Mail list logo
