On Sun, 06 Aug 2006 13:53:46 +0200 Iago Rubio <[EMAIL PROTECTED]> wrote:
> On Sun, 2006-08-06 at 11:37 +0200, gwenhael wrote: > > 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 > [snip] > > > 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: 30 allocs, 30 frees, 1,981 bytes allocated. > [snip] > > what is your version of gtk+, glib, glibc and gcc? > > I run valgrind with : > > valgrind -v --tool=memcheck --trace-children=yes --db-attach=no > > --log-file-exactly=error-valgrind.log --leak-check=yes > > --leak-resolution=high --show-reachable=yes ./test > > I run "valgrind ./test". > > That's what I was trying to tell you :) > > Your first post - "... valgrind made an log file containing ..." - have > not enough information to help to track what was going on when you > checked the leak. > > > Others persons, running Gentoo, have the same problem. I think that this is > > problem relative to Gentoo or with an certain version of libraries needed > > by gtk+. > > Running on Fedora5 gcc-4.1.1-1, gtk2-2.8.18-1, glib2-2.10.3 and using > your valgrind options the output is: > > LEAK SUMMARY: > definitely lost: 0 bytes in 0 blocks. > possibly lost: 48,440 bytes in 49 blocks. > still reachable: 160,448 bytes in 2,921 blocks. > suppressed: 0 bytes in 0 blocks. > > I don't know if it matches the output on your system as you didn't > posted anywhere reachable the valgrind log file, but if it doesn't > match, it could be a Gentoo problem. > > 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 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, the best place to discuss it is on > the gtk-devel list. > > > Cheers. > -- > Iago Rubio > > _______________________________________________ > gtk-app-devel-list mailing list > gtk-app-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list > The result to valgrind is : ==29096== LEAK SUMMARY: ==29096== definitely lost: 0 bytes in 0 blocks. ==29096== possibly lost: 800 bytes in 20 blocks. ==29096== still reachable: 41,380 bytes in 618 blocks. ==29096== suppressed: 0 bytes in 0 blocks. --29096-- memcheck: sanity checks: 33 cheap, 2 expensive --29096-- memcheck: auxmaps: 0 auxmap entries (0k, 0M) in use --29096-- memcheck: auxmaps: 0 searches, 0 comparisons --29096-- memcheck: secondaries: 38 issued (2432k, 2M) --29096-- memcheck: secondaries: 115 accessible and distinguished (7360k, 7M) --29096-- tt/tc: 12,535 tt lookups requiring 13,041 probes --29096-- tt/tc: 12,535 fast-cache updates, 3 flushes --29096-- translate: new 5,802 (124,805 -> 2,017,944; ratio 161:10) [0 scs] --29096-- translate: dumped 0 (0 -> ??) --29096-- translate: discarded 7 (166 -> ??) --29096-- scheduler: 1,683,892 jumps (bb entries). --29096-- scheduler: 33/8,957 major/minor sched events. --29096-- sanity: 34 cheap, 2 expensive checks. --29096-- exectx: 30,011 lists, 665 contexts (avg 0 per list) --29096-- exectx: 1,999 searches, 1,344 full compares (672 per 1000) --29096-- exectx: 0 cmp2, 159 cmp4, 37,600 cmpAll Gwenhaël _______________________________________________ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
