Consider the following Class in swift that maintains a recursive relationship with itself
class OctupPromisable {
var promise: OctupPromisable?
weak var chainedPromise: OctupPromisable?
func then(octupPromisable: OctupPromisable) -> OctupPromisable? {
self.promise = octupPromisable
octupPromisable.chainedPromise = self
return self.promise
}
func start() {
if nil == self.chainedPromise {
self.fire(nil)
}else {
self.chainedPromise!.start()
}
}
}
used as such:
OctupPromisable()
.then(OctupPromisable())
.then(OctupPromisable())
.start()
when I call start with the chainedPromise being weak, it always results in the chainedPromise being nil and hence the start method never recurses.
Making the chainedPromise strong, causes the start method to recurse and work correctly. But in doing so am I not creating a strong cyclic relationship that leads to memory leak? If so, what can be done in order to achieve the recursion and yet avoid memory leak?
Thanks!
Make your chained process strong, but after you've used it, set it to nil. You're done with it, so you don't need to hold a strong reference any more. If there are no other strong references, the object will be deallocated.
If you don't need to keep references after execution, you could use a strong reference and release inner promises recursively, so when your first promise deallocate, it will not cause a memory leak.
I couldn't test the code but it goes like this:
class OctupPromisable {
weak var promise: OctupPromisable? // Make it weak to avoid reference cycle
var chainedPromise: OctupPromisable? // Make it a strong reference
func start() {
if nil == self.chainedPromise {
self.fire(nil)
} else {
self.chainedPromise!.start()
self.chainedPromise = nil // Will be deallocated after all 'start' calls
}
}
}
Related
With swift compiler optimizations implicitly unwrapped optional variables do not survive the whole scope, but are released immediately after usage.
Here is my environment:
swift --version
outputs
Apple Swift version 5.3.2 (swiftlang-1200.0.45 clang-1200.0.32.28)
Target: x86_64-apple-darwin20.2.0
Xcode version is Version 12.3 (12C33)
Consider this most rudimentary example that shows the issue:
final class SomeClass {
func doSth() {}
deinit {
print("deinit")
}
}
func do() {
var someObject: SomeClass! = SomeClass()
someObject.doSth()
print("done")
}
This should ouput
done
deinit
However, in release builds (with Swift code optimizations enabled "-O") it prints the other way round:
deinit
done
This is ONLY the case for var someObject: SomeClass!.
The following alterations of that code ALL output correctly (meaning the Object is released when the scope of the function is left):
Define var as constant:
func doSthSpecial() {
let someObject: SomeClass! = SomeClass()
someObject.doSth()
print("done")
}
Define var as optional explicitly:
func doSthSpecial() {
var someObject: SomeClass? = SomeClass()
someObject.doSth()
print("done")
}
Access like an optional:
func doSthSpecial() {
var someObject: SomeClass! = SomeClass()
someObject?.doSth()
print("done")
}
These last three implementations all output
done
deinit
in that order.
Somehow this leaves me speechless 🤷‍♂️.
I understand this optimization, it makes sense. But as a programmer we are used to local variables inside of functions being available until leaving the scope.
The problem I have here is about the lifetime of an object that is stored in such an implicitly unwrapped optional variable. If I have code that depends on the lifetime of this object (which is the case with RxSwift and its DisposeBags for example) then I am getting weird behavior, unexpected behavior!
I could consider this as a bug in Swift, but what do you think? Bug or no bug?
Here is a more real-world scenario with RxSwift where you could be using such a construct:
import UIKit
import RxSwift
final class SomeClass {
func doSth() {}
deinit {
print("deinit")
}
}
class ViewController: UIViewController {
let providePassword = PublishSubject<String>()
lazy var askForPassword: Observable<String> = {
return Observable.create { observer in
_ = self.providePassword.subscribe(observer)
return Disposables.create()
}
.debug(">>> ask for password signal")
}()
private func performAsyncSyncTask() {
DispatchQueue.global().async {
var disposeBag: DisposeBag! = DisposeBag()
let sema = DispatchSemaphore(value: 0)
self.askForPassword
.subscribe(onNext: { pw in
print(pw)
sema.signal()
})
.disposed(by: disposeBag)
_ = sema.wait(timeout: DispatchTime.distantFuture)
disposeBag = nil
}
}
#IBAction func startAskPassword(sender: AnyObject) {
self.performAsyncSyncTask()
}
#IBAction func sendPassword(sender: AnyObject) {
self.providePassword.on(.next("hardcoded pw"))
}
}
The problem here is: When executing self.performAsyncSyncTask() it is subscribed to askForPassword but because in optimized builds the implicitly unwrapped optional variable is purged immediately after using it in .disposed(by: disposeBag).
This destroys the signal immediately after subscribing to it.
But as a programmer we are used to local variables inside of functions being available until leaving the scope.
This hasn't been the case since ARC was first released for ObjC. ARC has always had the option to release objects after their last use (and very often makes use of this). This is by design, and is not a bug in Swift (or in ObjC, where it's also true).
In Swift, if you want to extend the lifetime of an object beyond its last use,withExtendedLifetime is explicitly for this purpose.
var someObject: SomeClass! = SomeClass()
withExtendedLifetime(someObject) {
someObject.doSth()
print("done")
}
Keep in mind that it is legal for objects to have balanced retain/autorelease calls on them, which may cause them to outlive their scope as well. This is much less common in Swift, but still legal and happens if you pass a Swift object to ObjC (which can happen in many places you may not expect).
You should be very careful relying on when deinit will be called. It can surprise you, and isn't even promised in all cases (for example, deinit is not called during program quit on Mac, which tends to surprise C++ developers).
IMO performAsyncSyncTask is a dangerous pattern, and should be redesigned with clearer ownership. I don't do enough RxSwift work to immediately redesign it, but blocking the whole thread on a DispatchSemaphore seems the wrong way to integrate with any reactive system. Threads are a finite resource, and this forces the system to create more while this one is blocked doing nothing.
Can someone please help me to avoid memory leak below
class Base {
var refer: Referenced?
init() {
self.refer = Referenced()
}
deinit {
print("deinit called")
}
}
class Referenced {
var native: Native
init(){
native = Native.init(baseRef: Base())
}
}
struct Native {
var baseRef: Base
}
func testMe () {
var base:Base? = Base()
base?.refer = nil
base = nil
}
testMe()
Looks like there is a cyclic reference in here. Base -> Referenced and Referenced -> Native -> Base
But I am unsure how to break this cycle .
There are two issues here:
As others have pointed out, in general, when you have two or more reference types referring to each other, you need to make one of those references weak to break the strong reference cycle. See Resolving Strong Reference Cycles Between Class Instances.
The more serious problem here is that you have infinite loop. The init of Base is instantiating a new Referenced instance, but the init of Referenced is creating another Base instance (which it’s passing to the Native instance). That new Base instance will then create another Referenced instance, repeating the process, and it will continue doing this until it runs out of memory/stack.
Add print statements inside your various init methods, and you’ll see this infinite loop in action.
You should revisit this model, identify an “ownership” graph. Parent objects can keep strong references to child objects (and possibly instantiate child objects, if appropriate), but child objects should only keep weak references back to their parent objects (and most likely not instantiate new parent objects).
For example, you might do:
class Parent {
var child: Child?
init() {
self.child = Child(parent: self)
}
deinit {
print("deinit called")
}
}
class Child {
weak var parent: Parent?
init(parent: Parent) {
self.parent = parent
}
}
And
func testMe() {
var parent: Parent? = Parent()
parent = nil // in this case, this is unnecessary because `parent` is a local variable, but this is here for illustrative purposes; but note that we don’t have to `nil` the `child`
}
Here, you instantiate a Parent object, which happens to instantiate a child. But note that:
The Parent supplies itself as a parameter to the Child;
The Child only maintains a weak reference back to the Parent; and
The Child obviously does not instantiate a new Parent, but rather just uses the reference that was supplied to it.
You can do a rendition of this with your Native struct, too, but the idea will be the same: Break the strong reference cycle with a weak reference and avoid the infinite loop.
Frankly, in these cases, abstract type names make examples unnecessarily confusing. If you clarify what these various types actual represent with a practical, real-world example, the ownership model will undoubtedly become more self-evident.
Change one of the reference as weak like this :
class Base {
weak var refer: Referenced?
init() {
self.refer = Referenced()
}
deinit {
print("deinit called")
}
}
Hope this helps.
You need to mark either Base.refer or Native.baseRef as weak to break the cycle, i.e. change var to weak var.
First of all, at the code snippet you passed, you have a problem with infinite circular dependency like this:
Base -> Referenced -> Native -> Base...
An instance of Native struct is not referencing the Base instance at the beginning of this chain, it is always creating a new one and this behavior is infinite. Just copy your code to the playground and try to run it. You will receive an "Execution was interrupted" error.
So, your code won't even run. As I suppose, what you are trying to achieve is for a Native struct to hold the reference to the first Base instance. Here is the right solution where we pass the reference from Base to Referenced and to Native that will hold the reference:
class Base {
var refer: Referenced?
init() {
self.refer = Referenced(base: self)
}
deinit {
print("deinit called")
}
}
class Referenced {
var native: Native
init(base: Base){
native = Native.init(baseRef: base)
}
}
struct Native {
var baseRef: Base
}
And now, as Native is referencing to the Base parent, you will struggle with the memory leak you mention in the original question. And this time, to prevent the memory leak you have to make your baseRef var weak like this:
weak var baseRef: Base?
Does accessing a singleton within a closure cause a retain cycle?
Specifically something like this example:
class TheSingleton
{
static let shared = TheSingleton() //THE SINGLETON
enum Temperature //An associated enum
{
case cold, hot
}
var currentTemp: Temperature? //A non-class-type variable
var aPicture: UIImage? //A class-type variable
func giveMeFive() -> Int //A function
{
return 5
}
//Pay attention to this
func doSomething(onDone: #escaping (Int) -> ())
{
OtherSVC.upload("Mr. Server, do async stuff plz") { (inImage) in
TheSingleton.shared.currentTemp = .cold
TheSingleton.shared.aPicture = inImage
onDone(TheSingleton.shared.giveMeFive())
}
}
}
//Fire the thing
TheSingleton.shared.doSomething { _ in}
If so, I don't really know how to write a capture list for this...
[weak TheSingleton.shared] (inImage) in
You can't do that ^
I included three cases because maybe the type of data matters?
I think I'm missing some fundamentals on capture lists and closure retain cycles.
All I know is whenever you access something outside of a closure's curly braces, you have to unown/weak it if it's a class-type object.
That's because closures create strong references by default.
I thought I could be cheeky and get around retain cycles by calling the entire singleton in closures, but I'm probably being dumb by turning a blind eye.
Would a solution be to do something like:
var updateDis = TheSingleton.shared.aPicture
OtherSVC.upload("ugh this is lame, and more work") { [unowned updateDis] inPic in
updateDis = inPic
}
?
Since you are writing a singleton, TheSingleton.shared is pretty much always going to be the same thing as self, so capture unowned self or weak self instead. I would prefer weak here because self will pretty much always be retained by the class and will only be deallocated when the application terminates.
OtherSVC.upload("Mr. Server, do async stuff plz") { [unowned self] (inImage) in
self..currentTemp = .cold
self.aPicture = inImage
onDone(self.giveMeFive())
}
following is a code sample you can run in a playground
import Foundation
class TempNotifier {
var onChange: (Int) -> Void = {t in }
var currentTemp = 72
init() {
// 1.
onChange = { [unowned self] temp in
self.currentTemp = temp
}
// 2.
onChange = {[unowned self] temp in
self.tempHandler(temp)
}
// 3.
unowned let s = self
onChange = s.tempHandler
}
deinit {
println("deinit")
}
private func tempHandler(temp: Int) {
self.currentTemp = temp
}
}
var tN: TempNotifier? = TempNotifier()
tN = nil
It illustrates 3 ways of assigning a value to a block with potential retain-cycle. Case 1. and 2. create no retain cycle due to unowned self however in case 3. it seems like there is no way to break the retain cycle (deinit is never printed). As you can see, I even tried to create a local unowned reference.
Is this the desired behaviour, is it "by design"? Or am I missing something?
Thanks!
Cross-posted from https://devforums.apple.com/message/1122247
Yes, this is the designed behavior.
Accessing a method without calling it, like s.tempHandler, is equivalent to a closure expression like { x in s.tempHandler(x) }. Here s is not marked unowned or weak, and hence is retained by the closure. If you want it to be captured as unowned or weak, you must explicitly write out the closure.
Which one happens first?
Zeroing (nilling) weak variable.
deinit
Without looking at the documentation, nor implementation...
Only one order makes sense: nilling has to come first.
If deinitialization would start before nilling weak references ARC would suffer the good old resurrection problem (retaining an object that is in the process of being deallocated). That is not the case.
Here's my mental model of object destruction (again, not from the documentation, this can differ from real world):
last strong reference to an object goes away
retain count goes to zero (logically)
object is internally flagged for destruction, disabling any more new references
all weak references are nilled
unowned reference count is checked and traps if non-zero
deinit chain is called, possibly calling through to objc base classes dealloc
strong references to properties and ivars go away
objc side effects of dtor happen (associated objects, c++ destruction, ...)
memory is reclaimed
Step 1 through 4 happen atomically with regards to other threads potentially taking new strong references to the object.
Zeroing weak variable happens first. deinit happens later. At least in current implementation (Xcode 6.1, Swift 1.1) This is a result of observation of specific implementation, and I don't know how it is actually defined by the authors... If you have explicit source, please comment or answer.
There's also a related discussion in ADC forum.
Test code Avoid Playground when testing this to get correct lifecycle behaviour.
class AAA {
func test() {
}
}
var a1 = nil as AAA?
weak var a2 = nil as AAA?
class BBB: AAA {
var data = "Here be dragons."
override func test() {
println("test() called and a2 is now \(a2).")
}
deinit {
println("deinit called and a2 is now \(a2).")
}
}
a1 = BBB()
a2 = a1
a2!.test()
a1 = nil
Result:
test() called and a2 is now Optional(weak_deinit_order_comparison.BBB).
deinit called and a2 is now nil.
Then, the weak variable becomes nil before the deinit to be called.
Update
This pre-nilling is applied equally to unowned objects. Unowned object will become inaccessible at the point of deist just like weak, and trial to access unowned object at the deinit will crash the app.
Update 2
If you assign self to a weak var variable in deinit, it will become nil immediately. (Xcode Version 6.3.2 (6D2105))
class Foo {
init() {
}
deinit {
var a = self
weak var b = self
unowned var c = self
let d = Unmanaged.passUnretained(self)
println(a) // prints `Foo`.
println(b) // prints `nil`.
// println(c) // crashes.
println(d.takeUnretainedValue()) // prints `Foo`.
}
}
var f = Foo() as Foo?
f = nil