search

mstorsjo / llvm-mingw

An LLVM/Clang/LLD based mingw-w64 toolchain
Other
1.75k stars 176 forks source link

Compilation/Execution Failure on Network Drive #393

Open ronpinkas opened 5 months ago

ronpinkas commented 5 months ago

Environment Details Operating System: Windows 11 Pro 22621.3007 Mingw-LLVM Version: 17.0.6 (build 20231128-ucrt-x86_64) Clang Version: 17.0.6

Steps to Reproduce Compiled a simple C program (test.c) using clang with the following command: c:\llvm-mingw-20231128-ucrt-x86_64\bin\clang -v test.c -o test.exe. Executed the compiled program in the command prompt with test.exe. Copied the test.c file to another drive and repeated the compilation and execution process.

Expected Behavior The compiled executable test.exe should run successfully, printing the expected output ("Hello World" followed by the clang version).

Actual Behavior On the initial compilation and execution on the C drive, the program ran successfully. After moving to the Z drive, recompiling, and executing, received an error: "The system cannot execute the specified program." Additional Information The test.c file contains the following code:

#include <stdio.h>

int main(int argc, char** argv) {
    printf("Hello World");
    printf(__clang_version__);
}

Compilation and verbose output details for both C and Z drives are attached. Tried executing llvm-objdump.exe -t test.exe, but it only showed "SYMBOL TABLE:" without further details. Ming-CLang-failure-verbose.txt

Both executables have the same size 91,136 but even when copying the Z drive exe to C drive it exhibits the same issues:

  1. Can't be executed.
  2. Symbol Table is empty.
mstorsjo commented 5 months ago

Without looking closer at this, this sounds like it possibly could be the same issue as https://github.com/mstorsjo/llvm-mingw/issues/327. That one should be fixed in the upcoming LLVM 18.x which still be released in the next few months. If you grab the latest nightly build from https://github.com/mstorsjo/llvm-mingw/releases/nightly, you should be able to test if it that fixes it for you.

ronpinkas commented 5 months ago

May very well be, because in my real project I also had intermittent errors like:

... (many more) In file included from source\common\hbarch.c:53: In file included from source\common\hbarch.c:53: In file included from source\common\hbarch.c:53: source\common\hbarch.c:53:10: error: #include nested too deeply

and other ODD errors (project build and test successfully with numerous compilers).

When attempting to reduce, I found that even the smallest simplest source will compile/link "correctly" but results in invalid executable. The problem manifested when EITHER the source OR the toolchain was stored on a "network" drive (VirtualBox host folder shared with Windows 11 VM). Needless to say NOT a permission issue. I will try latest nightly build asap and will report back.

ronpinkas commented 5 months ago

FWIW, our sizable project (xBase Compiler, Interpreter, RTL) compiles links and tests successfully once moved to the C drive. Kudos and thanks.

mstorsjo commented 5 months ago

The problem manifested when EITHER the source OR the toolchain was stored on a "network" drive (VirtualBox host folder shared with Windows 11 VM).

