[SR-4602] ARC issue?

[swift-ci]

Previous ID	SR-4602
Radar	None
Original Reporter	johann (JIRA User)
Type	Bug
Status	Resolved
Resolution	Invalid

Attachment: Download

Environment

MacOS 10.12.4, Swift 8.3.1

Additional Detail from JIRA

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

md5: 2cf1c56a11dffb5cf5d2c7e6272e4a33

Issue Description:

The following Swift program dies. I'm running it with "xcrun swift a.swift" where a.swift contains the 7 lines below. I'm using [unowned self] to ensure the memory frees up after the computation completes (it does not otherwise). Thanks.

class C {
    let a: Int
    lazy var b: () -> Int = { [unowned self] in return self.a }
    init(_ a: Int) { self.a = a }
    deinit { print("die") }
}
print(C(7).b())

die
0 swift 0x00000001091a3ec7 PrintStackTraceSignalHandler(void*) + 39
1 swift 0x00000001091a3376 SignalHandler(int) + 646
2 libsystem_platform.dylib 0x00007fffe1c7fb3a _sigtramp + 26
3 libsystem_platform.dylib 0x0000ffff00001fa0 _sigtramp + 506995840
4 libsystem_platform.dylib 0x000000010b7215ee _sigtramp + 699013838
5 libsystem_platform.dylib 0x000000010b7210ec _sigtramp + 699012556
6 swift 0x0000000106aebe2f llvm::MCJIT::runFunction(llvm::Function*, llvm::ArrayRef<llvm::GenericValue>) + 655
7 swift 0x0000000106af1a23 llvm::ExecutionEngine::runFunctionAsMain(llvm::Function*, std::**1::vector<std::1::basic_string<char, std::1::char_traits<char>, std::1::allocator<char> >, std::1::allocator<std::1::basic_string<char, std::1::char_traits<char>, std::_1::allocator<char> > > > const&, char const* const*) + 707
8 swift 0x0000000105feeb09 swift::RunImmediately(swift::CompilerInstance&, std::1::vector<std::1::basic_string<char, std::1::char_traits<char>, std::1::allocator<char> >, std::1::allocator<std::1::basic_string<char, std::1::char_traits<char>, std::_1::allocator<char> > > > const&, swift::IRGenOptions&, swift::SILOptions const&) + 3385
9 swift 0x0000000105fc4da4 swift::performFrontend(llvm::ArrayRef<char const*>, char const*, void*, swift::FrontendObserver*) + 50596
10 swift 0x0000000105f7257c main + 9052
11 libdyld.dylib 0x00007fffe1a70235 start + 1
12 libdyld.dylib 0x000000000000000a start + 509148630
Stack dump:
0. Program arguments: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/swift -frontend -interpret b.swift -enable-objc-interop -sdk /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk -color-diagnostics -module-name b
Trace/BPT trap: 5

[belkadan]

This is correct behavior. After accessing C(7).b, nothing is keeping the C instance alive anymore, so the compiler is allowed to release it before actually invoking the closure you got back.

[swift-ci]

Comment by Johann George (JIRA)

That makes sense. I suppose I'll have to find a different paradigm. Thanks.

[belkadan]

If you know that b is one-shot, you could write it as

lazy var b: () -> Int = {
  let result = self.a
  self.b = { fatalError("already called once") }
  return result
}

But that's still a bit of a hassle.

[swift-ci]

Comment by Johann George (JIRA)

True. Does that mean that the following could also possibly fail:

class C {
var a = 3
func f() -> Int { return a }
}
C().f()

Since after it has evaluated C().f but before it calls f, there is nothing keeping C alive anymore?

[belkadan]

No, for normal methods self is guaranteed to be alive for the duration of the call. It's specifically because b is a function value (closure) and not a method that this problem exists.