[SR-585] Segfault on Linux in code using "catch let error as NSError" #43202

swift-ci · 2016-01-19T23:34:38Z


Previous ID	SR-585
Radar	rdar://problem/30766599
Original Reporter	rothomp3 (JIRA User)
Type	Bug
Status	Resolved
Resolution	Done

Attachment: Download

Environment

Ubuntu Linux 15.10
LLVM 3ebdbb2c7e, Clang f66c5bb67b, Swift e25cd88

Additional Detail from JIRA


Votes	8
Component/s	Compiler
Labels	Bug, RunTimeCrash, Runtime
Assignee	rothomp3 (JIRA)
Priority	Medium

md5: f2030dd3a4949c21dd4280ad4f13922d

is duplicated by:

SR-3565 SIGSEGV: invalid address constructing AnyError from NSError
SR-1380 NSFileManager.moveItem(atPath:toPath:) segfaults on Ubuntu 15.10

relates to:

SR-1547 NSData causes segmentation fault

Issue Description:

Short example to reproduce the problem:

import Foundation

do {
    throw NSError(domain: "com.mydomain", code: -1, userInfo: [NSLocalizedDescriptionKey: "an error!"])
} catch let error as NSError {
    print(error.userInfo)
}

Backtrace from "swift errortest.swift":

#&#8203;0 0x0000000003042448 llvm::sys::PrintStackTrace(llvm::raw_ostream&) (/home/robert/swift/usr/bin/swift+0x3042448)
#&#8203;1 0x0000000003040c46 llvm::sys::RunSignalHandlers() (/home/robert/swift/usr/bin/swift+0x3040c46)
#&#8203;2 0x0000000003042f76 SignalHandler(int) (/home/robert/swift/usr/bin/swift+0x3042f76)
#&#8203;3 0x00007fa62486ad10 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x10d10)
#&#8203;4 0x00007fa621bb2eb7 swift_dynamicCast (/home/robert/swift/usr/lib/swift/linux/libswiftCore.so+0x2fceb7)
#&#8203;5 0x00007fa624c7b1b2
#&#8203;6 0x0000000000d1f6c4 llvm::MCJIT::runFunction(llvm::Function*, llvm::ArrayRef<llvm::GenericValue>) (/home/robert/swift/usr/bin/swift+0xd1f6c4)
#&#8203;7 0x0000000000d22ccf llvm::ExecutionEngine::runFunctionAsMain(llvm::Function*, std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > const&, char const* const*) (/home/robert/swift/usr/bin/swift+0xd22ccf)
#&#8203;8 0x0000000000bfd338 swift::RunImmediately(swift::CompilerInstance&, std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > const&, swift::IRGenOptions&, swift::SILOptions const&) (/home/robert/swift/usr/bin/swift+0xbfd338)
#&#8203;9 0x00000000007775d4 performCompile(swift::CompilerInstance&, swift::CompilerInvocation&, llvm::ArrayRef<char const*>, int&) (/home/robert/swift/usr/bin/swift+0x7775d4)
#&#8203;10 0x0000000000772b89 frontend_main(llvm::ArrayRef<char const*>, char const*, void*) (/home/robert/swift/usr/bin/swift+0x772b89)
#&#8203;11 0x000000000076e276 main (/home/robert/swift/usr/bin/swift+0x76e276)
#&#8203;12 0x00007fa6231f0a40 __libc_start_main /build/buildd/glibc-2.21/csu/libc-start.c:323:0
#&#8203;13 0x000000000076d799 _start (/home/robert/swift/usr/bin/swift+0x76d799)
Stack dump:
0.  Program arguments: /home/robert/swift/usr/bin/swift -frontend -interpret ./errortest.swift -target x86_64-unknown-linux-gnu -disable-objc-interop -module-name errortest

The text was updated successfully, but these errors were encountered:

swift-ci · 2016-02-15T16:00:54Z

Comment by John Endres (JIRA)

A note here. This crash seems to be specific to catching NSError. When throwing something based off of the ErrorType protocol, the crash does not happen.

swift-ci · 2016-02-18T08:32:11Z

Comment by Vadim Eisenberg (JIRA)

The problem seems to be due to the fact that in the swift-corelibs-foundation NSError does not implement ErrorType: https://github.com/apple/swift-corelibs-foundation/blob/master/Foundation/NSError.swift

While https://github.com/apple/swift/blob/master/stdlib/public/SDK/Foundation/NSError.swift provides an extension that does:
extension NSError : ErrorType {
public var _domain: String { return domain }
public var _code: Int { return code }
}

swift-ci · 2016-02-18T15:57:11Z

Comment by Robert Thompson (JIRA)

vadim (JIRA User) Check further down in the file,

extension NSError : ErrorType { }

on line 168 😉

swift-ci · 2016-02-18T16:13:08Z

Comment by Vadim Eisenberg (JIRA)

