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.

Sign up for GitHub

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

Jump to bottom

[SR-1567] [SwiftPM] Prevent/solve issue with seeing headers in /usr/include and SDK (was: compiler crash when passing -Xcc -I/usr/include to swiftc) #5281

Closed
ankitspd opened this issue May 19, 2016 · 19 comments
Closed

[SR-1567] [SwiftPM] Prevent/solve issue with seeing headers in /usr/include and SDK (was: compiler crash when passing -Xcc -I/usr/include to swiftc) #5281

ankitspd opened this issue May 19, 2016 · 19 comments
Labels
bug

Comments

@ankitspd
Copy link
Member

Previous ID SR-1567
Radar rdar://problem/28030420
Original Reporter @aciidb0mb3r
Type Bug
Status Resolved
Resolution Cannot Reproduce

Attachment: Download

Additional Detail from JIRA
Votes 1
Component/s Compiler, Package Manager
Labels Bug, ClangImporter, CompilerCrash
Assignee None
Priority Medium

md5: 2a4e522bb9e3593da3cc9bab47b22184

is duplicated by:

  • SR-2482 Compiler Crash on Dual Core Macs but not Quad Core Mac

relates to:

  • SR-89 Segfault importing sqlite3.h from system module

Issue Description:

I don't exactly know how to describe it but attaching the minimal package which reproduces this crash.

  1. unzip
  2. cd crash/sample
  3. swift build -Xcc -I/usr/include

Crash :

Compile Swift Module 'sample' (1 sources)
Assertion failed: ((ID || !Mod) && "asked for module ID for non-local, non-imported module"), function getSubmoduleID, file /Users/buildnode/jenkins/workspace/oss-swift-package-osx/llvm/tools/clang/lib/Serialization/ASTWriter.cpp, line 2377.
0  swift                    0x000000010886a54b llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 43
1  swift                    0x00000001088697d6 llvm::sys::RunSignalHandlers() + 70
2  swift                    0x000000010886ac1f SignalHandler(int) + 383
3  libsystem_platform.dylib 0x00007fff87561eaa _sigtramp + 26
4  swift                    0x00000001093fc3f0 clang::vfs::getNextVirtualUniqueID()::UID + 71992
5  swift                    0x000000010886a9f6 abort + 22
6  swift                    0x000000010886a9d1 __assert_rtn + 81
7  swift                    0x0000000106cd7402 clang::ASTWriter::WritePreprocessor(clang::Preprocessor const&, bool) + 6210
8  swift                    0x0000000106cee150 clang::ASTWriter::WriteASTCore(clang::Sema&, llvm::StringRef, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, clang::Module*) + 9168
9  swift                    0x0000000106cebd32 clang::ASTWriter::WriteAST(clang::Sema&, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, clang::Module*, llvm::StringRef, bool) + 642
10 swift                    0x0000000106d28700 clang::PCHGenerator::HandleTranslationUnit(clang::ASTContext&) + 112
11 swift                    0x0000000106b535bc clang::MultiplexConsumer::HandleTranslationUnit(clang::ASTContext&) + 44
12 swift                    0x0000000106d35ca5 clang::ParseAST(clang::Sema&, bool, bool) + 581
13 swift                    0x0000000106b1e7a9 clang::FrontendAction::Execute() + 73
14 swift                    0x0000000106aeb361 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 1073
15 swift                    0x00000001087fc96b llvm::CrashRecoveryContext::RunSafely(llvm::function_ref<void ()>) + 283
16 swift                    0x00000001087fcb30 RunSafelyOnThread_Dispatch(void*) + 48
17 swift                    0x000000010886bc6d ExecuteOnThread_Dispatch(void*) + 13
18 libsystem_pthread.dylib  0x00007fff95cd6c13 _pthread_body + 131
19 libsystem_pthread.dylib  0x00007fff95cd6b90 _pthread_body + 0
20 libsystem_pthread.dylib  0x00007fff95cd4375 thread_start + 13
Stack dump:
0.  <eof> parser at end of file
<unknown>:0: error: unable to execute command: Illegal instruction: 4
<unknown>:0: error: compile command failed due to signal (use -v to see invocation)
<unknown>:0: error: build had 1 command failures
error: exit(1): /Users/aciid/mycode/swift.org/swift-package-manager/.build/debug/swift-build-tool -f /Users/aciid/mycode/crash/sample/.build/debug.yaml
@belkadan
Copy link

@benlangmuir, any ideas?

@ddunbar
Copy link
Member

ddunbar commented Aug 15, 2016

@aciidb0mb3r can you check if this is still an issue?

@swift-ci
Copy link
Contributor

Comment by Ian Partridge (JIRA)

Kitura is seeing this as we migrate from 07-20a to 08-07a.

Travis build: https://travis-ci.org/IBM-Swift/Kitura-net/jobs/153515406

Is there a workaround?

@belkadan
Copy link

I don't think anything changed here recently. I don't know of a workaround.

@belkadan
Copy link

