[Wien] Segfault in runsp -so (lapw1), gfortran 6.4 on mac os sierra
Hugo Strand
hugo.strand at gmail.com
Wed Sep 20 14:04:23 CEST 2017
The segfault persists also when disabling optimisation using "-O0" for
gfortran. Best, H
On Wed, Sep 20, 2017 at 1:52 PM, Hugo Strand <hugo.strand at gmail.com> 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
>
>
> On Wed, Sep 20, 2017 at 9:44 AM, Hugo Strand <hugo.strand at gmail.com>
> wrote:
>
>> Dear Wien2k experts,
>>
>> I attending the Wien2k workshop and I am trying to run the exercises on
>> my own laptop. However attempting to do spin orbit calculations on NiO as
>> described in,
>>
>> http://susi.theochem.tuwien.ac.at/events/ws2017/notes/tutori
>> al_AFM_LDA+U_SO.pdf
>>
>> yields a segfault in lapw1 when running runsp -so. (The gga and gga+u
>> calculations works fine only the SOC cases fail.) I am using mac os Sierra
>> (v10.12.6) and gfortran 6.4.0 installed using MacPorts.
>>
>> I have recompiled Wien2k with -fsanitize=address which gives a partial
>> backtrace, see below. I have searched the mailing list for issues relating
>> to gfortran, segfaults, and mac os without finding anything. I am posting
>> the issue here after talking to Prof. Blaha.
>>
>> Any guidance on how to debug this would be warmly welcome.
>>
>> Best regards,
>> Hugo Strand
>>
>> --
>> Postdoc/Maître-assistant
>> Strongly correlated quantum materials (Prof. A. Georges)
>>
>> Department of Quantum Matter Physics
>> Université de Genève, Ecole de Physique
>> 24, Quai Ernest-Ansermet
>> CH-1211 Geneva 4
>> Switzerland
>>
>>
>> [NiOso] $ runsp -so
>> STOP LAPW0 END
>> =================================================================
>> ==64736==ERROR: AddressSanitizer: global-buffer-overflow on address
>> 0x0001099a7746 at pc 0x000109cac8b9 bp 0x7fff562d9d10 sp 0x7fff562d94c0
>> READ of size 7 at 0x0001099a7746 thread T0
>> #0 0x109cac8b8 in wrap_strlen.part.110 (/opt/local/lib/gcc6/libasan.3
>> .dylib+0x278b8)
>> #1 0x7fffacd29aa3 in DTREVC (/System/Library/Frameworks/Ac
>> celerate.framework/Versions/A/Frameworks/vecLib.framework/Ve
>> rsions/A/libLAPACK.dylib+0x1ffaa3)
>> #2 0x7fffacd29a71 in DTREVC (/System/Library/Frameworks/Ac
>> celerate.framework/Versions/A/Frameworks/vecLib.framework/Ve
>> rsions/A/libLAPACK.dylib+0x1ffa71)
>> #3 0x10993f6ea in dscgst_ (/Users/hugstr/src/WIEN2k_17.1
>> _debug_attempt/lapw1+0x10001b6ea)
>>
>> 0x0001099a7746 is located 0 bytes to the right of global variable '*lC3'
>> defined in 'dscgst_tmp_.F' (0x1099a7740) of size 6
>> SUMMARY: AddressSanitizer: global-buffer-overflow
>> (/opt/local/lib/gcc6/libasan.3.dylib+0x278b8) in wrap_strlen.part.110
>> Shadow bytes around the buggy address:
>> 0x100021334e90: f9 f9 f9 f9 00 05 f9 f9 f9 f9 f9 f9 00 00 00 00
>> 0x100021334ea0: 00 02 f9 f9 f9 f9 f9 f9 00 00 02 f9 f9 f9 f9 f9
>> 0x100021334eb0: 00 00 00 00 00 f9 f9 f9 f9 f9 f9 f9 07 f9 f9 f9
>> 0x100021334ec0: f9 f9 f9 f9 00 00 03 f9 f9 f9 f9 f9 00 f9 f9 f9
>> 0x100021334ed0: f9 f9 f9 f9 07 f9 f9 f9 f9 f9 f9 f9 00 00 00 00
>> =>0x100021334ee0: 01 f9 f9 f9 f9 f9 f9 f9[06]f9 f9 f9 f9 f9 f9 f9
>> 0x100021334ef0: 00 00 00 00 00 f9 f9 f9 f9 f9 f9 f9 00 01 f9 f9
>> 0x100021334f00: f9 f9 f9 f9 05 f9 f9 f9 f9 f9 f9 f9 00 00 00 00
>> 0x100021334f10: 00 04 f9 f9 f9 f9 f9 f9 01 f9 f9 f9 f9 f9 f9 f9
>> 0x100021334f20: 04 f9 f9 f9 f9 f9 f9 f9 06 f9 f9 f9 f9 f9 f9 f9
>> 0x100021334f30: 01 f9 f9 f9 f9 f9 f9 f9 01 f9 f9 f9 f9 f9 f9 f9
>> Shadow byte legend (one shadow byte represents 8 application bytes):
>> Addressable: 00
>> Partially addressable: 01 02 03 04 05 06 07
>> Heap left redzone: fa
>> Heap right redzone: fb
>> Freed heap region: fd
>> Stack left redzone: f1
>> Stack mid redzone: f2
>> Stack right redzone: f3
>> Stack partial redzone: f4
>> Stack after return: f5
>> Stack use after scope: f8
>> Global redzone: f9
>> Global init order: f6
>> Poisoned by user: f7
>> Container overflow: fc
>> Array cookie: ac
>> Intra object redzone: bb
>> ASan internal: fe
>> Left alloca redzone: ca
>> Right alloca redzone: cb
>> ==64736==ABORTING
>>
>> Program received signal SIGABRT: Process abort signal.
>>
>> Backtrace for this error:
>> #0 0x109ba1e26
>> #1 0x109ba15ec
>> #2 0x7fffc532ab39
>>
>> > stop error
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20170920/354bd002/attachment.html>
More information about the Wien
mailing list