Non-deterministic results compiling on virtual Windows 8.1 Pro Update when using a Shared Folder

[llvmbot]

Bugzilla Link	21143
Version	3.7
OS	Windows NT
Attachments	Source code with output logs
Reporter	LLVM Bugzilla Contributor
CC	@majnemer,@zygoloid,@rnk

Extended Description

1. Install Windows 8.1 Pro Update on a virtual machine (tried with VirtualBox 4.3.16 on a Windows 7 x64 host as well as Parallels on an OS X host).

2. On the guest, install gcc-arm-embedded (https://launchpad.net/gcc-arm-embedded/4.8/4.8-2014-q3-update/+download/gcc-arm-none-eabi-4_8-2014q3-20140805-win32.exe) and LLVM (http://llvm.org/releases/3.5.0/LLVM-3.5.0-win32.exe).

3. On the host, extract the attached files. Create a VirtualBox/Parallels shared folder so the guest can access the extracted files. On the guest, use the "Map Network Drive" button to map the shared folder as drive 'E'.

4. On the guest, open the command prompt and and run the following commands:

cd "C:\Program Files\LLVM\bin"

clang -ferror-limit=0 -isystem "C:\Program Files\GNU Tools ARM Embedded\4.8 2014q3\lib\gcc\arm-none-eabi\4.8.4\include" -isystem "C:\Program Files\GNU Tools ARM Embedded\4.8 2014q3\lib\gcc\arm-none-eabi\4.8.4\include-fixed" -isystem "C:\Program Files\GNU Tools ARM Embedded\4.8 2014q3\arm-none-eabi\include" -IE:\Doorbell.Bundle01\Doorbell.cydsn -IE:\Doorbell.Bundle01\Doorbell.cydsn\Generated_Source\PSoC4 -c E:\Doorbell.Bundle01\Doorbell.cydsn\main.c -o E:\Doorbell.Bundle01\Doorbell.cydsn\main.o

It may be necessary to change the paths to "Program Files (x86)" if using a 64-bit guest. main.c contains a syntax error and is not expected to compile correctly.

5. Repeat the command several times. You get different numbers of errors/warnings and sometimes get stuck in an infinite (?) loop. While stuck in this loop the memory usage keeps increasing. Log files for 16 consecutive runs have been included in the attachment. Note: file12.txt was an infinite loop that was eventually interrupted with Ctrl+C. file4.txt contains the expected results.

Note: I saw a similar issue when calling clang_createTranslationUnitFromSourceFile with the same source files.

[llvmbot]

This issue still exists in 3.7.0.

[llvmbot]

Just had another user run into this. He was running Win7-64 via Parallels on the Mac, source file on drop-box. Moving it to local directory works around problem. My company will pay to get this fixed.

[rnk]

Maybe this is related to inode reuse, as described in http://llvm.org/pr21705?

[rnk]

Any chance of getting this fixed before you drop support for Windows XP?

I looked at the logs you attached some time ago, but I have no idea what went wrong. We'll have to wait until someone has time replicate this setup.

[llvmbot]

Any chance of getting this fixed before you drop support for Windows XP?

[llvmbot]

Note: the same issue can be seen with Windows 7 Pro with the rest of the setup the same (virtual machine with a shared folder).

[llvmbot]

Preprocessed source The preprocessor produces inconsistent results. Some examples are attached. Sometimes the preprocessor fails with errors (an example of this is also attached).

clang -ferror-limit=0 -isystem "C:\Program Files\GNU Tools ARM Embedded\4.8 2014q3\lib\gcc\arm-none-eabi\4.8.4\include" -isystem "C:\Program Files\GNU Tools ARM Embedded\4.8 2014q3\lib\gcc\arm-none-eabi\4.8.4\include-fixed" -isystem "C:\Program Files\GNU Tools ARM Embedded\4.8 2014q3\arm-none-eabi\include" -IE:\Doorbell.Bundle01\Doorbell.cydsn -IE:\Doorbell.Bundle01\Doorbell.cydsn\Generated_Source\PSoC4 -E E:\Doorbell.Bundle01\Doorbell.cydsn\main.c

[rnk]

I have a feeling that an asserts build would reveal the problem earlier. Does the problem reproduce if you preprocess the source? Either way, can you attach that?