[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