Comment by Dietmar Planitzer (JIRA)

@compnerd I guess that you might most likely be able to give us an hint about what might be wrong / what we can do to fix this / what extra info we could provide to help fix this.

Comment by Dietmar Planitzer (JIRA)

We've done some more investigation on this by building a RelWithDebInfoAssert version of the Swift compiler and running that in the Visual Studio debugger like this:

Devenv.exe /debugexe C:\Users\dplan\Documents\Developer\swift-repos\build\Ninja-RelWithDebInfoAssert\swift-windows-amd64\bin\swiftc.exe -c -target x86_64-unknown-windows-msvc -resource-dir C:/Users/dplan/Documents/Developer/swift-repos/build/Ninja-RelWithDebInfoAssert/swift-windows-amd64/lib/swift -O -I C:/Users/dplan/Documents/Developer/swift-repos/build/Ninja-RelWithDebInfoAssert/swift-windows-amd64/lib/swift/windows/x86_64 -module-cache-path C:/Users/dplan/Documents/Developer/swift-repos/build/Ninja-RelWithDebInfoAssert/swift-windows-amd64/module-cache -no-link-objc-runtime -Xfrontend -enable-resilience -swift-version 3 -D_USRDLL -Xcc -Xclang -Xcc -ivfsoverlay -Xcc -Xclang -Xcc "C:/Users/dplan/Documents/Developer/swift-repos/build/Ninja-RelWithDebInfoAssert/swift-windows-amd64/windows-sdk-vfs-overlay.yaml" -Xfrontend "-IC:/Program Files (x86)/Microsoft Visual Studio/2017/Community/VC/Tools/MSVC/14.14.26428/include" -Xfrontend "-IC:/Program Files (x86)/Windows Kits/10/Include/10.0.17134.0/ucrt" -Xfrontend "-IC:/Program Files (x86)/Windows Kits/10/Include/10.0.17134.0/shared" -Xfrontend "-IC:/Program Files (x86)/Windows Kits/10/Include/10.0.17134.0/um" -Xfrontend -autolink-library -Xfrontend oldnames -Xfrontend -autolink-library -Xfrontend msvcrtd -module-link-name swiftSwiftPrivateLibcExtras -force-single-frontend-invocation -parse-as-library -o C:/Users/dplan/Documents/Developer/swift-repos/build/Ninja-RelWithDebInfoAssert/swift-windows-amd64/stdlib/private/SwiftPrivateLibcExtras/windows/x86_64/SwiftPrivateLibcExtras.obj C:/Users/dplan/Documents/Developer/swift-repos/swift/stdlib/private/SwiftPrivateLibcExtras/SwiftPrivateLibcExtras.swift C:/Users/dplan/Documents/Developer/swift-repos/swift/stdlib/private/SwiftPrivateLibcExtras/Subprocess.swift

The Visual Studio debugger catches a heap corruption exception (see screenshot "heap_corruption_exception") in the LLVM PassManagerBuilder::addExtension() function when it tries to do a std::move() on a static function. It appears that the MS std::move() seems to think that a dynamically allocated function object was passed in and so it tries to free the memory which it shouldn't.

I've attached the stack trace (see "heap_corruption_stack_trace").

I have been building debug rather than release and that does not exhibit this. It has to be an optimization that gets something wrong. It would be helpful to track down where the corruption actually occurs. I guess one other thing that could be interesting would be to try libc++ instead (which I have ported to run on Windows with MS ABI as well) to see if it is the {{std::function}} implementation.

Comment by Dietmar Planitzer (JIRA)

@compnerd Thank you for the info.

I've built a debug version of Swift and that doesn't show this crash. I'm able to compile and run certain types of simple Swift apps. Basically anything that doesn't trigger a dynamic cast but I see crashes if the app or stdlib tries to do a dynamic cast. I've written up a separate bug about this with info about what I've been able to find out so far: SR-7991.

Is the clang C++ library part of the llvm-clang project or is this a separate project? I'd like to give this a shot if possible.

I believe this has been fixed.