[SR-4363] isa-swizzling causes protocol variable access to crash

[swift-ci]

Previous ID	SR-4363
Radar	rdar://problem/31275541
Original Reporter	vladot (JIRA User)
Type	Bug
Status	Resolved
Resolution	Done

Attachment: Download

Environment

Mac OS X 10.11.5 + XCode 8.2.1

Additional Detail from JIRA

Votes	0
Component/s	Compiler
Labels	Bug, RunTimeCrash, Runtime
Assignee	None
Priority	Medium

md5: 4be0928a50bcb0c800fb21ca3baf013c

Issue Description:

I am not sure whether this is an NSObject issue or a Swift issue, but since it seems to me that the general problem is with accessing protocol variables after isa-swizzling, I think it falls more in the Swift domain. Here goes:

I have a protocol and the first steps of its type-erasure like so

import Foundation

protocol A: class { }

class AbstractA: A { }

class DelegatedA<D: A>: AbstractA {
    init(_ d: D) { }
}

class AnyA: DelegatedA<AbstractA> {
    init<D: A>(_ d: D) {
        super.init(DelegatedA<D>(d))
    }
}

extension A {
    var anyA: AnyA {
        return AnyA(self)
    }
}

Now I declare a class that conforms to the protocol and also inherits from NSObject

class B: NSObject, A { }

Next I declare a variable from the class B and upcast it to NSObject

var b = B()
let d: NSObject = b

Casting d to A and type-erasing it works fine

(d as! A).anyA

Now we define an observer of b

class O: NSObject { }
var o = O()
b.addObserver(o, forKeyPath: "xxx", options: [.new], context: nil)

This isa-swizzles b and now the type-erasure of d crashes

(d as! A).anyA

I have attached a snapshot of the top of the stack after the crash. The crash is in _buildDemanglingForNominalType.

Thanks,
Vladimir

[swift-ci]

Comment by Vladimir Trifonov (JIRA)

It seems that the problem has to do with the fact that the new variable (anyA) is defined only in the extension and not in the protocol itself. Including the variable as a requirement in the protocol makes the crash go away. While this did solve my problem, it still is awkward that I am forced to include something in the protocol, simply because a class that implements the protocol is observed.

[belkadan]

With assertions on on master I'm getting

Assertion failed: (registered == c && "objc_readClassPair failed to instantiate the class in-place"), function swift_instantiateObjCClass, file /Volumes/Data/swift-public/swift/stdlib/public/runtime/SwiftObject.mm, line 1161.

but without assertions it's working fine for me in Swift 3.1, which is good news for you.

[belkadan]

@swift-ci create

[belkadan]

I suspect this assertion's just not valid for dynamic subclasses.

[gparker42]

The assertion fails because objc_readClassPair() returned nil. objc_readClassPair() returned nil because it already has a class with that name (_TtGC4test10DelegatedACS_1B_ a.k.a. test.DelegatedA<test.B>). I'm not sure why Swift is asking for the same class name to be used twice.

[gparker42]

Looks like swift_getObjectType() is failing to punch through the artificial NSKVONotifying_test.B class at the second call to anyA. The KVO class is then passed to the generics lookup machinery which isn't expecting that.

[gparker42]

The comments for swift_getObjectType clearly state the intention to avoid KVO subclasses, but I don't see anything in the implementation that attempts to do any such thing.

[belkadan]

cc @jckarter

[jckarter]

Makes sense to me for swift_getObjectType to look through artificial subclasses.

[gparker42]

#10561

[bob-wilson]

This is done now.