Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

On LLVM 9.0.0-1.5.2 clang.clang_createIndex() hangs indefinitely #830

Closed
mennodenhollander opened this issue Dec 18, 2019 · 9 comments
Closed
Labels

Comments

@mennodenhollander
Copy link

We updated our llvm-platform dependency from version 8.0.0-1.5.1 to 9.0.0-1.5.2. After updating we are unable to use the clang API, because it hangs on clang.clang_createIndex(). We can easily reproduce it by running the provided ClangASTVisitorExample with llvm-platform 9.0.0-1.5.2 dependency on windows x64.

@saudet
Copy link
Member

saudet commented Dec 18, 2019

It's possible something's changed between 8.0.0 and 9.0.0.
@Neiko2002 Would you by any chance know what's happening?

@saudet
Copy link
Member

saudet commented Dec 18, 2019

LLVM doesn't officially support DLLs on Windows. @delthas was able to come up with a hack that used to work well, but a few things changed with LLVM 9.0.0 requiring an update from Visual Studio 2015 to 2017. I guess we'll need to figure out how to make that work well again...

@saudet
Copy link
Member

saudet commented Dec 19, 2019

What changed was mainly the need to add -DCMAKE_SHARED_LINKER_FLAGS="/FORCE:MULTIPLE, but Microsoft states that "a file created with this option may not run as expected":
https://docs.microsoft.com/en-us/cpp/build/reference/force-force-file-output?view=vs-2019
Finding the cause of these multiple definitions might well fix this issue.

@saudet
Copy link
Member

saudet commented Dec 19, 2019

It looks like building DLLs on Windows is now kind of supported: https://reviews.llvm.org/D56774
We should look into building using that new build_llvm_package.bat script...
@mennodenhollander Could you try it and see if we get functional DLLs that way?

@saudet
Copy link
Member

saudet commented Mar 3, 2020

While starting to debug this, I found something interesting. The clang.exe resulting from the same build also fails in the same way (an apparent infinite loop) when calling something like clang -ast-print sample3.cc. LLVM 9.0.1 doesn't fix this, and neither does using Visual Studio 2019 instead of 2017, or building in Debug mode instead of Release mode, so it's probably not something related to compiler optimizations either. They all behave the same way. clang.exe doesn't depend on libclang.dll, but both clang.exe and libclang.dll depend on LLVM-C.dll while jniLLVM.dll doesn't depend on LLVM-C.dll, so that might explain why LLVM works, but not Clang. dumpbin /dependents LLVM-C.dll reveals that it depends on LLVM-C.dll:

$ dumpbin //dependents LLVM-C.dll
Microsoft (R) COFF/PE Dumper Version 14.16.27035.0
Copyright (C) Microsoft Corporation.  All rights reserved.


Dump of file LLVM-C.dll

File Type: DLL

  Image has the following dependencies:

    VCRUNTIME140.dll
    ucrtbase.dll
    KERNEL32.dll
    LLVM-C.dll
    SHELL32.dll
    ole32.dll
    ADVAPI32.dll
    MSVCP140.dll

  Summary

        F000 .data
      136000 .pdata
      522000 .rdata
       18000 .reloc
        1000 .rsrc
      E74000 .text

Because of that it may end up trying to load itself in an infinite loop, but it doesn't explain why it's not failing at load time... Well, in any case, that's probably something that needs to be fixed :)

@mennodenhollander
Copy link
Author

Thanks for reporting this. A colleague of mine is also looking into this. We have tried different combinations of compilation flags and trying to pinpoint the change that causes the issue, but so far no success. I will let him know of your finding.

@saudet
Copy link
Member

saudet commented Mar 3, 2020

Good news, it looks like disabling that buggy LLVM-C.dll with -DLLVM_BUILD_LLVM_C_DYLIB=OFF successfully works around the issue! Please give it a try with 9.0.1-1.5.3-SNAPSHOT and let me know if you encounter any other problems. Thanks to you for reporting this issue!

@saudet saudet removed the help wanted label Mar 3, 2020
@eversl
Copy link

eversl commented Mar 5, 2020

I'm Menno's colleague. This fix does seem to do the trick indeed. Thanks!

@saudet
Copy link
Member

saudet commented Apr 15, 2020

The workaround has been released with version 1.5.3. Thanks again for reporting and for testing!

@saudet saudet closed this as completed Apr 15, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants