c f wrote:
snip
I have checked the GTK documentation and it states that gtk_exit free
all resources allocated for GTK+. gtk_exit is depricated and using
exit is recommended. I have tested both but non of them improved the
situation (still more than 5000 leaks).
This is normal. GTK is not
On Sat, 2007-11-24 at 10:09 +0100, Vincent Torri wrote:
From what I've heard about memory leaking, this is not unique to the
GTK library. If the rumours are correct, applications like `ls` are
notorious for leaking memory, safe in the knowledge that the OS will
clean up after them.
On Sat, 24 Nov 2007, Michael Lamothe wrote:
From what I've heard about memory leaking, this is not unique to the
GTK library. If the rumours are correct, applications like `ls` are
notorious for leaking memory, safe in the knowledge that the OS will
clean up after them.
and if someone
Vincent Torri escreveu:
On Sat, 24 Nov 2007, Michael Lamothe wrote:
From what I've heard about memory leaking, this is not unique to the
GTK library. If the rumours are correct, applications like `ls` are
notorious for leaking memory, safe in the knowledge that the OS will
clean
Vincent Torri escreveu:
On Sat, 24 Nov 2007, Junior Polegato - GTK+ GTKmm wrote:
Vincent Torri escreveu:
On Sat, 24 Nov 2007, Michael Lamothe wrote:
From what I've heard about memory leaking, this is not unique to the
GTK library. If the rumours are correct, applications like `ls` are
Junior Polegato - GTK+ GTKmm wrote:
Vincent Torri escreveu:
On Sat, 24 Nov 2007, Junior Polegato - GTK+ GTKmm wrote:
Vincent Torri escreveu:
On Sat, 24 Nov 2007, Michael Lamothe wrote:
From what I've heard about memory leaking, this is not unique to the
GTK library. If the rumours are
From what I've heard about memory leaking, this is not unique to the
GTK library. If the rumours are correct, applications like `ls` are
notorious for leaking memory, safe in the knowledge that the OS will
clean up after them.
Excellent work on the enable-debug switch, I'll have to keep this
Hi,
In my opinion the definition what you have given describes well when a
memory leak can cause serious problems but I would call memory
leak,any dynamically allocated memory what is not freed when you are
done with it .
However it is true that OS will cleanup everything when the program
I have used mtrace to check for memory leaks. In this simple
application there are more than 5000 memory allocation which is not
freed.
Note that just a dynamic memory allocation that isn't freed before the
application terminates is not a leak, in case there still exists a way
to access
Hi,
I have made a simple application with a top level window:
#include gtk/gtk.h
#include mcheck.h
gboolean OnDeleteHandler(GtkWidget *sender,
GdkEvent *event,
gpointer data)
{
return FALSE;
}
void OnDestroyHandler(GtkWidget
I'm no master profiler but I think that you'll want to put a
gtk_widget_destroy(mainWindow); after the gtk_main();. You really
don't need to do this because it will be destroyed when the
application terminates 0.01 seconds after that line. But if you feel
you must then go for it. I also like to
Hi Michael,
Thanks for your suggestion.
Actually I have not mentioned but I also tried to decrease the ref
count of the mainWindow (just to be sure). In theory it is already
destroyed at this point as the main quit is called in the destoyed
handler of the main window. In that case (unref), GTK
On Wed, 21 Nov 2007 20:15:25 +0100 c f wrote:
[...]
I have used mtrace to check for memory leaks. In this simple
application there are more than 5000 memory allocation which is not
freed.
See:
http://www.gtk.org/faq/#AEN703
I have checked the GTK documentation and it states that gtk_exit
On Fri, 2006-08-04 at 13:25 +0200, gwenj wrote:
Hello,
I use gtk+ for my soft's graphic interface.
But valgrind make an log file containing approximately 22700 lines for an
simple source code like :
#include gtk/gtk.h
int main(int argc, char **argv) {
gtk_init(argc, argv);
On Sun, Aug 06, 2006 at 09:45:00AM +0200, Iago Rubio wrote:
I've just compiled and run this code snippet with valgrind, and the
results are on my system (Fedora):
ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 12 from 1)
malloc/free: in use at exit: 0 bytes in 0 blocks.
malloc/free:
padding - where a pointer to an object is returned as the start +
padding of the memory block as with pymalloc and python debug builds.
From this output I would not bet that exists - for sure - a memory leak
on gtk, but it may be investigated further.
ITOH if you are sure the leak exists
On Sun, 6 Aug 2006, Iago Rubio wrote:
The 'possibly lost' bites means - AFAIK - that exists pointers to the
interior of the analyzed block that may have pointed to the start of the
block and have been moved, among other possible causes, such as debug
padding - where a pointer to an object is
On Sun, 06 Aug 2006 09:45:00 +0200
Iago Rubio [EMAIL PROTECTED] wrote:
On Fri, 2006-08-04 at 13:25 +0200, gwenj wrote:
Hello,
I use gtk+ for my soft's graphic interface.
But valgrind make an log file containing approximately 22700 lines for an
simple source code like :
#include
padding - where a pointer to an object is returned as the start +
padding of the memory block as with pymalloc and python debug builds.
From this output I would not bet that exists - for sure - a memory leak
on gtk, but it may be investigated further.
ITOH if you are sure the leak exists
On Sun, 2006-08-06 at 11:38 +0200, David Nečas (Yeti) wrote:
On Sun, Aug 06, 2006 at 09:45:00AM +0200, Iago Rubio wrote:
I've just compiled and run this code snippet with valgrind, and the
results are on my system (Fedora):
ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 12 from
On Sun, 2006-08-06 at 14:07 +0200, gwenj wrote:
The result to valgrind is :
==29096== LEAK SUMMARY:
==29096==definitely lost: 0 bytes in 0 blocks.
Nothing malloc'ed and not freed.
==29096== possibly lost: 800 bytes in 20 blocks.
This may be investigated further, but I bet they are
==29096==still reachable: 41,380 bytes in 618 blocks.
That's completely normal. Surely they're static variables holding
pointers to freed memory.
maybe this comes from glib memory allocator. I have such results with
gstreamer too
Vincent
___
On Sun, 2006-08-06 at 20:55 +0200, Vincent Torri wrote:
==29096==still reachable: 41,380 bytes in 618 blocks.
That's completely normal. Surely they're static variables holding
pointers to freed memory.
maybe this comes from glib memory allocator. I have such results with
Hello,
I use gtk+ for my soft's graphic interface.
But valgrind make an log file containing approximately 22700 lines for an
simple source code like :
#include gtk/gtk.h
int main(int argc, char **argv) {
gtk_init(argc, argv);
GtkWidget *win= gtk_window_new(GTK_WINDOW_TOPLEVEL);
Hello,
I use gtk+ for my soft's graphic interface.
But valgrind make an log file containing approximately 22700 lines for an
simple source code like :
#include gtk/gtk.h
int main(int argc, char **argv) {
gtk_init(argc, argv);
GtkWidget *win= gtk_window_new(GTK_WINDOW_TOPLEVEL);
25 matches
Mail list logo
