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: new5,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
