[FLASH-USERS] Problem with Compiling Flash3.0

[Seyit Hocuk]

Hi Chris, Tomek


Tomek, I was thinking the same thing. Though I tried with different 
mpich(2) versions. Same problem. Maybe I need to reinstall Mpich2 
completely again. I  thought the same thing, but should it not give a 
problem while compiling then.


Chris, I run 1 proc. I haven't tried with multi procs. See Below for gdb 
output.




FFLAGS_DEBUG =  -c -r8 -i4 -g -I $(MPI_PATH)/include
(-g included)

seyit at si01:~/FLASH3.0/object$ gdb flash3
GNU gdb 6.6-debian
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain 
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu"...
Using host libthread_db library "/lib/libthread_db.so.1".
(gdb) r
Starting program: /home/users/seyit/FLASH3.0/object/flash3
[Thread debugging using libthread_db enabled]
[New Thread 47309188393856 (LWP 6207)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 47309188393856 (LWP 6207)]
0x00002b07062edf08 in MPIR_ToPointer () from /usr/lib/libhdf5-1.6.5.so.0
(gdb) bt
#0  0x00002b07062edf08 in MPIR_ToPointer () from /usr/lib/libhdf5-1.6.5.so.0
#1  0x00002b07062f031f in PMPI_Comm_rank () from /usr/lib/libhdf5-1.6.5.so.0
#2  0x00000000005f0c3b in pmpi_comm_rank__ ()
#3  0x000000000040bec7 in driver_initparallel (mype=0, numprocs=0) at 
Driver_initParallel.F90:39
#4  0x000000000040b515 in driver_initflash () at Driver_initFlash.F90:84
#5  0x00000000004108fe in flash () at Flash.F90:36
(gdb)






FFLAGS_DEBUG =  -c -r8 -i4 -I $(MPI_PATH)/include
(no -g)

seyit at si01:~/FLASH3.0/object$ gdb flash3
GNU gdb 6.6-debian
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain 
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu"...
Using host libthread_db library "/lib/libthread_db.so.1".
(gdb) r
Starting program: /home/users/seyit/FLASH3.0/object/flash3
[Thread debugging using libthread_db enabled]
[New Thread 47644112931712 (LWP 19960)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 47644112931712 (LWP 19960)]
0x00002b55013dbf08 in MPIR_ToPointer () from /usr/lib/libhdf5-1.6.5.so.0
(gdb) bt
#0  0x00002b55013dbf08 in MPIR_ToPointer () from /usr/lib/libhdf5-1.6.5.so.0
#1  0x00002b55013de31f in PMPI_Comm_rank () from /usr/lib/libhdf5-1.6.5.so.0
#2  0x000000000055da6b in pmpi_comm_rank__ ()
#3  0x00000000004091d7 in driver_initparallel_ ()
#4  0x0000000000408af7 in driver_initflash_ ()
#5  0x000000000040d55d in MAIN__ ()




Chris Daley wrote:
> 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.
>>>>