Ok. Can you add some kind of printf() to your app and see if you're running
the right binary? As uninitialized value detection works for me, it might
also help to post the code you're running.
Bjoern
2010/4/14 ajit gunge peacepan...@yahoo.com
No it didn't work.All I want is the exact line
Hi,
Valgrind reports definitely lost memory leak when I am invoking
openpty(). Could some one tell me whether it is a bug in valgrind or my
mistake in using openpty? Thanks.
My program is:
#include unistd.h
#include glib.h
#include stdio.h
#include stdlib.h
#include utmp.h
#include pty.h
int
Hi,
On 04/14/2010 03:50 PM, jody wrote:
Hi
It is very well possible that openpty itself has a leak.
It is quite common that library functions don't clean up nicely after
their work is done...
Heh, if that is the case, I might submit a bug to library developer
then. But it's really common
Unless your program is in a directory specified in your $PATH, you are
valgrinding the /bin/test utility.
The right command to invoke Valgrind is:
valgrind --tool=memcheck ./test
On Tue, Apr 13, 2010 at 11:22 PM, ajit gunge peacepan...@yahoo.com wrote:
Hi All,
I am trying to run the sample
It is very well possible that openpty itself has a leak.
It is quite common that library functions don't clean up nicely after
their work is done...
Heh, if that is the case, I might submit a bug to library developer
then. But it's really common to use openpty in such way, so I wonder if
I
First of all... I don't know what went wrong, but I apparently didn't have
your patch in the valgrind binary when I ran that test. Sorry.
I have now tried your test program without valgrind, and it hits an
assert:
# ./dcbzl
dcbzl: dcbzl.c:38: main: Assertion `block[(128)+i] == 0x00' failed.
The actual leak appears to be lower in the backtrace, maybe in
getgrnam_r@@GLIBC_2.1.2 or nss_parse_service_list or the like.
For valgrind nss_parse_service_list Google gives this result which
advises to call __libc_freeres() to get accurate Valgrind results:
On Wed, Apr 14, 2010 at 8:34 AM, Rainer Gerhards rgerha...@gmail.comwrote:
I am working with the svn version of valgrind (updated this morning).
I see a series of violations in drd which I can not identify the root
cause. An example violation looks like this:
==22593== Thread 3:
==22593==
On Apr 14, 2010, at 6:01 AM, Mogens Lindholdt Lauridsen wrote:
First of all... I don't know what went wrong, but I apparently
didn't have your patch in the valgrind binary when I ran that test.
Sorry.
No worries, it's easy to do.
I have now tried your test program without valgrind, and
That may not be a valid instruction for your particular processor. I
was working under the assumption that you were using a PPC970. Does
my test program run correctly *outside* of valgrind, or does it give
you a SIGILL?
If I change the BLOCK_SIZE from 128 to 32, your test program runs fine on
10 matches
Mail list logo
