[Wien] Segfault in runsp -so (lapw1), gfortran 6.4 on mac os sierra
Gavin Abo
gsabo at crimson.ua.edu
Thu Sep 21 07:21:42 CEST 2017
In your traceback, there is:
#1 0x1090555ec in zlatd4_
/Users/hugstr/src/WIEN2k_17alpha_20170920_1100/SRC_lapwso/lap_bp.f:4427
On line 4427 of SRC_lapwso/lap_bp.f in WIEN2k 17.1, there is:
ABP(I1I)
In the same file,
Line 4212 has:
COMPLEX*16 ABP( * )
Line 4242-4243 has:
! ABP (input/output) COMPLEX*16 array,
! dimension (1:n*(n+1)/2+(n/hb+1)*hb*(hb-1)/2)
In SRC_lapwso/hmsec.F, line 4 has:
USE param
Line 771 has:
allocate (hso(num2))
In hmsec, it looks like the zhhevx call passes hso to variable AP that
later gets passed to ABP.
In SRC_lapwso/modules.F:
MODULE param
INTEGER :: num2= 0
Line 205 in SRC_lapwso/lapwso.F:
num2= nume2*(nume2+1)/2+(nume2/hblock+1)*(hblock*(hblock-1)/2)
I'm not completely sure, but I wonder if the error is caused because in
PROGRAM lapwso of lapwso.F there is not a line:
USE param
On 9/20/2017 5:52 AM, Hugo Strand wrote:
> Adding debug symbols in lapwso with "-g -ggdb" gives the full
> backtrace showing line numbers in the source code where the invalid
> memory access occurs (lap_bp.f:4427), see below.
>
> Best, Hugo
>
> [NiO] $ runsp -so
> STOP LAPW0 END
> Note: The following floating-point exceptions are signalling:
> IEEE_UNDERFLOW_FLAG
> STOP LAPW1 END
> Note: The following floating-point exceptions are signalling:
> IEEE_UNDERFLOW_FLAG
> STOP LAPW1 END
> ASAN:DEADLYSIGNAL
> =================================================================
> ==50875==ERROR: AddressSanitizer: SEGV on unknown address
> 0x00088d7a3c70 (pc 0x7fffaca48086 bp 0x7fff56c4fff0 sp 0x7fff56c4fff0 T0)
> #0 0x7fffaca48085 in APL_stbmvUTN_AVX
> (/System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib+0xa5085)
> #1 0x1090555ec in zlatd4_
> /Users/hugstr/src/WIEN2k_17alpha_20170920_1100/SRC_lapwso/lap_bp.f:4427
> #2 0x109051ece in zhhtr4_
> /Users/hugstr/src/WIEN2k_17alpha_20170920_1100/SRC_lapwso/lap_bp.f:3933
> #3 0x10905133f in zhhtrd_
> /Users/hugstr/src/WIEN2k_17alpha_20170920_1100/SRC_lapwso/lap_bp.f:4164
> #4 0x109068425 in zhhevx_
> /Users/hugstr/src/WIEN2k_17alpha_20170920_1100/SRC_lapwso/lap_bp.f:3244
> #5 0x1090032c6 in hmsec_
> /Users/hugstr/src/WIEN2k_17alpha_20170920_1100/SRC_lapwso/hmsec.F:790
> #6 0x10902750b in MAIN__
> /Users/hugstr/src/WIEN2k_17alpha_20170920_1100/SRC_lapwso/lapwso.F:592
> #7 0x109027b74 in main
> /Users/hugstr/src/WIEN2k_17alpha_20170920_1100/SRC_lapwso/lapwso.F:2
> #8 0x7fffc511b234 in start (/usr/lib/system/libdyld.dylib+0x5234)
> #9 0x1 (<unknown module>)
>
> AddressSanitizer can not provide additional info.
> SUMMARY: AddressSanitizer: SEGV
> (/System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib+0xa5085)
> in APL_stbmvUTN_AVX
> ==50875==ABORTING
>
> Program received signal SIGABRT: Process abort signal.
>
> Backtrace for this error:
> #0 0x1092a8e26
> #1 0x1092a85ec
> #2 0x7fffc532ab39
>
> > stop error
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20170920/7833aaa2/attachment.html>
More information about the Wien
mailing list