EXCEPTION_ACCESS_VIOLATION when using ucrt64 libs with clang64

[avelure]

In #976 I reported having problem with an exception being thrown when running from the native commandline.
But I was testing something else and realized this is a general problem caused by the order in my PATH variable.
I recently changed to have msys64/ucrt64/bin in front of msys64/clang64/bin, so I assume it is picking up a dll or something that is not completely compatible.

Is there a simple way to debug this further to find the culprit, or is it something that can be solved in NVC?

*** Caught exception c0000005 (EXCEPTION_ACCESS_VIOLATION) [address=000000000000930C, ip=000000000000930C] ***

[00007FF77A7E3140]
[00007FF77A7E34F9]
[00007FF809DD0B0C] UnhandledExceptionFilter+0x1ec
[00007FF80C9F987D] RtlCopyMemory+0x2bbd
[00007FF80C9DF6A7] _C_specific_handler+0x97
[00007FF80C9F51DF] _chkstk+0x12f
[00007FF80C96E866] RtlFindCharInUnicodeString+0xa96
[00007FF80C9F41CE] KiUserExceptionDispatcher+0x2e
[000000000000930C]

nvc 1.14.0 (1.14.0.r7.g4cb3822b) (Using LLVM 18.1.8) [x86_64-w64-mingw32]

Please report this bug at https://github.com/nickg/nvc/issues`

0x000000000000930c in ?? ()
(gdb) bt
#0  0x000000000000930c in ?? ()
#1  0x00007fffc9dc1593 in .Ltlab_alloc () from C:\proj\public\minimal\work\_WORK.TEST.elab.dll
#2  0x0000000000000002 in ?? ()
#3  0x00007fffc9dc3050 in WORK.TEST.P_PROC.descr () from C:\proj\public\minimal\work\_WORK.TEST.elab.dll
#4  0x000000000063a020 in ?? ()
#5  0x000000000063a070 in ?? ()
#6  0xc4ceb9fe1a85ec53 in ?? ()
#7  0x00007fffc9dc14dd in WORK.TEST () from C:\proj\public\minimal\work\_WORK.TEST.elab.dll
#8  0x00007ff77a8b8a07 in jit_try_vcall (j=0x63a020, f=0x60bbf0, result=0x14f0d0, args=0x14f100, tlab=0x14f0e0) at ../src/jit/jit-core.c:666
#9  0x00007ff77a8a6e07 in jit_fastcall (j=0x8, handle=<optimized out>, result=0x14f0d0, p1=..., p2=..., tlab=0x14f0e0) at ../src/jit/jit-core.c:760
#10 reset_scope (m=0x2297970, s=0x22560c0) at ../src/rt/model.c:1049
#11 0x00007ff77a8a6e40 in reset_scope (m=0x2297970, s=0x60b940) at ../src/rt/model.c:1061
#12 0x00007ff77a7d98df in model_reset (m=0x2297970) at ../src/rt/model.c:2378
#13 run_cmd (argc=2, argv=0x5bb648, state=0x14fe20) at ../src/nvc.c:852
#14 process_command (argc=2, argv=0x5bb648, state=0x14fe20) at ../src/nvc.c:2117
#15 0x00007ff77a7dc188 in elaborate (argc=2, argv=0x14efe0, state=0x14fe20) at ../src/nvc.c:533
#16 process_command (argc=4, argv=0x5bb638, state=0x14fe20) at ../src/nvc.c:2115
#17 0x00007ff77a7d290b in main (argc=8, argv=0x14efe0) at ../src/nvc.c:2257

* thread #1, stop reason = Exception 0xc0000005 encountered at address 0x00930c: User-mode data execution prevention (DEP) violation at location 0x0000930c
    frame #0: 0x000000000000930c