(because we haven't seen it on macOS systems)

@belkadan
Copy link

…oh, Ankit's system is a macOS system. In that case I'm confused. Maybe there are conflicting module definitions? (/usr/include should already be searched by default anyway.)

@ankitspd
Copy link
Member Author

unfortunately I won't be able to re-check this again on my MacBook for another week

@ddunbar
Copy link
Member

ddunbar commented Aug 19, 2016

I wonder if this is related to whether or not users have the command line tools installed causing an SDK to be present in /usr/include.

@belkadan
Copy link

Aha, this is probably SR-89 and also rdar://problem/26866326. Here's my guess as to what's going on, based on Daniel's idea and mren2 (JIRA User)'s diagnosis in the Radar: you're importing curl/curl.h from /usr/include, which picks up the Darwin module in /usr/include. However, the rest of the system expects the Darwin module to be in $SDKROOT/usr/include. At some point Clang goes to write references to these out to disk and gets very confused.

@swift-ci
Copy link
Contributor

Comment by Shmuel Kallner (JIRA)

We do indeed include curl/curl.h, however we do it as follows:

1) We have a project in the repository https://github.com/IBM-Swift/CCurl.git
2) The module.modulemap file specifies an include file within the project, shim.h
3) In the file shim.h we include curl/curl.h as follows:

#import <curl/curl.h>

The build is being run by simply executing:

swift build

@ddunbar
Copy link
Member

ddunbar commented Aug 26, 2016

I think the root cause when using swift build is that users should never end up in a situation where they are finding headers from /usr/include and from the SDK.

We ultimately need to figure out why that is happening here and fix it. To some extent the Clang crash is a red herring, because even if Clang didn't crash here it would likely be a bad situation to be in.

@ddunbar
Copy link
Member

ddunbar commented Aug 26, 2016

Given that we have SR-89 and a Radar for the clang crash, let's use this for figuring out why SwiftPM users are ending up in this situation.

@ddunbar
Copy link
Member

ddunbar commented Aug 26, 2016

The example of IBM-Swift/CCurl doesn't completely make sense to me, as it is just using local header search for hte shim.h and relying on regular header search inside that. I don't see why that should cause us to end up in /usr/include.

@swift-ci
Copy link
Contributor

Comment by Shmuel Kallner (JIRA)

The issue apparently was a combination of using XCode 8 beta 6 with the Swift 3 08/07 driver. SPM in the 08/07 driver incorrectly picked up IBM-Swift/CCurl 0.2.0, instead of 0.2.1. The difference that seemed to matter the most was that the 0.2.0 version of IBM-Swift/CCurl has a pkgConfig element in it's Package.swift file, while the 0.2.1 version doesn't have it.

Adding this information to help debug this problem for others. We in Kitura abandoned the migration to the 08/07 driver of Swift and have since migrated to the 08/23 driver without any problems.

@swift-ci
Copy link
Contributor

swift-ci commented Nov 2, 2016

Comment by Jeffrey Bergier (JIRA)

I don't know if this comment helps at all. But this problem has only been effecting me on some Macs. I've had 3 Macs all with exact same El Capitan and Xcode configuration. This problem was an issue on 2 of 3 Macs. The third Mac compiled fine.

Then after the Sierra update, I could compile on 2 of the 3 Macs (the third was not Sierra compatible). However, since the 12.1 update, the issue has reappeared.

I'm essentially dead in the water on the 12" MacBook. It works on fine on an older 15" rMBP.

@swift-ci
Copy link
Contributor

swift-ci commented Nov 3, 2016

Comment by Jeffrey Bergier (JIRA)

Ignore my previous comment. I've been working with the Perfect web server guys and we tracked down what causes Perfect-CURL to fail to compile. I'm assuming its the same failure as Kitura CURL failing.

First there are two pre-requisites:

1) Xcode Command Line Tools installed (xcode-select -install)
2) Pkg-Config installed via home-brew

If both of those things are installed then it fails to compile. If only 1 of the 2 is installed then it works. So I just did brew uninstall pkg-config and it fixed the problem. I was able to install and uninstall pkg-config on 2 Macs and verify the crash happened and then didn't happen like clock work.

So I'm not sure if this "solves" the problem, but its a workaround for now.

@ankitspd
Copy link
Member Author

ankitspd commented Nov 3, 2016

The original problem doesn't involve pkg-config and I cannot reproduce it anymore .

However the multiple pkg-config thing sounds like a SwiftPM bug, jeffburg@jeffburg.com (JIRA User) Can you open a new bug for that with output of this command with and without CLT:
$ pkg-config --cflags libcurl

@swift-ci
Copy link
Contributor

swift-ci commented Nov 3, 2016

Comment by Jeffrey Bergier (JIRA)

@aciidb0mb3r sure thing. New bug is SR-3129

@ankitspd
Copy link
Member Author

Closing this as I don't see this error anymore on latest toolchain right now -> swift-DEVELOPMENT-SNAPSHOT-2016-11-15-a

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
@shahmishal shahmishal transferred this issue from apple/swift May 4, 2022
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@ddunbar @belkadan @ankitspd @swift-ci