[FLASH-USERS] Big Problem??

[Chris Daley]

Hi Seyit,

I fully agree with Carlo's recommendation - Valgrind is an excellent
tool.  However, before resorting to such a powerful tool, it may be
worthwhile using your compiler to detect uninitialised data.  I notice
that you have the intel compiler on two of your computing platforms.

Try adding "-check uninit" and "-traceback" to your Fortran
(debug) compilation options.  This will check if an uninitialised variable
is used in a calculation, and will generate a runtime error if it is used.

I've just run a mini test in which I used a variable in my 
Simulation_initBlock.F90
that is never initialised.   Here is the output:

forrtl: severe (193): Run-Time Check Failure. The variable 
'simulation_initblock_$PP' is being used without being defined
Image              PC                Routine            Line        Source
flash3             00000000006B010B  Unknown               Unknown  Unknown
flash3             00000000006AE446  Unknown               Unknown  Unknown
flash3             00000000006878DE  Unknown               Unknown  Unknown
flash3             000000000065CEB2  Unknown               Unknown  Unknown
flash3             000000000065D147  Unknown               Unknown  Unknown
flash3             000000000049D3DC  simulation_initbl          88  
Simulation_initBlock.F90
flash3             000000000044F05B  Unknown               Unknown  Unknown
flash3             000000000040E152  Unknown               Unknown  Unknown
flash3             000000000041211D  Unknown               Unknown  Unknown
flash3             0000000000404A6A  Unknown               Unknown  Unknown
libc.so.6          000000355501C3FB  Unknown               Unknown  Unknown
flash3             00000000004049AA  Unknown               Unknown  Unknown
p0_31573:  p4_error: interrupt SIGx: 13

Remember to compile your code in "debug" mode, i.e. to
include the -g compilation flag and no optimisations.

You may also want to look at the option "-ftrapuv" which initialises
local stack variables to "unusual values".  Further information about
all of these options can be found in the intel man page.

Regards,
Chris


Carlo Graziani wrote:
> Hi Seyit.
>
> Nathan's suggestion of investigating un-initialized variables use
> and erratically allocated/deallocated memory is very sensible for
> tracking down a problem that manifests itself as unpredictable behavior.
>
> There is actually an open-source tool for doing this called valgrind.
> It may already be installed on your local linux systems, and if not it
> is easy enough to obtain.
>
> One runs a program under valgrind very simply (the documentation gives
> more options):
>
> Prompt> valgrind <program-name> <program arguments>
>
> Then one sits back and digests the potentially-voluminous output.
>
> Valgrind will flag any access to uninitialized memory and 
> memory-management
> screw-ups.
>
> Caveats are: 
> (1) It's slow;
>
> (2) You'd be amazed at how much valgrind finds distasteful in system
> libraries.  You'll probably have to filter away a bunch of uninteresting
> warnings about libc/mpi/hdf5 and so on (which are probably harmless,
> and which you can't do much about anyway).  Valgrind has some facilities
> for suppressing certain types of warnings, which you can use to cut down
> the noise.
>
> If you can make a small version of the problem, running on one 
> processor, that
> exhibits the erratic behavior, this would probably be an ideal case to
> feed to valgrind.  There's some support for parallel debugging, but 
> you'd probably
> have to spend some quality time with documentation and haunt some other
> mailing lists to get that running.
>
> Cheers,
>
> Carlo
>
> Nathan Hearn wrote:
>> Hi Seyit,
>>
>>     An uninitialized variable is one that is declared (specified as
>> integer, real, etc.), but not assigned a value.  Thus, an
>> uninitialized variable usually has whatever value was in its memory
>> location before it was declared.  (It could be a random number,
>> "infinity," or just garbage.)  If this variable gets used before a
>> value is assigned to it, strange behavior may result, which would be
>> very compiler- and architecture-specific).  If you are using
>> uninitialized pointer or allocatable variables, the effects can be
>> quite drastic and hard to identify.
>>
>>     Generally speaking, it is a good idea to assign a value to every
>> variable soon after it is declared, even if it is only a temporary
>> value that is not actually used.  (As I recall, there is a way to
>> assign a null value to pointers, which is also a very useful
>> practice.)
>>
>>
>> - Nathan
>>
>>
>> On 8/4/08, Seyit Hocuk <seyit at astro.rug.nl> wrote:
>>> Hi Paul, hi Nathan,
>>>
>>> First of all; using --with-default-api-version=v16 when configuring
>>> hdf5-1.8.1 works fine. Thanks for that Paul.
>>>
>>> Nathan, if you mean by uninitialized that the types are not defined
>>> (like in config file REAL or INTEGER or whatever), then no because I
>>> define them all. But if you mean I have included modules or parameters
>>> which I don't use, that's correct and I am no expert in programming so
>>> it might indeed be good to check this.
>>>
>>> Greetz,
>>> Seyit
>
>