error: Only part of a ReadProcessMemory or WriteProcessMemory request was completed.
(lldb) bt
* thread #1, stop reason = Exception 0xc0000005 encountered at address 0x00930c: User-mode data execution prevention (DEP) violation at location 0x0000930c
  * frame #0: 0x000000000000930c
    frame #1: 0x00007fffd8d01593 _WORK.TEST.elab.dll`.Ltlab_alloc + 35
    frame #2: 0x00007fffd8d014dd _WORK.TEST.elab.dll`WORK.TEST + 93
    frame #3: 0x00007ff77a8b8a07 nvc.exe`jit_try_vcall(j=0x00000261b209e5d0, f=0x00000261b20d8350, result=0x000000921cafebd0, args=0x000000921cafec00, tlab=0x000000921cafebe0) at jit-core.c:666:7
    frame #4: 0x00007ff77a8a6e07 nvc.exe`reset_scope [inlined] jit_fastcall(j=<unavailable>, handle=<unavailable>, result=0x000000921cafebd0, p1=<unavailable>, p2=(integer = 0, pointer = 0x0000000000000000, real = 0), tlab=0x000000921cafebe0) at jit-core.c:760:11
    frame #5: 0x00007ff77a8a6dd5 nvc.exe`reset_scope(m=0x00000261b208a7f0, s=0x00000261b3b45bd0) at model.c:1049:11
    frame #6: 0x00007ff77a8a6e40 nvc.exe`reset_scope(m=0x00000261b208a7f0, s=0x00000261b206b5a0) at model.c:1061:7
    frame #7: 0x00007ff77a7d98df nvc.exe`process_command [inlined] model_reset(m=0x00000261b208a7f0) at model.c:2378:4
    frame #8: 0x00007ff77a7d976f nvc.exe`process_command [inlined] run_cmd(argc=2, argv=0x00000261b2021ac8, state=0x000000921caff920) at nvc.c:852:4
    frame #9: 0x00007ff77a7d8a1a nvc.exe`process_command(argc=2, argv=0x00000261b2021ac8, state=0x000000921caff920) at nvc.c:2117:14
    frame #10: 0x00007ff77a7dc188 nvc.exe`process_command [inlined] elaborate(argc=2, argv=<unavailable>, state=0x000000921caff920) at nvc.c:533:22
    frame #11: 0x00007ff77a7dbe28 nvc.exe`process_command(argc=4, argv=0x00000261b2021ab8, state=0x000000921caff920) at nvc.c:2115:14
    frame #12: 0x00007ff77a7d290b nvc.exe`main(argc=<unavailable>, argv=<unavailable>) at nvc.c:2257:20
    frame #13: 0x00007ff77a7c1313 nvc.exe`__tmainCRTStartup at crtexe.c:259:15
    frame #14: 0x00007ff77a7c1366 nvc.exe`mainCRTStartup at crtexe.c:180:9
    frame #15: 0x00007ff80a85257d kernel32.dll`BaseThreadInitThunk + 29
    frame #16: 0x00007ff80c9aaf28 ntdll.dll`RtlUserThreadStart + 40
(lldb)

[nickg]

Try ldd from an MSYS shell on nvc.exe and the DLL in the working library directory (e.g. _WORK.TEST.elab.dll above). Is it also a problem if you elaborate with --jit? One problem might be that the the generated DLL is linked against the nvc.exe that produced it (should see that in the ldd output).

[avelure]

Here is the ldd output, if I elaborate with --jit the issue disappears.

