[SR-10308] EXC_BAD_ACCESS crash when capturing self weakly in a convenience initializer

[swift-ci]

Previous ID	SR-10308
Radar	None
Original Reporter	dbeard (JIRA User)
Type	Bug

Environment

Xcode Version 10.2 (10E125) / Swift 5.0

macOS version 10.14.4 (18E226)

Additional Detail from JIRA

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

md5: b46c020e08aba8bae2389a3ca0cb2b74

Issue Description:

The following code causes a crash at runtime, but compiles fine:

import UIKit


enum FooType {
    case one
    case two
}


typealias Permutation = () -> (Void)


@objcMembers
class CatalogItem: NSObject {


    var t: FooType
    var permutation: Permutation?


    required init(t: FooType) {
        self.t = t
    }
}


@objcMembers
class Subclass: CatalogItem {
    convenience init() {
        self.init(t: .one)


        self.permutation = { [weak self] in
            print(self?.t)
        }
    }
}


class ViewController: UIViewController {
    override func viewDidLoad() {
        super.viewDidLoad()
        let s = Subclass() // EXC_BAD_ACCESS !
    }
} 

[swift-ci]

Comment by Daniel Beard (JIRA)

Note, if I remove the convenience init, remove the 'required' specifier from the superclass and make it a regular init that calls super, there isn't a crash here.

But the compiler shouldn't let me do this.

[belkadan]

Hm, I think this should be fine. After the self.init is done, you have a fully-built object, and it should be fine to capture that.

[belkadan]

Reduced to strip out UIKit:

import Foundation

enum FooType {
    case one
    case two
}


typealias Permutation = () -> (Void)


@objcMembers
class CatalogItem: NSObject {


    var t: FooType
    var permutation: Permutation?


    required init(t: FooType) {
        self.t = t
    }
}


@objcMembers
class Subclass: CatalogItem {
    convenience init() {
        self.init(t: .one)


        self.permutation = { [weak self] in
            print(self?.t)
        }
    }
}

do {
    let s = Subclass() // EXC_BAD_ACCESS !
}

[belkadan]

@mikeash, maybe a runtime issue?