[Developers] Valgrind warnings

[Steve White]

Ian,


On 14.11.06, Ian Hinder wrote:
> 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?
> 
You're right.  (This has been brought up before, and called a bug, but
nobody has done anything about it.)

I suppose it makes sense to try compiling it with optimizations
explicitly turned off, but based on the results of my small example,
this is unlikely to change the outcome.

Thanks!


> 
> > 
> > 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
> _______________________________________________
> Developers mailing list
> Developers at cactuscode.org
> http://www.cactuscode.org/mailman/listinfo/developers
> 

-- 
Steve White : Programmer
Max-Planck-Institut für Gravitationsphysik      Albert-Einstein-Institut
Am Mühlenberg 1, D-14476 Golm, Germany                  +49-331-567-7625