[FLASH-USERS] Problem with Compiling Flash3.0

[Chris Daley]

Hi Seyit,

Is the failure happening when you run using one processor also?

For one processor, an easy way to determine which line is causing the 
crash is to use gdb.

 From console type:  gdb flash3
Run the code by typing: r
When code crashes type: bt
This generates a stack backtrace which, now we have compiled in 'debug' 
mode,
will tell you where the problem occurred with line level detail.

(For parallel debugging, type: mpirun -np x -gdb flash3).

Or, if you have a core file type: gdb -c corefile flash3
Once again type: bt

Finally, please ensure that FFLAGS_DEBUG in Makefile.h includes the -g 
flag.  This
is what gives us the line level detail.

Regards,
Chris


Seyit Hocuk wrote:
> Hi Nathan,
>
> -debug (meaning without -fast) results in the same segmentation fault. 
> This new compiler gives me a headache.
>
> Seyit.
>
>
>
>
> Nathan Hearn wrote:
>> Hi Seyit,
>>
>>     Looking at the compiler output that you showed, I don't see any
>> warnings.  The "remark" statements that you see are just the Intel
>> compiler's way of declaring that it produced vectorized (SSE2+) code
>> for some of the loops.  (The compiler is apparently very happy when
>> this happens...)  But yes, there is certainly a problem at runtime.
>>
>>     I noticed that you are using fairly aggressive optimizations
>> (i.e., the "-fast -ipo" flags in FFLAGS_OPT).  Have you tested the
>> code without optimizations?  (Running setup with the -debug flag will
>> result in the FFLAGS_DEBUG options being used instead of FFLAGS_OPT.)
>>
>>
>> - Nathan
>>
>>
>>
>> On Tue, Jun 3, 2008 at 9:56 AM, Seyit Hocuk <seyit at astro.rug.nl> wrote:
>>  
>>> Hi,
>>>
>>> Putting the correct HDF5 path solved only part of the problem. I 
>>> still have
>>> a lot of warnings and the simulation does not start, giving the 
>>> error below,
>>> even though making ends with success. Both for FLASH2.5 and for 
>>> FLASH3.0.
>>>
>>> Regards,
>>> Seyit.
>>>