[Developers] Valgrind warnings

Steve White steve.white at aei.mpg.de
Sun Nov 12 11:09:44 CST 2006


Hi,

I'm trying to debug a strange problem in this JobChaining project.  I'll
describe the problem and history.  Perhaps you could provide some advice,
or try to run valgrind on your favourite code, or relate an experience.

I get a reproducible effect when running a big par file of Luca's.
The processes just run into the weeds, usually appearing to hang in
library routines.  Forced core dumps don't show a complete backtrace. 
It's stack damage.

So I ran the thing in Valgrind.  I see great numbers of warnings about
uninitialized memory being used, which at least seem to start in the
Parameters.c file.  Now, that code is generally objectionable, and features
many potential bugs, but all attempts to locate the source of this 
warning have so far failed.

My best lead on the problem at hand is this warning.

Beside this, I have tried many dozens of kinds of expreriments, but haven't
been able to make a lot of sense of what I'm seeing.

Now, a curiosity:  A build of a JobChain WaveToy with Carpet, with the same
Cactus configuration, showed no such errors when run under Valgrind.  

However, I had not updated my arrangements generally in some time, only
Carpet-dev and JobChaining were quite up-to-date; the others were some
month or two old.  When I then updated everything, the Valgrind errors
appeared in my Wavetoy *too*.  The first reports appear when Carpet is
creating certain parameters (example attached).

Note that the Valgrind complaints may reflect problems in the C
libraries.

Unfortunately, I failed to anticipate this and did not record the state
of my arrangements etc before I did the update.  I was not using
Formaline.  Yesterday, I attempted to recreate my build free from warnings
by regressing my checkouts of arrangements and the Flesh.  I had no luck. 
I don't understand.  I have asked our sysadmin to retrieve backups of the
directories involved.

Now, in LAM runs, I have always seen uninitialized memory warnings from
the LAM library.  Also, even in a very simple PUGH WaveToy, I get some use of
uninitialized memory in the evolution loop... 

But I'm very suspicious about these Parameter.c warnings right at the
beginning of Carpet runs.

Thanks for your time.

-- 
Steve White : Programmer
Max-Planck-Institut für Gravitationsphysik      Albert-Einstein-Institut
Am Mühlenberg 1, D-14476 Golm, Germany                  +49-331-567-7625
-------------- next part --------------
==11345== Conditional jump or move depends on uninitialised value(s)
==11345==    at 0x1BEDD90D: re_compile_internal (in /lib/libc-2.3.6.so)
==11345==    by 0x1BEDECA5: regcomp (in /lib/libc-2.3.6.so)
==11345==    by 0x805C921: CCTK_RegexMatch (Misc.c:1162)
==11345==    by 0x8050125: ParameterSetString (Parameters.c:2092)
==11345==    by 0x804FDB7: ParameterSetSimple (Parameters.c:1998)
==11345==    by 0x804E027: CCTKi_ParameterCreate (Parameters.c:351)
==11345==    by 0x8075BEB: CCTKi_BindingsCreateCarpetParameters (Carpet_Parameters.c:172)
==11345==    by 0x8074D6D: CCTKi_BindingsParametersInitialise (BindingsParameters.c:39)
==11345==    by 0x8055399: CCTKi_InitialiseSubsystemDefaults (Subsystems.c:51)
==11345==    by 0x804D961: CCTKi_InitialiseCactus (InitialiseCactus.c:91)
==11345==    by 0x804D89C: main (flesh.cc:64)



More information about the Developers mailing list