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-2912] Compiler crashes on Objective-C code that is broken due to a missing define #45506

Open
swift-ci opened this issue Oct 10, 2016 · 3 comments
Open

[SR-2912] Compiler crashes on Objective-C code that is broken due to a missing define #45506

swift-ci opened this issue Oct 10, 2016 · 3 comments
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler in itself crash Bug: A crash, i.e., an abnormal termination of software serialization Area → compiler: Serialization & deserialization

Comments

@swift-ci
Copy link
Collaborator

Previous ID SR-2912
Radar None
Original Reporter dmishe (JIRA User)
Type Bug

Attachment: Download

Environment

Apple Swift version 3.0 (swiftlang-800.0.46.2 clang-800.0.38)
Target: x86_64-apple-macosx10.9

Additional Detail from JIRA
Votes 0
Component/s Compiler
Labels Bug, ClangImporter, CompilerCrash, Serialization
Assignee None
Priority Medium

md5: 48892a42695da5c3376568c42b84f14d

Issue Description:

Suppose we have an Objective-C class, which existence is gated by a preprocessor define:

#ifdef CMODULE_ENABLED
@interface CModule: NSObject
@end
#endif

And a Swift class Foo (module Foo) which uses CModule

import CModule
public class Foo {
    public func module() -> CModule {  return CModule() }}

If we compile Foo without the define flag, we get this nice error message:

$ swiftc -c src/foo.swift -Isrc/cmodule

