2010/1/1 Erik de Castro Lopo mle+...@mega-nerd.com:
- How does one go about teasing out the difference between my memory
leaks and GTK stuff I have no control over?
Just a few thoughts
Valgrind is an excellent product, and is designed for programmer use only.
It shows where
On Sat, Jan 2, 2010 at 4:20 AM, jcup...@gmail.com wrote:
2010/1/1 Erik de Castro Lopo mle+...@mega-nerd.com:
- How does one go about teasing out the difference between my memory
leaks and GTK stuff I have no control over?
I usually run my app twice: once with just startup/shutdown and
Bill C wrote:
Valgrind is an excellent product, and is designed for programmer use only.
It shows where unreleased memory was allocated, so one can trace each
chunk of memory to see if it should have been released, and take
appropriate action it your code allocated it.
That is easy when
Erik de Castro Lopo mle+...@mega-nerd.com wrote:
==12528== 27,300 bytes in 175 blocks are still reachable in loss record
11,194 of 11,196
==12528== at 0x4024C1C: malloc (vg_replace_malloc.c:195)
==12528== by 0x4B342E3: g_malloc (gmem.c:131)
==12528== by 0x4B4A418: g_slice_alloc
Dan Kegel wrote:
Erik de Castro Lopo mle+...@mega-nerd.com wrote:
==12528== 27,300 bytes in 175 blocks are still reachable in loss record
11,194 of 11,196
==12528== at 0x4024C1C: malloc (vg_replace_malloc.c:195)
==12528== by 0x4B342E3: g_malloc (gmem.c:131)
==12528== by
On Tue, Jan 05, 2010 at 09:39:48AM +1100, Erik de Castro Lopo wrote:
==12528== 27,300 bytes in 175 blocks are still reachable in loss record
11,194 of 11,196
==12528==at 0x4024C1C: malloc (vg_replace_malloc.c:195)
==12528==by 0x4B342E3: g_malloc (gmem.c:131)
==12528==by
On Mon, Jan 04, 2010 at 02:56:44PM -0800, Dan Kegel wrote:
Erik de Castro Lopo mle+...@mega-nerd.com wrote:
==12528== 27,300 bytes in 175 blocks are still reachable in loss record
11,194 of 11,196
==12528== at 0x4024C1C: malloc (vg_replace_malloc.c:195)
==12528== by 0x4B342E3:
2010/1/2 jcup...@gmail.com:
Sorry, I posted hastily, I do get an annoying number of leaks if I let
it run a little longer, I see what you mean. I'm sure it wasn't as bad
back in 9.04.
I'll try to make a better suppression file tomorrow.
Here's another suppression file:
I think much of this boils down to the definition of leak. My
impression is that GTK+ and GLib developers don't consider as leaks
once-only allocations that either indeed truly are unreachable almost
right away after being used (as long as they are small) (but of
course, if possible one should
Tor Lillqvist wrote:
I think much of this boils down to the definition of leak. My
impression is that GTK+ and GLib developers don't consider as leaks
once-only allocations that either indeed truly are unreachable almost
right away after being used (as long as they are small) (but of
course,
On Sat, 2010-01-02 at 14:40 +1100, Erik de Castro Lopo wrote:
I'm having trouble differentiating between memory leaks in my code and
apparent leaks in GTK when using valgrind.
Even the minimal hello world program from the GTK tutorial:
http://library.gnome.org/devel/gtk-tutorial/stable
2010/1/3 Erik de Castro Lopo mle+...@mega-nerd.com:
Erik de Castro Lopo wrote:
Don't you think that maybe a suppression file is not the right approach
to this problem?
Specifically, I am concerned about the possibility of a suppressions file
that hides a real memory leak where a program bug
Sven Neumann wrote:
I agree that it would help a lot if we could in one way or another get
rid of false positives. But my experience shows that you get pretty much
the same valgrind warnings no matter how large your GTK+ application is.
Your 100 line demo program will produce the same set of
There has definitely been a degradation in the ability
of valgrind to find memory leaks in gtk+ applications
over the past, say, 5 years.
I think the basic problem is that there are more singletons
and that gtk+ object hold more pointers to other objects
than they used to.
IMHO, the situation
2010/1/2 Erik de Castro Lopo mle+...@mega-nerd.com:
when run as follows (suppression file from http://live.gnome.org/Valgrind):
I use the following suppression file on Ubuntu 9.10:
{
ldopen1
Memcheck:Addr4
obj:/lib/ld-2.6.1.so
}
{
xwrite1
Memcheck:Param
on the helloworld program from the GTK
tutorial and valgrind on Ubuntu 9.10 run as:
$ export G_SLICE=always-malloc
$ export G_DEBUG=gc-friendly
$ valgrind --tool=memcheck --leak-check=full --leak-resolution=high \
--num-callers=50 --show-reachable=yes \
--suppressions=gtk.suppression2
2010/1/2 Erik de Castro Lopo mle+...@mega-nerd.com:
With your suppressions file on the helloworld program from the GTK
tutorial and valgrind on Ubuntu 9.10 run as:
Sorry, I posted hastily, I do get an annoying number of leaks if I let
it run a little longer, I see what you mean. I'm sure
2010/1/2 Erik de Castro Lopo mle+...@mega-nerd.com:
for my 300,000 line GTK application.
Is that public? In revision control somewhere?
It's the nip2 GUI for the vips image processing library:
http://www.vips.ecs.soton.ac.uk
Sources here:
http://vips.svn.sourceforge.net/viewvc/vips/
John
jcup...@gmail.com wrote:
Sorry, I posted hastily, I do get an annoying number of leaks if I let
it run a little longer, I see what you mean. I'm sure it wasn't as bad
back in 9.04.
I've just tried the helloworld program on Ubuntu 9.04 and the results:
==23067== LEAK SUMMARY:
==23067==
Erik de Castro Lopo wrote:
Don't you think that maybe a suppression file is not the right approach
to this problem?
Specifically, I am concerned about the possibility of a suppressions file
that hides a real memory leak where a program bug continually allocates
resources that are not released
Hi all,
I'm having trouble differentiating between memory leaks in my code and
apparent leaks in GTK when using valgrind.
Even the minimal hello world program from the GTK tutorial:
http://library.gnome.org/devel/gtk-tutorial/stable/c39.html#SEC-HELLOWORLD
when run as follows (suppression
21 matches
Mail list logo