This sounds exactly like the issue that was fixed; intermittent errors, happening with either source or toolchain on the network drive, and specifically happening on VirtualBox folder sharing. (Apparently VMware folder sharing doesn't have this issue, but VirtualBox, and Remote Desktop folder sharing do have the issue.)

ronpinkas commented 5 months ago

Having just tested the latest nightly (llvm-mingw-nightly-ucrt-x86_64.zip) I am sad to report that the failure persists and is very easy to replicate.

  1. Place the simplest 'hello world' test.c on a Network Drive (VirtualBox Host folder share).
  2. C:\llvm-mingw-nightly-ucrt-x86_64\bin\clang.exe -v test.c -o test.exe

Resulting executable (no warnings nor errors) in not executable and llvm-objdump -t will report empty symbol table.

FWIW:

  1. This nightly DID SOLVE the invalid warnings and errors when attempting to build our real project (on same network drive) but the process stopped when trying to execute the first built utility, failed (same invalid executable issue).
  2. Compiling, linking, testing of real project on the C drive works flawlessly.
ronpinkas commented 5 months ago

Martin,

The intermittent errors appears to have been fixed. The remaining issue I stumbled upon is very easy to replicate and involvess NO WARNINGS NOR ERRORs, rather the generated executable is invalid.

Here is the whole simple story:

Z:>c:\llvm-mingw-nightly-ucrt-x86_64\bin\clang -v test.c -o test.exe clang version 18.0.0git (https://github.com/llvm/llvm-project.git 3edf82d5566ed5c9898f52b5591c05f6366d6bac) Target: x86_64-w64-windows-gnu Thread model: posix InstalledDir: c:/llvm-mingw-nightly-ucrt-x86_64/bin "C:/llvm-mingw-nightly-ucrt-x86_64/bin/clang-18.exe" -cc1 -triple x86_64-w64-windows-gnu -emit-obj -mrelax-all -dumpdir test.exe- -disable-free -clear-ast-before-backend -disable-llvm-verifier -discard-value-names -main-file-name test.c -mrelocation-model pic -pic-level 2 -mframe-pointer=none -fmath-errno -ffp-contract=on -fno-rounding-math -mconstructor-aliases -mms-bitfields -funwind-tables=2 -fno-use-init-array -target-cpu x86-64 -tune-cpu generic -debugger-tuning=gdb -fdebug-compilation-dir=Z:/ -v -fcoverage-compilation-dir=Z:/ -resource-dir C:/llvm-mingw-nightly-ucrt-x86_64/lib/clang/18 -internal-isystem C:/llvm-mingw-nightly-ucrt-x86_64/lib/clang/18/include -internal-isystem c:/llvm-mingw-nightly-ucrt-x86_64/x86_64-w64-mingw32/include -internal-isystem c:/llvm-mingw-nightly-ucrt-x86_64/x86_64-w64-mingw32/usr/include -internal-isystem c:/llvm-mingw-nightly-ucrt-x86_64/include -ferror-limit 19 -fmessage-length=120 -fno-use-cxa-atexit -fgnuc-version=4.2.1 -exception-model=seh -fcolor-diagnostics -faddrsig -o C:/Users/RONPIN~1/AppData/Local/Temp/test-930645.o -x c test.c clang -cc1 version 18.0.0git based upon LLVM 18.0.0git default target x86_64-w64-mingw32 ignoring nonexistent directory "c:/llvm-mingw-nightly-ucrt-x86_64/x86_64-w64-mingw32/include" ignoring nonexistent directory "c:/llvm-mingw-nightly-ucrt-x86_64/x86_64-w64-mingw32/usr/include"

include "..." search starts here:

include <...> search starts here:

C:/llvm-mingw-nightly-ucrt-x86_64/lib/clang/18/include c:/llvm-mingw-nightly-ucrt-x86_64/include End of search list. "c:/llvm-mingw-nightly-ucrt-x86_64/bin/ld.lld" -m i386pep -Bdynamic -o test.exe c:/llvm-mingw-nightly-ucrt-x86_64/x86_64-w64-mingw32/lib/crt2.o c:/llvm-mingw-nightly-ucrt-x86_64/x86_64-w64-mingw32/lib/crtbegin.o -Lc:/llvm-mingw-nightly-ucrt-x86_64/x86_64-w64-mingw32/lib -Lc:/llvm-mingw-nightly-ucrt-x86_64/x86_64-w64-mingw32/mingw/lib -Lc:/llvm-mingw-nightly-ucrt-x86_64/lib -LC:/llvm-mingw-nightly-ucrt-x86_64/lib/clang/18/lib/windows C:/Users/RONPIN~1/AppData/Local/Temp/test-930645.o -lmingw32 C:/llvm-mingw-nightly-ucrt-x86_64/lib/clang/18/lib/windows/libclang_rt.builtins-x86_64.a -lunwind -lmoldname -lmingwex -lmsvcrt -ladvapi32 -lshell32 -luser32 -lkernel32 -lmingw32 C:/llvm-mingw-nightly-ucrt-x86_64/lib/clang/18/lib/windows/libclang_rt.builtins-x86_64.a -lunwind -lmoldname -lmingwex -lmsvcrt -lkernel32 c:/llvm-mingw-nightly-ucrt-x86_64/x86_64-w64-mingw32/lib/crtend.o

Z:>test The system cannot execute the specified program.

Z:>c:\llvm-mingw-nightly-ucrt-x86_64\bin\llvm-objdump.exe -t test.exe

test.exe: file format coff-

SYMBOL TABLE:

Z:>

The source is the simplest 'hello world' sample.

Ron

On Jan 13, 2024, at 3:19 PM, Martin Storsjö @.***> wrote:

The problem manifested when EITHER the source OR the toolchain was stored on a "network" drive (VirtualBox host folder shared with Windows 11 VM).

This sounds exactly like the issue that was fixed; intermittent errors, happening with either source or toolchain on the network drive, and specifically happening on VirtualBox folder sharing. (Apparently VMware folder sharing doesn't have this issue, but VirtualBox, and Remote Desktop folder sharing do have the issue.)

— Reply to this email directly, view it on GitHub https://github.com/mstorsjo/llvm-mingw/issues/393#issuecomment-1890757836, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADYCEIZ4RMZWOR7AB5AQVU3YOLT3VAVCNFSM6AAAAABBZFCUPCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOJQG42TOOBTGY. You are receiving this because you authored the thread.

mstorsjo commented 5 months ago

Having just tested the latest nightly (llvm-mingw-nightly-ucrt-x86_64.zip) I am sad to report that the failure persists and is very easy to replicate.

  1. Place the simplest 'hello world' test.c on a Network Drive (VirtualBox Host folder share).
  2. C:\llvm-mingw-nightly-ucrt-x86_64\bin\clang.exe -v test.c -o test.exe

Resulting executable (no warnings nor errors) in not executable and llvm-objdump -t will report empty symbol table.

FWIW:

  1. This nightly DID SOLVE the invalid warnings and errors when attempting to build our real project (on same network drive) but the process stopped when trying to execute the first built utility, failed (same invalid executable issue).
  2. Compiling, linking, testing of real project on the C drive works flawlessly.

Thanks for testing! That's a shame that this issue remains.

I presume that this final remaining issue only occurs when the output executable is on the network drive - having the toolchain or the input sources on the network drive is fine, as long as the output executable is on a local file system. I would expect that the issue has to do with how lld writes the executable (via a memory mapped file).

Out of curiosity, can you share the resulting executable in this case?

I guess I'll have to try to reproduce this on VirtualBox or something similar. (I don't have VirtualBox installed myself at the moment...) The issue with intermittent errors was reproducible on Remote Desktop shared folders as well, but I'm not sure if this one appears there, I think I tested that case as well.

ronpinkas commented 5 months ago

Sure. See attached as a zip 

On Jan 13, 2024, at 4:18 PM, Martin Storsjö @.***> wrote:

Having just tested the latest nightly (llvm-mingw-nightly-ucrt-x86_64.zip) I am sad to report that the failure persists and is very easy to replicate.

Place the simplest 'hello world' test.c on a Network Drive (VirtualBox Host folder share). C:\llvm-mingw-nightly-ucrt-x86_64\bin\clang.exe -v test.c -o test.exe Resulting executable (no warnings nor errors) in not executable and llvm-objdump -t will report empty symbol table.

FWIW:

This nightly DID SOLVE the invalid warnings and errors when attempting to build our real project (on same network drive) but the process stopped when trying to execute the first built utility, failed (same invalid executable issue). Compiling, linking, testing of real project on the C drive works flawlessly. Thanks for testing! That's a shame that this issue remains.

I presume that this final remaining issue only occurs when the output executable is on the network drive - having the toolchain or the input sources on the network drive is fine, as long as the output executable is on a local file system. I would expect that the issue has to do with how lld writes the executable (via a memory mapped file).

Out of curiosity, can you share the resulting executable in this case?

I guess I'll have to try to reproduce this on VirtualBox or something similar. (I don't have VirtualBox installed myself at the moment...) The issue with intermittent errors was reproducible on Remote Desktop shared folders as well, but I'm not sure if this one appears there, I think I tested that case as well.

— Reply to this email directly, view it on GitHub https://github.com/mstorsjo/llvm-mingw/issues/393#issuecomment-1890771208, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADYCEI6GSYT3NSLAPI4JI43YOL2YZAVCNFSM6AAAAABBZFCUPCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOJQG43TCMRQHA. You are receiving this because you authored the thread.

mstorsjo commented 5 months ago

Sure. See attached as a zip 

Sorry, the zip attachment didn't seem to make it through here - can you attach it to a post via the web interface?

ronpinkas commented 5 months ago

Sorry :) test.exe.zip

mstorsjo commented 5 months ago

