[Developers] Valgrind warnings
hinder at gravity.psu.edu
Tue Nov 14 10:05:30 CST 2006
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
> So I don't think that optimization is triggering the Valgrind errors.
> On 12.11.06, Steve White wrote:
>> 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
>> 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
hinder at gravity.psu.edu
More information about the Developers