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

Jump to bottom

[SR-10265] Compiler segfault when building custom clang module code against a bson_t #52665

Open
swift-ci opened this issue Apr 2, 2019 · 5 comments
Open

[SR-10265] Compiler segfault when building custom clang module code against a bson_t #52665

swift-ci opened this issue Apr 2, 2019 · 5 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

Comments

@swift-ci
Copy link
Collaborator

swift-ci commented Apr 2, 2019

Previous ID SR-10265
Radar rdar://problem/56834889
Original Reporter mbroadst (JIRA User)
Type Bug
Environment

Ubuntu 18.04, Swift 4.2

Additional Detail from JIRA
Votes 0
Component/s Compiler
Labels Bug, CompilerCrash
Assignee mbroadst (JIRA)
Priority Medium

md5: 59e08a11c4a48295fc1a65793daa9393

Issue Description:

In Swift 5 we no longer have type information for bson_t due to the fact that by default the type is 128 byte aligned. Unfortunately, the libbson api doesn't provide us an accessor for the len field of a bson_t, so I figured in the meantime I'd provide one built into our libbson bindings. This works fine on OSX, but crashes the linux compiler in clang code that's generating code for accessing the bson_t. The backtrace for that looks like:

swift: /home/buildnode/jenkins/workspace/oss-swift-4.2-package-linux-ubuntu-16_04/llvm/tools/clang/lib/CodeGen/CGRecordLayout.h:187: unsigned int clang::CodeGen::CGRecordLayout::getLLVMFieldNo(const clang::FieldDecl *) const: Assertion `FieldInfo.count(FD) && "Invalid field for record!"' failed.
Process 12769 stopped
* thread #​1, name = 'swift', stop reason = signal SIGABRT
    frame #​0: 0x00007ffff630a428 libc.so.6`__GI_raise(sig=6) at raise.c:54
