valgrind-users — General discussion list for Valgrind users

Re: [Valgrind-users] gcc -pg & valgrind errors

[Dirk M. <dm...@gm...>]

On Don, 19 Jun 2003, Stijn van Dongen wrote:
> 
> Is it obvious that I should not use -pg, or should valgrind do
> just fine with -pg and must I further investigate this stuff (and
> post a minimal example) ? - or does -pg not mix with some of the
> other gcc options I am using?

No, you're just hitting bugs in your libc. As you can see nothing references 
any function that is in your code, so there is no reason to worry. valgrind 
does not difference between application and library code, it simply reports 
all errors it finds. 

the mcleanup() and similiar handlers are code paths that are only used 
during profiling. 


-- 
Dirk

[Valgrind-users] gcc -pg & valgrind errors

[Stijn v. D. <st...@di...>]

   Hi,

recently I profiled a program with gprof, so compiled the sources
with -pg (and -g as well by the way, I am assuming those mix without
problems).

At that point valgrind began to emit strange errors; stuff like
[ for a single-statement program importing a thoroughly tested library. ]

[gershwin hobo mcl/shtest > valgrind --num-callers=12 ./tst
==1161== Memcheck, a.k.a. Valgrind, a memory error detector for
x86-linux.
==1161== Copyright (C) 2002, and GNU GPL'd, by Julian Seward.
==1161== Using valgrind-1.9.6, a program instrumentation system for
x86-linux.
==1161== Copyright (C) 2000-2002, and GNU GPL'd, by Julian Seward.
==1161== Estimated CPU clock rate is 449 MHz
==1161== For more details, rerun with: -v
==1161== 
==1161== Conditional jump or move depends on uninitialised value(s)
==1161==    at 0x4032A049: (within /lib/libc-2.2.5.so)
==1161==    by 0x4017E44F: (within
/home/hobo/local/lib/valgrind/valgrind.so)
==1161==    by 0x403297CD: moncontrol (in /lib/libc-2.2.5.so)
==1161==    by 0x40329EB5: _mcleanup (in /lib/libc-2.2.5.so)
==1161==    by 0x40283E52: exit (in /lib/libc-2.2.5.so)
==1161==    by 0x40271154: __libc_start_main (in /lib/libc-2.2.5.so)
==1161==    by 0x80487D0: (within
/home/hobo/cvs/topaz/micans/mcl/shtest/tst)
==1161== 
==1161== Invalid free() / delete / delete[]
==1161==    at 0x40167B8B: free (vg_clientfuncs.c:185)
==1161==    by 0x40329ED8: _mcleanup (in /lib/libc-2.2.5.so)
==1161==    by 0x40283E52: exit (in /lib/libc-2.2.5.so)
==1161==    by 0x40271154: __libc_start_main (in /lib/libc-2.2.5.so)
==1161==    by 0x80487D0: (within
/home/hobo/cvs/topaz/micans/mcl/shtest/tst)
==1161==    Address 0x40375024 is not stack'd, malloc'd or free'd
==1161== 
==1161== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0)
==1161== malloc/free: in use at exit: 233 bytes in 3 blocks.
==1161== malloc/free: 4 allocs, 2 frees, 234 bytes allocated.
==1161== For a detailed leak analysis,  rerun with: --leak-check=yes
==1161== For counts of detected errors, rerun with: -v

recompiling with '-g -Wall -pedantic -ansi -O2' and without -pg
make the errors go away.

Is it obvious that I should not use -pg, or should valgrind do
just fine with -pg and must I further investigate this stuff (and
post a minimal example) ? - or does -pg not mix with some of the
other gcc options I am using?

I checked the web docs, and failed in finding an answer there.

regards,
Stijn

Re: [Valgrind-users] Using valgrind with interactive console apps

[Nicholas N. <nj...@ca...>]

On Thu, 19 Jun 2003 Sun...@ut... wrote:

> Is there a way to have Valgrind allow for user interactivity? Basically I
> have a threaded app, with the main function in a loop, looking for gets().
> A menu is provided to the user if any key is entered, and further input is
> received from this point onwards (basically in the form of a question). The
> other threads use the values from the interactive menu/user input for
> processing.
>
> I could not get Valgrind to allow for the user input portion - rather the
> process starts, and all user input causes the app to not proceed.

Valgrind should cope fine in this situation.  It might be a bug that's
causing the problem, but you'll have to give us more information to be
able to tell.  If you can strip your program down to a small example that
exhibits the problem, even better.

N

[Valgrind-users] Using valgrind with interactive console apps

[<Sun...@ut...>]

Is there a way to have Valgrind allow for user interactivity? Basically I
have a threaded app, with the main function in a loop, looking for gets().
A menu is provided to the user if any key is entered, and further input is
received from this point onwards (basically in the form of a question). The
other threads use the values from the interactive menu/user input for
processing.

I could not get Valgrind to allow for the user input portion - rather the
process starts, and all user input causes the app to not proceed.

Cheers.

Re: [Valgrind-users] Help understanding error.

[Michael L. <in...@pa...>]

> Beats me.  Looks like you're not compiling with g++, as I don't
> recognise the name mangling scheme for _GLOBAL__I__ZN12MyApp4_ptrE.  Ar=
e
> you using the Intel compiler?  Perhaps it's generating bad code.

Here is the compile environment:

Linux 2.4.21 #1 SMP i686 AMD Athlon(tm) MP 2200+ AuthenticAMD GNU/Linux

gcc (GCC) 3.2.2  glibc-2.3.1-r4

AM_CXXFLAGS=09=3D -march=3Dathlon-mp -g -O -Wall -pipe -pthread=09\
=09-fstack-check =09=09=09=09=09=09\
=09-I@top_srcdir@/src/include =09=09=09\
=09-I@top_srcdir@/gui/plot=09=09=09=09\
=09-I/usr/include/postgresql/server=09\
=09-I${QTDIR}/include=09=09=09=09=09\
=09-DQT_THREAD_SUPPORT=09=09=09=09=09\
=09-D_GNU_SOURCE=09=09=09=09=09=09

Re: [Valgrind-users] Help getting started

[Michael L. <in...@pa...>]

That was the problem.  Did it like this:

export WANT_AUTOMAKE=3D1.6; ./autogen.sh

The build then completed.  Thank you.

Re: [Valgrind-users] Help getting started

[Olly B. <ol...@su...>]

On Thu, Jun 19, 2003 at 09:03:51AM +0100, Nicholas Nethercote wrote:
> On Wed, 18 Jun 2003, Michael Labhard wrote:
> 
> > So downloaded from CVS but it would not build.
> > vg_constants.h:35:31: vg_constants_skin.h: No such file or directory
> 
> That's strange... do you have a file named include/vg_constants_skin.h?
> Maybe your checkout from SourceForge was somehow incomplete?  I can't
> think of any other reason why this might happen.

I ran into this recently.  The problem is that valgrind needs automake
1.6 or newer - AM_CCASFLAGS is ignored by automake 1.4 and 1.5, and so
the vg_dispatch.S is built without the -I switches in add_includes:

gcc  -mpreferred-stack-boundary=2 -c `test -f vg_dispatch.S || echo './'`vg_dispatch.S

The easiest fix is to insist on a newer automake - add this line to
coregrind/Makefile.am (putting it first is conventional):

AUTOMAKE_OPTIONS = 1.6

Cheers,
    Olly

RE: [Valgrind-users] Help understanding error.

