[FLASH-USERS] Big Problem??
Seyit Hocuk
seyit at astro.rug.nl
Thu Aug 14 13:03:23 EDT 2008
Hi Chris, Nathan, Carlo,
It has been a while now, but finally I had time to check some stuff.
Like Chris said I tried compiling with -CU (check uninit) and also with
-ftrapuv. The error with -CU is shown here below. However, the same
error is showing when I use normal jeans setup and a different error is
generated with Sedov test problem. I think there are many undeclared
variables or subroutines anyway. When I use -ftrapuv, I get segmentation
faults. These debug options are not much use unfortunately.
By the way, what is the use of -g when debugging. It seems like it is
doing nothing.
* JEANS SETUP
perturbation is unstable with growth time 8776137041619.21
forrtl: severe (193): Run-Time Check Failure. The variable
'poisson_mg_relax_$ERROR' is being used without being defined
Image PC Routine Line
Source
flash2 00000000005B70FE Unknown Unknown Unknown
flash2 00000000005B62FE Unknown Unknown Unknown
flash2 000000000056EB56 Unknown Unknown Unknown
flash2 0000000000536D51 Unknown Unknown Unknown
flash2 00000000005383C6 Unknown Unknown Unknown
flash2 00000000004D31E4 poisson_mg_relax_ 315
poisson_mg_relax.F90
flash2 00000000004D4DE9 poisson_mg_solve_ 38
poisson_mg_solve.F90
flash2 00000000004CA3C4 mg_cycle_ 82
mg_cycle.F90
flash2 00000000004CEEC8 multigrid_ 150
multigrid.F90
flash2 00000000004D249A poisson_ 87
poisson.F90
flash2 0000000000430CE6 modulegravpotenti 139
GravPotentialAllBlocks.F90
flash2 000000000042AF1B init_from_scratch 257
init_from_scratch.F90
flash2 000000000041D45A init_flash_ 324
init_flash.F90
flash2 000000000041C5BF MAIN__ 62
flash.F90
flash2 0000000000405362 Unknown Unknown Unknown
libc.so.6 00007F7DBB0131C4 Unknown Unknown Unknown
flash2 00000000004052A9 Unknown Unknown Unknown
* SEDOV EXPLOSION SETUP
[CHECKPOINT_WR] NOTE: will send 710 blocks per message.
[CHECKPOINT_WR] Writing checkpoint file sedov_hdf5_chk_0000
Progress: |
forrtl: severe (193): Run-Time Check Failure. The variable
'perfmon_mp_log_timers_$CHECKPT_NUM' is being used without being defined
Image PC Routine Line
Source
flash2 00000000005A1856 Unknown Unknown Unknown
flash2 00000000005A0A56 Unknown Unknown Unknown
flash2 000000000055A646 Unknown Unknown Unknown
flash2 0000000000522B81 Unknown Unknown Unknown
flash2 00000000005241F6 Unknown Unknown Unknown
flash2 00000000004CB301 perfmon_mp_log_ti 1067
perfmon.F90
flash2 0000000000465F75 checkpoint_wr_ 701
checkpoint_wr.F90
flash2 000000000045E2F6 output_initial_ 189
output_initial.F90
flash2 000000000041DB09 init_flash_ 335
init_flash.F90
flash2 000000000041CC33 MAIN__ 62
flash.F90
flash2 00000000004051E2 Unknown Unknown Unknown
libc.so.6 00007F0BCE1FF1C4 Unknown Unknown Unknown
flash2 0000000000405129 Unknown Unknown Unknown
Chris Daley wrote:
> 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
>>
>>
>
More information about the flash-users
mailing list