$ ldd /clang64/bin/nvc
        ntdll.dll => /c/Windows/SYSTEM32/ntdll.dll (0x7ff80c950000)
        KERNEL32.DLL => /c/Windows/System32/KERNEL32.DLL (0x7ff80a840000)
        KERNELBASE.dll => /c/Windows/System32/KERNELBASE.dll (0x7ff809c70000)
        apphelp.dll => /c/Windows/SYSTEM32/apphelp.dll (0x7ff801260000)
        ucrtbase.dll => /c/Windows/System32/ucrtbase.dll (0x7ff80a3d0000)
        zlib1.dll => /clang64/bin/zlib1.dll (0x7fffdd1d0000)
        dbghelp.dll => /c/Windows/SYSTEM32/dbghelp.dll (0x7ff8072b0000)
        libzstd.dll => /clang64/bin/libzstd.dll (0x7fff8f8a0000)
        libffi-8.dll => /clang64/bin/libffi-8.dll (0x7ff803de0000)
        combase.dll => /c/Windows/System32/combase.dll (0x7ff80a910000)
        libcapstone.dll => /clang64/bin/libcapstone.dll (0x7fff35000000)
        RPCRT4.dll => /c/Windows/System32/RPCRT4.dll (0x7ff80b8e0000)
        libLLVM-18.dll => /clang64/bin/libLLVM-18.dll (0x7ffefb560000)
        SHELL32.dll => /c/Windows/System32/SHELL32.dll (0x7ff80bc00000)
        OLEAUT32.dll => /c/Windows/System32/OLEAUT32.dll (0x7ff80a760000)
        msvcp_win.dll => /c/Windows/System32/msvcp_win.dll (0x7ff80a4f0000)
        msvcp_win.dll => /c/Windows/System32/msvcp_win.dll (0x222d53d0000)
        USER32.dll => /c/Windows/System32/USER32.dll (0x7ff80c5a0000)
        win32u.dll => /c/Windows/System32/win32u.dll (0x7ff80a320000)
        GDI32.dll => /c/Windows/System32/GDI32.dll (0x7ff80b3b0000)
        gdi32full.dll => /c/Windows/System32/gdi32full.dll (0x7ff80a200000)
        ole32.dll => /c/Windows/System32/ole32.dll (0x7ff80aca0000)
        ADVAPI32.dll => /c/Windows/System32/ADVAPI32.dll (0x7ff80ae60000)
        msvcrt.dll => /c/Windows/System32/msvcrt.dll (0x7ff80bb10000)
        sechost.dll => /c/Windows/System32/sechost.dll (0x7ff80af20000)
        bcrypt.dll => /c/Windows/System32/bcrypt.dll (0x7ff80a650000)
        WS2_32.dll => /c/Windows/System32/WS2_32.dll (0x7ff80b3e0000)
        libc++.dll => /clang64/bin/libc++.dll (0x7fff89e60000)
        libxml2-2.dll => /clang64/bin/libxml2-2.dll (0x7fff82e50000)
        liblzma-5.dll => /clang64/bin/liblzma-5.dll (0x7fffd4e70000)
        libiconv-2.dll => /clang64/bin/libiconv-2.dll (0x7fff7d610000)

$ ldd /c/proj/public/minimal/work/_WORK.TEST.elab.dll
        ntdll.dll => /c/Windows/SYSTEM32/ntdll.dll (0x7ff80c950000)
        KERNEL32.DLL => /c/Windows/System32/KERNEL32.DLL (0x7ff80a840000)
        KERNELBASE.dll => /c/Windows/System32/KERNELBASE.dll (0x7ff809c70000)
        msvcrt.dll => /c/Windows/System32/msvcrt.dll (0x7ff80bb10000)
        ucrtbase.dll => /c/Windows/System32/ucrtbase.dll (0x7ff80a3d0000)

[nickg]

I tried various combinations of mixing up PATH between mingw64 and clang64 but couldn't reproduce this. But in my case the DLL in the work library is linked against nvc.exe:

$ ldd work/_WORK.IEEE1.elab.dll
        ntdll.dll => /c/Windows/SYSTEM32/ntdll.dll (0x7ffa31870000)
        KERNEL32.DLL => /c/Windows/System32/KERNEL32.DLL (0x7ffa30e50000)
        KERNELBASE.dll => /c/Windows/System32/KERNELBASE.dll (0x7ffa2f0d0000)
        msvcrt.dll => /c/Windows/System32/msvcrt.dll (0x7ffa30db0000)
        ucrtbase.dll => /c/Windows/System32/ucrtbase.dll (0x7ffa2f7a0000)
        nvc.exe => /clang64/bin/nvc.exe (0x7ff795560000)

[avelure]

I checked with sysinternal procmon for which files nvc accesses and it seems the problem could be that it is using cc from the ucrt64 path.

CLANG64
$ cc --version
clang version 18.1.8
Target: x86_64-w64-windows-gnu
Thread model: posix
InstalledDir: C:/msys64/clang64/bin

UCRT64
$ cc --version
cc.exe (Rev1, Built by MSYS2 project) 14.2.0
Copyright (C) 2024 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[nickg]

I checked with sysinternal procmon for which files nvc accesses and it seems the problem could be that it is using cc from the ucrt64 path.

Yeah I think my problem was that I had CC=clang in the configure arguments for the clang64 build so didn't see this. I think it should be fixed now (by using the full path by default). Could you test again?

[avelure]

Yes, it works now. Thanks for investigating :)