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.

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 }
}

Comment by Robert Thompson (JIRA)

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

extension NSError : ErrorType { }

on line 168 😉

Comment by Vadim Eisenberg (JIRA)

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

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.

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?

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.

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 #​1, name = 'Test', stop reason = signal SIGSEGV: invalid address (fault address: 0x90)
  * frame #​0: libswiftCore.so`swift_dynamicCast [inlined] swift::ValueWitnessFlags::getAlignmentMask() const at Metadata.h:231
    frame #​1: libswiftCore.so`swift_dynamicCast [inlined] swift::ValueWitnessTable::getAlignmentMask(this=0x0000000000000000) const at Metadata.h:733
    frame #​2: libswiftCore.so`swift_dynamicCast [inlined] swift::SwiftError::getValue(this=0x00000000008bf920) const at ErrorObject.h:119
    frame #​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

Comment by AdamDann (JIRA)

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

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.

This should fix it: #7761

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.

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

Should be fixed in master now.

Comment by Sergey Minakov (JIRA)

Will this fix be included into 3.1 version?

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).

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

@swift-ci create

PR for 3.1: #7847