[Developers] Valgrind warnings

[Ian Hinder]

Steve White wrote:
> Hi again,
> 
> I spoke with Erik yesterday concerning Valgrind in Cactus.  He commented
> that Valgrind didn't understand some compiler optimizations.  As 
> obvious as that is, I don't remember it having occurred to me.
> 
> But it doesn't seem to be the case here that an optimization is 
> triggering the Valgrind warnings.
> 
> First, I have a small test program (attached) that calls system routines
> similar to those in Cactus about which Valgrind is complaining.  By
> commenting out a line, you can trigger a similar complaint.
> 
> Valgrind produces the same results regardless of whether the program
> is compiled with the Intel flags
> 	-O3 -ip
> 
> Also, I have been compiling all these Cactus runs with OPTIMISE=no.

I have a vague memory that saying OPTIMISE=no just does not add any
optimization options to the command line, meaning that the default
optimization (usually -O2) is used.  Is that correct, or am I
misremembering?


> 
> So I don't think that optimization is triggering the Valgrind errors.
> 
> Cheers!
> 
> 
> On 12.11.06, Steve White wrote:
>> 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
> 
>> ==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)
>>
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Developers mailing list
> Developers at cactuscode.org
> http://www.cactuscode.org/mailman/listinfo/developers


-- 
Ian Hinder
hinder at gravity.psu.edu
http://www.gravity.psu.edu/~hinder