[Wien] ACML and gfortran strange segfaults.
Laurence Marks
L-marks at northwestern.edu
Wed Sep 8 13:55:34 CEST 2010
Sometimes a SIGSEV error message appears at the wrong place -- often
code has been overwritten so the place of the error is not where it
really is. Have you tried turning on (for the relevant codes) more
debugging options, e.g. -fbounds-check -g (check "man gfortran" and
"man gcc")
On Wed, Sep 8, 2010 at 6:35 AM, Vit <vitruss at gmail.com> wrote:
> Dear Prof. Blaha,
> At current version (just downloaded) line 53 is
> dosold1=0.d0
> As far as I know gfortran can't force I*4, but don't know about I*8 being
> default... It's possible to force only -fdefault-integer-8 and
> -fdefault-real-8.
> So I'm stuck now.
> Could you please suggest anything?
>
> With best regards,
> Victor Koroteev
>
> On Wed, 08 Sep 2010 14:42:08 +0700, Peter Blaha
> <pblaha at theochem.tuwien.ac.at> wrote:
>
>> I'm not sure if I read the output of gdb correctly and if it is of any
>> help.
>>
>> It complains about subroutine ados (line 53 ???, but this is a comment in
>> my source ?? are you using
>> the current version ??)
>> and the statement "dosold1=0.d0".
>> The latter is "problematic", because dosold1 is only real*8, but still it
>> is valid in Fortran
>> to have automatic type conversions. Furthermore, any reference to DOSOLD1
>> should occur ONLY
>> if "rxesw or rxes" is true, which should not happen in normal tetra
>> calculations.
>> ?????
>>
>> Just a guess: Since the problems occur in kgen and tetra, they could be
>> "related".
>> One guess would be, that these very old programs use integer arrays as
>> real ones
>> in some subroutines.
>> It implies that integer is I*4, while real is *8
>>
>> Could your gfortran by default use I*8 variables ? Then switch this off.
>>
>>
>> Am 08.09.2010 09:13, schrieb Vit:
>>>
>>> Here are some additions with debbugin symbols enabled and gdb:
>>>
>>> (gdb) run tetra.def Starting program: /opt/wien_2k/tetra tetra.def
>>> [Thread debugging using libthread_db enabled]
>>>
>>> Program received signal SIGSEGV, Segmentation fault. 0x00000000004073ba
>>> in ados (ns=DWARF-2 expression error: DW_OP_reg operations must be used
>>> either alone or in conjuction with
>>> DW_OP_piece. ) at ados.f:53 53 dosold1=0.d0 (gdb) bt #0
>>> 0x00000000004073ba in ados (ns=DWARF-2 expression error: DW_OP_reg
>>> operations must be used either alone or in conjuction
>>> with DW_OP_piece. ) at ados.f:53 #1 0x0000000000406292 in arbdos
>>> (nflow=DWARF-2 expression error: DW_OP_reg operations must be used either
>>> alone or in conjuction with DW_OP_piece.
>>> ) at arbdos.f:30 #2 0x0000000000404301 in tetra () at tetra.f:286 #3
>>> 0x0000000000408bea in main () #4 0x00002aaaab68ac4d in __libc_start_main ()
>>> from /lib/libc.so.6 #5
>>> 0x0000000000400f39 in _start ()
>>>
>>> Looking forward for your answer,
>>> Koroteev Victor.
>>>
>>> Dear Wien2k community!
>>> I've compiled Wien2k_10.1 with ACML and gfortran with self compiled
>>> fftw2 and scalapack. Now we have segfaults running kgen and tetra.
>>> Here is some info:
>>> kgen
>>> root at thunder /opt/wien_2k # ldd kgen
>>> linux-vdso.so.1 => (0x00007fff46d7a000)
>>> libpthread.so.0 => /lib/libpthread.so.0 (0x00002b0d86432000)
>>> libgfortran.so.3 => /usr/lib/libgfortran.so.3 (0x00002b0d8664e000)
>>> libm.so.6 => /lib/libm.so.6 (0x00002b0d8693b000)
>>> libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00002b0d86bbd000)
>>> libc.so.6 => /lib/libc.so.6 (0x00002b0d86dd3000)
>>> /lib64/ld-linux-x86-64.so.2 (0x00002b0d86212000)
>>>
>>> dmesg:
>>> [506583.894669] kgen[12028] trap divide error ip:40576a
>>> sp:7fff1c8f45a0 error:0 in kgen[400000+a000]
>>>
>>> tetra
>>> root at thunder /opt/wien_2k # ldd tetra
>>> linux-vdso.so.1 => (0x00007fffaafff000)
>>> libpthread.so.0 => /lib/libpthread.so.0 (0x00002b175df06000)
>>> libgfortran.so.3 => /usr/lib/libgfortran.so.3 (0x00002b175e122000)
>>> libm.so.6 => /lib/libm.so.6 (0x00002b175e40f000)
>>> libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00002b175e691000)
>>> libc.so.6 => /lib/libc.so.6 (0x00002b175e8a7000)
>>> /lib64/ld-linux-x86-64.so.2 (0x00002b175dce6000)
>>>
>>> dmesg:
>>> [506609.316764] tetra[12095]: segfault at 4 ip 00000000004073ba sp
>>> 00007fff95de75e0 error 6 in tetra[400000+a000]
>>>
>>> OPTIONS
>>> current:FOPT:-ffree-form -O2
>>> current:FPOPT:-ffree-form -O2
>>> current:LDFLAGS:$(FOPT) -lpthread
>>> current:DPARALLEL:'-DParallel'
>>> current:R_LIBS:-L/opt/acml4.4.0/gfortran64/lib -lacml
>>> current:RP_LIBS:-L/opt/scalapack/lib -lscalapack -lblacsF77 -lblacsC
>>> -lblacs -lblacsF77 -lblacsC -L/usr/lib/openmpi/lib -lmpi
>>> -L/opt/acml4.4.0/gfortran64/lib -lacml
>>> -L/opt/fftw2/lib -lfftw_mpi -lfftw -lm -lpthread
>>> current:MPIRUN:mpirun -n _NP_ -machinefile _HOSTS_ _EXEC_
>>>
>>> Could you please push me on where to look?
>>> With best regards,
>>> Koroteev Victor
>>> Junior researcher
>>> NIIC SB RAS.
>>>
>>> P.S. I don't want to install ifort and mkl, because it costs much for
>>> academics (and personal licenses don't suit).
>>>
>>>
>>>
>>>
>>> --
>>>
>>>
>>>
>>> _______________________________________________
>>> Wien mailing list
>>> Wien at zeus.theochem.tuwien.ac.at
>>> http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
>>
>
>
> --
> _______________________________________________
> Wien mailing list
> Wien at zeus.theochem.tuwien.ac.at
> http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
>
--
Laurence Marks
Department of Materials Science and Engineering
MSE Rm 2036 Cook Hall
2220 N Campus Drive
Northwestern University
Evanston, IL 60208, USA
Tel: (847) 491-3996 Fax: (847) 491-7820
email: L-marks at northwestern dot edu
Web: www.numis.northwestern.edu
Chair, Commission on Electron Crystallography of IUCR
www.numis.northwestern.edu/
Electron crystallography is the branch of science that uses electron
scattering and imaging to study the structure of matter.
More information about the Wien
mailing list