Target 0: (swift) stopped.
(lldb) bt
* thread #​1, name = 'swift', stop reason = signal SIGABRT
  * frame #​0: 0x00007ffff630a428 libc.so.6`__GI_raise(sig=6) at raise.c:54
    frame #​1: 0x00007ffff630c02a libc.so.6`__GI_abort at abort.c:89
    frame #&#8203;2: 0x00007ffff6302bd7 libc.so.6`__assert_fail_base(fmt="", assertion=<unavailable>, file=<unavailable>, line=<unavailable>, function=<unavailable>) at assert.c:92
    frame #&#8203;3: 0x00007ffff6302c82 libc.so.6`__GI___assert_fail(assertion=<unavailable>, file=<unavailable>, line=<unavailable>, function=<unavailable>) at assert.c:101
    frame #&#8203;4: 0x00000000006c26c5 swift`clang::CodeGen::CGRecordLayout::getLLVMFieldNo(clang::FieldDecl const*) const + 293
    frame #&#8203;5: 0x000000000078cf76 swift`emitAddrOfFieldStorage(clang::CodeGen::CodeGenFunction&, clang::CodeGen::Address, clang::FieldDecl const*) + 102
    frame #&#8203;6: 0x0000000000773955 swift`clang::CodeGen::CodeGenFunction::EmitLValueForField(clang::CodeGen::LValue, clang::FieldDecl const*) + 821
    frame #&#8203;7: 0x00000000007810bc swift`clang::CodeGen::CodeGenFunction::EmitMemberExpr(clang::MemberExpr const*) + 1164
    frame #&#8203;8: 0x0000000000770098 swift`clang::CodeGen::CodeGenFunction::EmitLValue(clang::Expr const*) + 1656
    frame #&#8203;9: 0x0000000000779a54 swift`clang::CodeGen::CodeGenFunction::EmitCheckedLValue(clang::Expr const*, clang::CodeGen::CodeGenFunction::TypeCheckKind) + 132
    frame #&#8203;10: 0x00000000007cee23 swift`clang::StmtVisitorBase<clang::make_ptr, (anonymous namespace)::ScalarExprEmitter, llvm::Value*>::Visit(clang::Stmt*) + 29107
    frame #&#8203;11: 0x00000000007d5626 swift`(anonymous namespace)::ScalarExprEmitter::VisitCastExpr(clang::CastExpr*) + 1078
    frame #&#8203;12: 0x00000000007bf536 swift`clang::CodeGen::CodeGenFunction::EmitScalarExpr(clang::Expr const*, bool) + 102
    frame #&#8203;13: 0x0000000000815236 swift`clang::CodeGen::CodeGenFunction::EmitReturnStmt(clang::ReturnStmt const&) + 1430
    frame #&#8203;14: 0x0000000000811e3d swift`clang::CodeGen::CodeGenFunction::EmitStmt(clang::Stmt const*, llvm::ArrayRef<clang::Attr const*>) + 2285
    frame #&#8203;15: 0x000000000081b9bf swift`clang::CodeGen::CodeGenFunction::EmitCompoundStmtWithoutScope(clang::CompoundStmt const&, bool, clang::CodeGen::AggValueSlot) + 95
    frame #&#8203;16: 0x0000000000864c30 swift`clang::CodeGen::CodeGenFunction::GenerateCode(clang::GlobalDecl, llvm::Function*, clang::CodeGen::CGFunctionInfo const&) + 752
    frame #&#8203;17: 0x000000000087a06c swift`clang::CodeGen::CodeGenModule::EmitGlobalFunctionDefinition(clang::GlobalDecl, llvm::GlobalValue*) + 508
    frame #&#8203;18: 0x0000000000874c39 swift`clang::CodeGen::CodeGenModule::EmitGlobalDefinition(clang::GlobalDecl, llvm::GlobalValue*) + 185
    frame #&#8203;19: 0x000000000087c674 swift`clang::CodeGen::CodeGenModule::EmitTopLevelDecl(clang::Decl*) + 116
    frame #&#8203;20: 0x00000000006cabf0 swift`(anonymous namespace)::CodeGeneratorImpl::HandleTopLevelDecl(clang::DeclGroupRef) + 144
    frame #&#8203;21: 0x000000000066a42b swift`swift::irgen::IRGenModule::getAddrOfClangGlobalDecl(clang::GlobalDecl, swift::ForDefinition_t) + 27
    frame #&#8203;22: 0x000000000050b68f swift`swift::irgen::IRGenModule::getAddrOfSILFunction(swift::SILFunction*, swift::ForDefinition_t) + 287
    frame #&#8203;23: 0x00000000005eb716 swift`swift::SILInstructionVisitor<(anonymous namespace)::IRGenSILFunction, void>::visit(swift::SILInstruction*) + 1798
    frame #&#8203;24: 0x00000000005e6ab8 swift`(anonymous namespace)::IRGenSILFunction::emitSILFunction() + 6936
    frame #&#8203;25: 0x00000000005e4a5e swift`swift::irgen::IRGenModule::emitSILFunction(swift::SILFunction*) + 1454
    frame #&#8203;26: 0x00000000005064d5 swift`swift::irgen::IRGenerator::emitGlobalTopLevel(bool) + 645
    frame #&#8203;27: 0x00000000005be9c1 swift`performIRGeneration(swift::IRGenOptions&, swift::ModuleDecl*, std::unique_ptr<swift::SILModule, std::default_delete<swift::SILModule> >, llvm::StringRef, swift::PrimarySpecificPaths const&, llvm::LLVMContext&, swift::SourceFile*, llvm::GlobalVariable**, unsigned int) + 1153
    frame #&#8203;28: 0x00000000005bf1a1 swift`swift::performIRGeneration(swift::IRGenOptions&, swift::SourceFile&, std::unique_ptr<swift::SILModule, std::default_delete<swift::SILModule> >, llvm::StringRef, swift::PrimarySpecificPaths const&, llvm::LLVMContext&, unsigned int, llvm::GlobalVariable**) + 113
    frame #&#8203;29: 0x00000000004df28d swift`performCompile(swift::CompilerInstance&, swift::CompilerInvocation&, llvm::ArrayRef<char const*>, int&, swift::FrontendObserver*, swift::UnifiedStatsReporter*) + 16477
    frame #&#8203;30: 0x00000000004da400 swift`swift::performFrontend(llvm::ArrayRef<char const*>, char const*, void*, swift::FrontendObserver*) + 2912
    frame #&#8203;31: 0x000000000048a348 swift`main + 1304
    frame #&#8203;32: 0x00007ffff62f5830 libc.so.6`__libc_start_main(main=(swift`main), argc=106, argv=0x00007fffffffc608, init=<unavailable>, fini=<unavailable>, rtld_fini=<unavailable>, stack_end=0x00007fffffffc5f8) at libc-start.c:291
    frame #&#8203;33: 0x0000000000488009 swift`_start + 41
(lldb)

So this brings up a few questions:

  • Why can we access bson_t's fields directly, but not in a custom helper within the binding

  • It's clear that bson_t's alignment is a big issue for us, but I assumed if we were careful then treating them as {{OpaquePointer}} s would be fine. Am I completely wrong about that?
@belkadan
Copy link
Contributor

belkadan commented Apr 2, 2019

Hm, yeah, I wouldn't expect that to fail. Have you gotten a chance to try with Swift 5 yet?

Any custom build instructions?

@swift-ci
Copy link
Collaborator Author

swift-ci commented Apr 2, 2019

Comment by Matt Broadstone (JIRA)

Hey, thanks for the quick response. You can build this branch of the swift driver. It requires you to have libmongoc installed which you can easily install via homebrew, or from source (this is in our README.md for further details). I'm testing against source install on ubuntu 18.04 of libmongoc 1.13.0. I haven't tested against Swift 5 on linux yet, but should be able to shortly.

@swift-ci
Copy link
Collaborator Author

swift-ci commented Apr 2, 2019

Comment by Matt Broadstone (JIRA)