Sorry :) test.exe.zip

Ok, weird - this file is 89 KB (seemingly the right size) just full of zeros. That definitely sounds like a bug with the way that lld writes output files via memory mapped files.

ronpinkas commented 5 months ago

Another observation, compiling the sample on the same Z drive but directing the output to the C drive (-o c:test.exe) produces a VALID exe.

mstorsjo commented 5 months ago

I tried to reproduce this, with VirtualBox 6.1.38 (on Ubuntu 22.04), with Windows 7 as the VM, and there, an executable written to a mounted shared folder works just fine. So either the issue varies with versions of VirtualBox (or the Guest Additions), or with the version of Windows.

ronpinkas commented 5 months ago

I am on latest VB 7.0.12, MacOS 14.1.1 Host, Windows 11 Pro with Guest Additions 7.0.12. I must admit this issue got me very curious. I have used this kind of configuration for many years and never had any issue with such drive - I wonder what kind of O/S feature might the Mapped Memory file used by LLD require to cause such failure. Would you mind pointing me at the relevant code? About to board a 5 hours flight :)

mstorsjo commented 5 months ago

I must admit this issue got me very curious. I have used this kind of configuration for many years and never had any issue with such drive - I wonder what kind of O/S feature might the Mapped Memory file used by LLD require to cause such failure. Would you mind pointing me at the relevant code? About to board a 5 hours flight :)

Sorry, your flight probably already landed...

For this case, when writing the output file in LLD, we first open a file buffer, which primarily is memory mapped, here: https://github.com/llvm/llvm-project/blob/llvmorg-17.0.6/lld/COFF/Writer.cpp#L673 https://github.com/llvm/llvm-project/blob/llvmorg-17.0.6/lld/COFF/Writer.cpp#L1624-L1626 We then finally close it and flush the written contents here: https://github.com/llvm/llvm-project/blob/llvmorg-17.0.6/lld/COFF/Writer.cpp#L705

One question; when LLD ends up writing a file with all zeros in your case - did it run successfully to completion, with a success return code, or did it silently fail somewhere between opening the file and actually writing the contents?

The opening of files and memory mapping happens here: https://github.com/llvm/llvm-project/blob/llvmorg-17.0.6/llvm/lib/Support/FileOutputBuffer.cpp

Actually, LLVM seems to be using a lot of fairly tricky APIs wrt file access - we've had a bunch of issues around these files on less fancy file systems so far, regarding ramdisks and quirky network mounts. The previous issue, regarding spurious failures, is that we want to have a unique ID for each file on disk. Previously, we used FileIndex from GetFileInformationByHandle to achieve this. FileIndex is only guaranteed to be unique as long as a file handle is open. On most file systems, like NTFS, the index is unique perpetually, but on some network mounts, the index numbers are reused very often, and only unique as long as the handles are open. To avoid that, we reverted to using a hash of the canonicalized path to a file on Windows, see https://github.com/llvm/llvm-project/commit/02a37547834902ed05fa9c5d1dcc9e31c37e2182.

Secondly, for some things (in particular, I think the LLD output does this), we create a temp file and set a flag to delete the file when the process exits (in order to always clean up such temp files even if we'd crash) - and if linking succeeded we clear the flag and rename the temp file over the destination file. This flag isn't supported on all file systems though, so we do a number of workarounds to manually delete the files in those cases. See https://reviews.llvm.org/D81803 for one fix to the original issue, https://bugs.llvm.org/show_bug.cgi?id=52080 and https://github.com/mstorsjo/llvm-mingw/issues/233 for more issues related to that fix, and 177176f75c6fa3f624d6d964b9d340ce39511565 for another fix on that matter.

I think these codepaths from these last few fixes here are relevant for the LLD output file case. See https://github.com/llvm/llvm-project/blob/llvmorg-17.0.6/llvm/lib/Support/FileOutputBuffer.cpp#L45-L51 where we decide to keep a temp file and rename it over the destination path name, https://github.com/llvm/llvm-project/blob/llvmorg-17.0.6/llvm/lib/Support/Path.cpp#L1256-L1307 for the implementation of TempFile::keep(), and https://github.com/llvm/llvm-project/blob/llvmorg-17.0.6/llvm/lib/Support/Windows/Path.inc for implementations of the functions used in TempFile::keep().

ronpinkas commented 5 months ago

Martin,

In my reduced sample case the process was a single call:

clang -v test.c -o test exe

I did not get to check ERRORLEVEL since the verbose output (as provided) did not suggest any error, and I did not consider the possibility of a silent error.

I will check ERRORLEVEL and will report back.

Ron

On Sun, Jan 14, 2024, 12:48 Martin Storsjö @.***> wrote:

I must admit this issue got me very curious. I have used this kind of configuration for many years and never had any issue with such drive - I wonder what kind of O/S feature might the Mapped Memory file used by LLD require to cause such failure. Would you mind pointing me at the relevant code? About to board a 5 hours flight :)

Sorry, your flight probably already landed...

For this case, when writing the output file in LLD, we first open a file buffer, which primarily is memory mapped, here: https://github.com/llvm/llvm-project/blob/llvmorg-17.0.6/lld/COFF/Writer.cpp#L673 https://github.com/llvm/llvm-project/blob/llvmorg-17.0.6/lld/COFF/Writer.cpp#L1624-L1626 We then finally close it and flush the written contents here: https://github.com/llvm/llvm-project/blob/llvmorg-17.0.6/lld/COFF/Writer.cpp#L705

One question; when LLD ends up writing a file with all zeros in your case

  • did it run successfully to completion, with a success return code, or did it silently fail somewhere between opening the file and actually writing the contents?

The opening of files and memory mapping happens here: https://github.com/llvm/llvm-project/blob/llvmorg-17.0.6/llvm/lib/Support/FileOutputBuffer.cpp

Actually, LLVM seems to be using a lot of fairly tricky APIs wrt file access - we've had a bunch of issues around these files on less fancy file systems so far, regarding ramdisks and quirky network mounts. The previous issue, regarding spurious failures, is that we want to have a unique ID for each file on disk. Previously, we used FileIndex from GetFileInformationByHandle to achieve this. FileIndex is only guaranteed to be unique as long as a file handle is open. On most file systems, like NTFS, the index is unique perpetually, but on some network mounts, the index numbers are reused very often, and only unique as long as the handles are open. To avoid that, we reverted to using a hash of the canonicalized path to a file on Windows, see @.*** https://github.com/llvm/llvm-project/commit/02a37547834902ed05fa9c5d1dcc9e31c37e2182 .

