Re: [gentoo-user] memory leak with gtk+-2.8.20-r1
Hi, On Wed, 02 Aug 2006 12:58:33 +0200 gwe [EMAIL PROTECTED] wrote: Someone has the same problem or an solution to solve this leak of memory? Thank you very much. You should at least describe the problem you have. You're just describing the things you've tried to nail it down, but what are the symptoms? What makes you think there's a memory leak in your program? -hwh -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] memory leak with gtk+-2.8.20-r1
Le Wed, 02 Aug 2006 13:20:07 +0200, Hans-Werner Hilse a écrit : Hi, On Wed, 02 Aug 2006 12:58:33 +0200 gwe [EMAIL PROTECTED] wrote: Someone has the same problem or an solution to solve this leak of memory? Thank you very much. You should at least describe the problem you have. You're just describing the things you've tried to nail it down, but what are the symptoms? What makes you think there's a memory leak in your program? -hwh I'm sorry I post only the end of log file of valgrind (the entire file is very big ~22500 lines). This is the result of execute the source code : ==13767== LEAK SUMMARY: ==13767==definitely lost: 36 bytes in 1 blocks. ==13767==indirectly lost: 120 bytes in 10 blocks. ==13767== possibly lost: 40,264 bytes in 47 blocks. ==13767==still reachable: 118,673 bytes in 1,963 blocks. ==13767== suppressed: 0 bytes in 0 blocks. --13767-- memcheck: sanity checks: 59 cheap, 3 expensive --13767-- memcheck: auxmaps: 0 auxmap entries (0k, 0M) in use --13767-- memcheck: auxmaps: 0 searches, 0 comparisons --13767-- memcheck: secondaries: 53 issued (3392k, 3M) --13767-- memcheck: secondaries: 115 accessible and distinguished (7360k, 7M) --13767-- tt/tc: 46,665 tt lookups requiring 56,738 probes --13767-- tt/tc: 46,665 fast-cache updates, 8 flushes --13767-- translate: new19,998 (425,678 - 6,983,632; ratio 164:10) [0 scs] --13767-- translate: dumped 0 (0 - ??) --13767-- translate: discarded 209 (3,781 - ??) --13767-- scheduler: 2,984,389 jumps (bb entries). --13767-- scheduler: 59/33,828 major/minor sched events. --13767--sanity: 60 cheap, 3 expensive checks. --13767--exectx: 30,011 lists, 4,057 contexts (avg 0 per list) --13767--exectx: 6,894 searches, 3,112 full compares (451 per 1000) --13767--exectx: 0 cmp2, 196 cmp4, 1,062,968 cmpAll -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] memory leak with gtk+-2.8.20-r1
Hi, On Wed, 02 Aug 2006 13:49:04 +0200 gwe [EMAIL PROTECTED] wrote: I'm sorry I post only the end of log file of valgrind (the entire file is very big ~22500 lines). This is the result of execute the source code : ==13767== LEAK SUMMARY: ==13767==definitely lost: 36 bytes in 1 blocks. ==13767==indirectly lost: 120 bytes in 10 blocks. ==13767== possibly lost: 40,264 bytes in 47 blocks. ==13767==still reachable: 118,673 bytes in 1,963 blocks. ==13767== suppressed: 0 bytes in 0 blocks. OK, but memory usage doesn't add up while the program is running, right? I think it may be just the missing call to gtk_exit(EXIT_SUCCESS) instead of return EXITSUCCESS. At least gtk_exit() is supposed to do final cleanup work. But I think this is rather OT for this list. If you don't get more answers here, you may seek help at the GTK project... -hwh -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] memory leak with gtk+-2.8.20-r1
gwe 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);
GtkWidget *win= gtk_window_new(GTK_WINDOW_TOPLEVEL);
g_signal_connect(G_OBJECT(win), destroy, G_CALLBACK(gtk_main_quit), NULL);
gtk_widget_show_all(win);
gtk_main();
return EXIT_SUCCESS;
}
For one, you didn't delete the dynamic memory you allocated when you
were finished with it. Before EXIT_SUCCESS, add:
delete win;
R
--
gentoo-user@gentoo.org mailing list
Re: [gentoo-user] memory leak with gtk+-2.8.20-r1
Hans-Werner Hilse wrote: Hi, On Wed, 02 Aug 2006 13:49:04 +0200 gwe [EMAIL PROTECTED] wrote: I'm sorry I post only the end of log file of valgrind (the entire file is very big ~22500 lines). This is the result of execute the source code : ==13767== LEAK SUMMARY: ==13767==definitely lost: 36 bytes in 1 blocks. ==13767==indirectly lost: 120 bytes in 10 blocks. ==13767== possibly lost: 40,264 bytes in 47 blocks. ==13767==still reachable: 118,673 bytes in 1,963 blocks. ==13767== suppressed: 0 bytes in 0 blocks. OK, but memory usage doesn't add up while the program is running, right? I think it may be just the missing call to gtk_exit(EXIT_SUCCESS) instead of return EXITSUCCESS. At least gtk_exit() is supposed to do final cleanup work. Ah yes, I wasn't aware that there was a function for this. You should definitely use this in place of the delete statement because it will do deeper cleaning. R -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] memory leak with gtk+-2.8.20-r1
Le Wed, 02 Aug 2006 17:30:10 +0200, Randy Barlow a écrit : Ah yes, I wasn't aware that there was a function for this. You should definitely use this in place of the delete statement because it will do deeper cleaning. the GTK Api said gtk_exit is deprecated and should not be used. In fact, i'm very astonished because it's not the first software with GTK I wrote but it's the first time that I have this problem. It's so recent -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] memory leak with gtk+-2.8.20-r1
Hi, On Wed, 02 Aug 2006 18:14:02 +0200 gwe [EMAIL PROTECTED] wrote: Ah yes, I wasn't aware that there was a function for this. You should definitely use this in place of the delete statement because it will do deeper cleaning. the GTK Api said gtk_exit is deprecated and should not be used. In fact, i'm very astonished because it's not the first software with GTK I wrote but it's the first time that I have this problem. It's so recent OK, I didn't counter-check it and was probably reading some outdated documentation. I was just searching for some kind of cleanup function and thought I found it. So it's probably in fact a gtk memory leak. Are you by chance running non-x86? That might explain why it passed some tests though buggy on that arch... OK, I'm out of suggestions :-) Maybe a manual delete would help, but I somehow doubt that (cleanup is probably done by gtk_main_quit() now?) -hwh -- gentoo-user@gentoo.org mailing list