rothomp3 (JIRA User) Oops. So the bug is not so simple to fix 🙂

swift-ci · 2016-03-13T17:52:34Z

Comment by John Brownlee (JIRA)

I wrote a test case for this and ran it in a debugger, and got the following backtrace:

thread Redundant Load Elimination Patches #1: tid = 17831, 0x00007ffff7aa7567 libswiftCore.so`swift::ValueWitnessFlags::getAlignmentMask(this=0x0074666977732f02) const + 23 at Metadata.h:237, name = 'TestFoundation', stop reason = signal SIGSEGV: invalid address (fault address: 0x0)

frame #0: 0x00007ffff7aa7567 libswiftCore.so`swift::ValueWitnessFlags::getAlignmentMask(this=0x0074666977732f02) const + 23 at Metadata.h:237
frame Redundant Load Elimination Patches #1: 0x00007ffff7aa753c libswiftCore.so`swift::ValueWitnessTable::getAlignmentMask(this=0x0074666977732e72) const + 28 at Metadata.h:741
frame Remove unnecessary unsafeUnwrap calls. #2: 0x00007ffff7aa7388 libswiftCore.so`swift::SwiftError::getValue(this=0x000000000090b9e0) const + 104 at ErrorObject.h:103
frame Initial implementation of a @_cdecl attribute to export top-level functions to C #3: 0x00007ffff7aa1cd4 libswiftCore.so`_dynamicCastToUnknownClassFromExistential(dest=0x00007fffffffd3a0, src=0x00007fffffffd3a8, srcType=0x00007ffff7fe0190, targetType=0x00007ffff770bbf8, flags=Default) + 356 at Casting.cpp:1519
frame install Foundation via the ninja script and add the test phase for Foundation #4: 0x00007ffff7aa1435 libswiftCore.so`swift_dynamicCast(dest=0x00007fffffffd3a0, src=0x00007fffffffd3a8, srcType=0x00007ffff7fe0190, targetType=0x00007ffff770bbf8, flags=Default) + 613 at Casting.cpp:2111
frame Only run bindings-build-record on OS X due to test flakiness on Liunx… #5: 0x000000000047347e TestFoundation`TestNSError.test_catchingError(self=<unavailable>, $error=<unavailable>) throws -> () + 190 at TestNSError.swift:35
frame Debug Info: Don't reset the debug scope after leaving the outermost s… #6: 0x0000000000473fea TestFoundation`partial apply + 26 at TestNSError.swift:0
frame Fix a bug in SILValue's hoistAddressProjections #7: 0x0000000000419c08 TestFoundation`thunk + 24 at TestNSAffineTransform.swift:0
frame Simplify configure pass for Foundation to use a defined variable for XCTest's build directory #8: 0x0000000000473f79 TestFoundation`partial apply for thunk + 89 at TestNSError.swift:0
frame update related projects list to include Foundation and XCTest #9: 0x00007ffff6bfcc7f libXCTest.so`thunk + 47 at <unknown>:0

I think the error is getting introduced around line ErrorObject.h:103
unsigned alignMask = type->getValueWitnesses()->getAlignmentMask();

There's guards around that code to prevent it from being run on a "pure NSError", but the isPureNSError method always returns false on the Swift runtime. It looks to me like the NSErrors on the Swift runtime need to be treated as pure NSErrors for the purposes of this casting. Changing the logic in Casting.cpp:1516 in this way prevents the crash, but I don't know how to properly distinguish NSError from native Swift errors to provide a real implementation of isPureNSError.

swift-ci · 2016-11-13T16:51:59Z

Comment by Mark Woollard (JIRA)

I've been looking into an issue over in Foundation - SR-1547 - which led me here as its actually the same issue as here and nothing to do with NSData as that issue suggests. From what I've deduced so far when an NSError is thrown and caught its the same instance that is `error` in the catch but is now treated as an instance of SwiftError C++ class which NSError is not (code passes the NSError instance into swift::swift_getErrorValue as SwiftError) and it all falls apart ! lldb sees the caught error as just the Error protocol but seems compiler is making further assumption that its an instance of SwiftError. Only started working through the codebase this w/e having decided to get involved so still limited in understanding but this seems pretty fundamental issue for Linux? I also note that throwing the swift error wrappers such as POSIXError, CocoaError or URLError gets around the issue - should the compiler be doing this wrapping automatically?

swift-ci · 2017-01-11T22:52:54Z

Comment by Maksim Rogov (JIRA)

Also seeing this issue on Ubuntu 16.04, hope we can get a fix by 3.1. Crashing error handling is really hard to track down 🙂

Update: This is a serious bug as Swift is pretty much unusable on Linux due to this.

gwynne · 2017-02-22T12:09:12Z

Still seeing this in the latest snapshots and on master, it's wreaking all kind of havoc. A fix would be great 🙂

Backtrace looks like this these days:

* thread #&#8203;1, name = 'Test', stop reason = signal SIGSEGV: invalid address (fault address: 0x90)
  * frame #&#8203;0: libswiftCore.so`swift_dynamicCast [inlined] swift::ValueWitnessFlags::getAlignmentMask() const at Metadata.h:231
    frame #&#8203;1: libswiftCore.so`swift_dynamicCast [inlined] swift::ValueWitnessTable::getAlignmentMask(this=0x0000000000000000) const at Metadata.h:733
    frame #&#8203;2: libswiftCore.so`swift_dynamicCast [inlined] swift::SwiftError::getValue(this=0x00000000008bf920) const at ErrorObject.h:119
    frame #&#8203;3: libswiftCore.so`swift_dynamicCast at Casting.cpp:1508
    frame #&#8203;4: libswiftCore.so`swift_dynamicCast(dest=<unavailable>, src=<unavailable>, srcType=<unavailable>, targetType=0x00007ffff75d5ef8, flags=Default) at Casting.cpp:2510

swift-ci · 2017-02-22T12:40:23Z

Comment by AdamDann (JIRA)

I would also like to see a fix for this, thanks.

gwynne · 2017-02-24T08:16:31Z

New info - it crashes on ANY attempt to use an NSError value in any way, regardless of whether you attempt to treat it specifically as NSError or not.

jckarter · 2017-02-25T02:44:30Z

This should fix it: #7761

jckarter · 2017-02-25T04:13:57Z

Even with the fix, though, I'd say that using NSError at all on Linux isn't a great idea. We provide the NSError bridge on Apple ObjC platforms for compatibility so that Swift code can work with the more specific CocoaError etc. types. There's no bridge on Linux so using NSError in the corelibs implementation breaks compatibility with code that uses those types.

gwynne · 2017-02-25T12:12:08Z

I was finally able to get my build working with this fix and I can confirm I no longer crash on Linux!!!!

jckarter · 2017-02-26T02:09:32Z

Should be fixed in master now.

swift-ci · 2017-02-27T20:11:19Z

Comment by Sergey Minakov (JIRA)

Will this fix be included into 3.1 version?

swift-ci · 2017-02-27T20:13:46Z

Comment by Maksim Rogov (JIRA)

naithar (JIRA User) I sure hope so! Very necessary fix unless they fix corelibs-foundation on Linux for 3.1 instead (not to use NSError).

ffried · 2017-02-28T11:42:29Z

@jckarter Does this also fix SR-1380 and SR-3565? Seems like this could be the same underlying issue.

jckarter · 2017-02-28T21:07:56Z

@swift-ci create

jckarter · 2017-03-01T20:07:40Z

PR for 3.1: #7847

swift-ci transferred this issue from apple/swift-issues Apr 25, 2022

AnthonyLatsis added the crash Bug: A crash, i.e., an abnormal termination of software label Dec 12, 2022

This issue was closed.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[SR-585] Segfault on Linux in code using "catch let error as NSError" #43202

[SR-585] Segfault on Linux in code using "catch let error as NSError" #43202

swift-ci commented Jan 19, 2016

swift-ci commented Feb 15, 2016

swift-ci commented Feb 18, 2016

swift-ci commented Feb 18, 2016

swift-ci commented Feb 18, 2016

swift-ci commented Mar 13, 2016

swift-ci commented Nov 13, 2016

swift-ci commented Jan 11, 2017

gwynne commented Feb 22, 2017

swift-ci commented Feb 22, 2017

gwynne commented Feb 24, 2017

jckarter commented Feb 25, 2017

jckarter commented Feb 25, 2017

gwynne commented Feb 25, 2017

jckarter commented Feb 26, 2017

swift-ci commented Feb 27, 2017

swift-ci commented Feb 27, 2017

ffried commented Feb 28, 2017

jckarter commented Feb 28, 2017

jckarter commented Mar 1, 2017

[SR-585] Segfault on Linux in code using "catch let error as NSError" #43202

[SR-585] Segfault on Linux in code using "catch let error as NSError" #43202

Comments

swift-ci commented Jan 19, 2016

swift-ci commented Feb 15, 2016

swift-ci commented Feb 18, 2016

swift-ci commented Feb 18, 2016

swift-ci commented Feb 18, 2016

swift-ci commented Mar 13, 2016

swift-ci commented Nov 13, 2016

swift-ci commented Jan 11, 2017

gwynne commented Feb 22, 2017

swift-ci commented Feb 22, 2017

gwynne commented Feb 24, 2017

jckarter commented Feb 25, 2017

jckarter commented Feb 25, 2017

gwynne commented Feb 25, 2017

jckarter commented Feb 26, 2017

swift-ci commented Feb 27, 2017

swift-ci commented Feb 27, 2017

ffried commented Feb 28, 2017

jckarter commented Feb 28, 2017

jckarter commented Mar 1, 2017