Secondly, for some things (in particular, I think the LLD output does this), we create a temp file and set a flag to delete the file when the process exits (in order to always clean up such temp files even if we'd crash) - and if linking succeeded we clear the flag and rename the temp file over the destination file. This flag isn't supported on all file systems though, so we do a number of workarounds to manually delete the files in those cases. See https://reviews.llvm.org/D81803 for one fix to the original issue, https://bugs.llvm.org/show_bug.cgi?id=52080 and #233 https://github.com/mstorsjo/llvm-mingw/issues/233 for more issues related to that fix, and 177176f75c6fa3f624d6d964b9d340ce39511565 https://github.com/llvm/llvm-project/commit/177176f75c6fa3f624d6d964b9d340ce39511565 for another fix on that matter.

I think these codepaths from these last few fixes here are relevant for the LLD output file case. See https://github.com/llvm/llvm-project/blob/llvmorg-17.0.6/llvm/lib/Support/FileOutputBuffer.cpp#L45-L51 where we decide to keep a temp file and rename it over the destination path name, https://github.com/llvm/llvm-project/blob/llvmorg-17.0.6/llvm/lib/Support/Path.cpp#L1256-L1307 for the implementation of TempFile::keep(), and https://github.com/llvm/llvm-project/blob/llvmorg-17.0.6/llvm/lib/Support/Windows/Path.inc for implementations of the functions used in TempFile::keep().

— Reply to this email directly, view it on GitHub https://github.com/mstorsjo/llvm-mingw/issues/393#issuecomment-1891068104, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADYCEI5LYKO7WPAN2N5BIRLYORAAHAVCNFSM6AAAAABBZFCUPCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOJRGA3DQMJQGQ . You are receiving this because you authored the thread.Message ID: @.***>

ronpinkas commented 5 months ago

Better than my words:

Z:\>type test.bat
y:\llvm-mingw-nightly-ucrt-x86_64\bin\clang -v test.c -o test.exe
echo %ERRORLEVEL%
y:\llvm-mingw-nightly-ucrt-x86_64\bin\llvm-objdump -t test.exe

Z:\>type test.c
#include <stdio.h>

int main( int argc, char** argv)
{
    printf("Hello World" );
    printf( __clang_version__ );
}
Z:\>test.bat

Z:\>y:\llvm-mingw-nightly-ucrt-x86_64\bin\clang -v test.c -o test.exe
clang version 18.0.0git (https://github.com/llvm/llvm-project.git 3edf82d5566ed5c9898f52b5591c05f6366d6bac)
Target: x86_64-w64-windows-gnu
Thread model: posix
InstalledDir: y:/llvm-mingw-nightly-ucrt-x86_64/bin
 "//VBoxSvr/Download/llvm-mingw-nightly-ucrt-x86_64/bin/clang-18.exe" -cc1 -triple x86_64-w64-windows-gnu -emit-obj -mrelax-all -dumpdir test.exe- -disable-free -clear-ast-before-backend -disable-llvm-verifier -discard-value-names -main-file-name test.c -mrelocation-model pic -pic-level 2 -mframe-pointer=none -fmath-errno -ffp-contract=on -fno-rounding-math -mconstructor-aliases -mms-bitfields -funwind-tables=2 -fno-use-init-array -target-cpu x86-64 -tune-cpu generic -debugger-tuning=gdb -fdebug-compilation-dir=Z:/ -v -fcoverage-compilation-dir=Z:/ -resource-dir //VBoxSvr/Download/llvm-mingw-nightly-ucrt-x86_64/lib/clang/18 -internal-isystem //VBoxSvr/Download/llvm-mingw-nightly-ucrt-x86_64/lib/clang/18/include -internal-isystem y:/llvm-mingw-nightly-ucrt-x86_64/x86_64-w64-mingw32/include -internal-isystem y:/llvm-mingw-nightly-ucrt-x86_64/x86_64-w64-mingw32/usr/include -internal-isystem y:/llvm-mingw-nightly-ucrt-x86_64/include -ferror-limit 19 -fmessage-length=120 -fno-use-cxa-atexit -fgnuc-version=4.2.1 -exception-model=seh -fcolor-diagnostics -faddrsig -o C:/Users/RONPIN~1/AppData/Local/Temp/test-456095.o -x c test.c
clang -cc1 version 18.0.0git based upon LLVM 18.0.0git default target x86_64-w64-mingw32
ignoring nonexistent directory "y:/llvm-mingw-nightly-ucrt-x86_64/x86_64-w64-mingw32/include"
ignoring nonexistent directory "y:/llvm-mingw-nightly-ucrt-x86_64/x86_64-w64-mingw32/usr/include"
#include "..." search starts here:
#include <...> search starts here:
 //VBoxSvr/Download/llvm-mingw-nightly-ucrt-x86_64/lib/clang/18/include
 y:/llvm-mingw-nightly-ucrt-x86_64/include
End of search list.
 "y:/llvm-mingw-nightly-ucrt-x86_64/bin/ld.lld" -m i386pep -Bdynamic -o test.exe y:/llvm-mingw-nightly-ucrt-x86_64/x86_64-w64-mingw32/lib/crt2.o y:/llvm-mingw-nightly-ucrt-x86_64/x86_64-w64-mingw32/lib/crtbegin.o -Ly:/llvm-mingw-nightly-ucrt-x86_64/x86_64-w64-mingw32/lib -Ly:/llvm-mingw-nightly-ucrt-x86_64/x86_64-w64-mingw32/mingw/lib -Ly:/llvm-mingw-nightly-ucrt-x86_64/lib -L//VBoxSvr/Download/llvm-mingw-nightly-ucrt-x86_64/lib/clang/18/lib/windows C:/Users/RONPIN~1/AppData/Local/Temp/test-456095.o -lmingw32 //VBoxSvr/Download/llvm-mingw-nightly-ucrt-x86_64/lib/clang/18/lib/windows/libclang_rt.builtins-x86_64.a -lunwind -lmoldname -lmingwex -lmsvcrt -ladvapi32 -lshell32 -luser32 -lkernel32 -lmingw32 //VBoxSvr/Download/llvm-mingw-nightly-ucrt-x86_64/lib/clang/18/lib/windows/libclang_rt.builtins-x86_64.a -lunwind -lmoldname -lmingwex -lmsvcrt -lkernel32 y:/llvm-mingw-nightly-ucrt-x86_64/x86_64-w64-mingw32/lib/crtend.o

Z:\>echo 0
0

Z:\>y:\llvm-mingw-nightly-ucrt-x86_64\bin\llvm-objdump -t test.exe

test.exe:       file format coff-<unknown arch>

SYMBOL TABLE:

Z:\>
ronpinkas commented 5 months ago

Reading the verbose output more carefully I notice that on SOME of the references to Y:\ it somehow uses the origin folder name instead of the MAPPED Drive (f.e. -resource-dir ). More curious, for the system includes it also uses the 2 different notations:

#include <...> search starts here:
//VBoxSvr/Download/llvm-mingw-nightly-ucrt-x86_64/lib/clang/18/include
y:/llvm-mingw-nightly-ucrt-x86_64/include
End of search list.

Same root folder is once listed with the ORIGIN name, and the 2nd instance with the MAPPED Drive notation.

ronpinkas commented 5 months ago

This is the story when the nightly is on the C drive:

Z:\>type test.bat
c:\llvm-mingw-nightly-ucrt-x86_64\bin\clang -v test.c -o test.exe
echo %ERRORLEVEL%
c:\llvm-mingw-nightly-ucrt-x86_64\bin\llvm-objdump -t test.exe

Z:\>type test.c
#include <stdio.h>

int main( int argc, char** argv)
{
    printf("Hello World" );
    printf( __clang_version__ );
}
Z:\>test.bat

Z:\>c:\llvm-mingw-nightly-ucrt-x86_64\bin\clang -v test.c -o test.exe
clang version 18.0.0git (https://github.com/llvm/llvm-project.git 3edf82d5566ed5c9898f52b5591c05f6366d6bac)
Target: x86_64-w64-windows-gnu
Thread model: posix
InstalledDir: c:/llvm-mingw-nightly-ucrt-x86_64/bin
 "C:/llvm-mingw-nightly-ucrt-x86_64/bin/clang-18.exe" -cc1 -triple x86_64-w64-windows-gnu -emit-obj -mrelax-all -dumpdir test.exe- -disable-free -clear-ast-before-backend -disable-llvm-verifier -discard-value-names -main-file-name test.c -mrelocation-model pic -pic-level 2 -mframe-pointer=none -fmath-errno -ffp-contract=on -fno-rounding-math -mconstructor-aliases -mms-bitfields -funwind-tables=2 -fno-use-init-array -target-cpu x86-64 -tune-cpu generic -debugger-tuning=gdb -fdebug-compilation-dir=Z:/ -v -fcoverage-compilation-dir=Z:/ -resource-dir C:/llvm-mingw-nightly-ucrt-x86_64/lib/clang/18 -internal-isystem C:/llvm-mingw-nightly-ucrt-x86_64/lib/clang/18/include -internal-isystem c:/llvm-mingw-nightly-ucrt-x86_64/x86_64-w64-mingw32/include -internal-isystem c:/llvm-mingw-nightly-ucrt-x86_64/x86_64-w64-mingw32/usr/include -internal-isystem c:/llvm-mingw-nightly-ucrt-x86_64/include -ferror-limit 19 -fmessage-length=120 -fno-use-cxa-atexit -fgnuc-version=4.2.1 -exception-model=seh -fcolor-diagnostics -faddrsig -o C:/Users/RONPIN~1/AppData/Local/Temp/test-2d9dd4.o -x c test.c
clang -cc1 version 18.0.0git based upon LLVM 18.0.0git default target x86_64-w64-mingw32
ignoring nonexistent directory "c:/llvm-mingw-nightly-ucrt-x86_64/x86_64-w64-mingw32/include"
ignoring nonexistent directory "c:/llvm-mingw-nightly-ucrt-x86_64/x86_64-w64-mingw32/usr/include"
#include "..." search starts here:
#include <...> search starts here:
 C:/llvm-mingw-nightly-ucrt-x86_64/lib/clang/18/include
 c:/llvm-mingw-nightly-ucrt-x86_64/include
End of search list.
 "c:/llvm-mingw-nightly-ucrt-x86_64/bin/ld.lld" -m i386pep -Bdynamic -o test.exe c:/llvm-mingw-nightly-ucrt-x86_64/x86_64-w64-mingw32/lib/crt2.o c:/llvm-mingw-nightly-ucrt-x86_64/x86_64-w64-mingw32/lib/crtbegin.o -Lc:/llvm-mingw-nightly-ucrt-x86_64/x86_64-w64-mingw32/lib -Lc:/llvm-mingw-nightly-ucrt-x86_64/x86_64-w64-mingw32/mingw/lib -Lc:/llvm-mingw-nightly-ucrt-x86_64/lib -LC:/llvm-mingw-nightly-ucrt-x86_64/lib/clang/18/lib/windows C:/Users/RONPIN~1/AppData/Local/Temp/test-2d9dd4.o -lmingw32 C:/llvm-mingw-nightly-ucrt-x86_64/lib/clang/18/lib/windows/libclang_rt.builtins-x86_64.a -lunwind -lmoldname -lmingwex -lmsvcrt -ladvapi32 -lshell32 -luser32 -lkernel32 -lmingw32 C:/llvm-mingw-nightly-ucrt-x86_64/lib/clang/18/lib/windows/libclang_rt.builtins-x86_64.a -lunwind -lmoldname -lmingwex -lmsvcrt -lkernel32 c:/llvm-mingw-nightly-ucrt-x86_64/x86_64-w64-mingw32/lib/crtend.o

Z:\>echo 0
0

Z:\>c:\llvm-mingw-nightly-ucrt-x86_64\bin\llvm-objdump -t test.exe

test.exe:       file format coff-<unknown arch>

SYMBOL TABLE:

Z:\>

The resulting exe is still just nul bytes.

ronpinkas commented 5 months ago

Any additional info or test I may provide to help?

mstorsjo commented 5 months ago

Any additional info or test I may provide to help?

I'll try to build a test version of LLD, with a bunch of debug printouts along the relevant codepaths, to see if we can detect what's happening, or to get to know if it ends executing some unusual codepath - I'll let you know when I have something you can test.

ronpinkas commented 5 months ago

Great, thx!

On Mon, Jan 15, 2024, 17:11 Martin Storsjö @.***> wrote:

Any additional info or test I may provide to help?

I'll try to build a test version of LLD, with a bunch of debug printouts along the relevant codepaths, to see if we can detect what's happening, or to get to know if it ends executing some unusual codepath - I'll let you know when I have something you can test.

— Reply to this email directly, view it on GitHub https://github.com/mstorsjo/llvm-mingw/issues/393#issuecomment-1892816935, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADYCEIYD7FXF52HIQPUTXXLYOWSQNAVCNFSM6AAAAABBZFCUPCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOJSHAYTMOJTGU . You are receiving this because you authored the thread.Message ID: @.***>

mstorsjo commented 5 months ago

If you download https://martin.st/temp/ld.lld-debug.exe and replace your ld.lld.exe in the bin directory with this one, and retry linking a test executable, I'd be interested in looking at the output messages from that.

(Your original ld.lld.exe probably is like 3 MB, while this one is 60 MB, this is expected, as the normal one uses libLLVM-<version>.dll while this one has got the LLVM bits statically linked in, for easier testing.)

I also made another version you can try, https://martin.st/temp/ld.lld-flush.exe. See https://github.com/llvm/llvm-project/blob/llvmorg-17.0.6/llvm/lib/Support/Windows/Path.inc#L920-L952, https://github.com/llvm/llvm-project/commit/acd8791c2619f2afc0347c1bff073b32fbffb5d6 and https://github.com/llvm/llvm-project/commit/3b9b4d2156673edda50584086fbfb0d66460b4d2 - if this fixes your issue, it seems like the windows kernel bug workaround is needed even on Windows 11, with the VirtualBox shared file system.

ronpinkas commented 5 months ago

The flush version FIXED the issue: Z:>copy y:\ld.lld-flush.exe c:\llvm-mingw-nightly-ucrt-x86_64\bin\ld.lld.exe Overwrite c:\llvm-mingw-nightly-ucrt-x86_64\bin\ld.lld.exe? (Yes/No/All): y 1 file(s) copied.

Z:>c:\llvm-mingw-nightly-ucrt-x86_64\bin\clang test.c -o test.exe mapped_file_region::init, calling CreateFileMappingW MapViewOfFile succeeded mapped_file_region::init succeeded mapped_file_region::init, calling CreateFileMappingW MapViewOfFile succeeded mapped_file_region::init succeeded mapped_file_region::init, calling CreateFileMappingW MapViewOfFile succeeded mapped_file_region::init succeeded mapped_file_region::init, calling CreateFileMappingW mapped_file_region::init, calling CreateFileMappingW MapViewOfFile succeeded mapped_file_region::init succeeded mapped_file_region::init, calling CreateFileMappingW MapViewOfFile succeeded mapped_file_region::init succeeded mapped_file_region::init, calling CreateFileMappingW MapViewOfFile succeeded mapped_file_region::init succeeded mapped_file_region::init, calling CreateFileMappingW mapped_file_region::init, calling CreateFileMappingW MapViewOfFile succeeded mapped_file_region::init succeeded MapViewOfFile succeeded mapped_file_region::init succeeded MapViewOfFile succeeded mapped_file_region::init succeeded FileOutputBuffer::create(test.exe, 1, 0) createOnDiskBuffer TempFile::create(test.exe.tmp%%%%%%%) created test.exe.tmp74d0690 setDeleteDisposition failed, setting RemoveOnClose mapped_file_region::init, calling CreateFileMappingW MapViewOfFile succeeded mapped_file_region::init succeeded mapped_file_region::unmapImpl Mapping 0000000000000000 mapped_file_region::unmapImpl Mapping 0000000000000000 mapped_file_region::unmapImpl Mapping 0000000000000000 mapped_file_region::unmapImpl Mapping 0000000000000000 mapped_file_region::unmapImpl Mapping 0000028C4D5D0000 Mode 1 readwrite 1 Exe 0 hasFlushBufferKernelBug 0 mapped_file_region::unmapImpl done mapped_file_region::unmapImpl Mapping 0000000000000000 mapped_file_region::unmapImpl Mapping 0000000000000000 FileOutputBuffer::create(test.exe, 91136, 1) createOnDiskBuffer TempFile::create(test.exe.tmp%%%%%%%) created test.exe.tmpf3c1d20 setDeleteDisposition failed, setting RemoveOnClose mapped_file_region::init, calling CreateFileMappingW MapViewOfFile succeeded mapped_file_region::init succeeded mapped_file_region::unmapImpl Mapping 0000000000000000 mapped_file_region::unmapImpl Mapping 0000000000000000 mapped_file_region::unmapImpl Mapping 0000000000000000 mapped_file_region::unmapImpl Mapping 0000000000000000 OnDiskBuffer::commit mapped_file_region::unmapImpl Mapping 0000028C4F650000 Mode 1 readwrite 1 Exe 1 hasFlushBufferKernelBug 0 calling FlushFileBuffers mapped_file_region::unmapImpl done mapped_file_region::unmapImpl Mapping 0000000000000000 TempFile::keep(test.exe), RemoveOnClose 1 calling rename_handle ShouldDelete 0

Z:>test.exe Hello World18.0.0git (https://github.com/llvm/llvm-project.git 3edf82d5566ed5c9898f52b5591c05f6366d6bac) Z:>

ronpinkas commented 5 months ago

I assume the debug output is same and you don' need me to o run the -debug version?

mstorsjo commented 5 months ago

I assume the debug output is same and you don' need me to o run the -debug version?

The debug output probably is near identical, yeah. It’d be nice just for verification though, if you could test the debug version (no need to copy the output), just to double check that the issue is present there still.

(Also note, these were built from the llvm 17.0.6 release, so the bug with spurious issues with input files on the network drive is present in this build.)

ronpinkas commented 5 months ago

Yes, the bug still present in the debug version:

Z:\>copy y:ld.lld-debug.exe c:\llvm-mingw-20231128-ucrt-x86_64\bin\ld.lld.exe
Overwrite c:\llvm-mingw-20231128-ucrt-x86_64\bin\ld.lld.exe? (Yes/No/All): y
        1 file(s) copied.

Z:\>c:\llvm-mingw-20231128-ucrt-x86_64\bin\clang.exe test.c -o test.exe
mapped_file_region::init, calling CreateFileMappingW
MapViewOfFile succeeded
mapped_file_region::init succeeded
mapped_file_region::init, calling CreateFileMappingW
MapViewOfFile succeeded
mapped_file_region::init succeeded
mapped_file_region::init, calling CreateFileMappingW
MapViewOfFile succeeded
mapped_file_region::init, calling CreateFileMappingW
mapped_file_region::init succeeded
MapViewOfFile succeeded
mapped_file_region::init succeeded
mapped_file_region::init, calling CreateFileMappingW
MapViewOfFile succeeded
mapped_file_region::init succeeded
mapped_file_region::init, calling CreateFileMappingW
mapped_file_region::init, calling CreateFileMappingW
MapViewOfFile succeeded
mapped_file_region::init succeeded
MapViewOfFile succeeded
mapped_file_region::init succeeded
mapped_file_region::init, calling CreateFileMappingW
MapViewOfFile succeeded
mapped_file_region::init succeeded
mapped_file_region::init, calling CreateFileMappingW
MapViewOfFile succeeded
mapped_file_region::init succeeded
FileOutputBuffer::create(test.exe, 1, 0)
createOnDiskBuffer
TempFile::create(test.exe.tmp%%%%%%%)
created test.exe.tmp470c303
setDeleteDisposition failed, setting RemoveOnClose
mapped_file_region::init, calling CreateFileMappingW
MapViewOfFile succeeded
mapped_file_region::init succeeded
mapped_file_region::unmapImpl Mapping 0000000000000000
mapped_file_region::unmapImpl Mapping 0000000000000000
mapped_file_region::unmapImpl Mapping 0000000000000000
mapped_file_region::unmapImpl Mapping 0000000000000000
mapped_file_region::unmapImpl Mapping 0000025A03030000
Mode 1 readwrite 1 Exe 0 hasFlushBufferKernelBug 0
mapped_file_region::unmapImpl done
mapped_file_region::unmapImpl Mapping 0000000000000000
mapped_file_region::unmapImpl Mapping 0000000000000000
FileOutputBuffer::create(test.exe, 91136, 1)
createOnDiskBuffer
TempFile::create(test.exe.tmp%%%%%%%)
created test.exe.tmpeb4eee7
setDeleteDisposition failed, setting RemoveOnClose
mapped_file_region::init, calling CreateFileMappingW
MapViewOfFile succeeded
mapped_file_region::init succeeded
mapped_file_region::unmapImpl Mapping 0000000000000000
mapped_file_region::unmapImpl Mapping 0000000000000000
mapped_file_region::unmapImpl Mapping 0000000000000000
mapped_file_region::unmapImpl Mapping 0000000000000000
OnDiskBuffer::commit
mapped_file_region::unmapImpl Mapping 0000025A050F0000
Mode 1 readwrite 1 Exe 1 hasFlushBufferKernelBug 0
mapped_file_region::unmapImpl done
mapped_file_region::unmapImpl Mapping 0000000000000000
TempFile::keep(test.exe), RemoveOnClose 1
calling rename_handle
ShouldDelete 0

Z:\>test.exe
The system cannot execute the specified program.

Z:\>

I did carefully read:

https://randomascii.wordpress.com/2018/02/25/compiler-bug-linker-bug-windows-kernel-bug/

and I must humbly insist that while the flush approach solved the kernel bug, the bug I encountered appears to have nothing in common with the situation described in the article - i.e not a heavy load, not 24 core, not a timing issue etc., rather very easy to recreate - completely consistent issue. Out of curiosity I also waited minutes to "allow buffers to be flushed", and I even tried a proper shut down - I could find no way to allow Windows to "flush" the file buffers. So, I suspect the underlaying cause is not at all rare and complex as described in the article.

ronpinkas commented 5 months ago

FWIW I also tried using the mentioned sync command but its NOT functional on a "non local" drive.

ronpinkas commented 5 months ago

If I were on the lld team I would insist that this requires further investigation or it will rear its ugly head yet again, sometime in the future.

mstorsjo commented 5 months ago

It looks to me like there's two separate issues:

I don't know exactly what the contract/API docs say about writes to memory mapped files, and when one needs to use FlushFileBuffers. On the onset, it looks like the VirtualBox driver(?) has a bug for this case, which does get hidden by explicitly calling FlushFileBuffers. Since we may need to call that anyway (and since we want the written data to be flushed anyway, it shouldn't hopefully incur too much extra overhead) it might be simplest to just always call it?

ronpinkas commented 5 months ago

Yes, and I would also research specifically this VB issue since its so replicable, just to confirm that it is indeed a buffer flush matter and that you understand its underlaying cause.

I find it extremely suspicious that the chrome team will encounter such intermittent 0 bytes in linked executable issue, in 2 different tool chains, sometimes "gone" for almost a year, then appearing "randomly", and supposedly related to complex scenario involving timing, yet what a coincidence that we encounter the same issue, easily replicable for the simplest of scenarios, and now supposedly a VB issue. My experience made me very skeptical of such coincidences.

ronpinkas commented 5 months ago

[seems difficult to believe that closing such handle would not issue a flush buffers.]

ronpinkas commented 5 months ago

I am not sure how/if relevant, but I tried to create a reduced sample that uses a similar workflow, i.e. memory mapped file to the the VB Shared folder, and it works correctly without FlushFileBuffers.

#include <iostream>
#include <string>
#include <windows.h>
#include <cstdio>
#include <tchar.h>  // Include for TCHAR and related functions

void PrintLastError(int line) {
    DWORD errorMessageID = ::GetLastError();
    if(errorMessageID == 0) {
        _tprintf(_T("Operation successful.\n"));
        return;
    }

    LPTSTR messageBuffer = nullptr;
    size_t size = FormatMessage(FORMAT_MESSAGE_ALLOCATE_BUFFER | FORMAT_MESSAGE_FROM_SYSTEM | FORMAT_MESSAGE_IGNORE_INSERTS,
                                NULL, errorMessageID, MAKELANGID(LANG_NEUTRAL, SUBLANG_DEFAULT), (LPTSTR)&messageBuffer, 0, NULL);

    _tprintf(_T("Line: %d Error code %lu: %s\n"), line, errorMessageID, messageBuffer);
    LocalFree(messageBuffer);
}

int main() {

    TCHAR tempDir[MAX_PATH];
    TCHAR tempFilePath[MAX_PATH];
    TCHAR finalFilePath[MAX_PATH] = _T("Z:\\test.exe"); // Set a valid final file path

    // Get a temporary file name using %TEMP% as the directory using "test" as the prefix
    if (GetTempPath(MAX_PATH, tempDir) == 0) {
        PrintLastError(__LINE__);
        return 1;
    }   
    // Get a temporary file name using %TEMP% as the directory using "test" as the prefix
    if (!GetTempFileName(tempDir, TEXT("test"), 0, tempFilePath)) {
        PrintLastError(__LINE__);
        return 1;
    }

    // Create a file
    HANDLE hFile = CreateFile(tempFilePath, GENERIC_READ | GENERIC_WRITE, 0, NULL, CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL);

    // Create a file mapping object
    HANDLE hMapFile = CreateFileMapping(hFile, NULL, PAGE_READWRITE, 0, 1024, NULL);
    if (hMapFile == NULL) {
        PrintLastError(__LINE__);
        CloseHandle(hFile);
        return 1;
    }

    // Map a view of the file into the address space
    LPVOID pMapView = MapViewOfFile(hMapFile, FILE_MAP_ALL_ACCESS, 0, 0, 1024);
    if (pMapView == NULL) {
        PrintLastError(__LINE__);
        CloseHandle(hMapFile);
        CloseHandle(hFile);
        return 1;
    }

    // Write to the memory area
    const char data[] = "Sample Data";
    memcpy(pMapView, data, sizeof(data));

    // Unmap the file and close handles
    UnmapViewOfFile(pMapView);
    CloseHandle(hMapFile);
    CloseHandle(hFile);

    // Rename file (simulate 'keep')
    if (!MoveFile(tempFilePath, finalFilePath)) {
        PrintLastError(__LINE__);
        return 1;
    }

    _tprintf(_T("File operation completed successfully.") );
    return 0;
}
mstorsjo commented 5 months ago

I tweaked your repro example, and got it to successfully reproduce the error (on Windows 7 in VirtualBox). There were two main details missed in your repro:

#include <windows.h>
#include <stdio.h>
#include <tchar.h>  // Include for TCHAR and related functions

void PrintLastError(int line) {
    DWORD errorMessageID = GetLastError();
    if(errorMessageID == 0) {
        _tprintf(_T("Operation successful.\n"));
        return;
    }

    LPTSTR messageBuffer = NULL;
    size_t size = FormatMessage(FORMAT_MESSAGE_ALLOCATE_BUFFER | FORMAT_MESSAGE_FROM_SYSTEM | FORMAT_MESSAGE_IGNORE_INSERTS,
                                NULL, errorMessageID, MAKELANGID(LANG_NEUTRAL, SUBLANG_DEFAULT), (LPTSTR)&messageBuffer, 0, NULL);

    _tprintf(_T("Line: %d Error code %lu: %s\n"), line, errorMessageID, messageBuffer);
    LocalFree(messageBuffer);
}

int main() {
    TCHAR tempFilePath[MAX_PATH] = _T("Z:\\test.exe.tmp");
    wchar_t finalFilePath[MAX_PATH] = L"Z:\\test.exe";

    // Create a file
    HANDLE hFile = CreateFile(tempFilePath, GENERIC_READ | GENERIC_WRITE | DELETE, 0, NULL, CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL);
    if (hFile == INVALID_HANDLE_VALUE) {
        PrintLastError(__LINE__);
        return 1;
    }

    // Create a file mapping object
    HANDLE hMapFile = CreateFileMapping(hFile, NULL, PAGE_READWRITE, 0, 1024, NULL);
    if (hMapFile == NULL) {
        PrintLastError(__LINE__);
        CloseHandle(hFile);
        return 1;
    }

    // Map a view of the file into the address space
    LPVOID pMapView = MapViewOfFile(hMapFile, FILE_MAP_ALL_ACCESS, 0, 0, 1024);
    if (pMapView == NULL) {
        PrintLastError(__LINE__);
        CloseHandle(hMapFile);
        CloseHandle(hFile);
        return 1;
    }
    // Close the mapping handle; the mapping is still kept open.
    CloseHandle(hMapFile);

    // Write to the memory area
    const char data[] = "Sample Data";
    memcpy(pMapView, data, sizeof(data));

    // Unmap the file
    UnmapViewOfFile(pMapView);
//    FlushFileBuffers(hFile);

    char buf[sizeof(FILE_RENAME_INFO) + sizeof(wchar_t)*100];
    FILE_RENAME_INFO *rename = (FILE_RENAME_INFO*)buf;
    rename->ReplaceIfExists = 1;
    rename->RootDirectory = 0;
    rename->FileNameLength = wcslen(finalFilePath) * sizeof(wchar_t);
    memcpy(rename->FileName, finalFilePath, wcslen(finalFilePath) * sizeof(wchar_t));

    // Rename with SetFileInformationByHandle(FileRenameInfo)
    if (!SetFileInformationByHandle(hFile, FileRenameInfo, buf, sizeof(buf))) {
        PrintLastError(__LINE__);
        CloseHandle(hFile);
        return 1;
    }
    CloseHandle(hFile);

    _tprintf(_T("File operation completed successfully.") );
    return 0;
}
ronpinkas commented 5 months ago

Great news! :)

ronpinkas commented 5 months ago

May I expect one of the next nightly builds to fix this issue?

mstorsjo commented 5 months ago

May I expect one of the next nightly builds to fix this issue?

Not quite yet; I've yet to propose a fix upstream to LLVM, and then we'll see what the consensus will be on the fix/workaround. I'll let you know once I post it for review/discussion there.

ronpinkas commented 5 months ago

Thx. I hope for a quick consensus - nothing like a small, reduced, self contained, sample to deliver a bug notification message.

mstorsjo commented 5 months ago

I submitted a PR for this now at https://github.com/llvm/llvm-project/pull/78597.

FWIW, it would be nice if you'd like to post a bug report to VirtualBox about this issue with the driver used for their shared folders, with the repro code attached. As it doesn't seem to happen with other virtualization softwares's shared folders, it seems like a bug specific to the VirtualBox implementation.

ronpinkas commented 5 months ago

Thanks. Posted an issue to VirtualBox https://github.com/Virtualbox-OSE/Virtualbox/issues/2

mati865 commented 5 months ago

I doubt the repository you have posted in has any activity. I'd recommend using the forum or the bugtracker.

ronpinkas commented 5 months ago

Done: https://www.virtualbox.org/ticket/21967

mstorsjo commented 5 months ago

A prerelease with LLVM 18.1.0 RC 1 is out now, at https://github.com/mstorsjo/llvm-mingw/releases/tag/20240130, where this issue should be fixed.