src/foo.swift:5:26: error: use of undeclared type 'CModule'
        public func module() -> CModule { 
                                ^
src/foo.swift:5:26: note: cannot use module 'CModule' as a type
        public func module() -> CModule {

Let's add -Xcc -DCMODULE_ENABLED to the compilation of Foo fixing the issue.

Then create another Swift class Bar (module Bar) that depends on Foo:

import Foo
public class Bar {
    public func crashMe() { print(Foo().module()) }}

And compile it, again, without setting the define:

$ swiftc -c src/bar.swift -Iout -Isrc/cmodule

0  swift                    0x0000000110822b6d PrintStackTraceSignalHandler(void*) + 45
1  swift                    0x00000001108225b6 SignalHandler(int) + 470
2  libsystem_platform.dylib 0x00007fff8a1f652a _sigtramp + 26
3  libsystem_platform.dylib 000000000000000000 _sigtramp + 1977654000
4  swift                    0x000000010e210ee9 swift::ModuleFile::getType(llvm::PointerEmbeddedInt<unsigned int, 31>) + 857
5  swift                    0x000000010e21110c swift::ModuleFile::getType(llvm::PointerEmbeddedInt<unsigned int, 31>) + 1404
6  swift                    0x000000010e21110c swift::ModuleFile::getType(llvm::PointerEmbeddedInt<unsigned int, 31>) + 1404
7  swift                    0x000000010e20e8c1 swift::ModuleFile::getDecl(llvm::PointerEmbeddedInt<unsigned int, 31>, llvm::Optional<swift::DeclContext*>) + 39137
8  swift                    0x000000010e219947 swift::ModuleFile::loadAllMembers(swift::Decl*, unsigned long long) + 647
9  swift                    0x000000010e42a80d (anonymous namespace)::hasFailableInits(swift::NominalTypeDecl*, swift::constraints::ConstraintSystem*) + 125
10 swift                    0x000000010e42a3e2 (anonymous namespace)::ConstraintGenerator::visitApplyExpr(swift::ApplyExpr*) + 642
11 swift                    0x000000010e423de0 (anonymous namespace)::ConstraintWalker::walkToExprPost(swift::Expr*) + 64
12 swift                    0x000000010e5945dc swift::ASTVisitor<(anonymous namespace)::Traversal, swift::Expr*, swift::Stmt*, bool, swift::Pattern*, bool, void>::visit(swift::Expr*) + 2796
13 swift                    0x000000010e598a56 (anonymous namespace)::Traversal::visitApplyExpr(swift::ApplyExpr*) + 86
14 swift                    0x000000010e593b7d swift::ASTVisitor<(anonymous namespace)::Traversal, swift::Expr*, swift::Stmt*, bool, swift::Pattern*, bool, void>::visit(swift::Expr*) + 141
15 swift                    0x000000010e598ada (anonymous namespace)::Traversal::visitApplyExpr(swift::ApplyExpr*) + 218
16 swift                    0x000000010e41f6b2 swift::constraints::ConstraintSystem::generateConstraints(swift::Expr*) + 610
17 swift                    0x000000010e496c29 swift::TypeChecker::solveForExpression(swift::Expr*&, swift::DeclContext*, swift::Type, swift::FreeTypeVariableBinding, swift::ExprTypeCheckListener*, swift::constraints::ConstraintSystem&, llvm::SmallVectorImpl<swift::constraints::Solution>&, swift::OptionSet<swift::TypeCheckExprFlags, unsigned int>) + 569
18 swift                    0x000000010e49959f swift::TypeChecker::typeCheckExpression(swift::Expr*&, swift::DeclContext*, swift::TypeLoc, swift::ContextualTypePurpose, swift::OptionSet<swift::TypeCheckExprFlags, unsigned int>, swift::ExprTypeCheckListener*, swift::constraints::ConstraintSystem*) + 703
19 swift                    0x000000010e51a5b8 swift::ASTVisitor<(anonymous namespace)::StmtChecker, void, swift::Stmt*, void, void, void, void>::visit(swift::Stmt*) + 488
20 swift                    0x000000010e5195ad swift::TypeChecker::typeCheckFunctionBodyUntil(swift::FuncDecl*, swift::SourceLoc) + 365
21 swift                    0x000000010e51dcfc swift::TypeChecker::typeCheckAbstractFunctionBody(swift::AbstractFunctionDecl*) + 188
22 swift                    0x000000010e4d264a swift::performTypeChecking(swift::SourceFile&, swift::TopLevelContext&, swift::OptionSet<swift::TypeCheckingFlags, unsigned int>, unsigned int, unsigned int) + 6714
23 swift                    0x000000010e187aab swift::CompilerInstance::performSema() + 5643
24 swift                    0x000000010dc3400d performCompile(swift::CompilerInstance&, swift::CompilerInvocation&, llvm::ArrayRef<char const*>, int&, swift::FrontendObserver*) + 2765
25 swift                    0x000000010dc31265 swift::performFrontend(llvm::ArrayRef<char const*>, char const*, void*, swift::FrontendObserver*) + 17029
26 swift                    0x000000010dbee82d main + 8685
27 libdyld.dylib            0x00007fff9bc3a5ad start + 1
28 libdyld.dylib            0x0000000000000019 start + 1681676909
Stack dump:
0.  Program arguments: /Applications/Xcode_8.0.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/swift -frontend -c -primary-file src/bar.swift -target x86_64-apple-macosx10.9 -enable-objc-interop -sdk /Applications/Xcode_8.0.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk -I src/cmodule -I out -g -emit-module-doc-path out/bar.swiftdoc -color-diagnostics -parse-as-library -module-name Bar -emit-module-path out/bar.swiftmodule -o out/bar.o 
1.  While type-checking 'crashMe' at src/bar.swift:5:9
2.  While type-checking expression at [src/bar.swift:6:3 - line:6:23] RangeText="print(Foo().module())"
3.  While loading members for 'Foo' at <invalid loc>
4.  While deserializing 'module' (FuncDecl #&#8203;2) 
<unknown>:0: error: unable to execute command: Segmentation fault: 11
<unknown>:0: error: compile command failed due to signal (use -v to see invocation)

1. While it's not surprising that Bar cannot be compiled, the compiler should show the same error message as we've seen with Foo, instead of crashing.

2. Should this actually compile, since Foo has all the information about C types it needs, and Bar is not really using any of it?

Sample crasher attached. Unpack and run build.sh.
@belkadan
Copy link
Contributor

It shouldn't crash, but fixing that is a big task (it means plumbing error results through all of the Serialization library). I don't think it's true that "Foo has all the information it needs" or that "Bar is not really using any of it". It's not sound for Bar not to know anything about the return type of module(), and it's questionable whether "just treat it as AnyObject" would be correct either.

@swift-ci
Copy link
Collaborator Author

Comment by Dmitry Shevchenko (JIRA)

Thanks for explanation. The guidance then is that every Swift module needs to pass required C flags to the Objective-C modules it depends on both directly and indirectly?

@belkadan
Copy link
Contributor

Yep. At some point we'll have better support for "private dependencies", but when it's part of your public interface it's still necessary to have a consistent enough view of the framework.

(It would be nice™ if the compiler could just pick up the flags it needs from the modules that you import, but of course there's no guarantee that two separate dependencies have compatible flags. This is of course a problem in C as well, but only when the conflicting headers are part of your public interface.)

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
@AnthonyLatsis AnthonyLatsis added the crash Bug: A crash, i.e., an abnormal termination of software label Dec 12, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler in itself crash Bug: A crash, i.e., an abnormal termination of software serialization Area → compiler: Serialization & deserialization
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@belkadan @swift-ci @AnthonyLatsis