I can confirm this issue is not present on Swift 5, but not with the same test since that branch doesn't include all the needed changes for using OpaquePointer everywhere for bson_t

@swift-ci
Copy link
Collaborator Author

swift-ci commented Apr 9, 2019

Comment by Matt Broadstone (JIRA)

Hi again, it looks like this problem is indeed present with Swift 5 on Linux. Here is the stack trace:

1.  While emitting IR SIL function "@$s10MongoSwift8DocumentV7rawBSON10Foundation4DataVvg".
 for getter for rawBSON (at /home/mbroadst/Development/mongo-swift-driver/Sources/MongoSwift/BSON/Document.swift:293:16)
2.  /home/mbroadst/Development/mongo-swift-driver/.build/checkouts/swift-bson/libbson.h:4:10: Generating code for declaration '_bson_get_len'
/home/mbroadst/.swiftenv/versions/5.0/usr/bin/swift[0x462b784]
/home/mbroadst/.swiftenv/versions/5.0/usr/bin/swift[0x4629550]
/home/mbroadst/.swiftenv/versions/5.0/usr/bin/swift[0x462b932]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x11390)[0x7f8876db9390]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x38)[0x7f88754f8428]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x16a)[0x7f88754fa02a]
/lib/x86_64-linux-gnu/libc.so.6(+0x2dbd7)[0x7f88754f0bd7]
/lib/x86_64-linux-gnu/libc.so.6(+0x2dc82)[0x7f88754f0c82]
/home/mbroadst/.swiftenv/versions/5.0/usr/bin/swift[0x6f28b5]
/home/mbroadst/.swiftenv/versions/5.0/usr/bin/swift[0x7ca056]
/home/mbroadst/.swiftenv/versions/5.0/usr/bin/swift[0x7b0649]
/home/mbroadst/.swiftenv/versions/5.0/usr/bin/swift[0x7bdf24]
/home/mbroadst/.swiftenv/versions/5.0/usr/bin/swift[0x7accb7]
/home/mbroadst/.swiftenv/versions/5.0/usr/bin/swift[0x7b6851]
/home/mbroadst/.swiftenv/versions/5.0/usr/bin/swift[0x8141f1]
/home/mbroadst/.swiftenv/versions/5.0/usr/bin/swift[0x819992]
/home/mbroadst/.swiftenv/versions/5.0/usr/bin/swift[0x800416]
/home/mbroadst/.swiftenv/versions/5.0/usr/bin/swift[0x89d076]
/home/mbroadst/.swiftenv/versions/5.0/usr/bin/swift[0x899c0f]
/home/mbroadst/.swiftenv/versions/5.0/usr/bin/swift[0x8a397f]
/home/mbroadst/.swiftenv/versions/5.0/usr/bin/swift[0x8e8c43]
/home/mbroadst/.swiftenv/versions/5.0/usr/bin/swift[0x9027d2]
/home/mbroadst/.swiftenv/versions/5.0/usr/bin/swift[0x8fc539]
/home/mbroadst/.swiftenv/versions/5.0/usr/bin/swift[0x9057e4]
ersions/5.0/usr/bin/swift[0x6faf40]
/home/mbroadst/.swiftenv/versions/5.0/usr/bin/swift[0x6962ab]
/home/mbroadst/.swiftenv/versions/5.0/usr/bin/swift[0x5256de]
/home/mbroadst/.swiftenv/versions/5.0/usr/bin/swift[0x62852a]
/home/mbroadst/.swiftenv/versions/5.0/usr/bin/swift[0x60f082]
/home/mbroadst/.swiftenv/versions/5.0/usr/bin/swift[0x5236c4]
/home/mbroadst/.swiftenv/versions/5.0/usr/bin/swift[0x5e5f5b]
/home/mbroadst/.swiftenv/versions/5.0/usr/bin/swift[0x5e6647]
/home/mbroadst/.swiftenv/versions/5.0/usr/bin/swift[0x4eb41d]
/home/mbroadst/.swiftenv/versions/5.0/usr/bin/swift[0x4e6706]
/home/mbroadst/.swiftenv/versions/5.0/usr/bin/swift[0x48da7e]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0)[0x7f88754e3830]
/home/mbroadst/.swiftenv/versions/5.0/usr/bin/swift[0x48b8b9]
<unknown>:0: error: unable to execute command: Aborted
<unknown>:0: error: compile command failed due to signal 6 (use -v to see invocation)
Makefile:13: recipe for target 'all' failed
make: *** [all] Error 1

This should be easier to test with MongoSwift now that Swift 5 support is landing here, and the helper was committed to our swift-bson bindings in v2.0.1.

Is there some sort of workaround for this in the meantime? This would seem to make it impossible for Linux users to use our driver at the moment. I was able to work around this by reading the embedded document length directly from the data.

@belkadan
Copy link
Contributor

belkadan commented Nov 2, 2019

@swift-ci create

@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
Projects
None yet
Milestone
No milestone
Development

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