[Vincent Penquerc'h <Vin...@ar...>]

> _GLOBAL__I__ZN12MyApp4_ptrE is not in your code, so there's a good(?)
> chance it's not your fault.

It looks very much like "static MyApp*	_ptr;" to me...

The occurence of

(/usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.2/include/g++-v3/bits/stl_set.h:102)

could hint at a bug in the ctor of MyApp which would wrongly use
a std::set object ?

-- 
Vincent Penquerc'h 

Re: [Valgrind-users] Help understanding error.

[Nicholas N. <nj...@ca...>]

On Wed, 18 Jun 2003, Michael Labhard wrote:

> ==10037== Invalid write of size 4
> ==10037==    at 0x408F3E14: _GLOBAL__I__ZN12MyApp4_ptrE
> (/usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.2/include/g++-v3/bits/stl_set.h:102)
> ==10037==    by 0x408F72B4: (within
> /home/mel/Projects/src/.libs/libmyapp.so.0.0.0)
> ==10037==    by 0x408C4110: (within
> /home/mel/Projects/src/.libs/libmyapp.so.0.0.0)
> ==10037==    by 0x4000AD4B: call_init (in /lib/ld-2.3.1.so)
> ==10037==    Address 0xBFFFE1C4 is not stack'd, malloc'd or free'd

_GLOBAL__I__ZN12MyApp4_ptrE is not in your code, so there's a good(?)
chance it's not your fault.

Valgrind says "Address 0xBFFFE1C4 is not stack'd, malloc'd or free'd" but
0xBFFFE1C4 looks like a stack address, maybe that code is writing just
beneath the stack pointer.  You could try the --workaround-gcc296-bugs=yes
option which skips that check.  You could also try to reduce the program
to a small example and see if it still happens;  if so you can probably be
more confident that it's not your fault, in which case suppressing it
would be appropriate.

N

Re: [Valgrind-users] Help getting started

[Nicholas N. <nj...@ca...>]

On Wed, 18 Jun 2003, Michael Labhard wrote:

> Starting to use valgrind and I find many errors that I want to suppress.
> Using 1.9.6.  Tried valgrind --gen-suppression but this version did not seem
> to recognize the option.  So downloaded from CVS but it would not build.
> Please advise.  Thank you.

> vg_constants.h:35:31: vg_constants_skin.h: No such file or directory

That's strange... do you have a file named include/vg_constants_skin.h?
Maybe your checkout from SourceForge was somehow incomplete?  I can't
think of any other reason why this might happen.

N

Re: [Valgrind-users] Help understanding error.

[Bryan O'S. <bo...@se...>]

On Wed, 2003-06-18 at 21:57, Michael Labhard wrote:

> What is the problem with this?  Thank you.

Beats me.  Looks like you're not compiling with g++, as I don't
recognise the name mangling scheme for _GLOBAL__I__ZN12MyApp4_ptrE.  Are
you using the Intel compiler?  Perhaps it's generating bad code.

	<b

[Valgrind-users] Help understanding error.

[Michael L. <in...@pa...>]

Please assist in explaining this output.  It regards a class varaiable=20
declared


=09static MyApp*=09_ptr;

and defined with

=09MyApp* MyApp::_ptr;

It is being initialized and released with:

=09static MyApp& GetRef()
=09{=09
=09=09if( 0 =3D=3D _ptr )
=09=09=09_ptr =3D new MyApp;
=09=09return *_ptr;
=09}

=09static void shutdown()
=09{=20
=09=09delete _ptr;=20
=09=09_ptr =3D 0;
=09}

valgrind output:

=3D=3D10037=3D=3D Invalid write of size 4
=3D=3D10037=3D=3D    at 0x408F3E14: _GLOBAL__I__ZN12MyApp4_ptrE=20
(/usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.2/include/g++-v3/bits/stl_set.h:1=
02)
=3D=3D10037=3D=3D    by 0x408F72B4: (within=20
/home/mel/Projects/src/.libs/libmyapp.so.0.0.0)
=3D=3D10037=3D=3D    by 0x408C4110: (within=20
/home/mel/Projects/src/.libs/libmyapp.so.0.0.0)
=3D=3D10037=3D=3D    by 0x4000AD4B: call_init (in /lib/ld-2.3.1.so)
=3D=3D10037=3D=3D    Address 0xBFFFE1C4 is not stack'd, malloc'd or free'=
d
=3D

What is the problem with this?  Thank you.

-- Michael

[Valgrind-users] Help getting started

[Michael L. <in...@pa...>]

Starting to use valgrind and I find many errors that I want to suppress. =
=20
Using 1.9.6.  Tried valgrind --gen-suppression but this version did not s=
eem=20
to recognize the option.  So downloaded from CVS but it would not build. =
=20
Please advise.  Thank you.

-- Michael


 Here is the build output:

Making all in .
make[3]: Entering directory=20
`/home/mel/Installs/valgrind-CVS/valgrind/coregrind'
source=3D'vg_replace_malloc.c' object=3D'vg_replace_malloc.o' libtool=3Dn=
o \
depfile=3D'.deps/vg_replace_malloc.Po' tmpdepfile=3D'.deps/vg_replace_mal=
loc.TPo'=20
\
depmode=3Dgcc3 /bin/sh ../depcomp \
gcc -DHAVE_CONFIG_H -I. -I. -I..  -I./demangle -I../include -I.=20
-DVG_LIBDIR=3D"\"/home/mel/local/lib"\"   -Winline -Wall -Wshadow -O=20
-fomit-frame-pointer -mpreferred-stack-boundary=3D2 -g=20
-mpreferred-stack-boundary=3D2 -fno-omit-frame-pointer -c `test -f=20
vg_replace_malloc.c || echo './'`vg_replace_malloc.c
rm -f lib_replace_malloc.a
ar cru lib_replace_malloc.a vg_replace_malloc.o
ranlib lib_replace_malloc.a
source=3D'vg_scheduler.c' object=3D'vg_scheduler.o' libtool=3Dno \
depfile=3D'.deps/vg_scheduler.Po' tmpdepfile=3D'.deps/vg_scheduler.TPo' \
depmode=3Dgcc3 /bin/sh ../depcomp \
gcc -DHAVE_CONFIG_H -I. -I. -I..  -I./demangle -I../include -I.=20
-DVG_LIBDIR=3D"\"/home/mel/local/lib"\"   -Winline -Wall -Wshadow -O=20
-fomit-frame-pointer -mpreferred-stack-boundary=3D2 -g=20
-mpreferred-stack-boundary=3D2 -c `test -f vg_scheduler.c || echo=20
'./'`vg_scheduler.c
source=3D'vg_default.c' object=3D'vg_default.o' libtool=3Dno \
depfile=3D'.deps/vg_default.Po' tmpdepfile=3D'.deps/vg_default.TPo' \
depmode=3Dgcc3 /bin/sh ../depcomp \
gcc -DHAVE_CONFIG_H -I. -I. -I..  -I./demangle -I../include -I.=20
-DVG_LIBDIR=3D"\"/home/mel/local/lib"\"   -Winline -Wall -Wshadow -O=20
-fomit-frame-pointer -mpreferred-stack-boundary=3D2 -g=20
-mpreferred-stack-boundary=3D2 -c `test -f vg_default.c || echo=20
'./'`vg_default.c
source=3D'vg_demangle.c' object=3D'vg_demangle.o' libtool=3Dno \
depfile=3D'.deps/vg_demangle.Po' tmpdepfile=3D'.deps/vg_demangle.TPo' \
depmode=3Dgcc3 /bin/sh ../depcomp \
gcc -DHAVE_CONFIG_H -I. -I. -I..  -I./demangle -I../include -I.=20
-DVG_LIBDIR=3D"\"/home/mel/local/lib"\"   -Winline -Wall -Wshadow -O=20
-fomit-frame-pointer -mpreferred-stack-boundary=3D2 -g=20
-mpreferred-stack-boundary=3D2 -c `test -f vg_demangle.c || echo=20
'./'`vg_demangle.c
gcc  -mpreferred-stack-boundary=3D2 -c `test -f vg_dispatch.S || echo=20
'./'`vg_dispatch.S
In file included from vg_dispatch.S:32:
vg_constants.h:35:31: vg_constants_skin.h: No such file or directory
make[3]: *** [vg_dispatch.o] Error 1
make[3]: Leaving directory=20
`/home/mel/Installs/valgrind-CVS/valgrind/coregrind'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory=20
`/home/mel/Installs/valgrind-CVS/valgrind/coregrind'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/mel/Installs/valgrind-CVS/valgrind'
make: *** [all] Error 2

Re: [Valgrind-users] Valgrind does not display any messages

[Olly B. <ol...@su...>]

On Tue, Jun 17, 2003 at 10:04:15AM -0500, Sarcar, Shourya C (MED) wrote:
> But when I run this with a particular program (I call it 've'), the
> program executes but Valgrind prints out no messages at all.
> The only outputs are the printfs from the executable (ve).

This is FAQ #5.

It probably means 've' is statically linked.  Try running ldd on ve:

ldd ve

This will say "not a dynamic executable" if ve is statically linked.  In
order to hook into execution, valgrind uses LD_PRELOAD tricks which only
work for dynamically linked executables.

Which reminds me that I wrote a quick patch to add a test for this case
(attached).  Not sure if it's worth the overhead or not, but I might as
well post it rather than leaving it sitting on my harddisk...

Cheers,
    Olly

Re: [Valgrind-users] Valgrind does not display any messages

[Nicholas N. <nj...@ca...>]

On Tue, 17 Jun 2003, Sarcar, Shourya C (MED) wrote:

> When I run Valgrind with any program (ls, ps, even my own HEllo ,
> World), Valgrind displays messages.
> But when I run this with a particular program (I call it 've'), the
> program executes but Valgrind prints out no messages at all.
> The only outputs are the printfs from the executable (ve).
>
> I have tried running with the -v option but to no avail.

From valgrind/FAQ.txt:

Q5. I try running "valgrind my_program", but my_program runs normally,
    and Valgrind doesn't emit any output at all.

A5. Is my_program statically linked?  Valgrind doesn't work with
    statically linked binaries.  my_program must rely on at least one
    shared object.  To determine if a my_program is statically linked,
    run:

      ldd my_program

    It will show what shared objects my_program relies on, or say:

      not a dynamic executable

    if my_program is statically linked.


N

[Valgrind-users] Valgrind does not display any messages

[Sarcar, S. C (MED) <Sho...@me...>]

I am a new Valgrind user

When I run Valgrind with any program (ls, ps, even my own HEllo ,
World), Valgrind displays messages.
But when I run this with a particular program (I call it 've'), the
program executes but Valgrind prints out no messages at all.
The only outputs are the printfs from the executable (ve).

I have tried running with the -v option but to no avail.

Shourya

Re: [Valgrind-users] Using helgrind with recycled objects

[Jeremy F. <je...@go...>]

On Tue, 2003-06-17 at 02:56, Stephane Donze wrote:
> Is it possible to configure the errors reported by helgrind ?
> 
> My multithreaded program uses object recycling to avoid wasting time in
> malloc'ing tons of small objects, so that when a thread T1 uses an
> object, it has often been allocated by another thread T2, and will
> probably be reused by a thread T3 before being freed by a thread T4. As
> a result, the error log produced by helgrind contains zillions of errors
> like this:
> 
> ==21303== Thread 28:
> ==21303== Possible data race writing variable at 0x42DBE028 
> ==21303==    at 0x40971949: 
> [snip]
> ==21303==    by 0x404FC422: thread_wrapper (vg_libpthread.c:671)
> ==21303==    by 0x4009B27C: do__quit (vg_scheduler.c:2154)
> ==21303==   Address 0x42DBE028 is 4 bytes inside a block of size 232
> alloc'd by thread 1
> ==21303==    at 0x400973AF: malloc (vg_clientfuncs.c:103)
> ==21303==    by 0x400978C2: realloc (vg_clientfuncs.c:268)
> 
> 
> is there a simple way to tell helgrind not to report this kind of error
> ?

In your allocator, use VALGRIND_HG_CLEAN_MEMORY(addr, len) to tell
Helgrind that you're recycling memory, and it should forget what it knew
about it.

	J

RE: [Valgrind-users] thread errors on non-threaded program

[Vincent Penquerc'h <Vin...@ar...>]

If the routine isn't recursive, just add "static" in front of your
local array, this will statically allocate it in the bss section
rather than dynamically on the stack. As for stack size, I don't
really know, maybe someone on the list knows.

-- 
Vincent Penquerc'h 

> -----Original Message-----
> From: Geert Fannes [mailto:gee...@es...]
> Sent: Tuesday, June 17, 2003 5:31 PM
> To: Vincent Penquerc'h
> Subject: Re: [Valgrind-users] thread errors on non-threaded program
> 
> 
> thank you for your response, it helped a lot! i allocated a 
> large array 
> at the beginning of that function in a stupid manner:
> 
> bool GRV::bLoadRVsFromFile(GDLLpGBaseObject *pRVList,const char 
> *strPathNameRV,const char *strPathNameCPD,bool bFilterStrict)
> {
>    FILE* pFileIn;
>    long lNrRVs = 0,lNrCPDs = 0,lNrElementsInRVList,i;
>    !!!char strBuffer[5000000]!!!;
> ...
> 
> instead of using:
> 
> new char[5000000];
> 
> do you have any idea how large my stack (or heap?) is? (i 
> mean the place 
> where local variables are located, like the char strBuffer[5000000].)
> 
> greets,
> geert.
> 
> 
> Vincent Penquerc'h wrote:
> >>hello, i have a monolythic C++ program (3766634 bytes) for which 
> >>valgrind gives errors like beneath. i don't know what these 
> >>errors mean, 
> >>but i don't trust the threaded stuff in it, since my program is 
> >>non-threaded (i even don't exactly know what a threaded 
> >>program is, i'm 
> >>guessing that it has to do with forking etc.)
> > 
> > 
> > Not quite. Forking creates a new process, threads are different
> > (I guess you could call them micro processes) running in the same
> > data space, albeit with different stacks.
> > In your case, you have a thread. Every program has a thread, but
> > a program is said to be threaded if it has more than 1 thread.
> > Your program is not threaded, but the "thread 1" message below
> > just says errors come the main program thread, which is, in your
> > case, your program's default thread.
> > 
> > 
> > 
> >>where can i find more information about the origin of the 
> >>error and the 
> >>error itself (i'm guessing that 15180 is some error code)? 
> > 
> > 
> > It's the process ID.
> > 
> > 
> >>==15180== Invalid write of size 1
> >>==15180==    at 0x80C3FDC: 
> >>GRV::bLoadRVsFromFile(GDLLpGBaseObject*, char 
> >>const*, char const*, bool) (GRV.cpp:346)
> >>==15180==    Address 0xBFB388EF is on thread 1's stack
> >>==15180==
> >>==15180== Invalid write of size 4
> >>==15180==    at 0x80C3FE2: 
> >>GRV::bLoadRVsFromFile(GDLLpGBaseObject*, char 
> >>const*, char const*, bool) (GRV.cpp:357)
> >>==15180==    Address 0xBFB388E4 is on thread 1's stack
> > 
> > 
> > Your program seems to be writing something in a memory location
> > which is not accessible. I'm not exactly sure about the error
> > message formats, but it looks like it's trying to write under
> > the stack pointer (which could be the result of a buffer overflow
> > in a local auto array). I'm not very used to Valgrind yet, so
> > I could be wrong on that diagnostic, so I'll let the pros figure
> > it out :)
> > 
> 
> 
> 

Re: [Valgrind-users] thread errors on non-threaded program

[Nicholas N. <nj...@ca...>]

On Tue, 17 Jun 2003, Geert Fannes wrote:

> hello, i have a monolythic C++ program (3766634 bytes) for which
> valgrind gives errors like beneath. i don't know what these errors mean,
> but i don't trust the threaded stuff in it, since my program is
> non-threaded (i even don't exactly know what a threaded program is, i'm
> guessing that it has to do with forking etc.)

Threads aren't quite the same as forking, although there are similarities.
But that doesn't matter in this case; you can ignore the "thread 1's
stack" bit, if your program doesn't use threads then everything runs in a
single thread which has the number 1.

The errors mean your program is writing to memory it shouldn't;  since
this memory is on your program's stack, maybe you're writing beneath the
stack pointer... maybe you are overrunning the bounds of a stack-allocated
array?

> where can i find more information about the origin of the error and the
> error itself (i'm guessing that 15180 is some error code)? did someone
> have the same error? is my program too big? why is the --num-caller not
> working for this error, while it is for others?
>
> valgrind --leak-check=yes --num-callers=30 ./test
>
> ==15180== Invalid write of size 1
> ==15180==    at 0x80C3FDC: GRV::bLoadRVsFromFile(GDLLpGBaseObject*, char
> const*, char const*, bool) (GRV.cpp:346)
> ==15180==    Address 0xBFB388EF is on thread 1's stack
> ==15180==
> ==15180== Invalid write of size 4
> ==15180==    at 0x80C3FE2: GRV::bLoadRVsFromFile(GDLLpGBaseObject*, char
> const*, char const*, bool) (GRV.cpp:357)
> ==15180==    Address 0xBFB388E4 is on thread 1's stack

15180 is the process ID number.  I'm not sure why you don't get a larger
stack trace, that is a bit odd.  But at least you have the exact lines at
which the invalid writes are happening, hopefully that's enough to find
them?

N

[Valgrind-users] thread errors on non-threaded program

[Geert F. <gee...@es...>]

hello, i have a monolythic C++ program (3766634 bytes) for which 
valgrind gives errors like beneath. i don't know what these errors mean, 
but i don't trust the threaded stuff in it, since my program is 
non-threaded (i even don't exactly know what a threaded program is, i'm 
guessing that it has to do with forking etc.)

where can i find more information about the origin of the error and the 
error itself (i'm guessing that 15180 is some error code)? did someone 
have the same error? is my program too big? why is the --num-caller not 
working for this error, while it is for others?

thnx,
geert.

valgrind --leak-check=yes --num-callers=30 ./test

==15180== Invalid write of size 1
==15180==    at 0x80C3FDC: GRV::bLoadRVsFromFile(GDLLpGBaseObject*, char 
const*, char const*, bool) (GRV.cpp:346)
==15180==    Address 0xBFB388EF is on thread 1's stack
==15180==
==15180== Invalid write of size 4
==15180==    at 0x80C3FE2: GRV::bLoadRVsFromFile(GDLLpGBaseObject*, char 
const*, char const*, bool) (GRV.cpp:357)
==15180==    Address 0xBFB388E4 is on thread 1's stack

Re: [Valgrind-users] Swap Space Problem

[John R. <jr...@Bi...>]

Olly Betts wrote:
> On Mon, Jun 16, 2003 at 06:57:07PM -0700, John Reiser wrote:
>>Insure++ for Linux/x86 has a "no preparation required" checking mode
>>which for large processes has a memory overhead factor close to 1/4
>>[total usage while monitoring is a factor of about (1 + 1/4) times the
>>non-monitored usage].
> 
> 
> Is this mode similar to valgrind's --skin=addrcheck?  According to the
> documentation, that has an overhead of about 1/8 (compared to 9/8 for
> memcheck).
> 
> Or does 1/4 mean that it's also tracking validity at the byte level
> (rather than at the bit level as memcheck does)?

It tracks addressability, and contents validity at the byte level.  So some
uses of bitfields trigger "false positive" complaints the first time.
[This can help identify performance bottlenecks.  Compilers may generate
slow code for consecutive accesses to adjacent bitfields.]
Also, the factor of 1/4 does not count the usual "red zone" padding
around allocated blocks.  The red zone can be adjusted, trading off
depth of traceback that is recorded at malloc and free.

If the original complaint
-----
VG_(get_memory_from_mmap): request for 8192 bytes failed.
VG_(get_memory_from_mmap): 2119042790 bytes already allocated.
-----
arose when many large blocks (say, several megabytes each) had been
free()d recently, then the delayed free list may be hoarding the space.
Reduce the length of the delayed free list, and try again.  This gives
you less protection for "referenced after being free()d", of course.

Re: [Valgrind-users] Re: --gen-suppressions prompting

[Leonard m. <spa...@ya...>]

--- Madhu M Kurup <mm...@ya...> wrote:
> Aargh. Should have explained this better:
> 
> --gen-suppressions=no (obvious)
> --gen-suppressions=yes (just like before, will ask you for each, dump
to stdout)
> --gen-suppressions=filename (will create filename.pidX and dump
there, no prompting at all)
>  
> I wanted to maintain backward compat with the previous usage...
> 
> 	Does that explain it?

Yes.  Thanks.

Randall


__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com

Re: [Valgrind-users] Swap Space Problem

[Olly B. <ol...@su...>]

On Mon, Jun 16, 2003 at 06:57:07PM -0700, John Reiser wrote:
> Mitchell Kang wrote:
> >VG_(get_memory_from_mmap): request for 8192 bytes failed.
> >VG_(get_memory_from_mmap): 2119042790 bytes already allocated.
> > 
> >This may mean that you have run out of swap space,
> >since running programs on valgrind increases their memory
> >usage at least 3 times.
> 
> Insure++ for Linux/x86 has a "no preparation required" checking mode
> which for large processes has a memory overhead factor close to 1/4
> [total usage while monitoring is a factor of about (1 + 1/4) times the
> non-monitored usage].

Is this mode similar to valgrind's --skin=addrcheck?  According to the
documentation, that has an overhead of about 1/8 (compared to 9/8 for
memcheck).

Or does 1/4 mean that it's also tracking validity at the byte level
(rather than at the bit level as memcheck does)?

Cheers,
    Olly

[Valgrind-users] Using helgrind with recycled objects

[Stephane D. <ste...@ex...>]

Is it possible to configure the errors reported by helgrind ?

My multithreaded program uses object recycling to avoid wasting time in
malloc'ing tons of small objects, so that when a thread T1 uses an
object, it has often been allocated by another thread T2, and will
probably be reused by a thread T3 before being freed by a thread T4. As
a result, the error log produced by helgrind contains zillions of errors
like this:

==21303== Thread 28:
==21303== Possible data race writing variable at 0x42DBE028 
==21303==    at 0x40971949: 
[snip]
==21303==    by 0x404FC422: thread_wrapper (vg_libpthread.c:671)
==21303==    by 0x4009B27C: do__quit (vg_scheduler.c:2154)
==21303==   Address 0x42DBE028 is 4 bytes inside a block of size 232
alloc'd by thread 1
==21303==    at 0x400973AF: malloc (vg_clientfuncs.c:103)
==21303==    by 0x400978C2: realloc (vg_clientfuncs.c:268)


is there a simple way to tell helgrind not to report this kind of error
?

Thanks
Stephane
 

[Valgrind-users] SIGSEGV in helgrind

[Stephane D. <ste...@ex...>]

Hello all,

I'm trying to use helgrind on my programs, but the first attempt gave me
the following messages:

==11449== Warning: SIGSEGV not in user code; either from syscall kill()
==11449==    or possible Valgrind bug.  This message is only shown 3
times.
==11449== Warning: SIGSEGV not in user code; either from syscall kill()
==11449==    or possible Valgrind bug.  This message is only shown 3
times.
==11449== Warning: SIGSEGV not in user code; either from syscall kill()
==11449==    or possible Valgrind bug.  This message is only shown 3
times.

The program seems to go on after these messages, but does not produce
any other output nor helgrind log. I kept it running several minutes
like this, and nothing happened except that the process takes 100% CPU
load (about 75% system and 25% user)

I'm running a Mandrake 9.1 system (kernel 2.4.21-0.13mdk, gcc 3.2.2,
glibc lsb-2.3.1)

Stephane