[Developers] Valgrind warnings

[Steve White]

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.

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)
> 


-- 
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 --------------
#include <sys/types.h>
#include <regex.h>
#include <stdio.h>

int CCTK_RegexMatch(const char *string,
                    const char *pattern,
                    const int nmatch,
                    regmatch_t *pmatch)

{
  int status = 0;
  regex_t re;
  if (regcomp(&re, pattern, REG_EXTENDED) == 0)
    {
    printf( "%s, '%s'\n", "doing regexec", string );
      status = regexec(&re, string, (size_t)nmatch, pmatch, 0);
      regfree(&re);
    }
  else
    return 1;
  return status;
}

int
Util_IntInRange( int inval, const char * range)
{
  regmatch_t pmatch[6];

  return CCTK_RegexMatch(range,
                     "(\\[|\\()?([^]):]*):?([^]):]*)?:?([^]):]*)?(\\]|\\))?",
                     6, pmatch) != 0;
}


int
main()
{
  char fakerange[10];
  fakerange[0] = '0';
  fakerange[1] = ':';
  fakerange[2] = '5';
  fakerange[3] = '\0';	/* delete this to cause memory error*/
  fakerange[4] = '\0';

  if( Util_IntInRange( 5, fakerange) )
    printf( "%s", "yes!\n" );
  else
    printf( "%s", "no.\n" );
  return 0;
}