Re: memory leak with gtk+-2.8.20-r1

[gwenj <gwenj free fr>]

On Sun, 06 Aug 2006 13:53:46 +0200
Iago Rubio <iago iagorubio com> wrote:

> On Sun, 2006-08-06 at 11:37 +0200, gwenhael wrote:
> > On Sun, 06 Aug 2006 09:45:00 +0200
> > Iago Rubio <iago iagorubio com> 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