Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[SR-9999] Runtime assertion hit when using an 'deallocated' unowned reference in a -O build #52402

hamishknight opened this issue Feb 25, 2019 · 4 comments


Copy link

@hamishknight hamishknight commented Feb 25, 2019

Previous ID SR-9999
Radar None
Original Reporter @hamishknight
Type Bug

Swift version 5.0-dev (LLVM 6ddb64316c, Swift d17602a)
Target: x86_64-apple-darwin18.2.0

Additional Detail from JIRA
Votes 0
Component/s Compiler
Labels Bug, Runtime
Assignee None
Priority Medium

md5: 3dc353b8937cf7587df306c968f94c7f

Issue Description:

In a -O build, the following trips a runtime assertion:

import Dispatch
import Foundation

func foo() {
  class MyObject {
    var value = 0

  var o = MyObject()
  unowned var u = o
  o = MyObject()

  DispatchQueue.main.asyncAfter(deadline: .now()) {
    print("old unowned u = \(u)")


./swiftc /Users/hamishknight/Desktop/Stochastic\ Projects/unowned\ unowned/unowned\ unowned/main.swift -sdk /Applications/ -O; and ./main
/Users/hamishknight/Desktop/Stochastic Projects/unowned unowned/unowned unowned/main.swift:18:15: warning: variable 'u' was never mutated; consider changing to 'let' constant
  unowned var u = o
          ~~~ ^
Assertion failed: (object->refCounts.getUnownedCount() && "object is not currently unowned-retained"), function swift_unownedRetainStrong, file /Users/hamishknight/Desktop/swift-dev/swift/stdlib/public/runtime/HeapObject.cpp, line 516.
fish: './main' terminated by signal SIGABRT (Abort)
Copy link

@belkadan belkadan commented Feb 26, 2019

cc @rjmccall, @jckarter. How do we capture unowned variables?

Copy link

@jckarter jckarter commented Feb 26, 2019

It ought to be captured as unowned into the closure. It's fishy that it crashes with an assertion failure rather than a proper runtime trap, but it seems like this code ought to trap regardless, because the owning reference goes away before even the closure is formed.

Copy link

@rjmccall rjmccall commented Feb 26, 2019

Agreed. We should do a better job of diagnosing this at runtime, but essentially we're complaining when we copy the unowned reference into the closure that the reference is already dead, which seems like the right thing to do.

Copy link
Collaborator Author

@hamishknight hamishknight commented Feb 26, 2019

Indeed it should raise a runtime error – for context, the original issue was discovered when building without assertions where the code would sometimes trigger the correct runtime error and sometimes abort with EXC_BAD_ACCESS, which makes me feel like we have a race condition going on somewhere.

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet

No branches or pull requests

4 participants