[FLASH-USERS] Problem with Compiling Flash3.0

[Rusty Lusk]

Just in case, did you call MPI_Init_thread?

Rusty

On Wednesday,Jun 4, 2008, at 1:29 PM, Seyit Hocuk wrote:

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