Storing NSTimer instance inside C++ wrapper - c++

Question

In an ARC enabled project I am trying to store an allocated NSTimer inside a C++ wrapper (the NSTimer instance is not initialized):
#ifndef Wrapper_h
#define Wrapper_h
class Wrapper {
public:
Wrapper(id data): data_(data) { }
private:
id data_;
};
#endif /* Wrapper_h */
and the code in question:
-(void)test {
id timer = [NSTimer alloc];
Wrapper* w = new Wrapper(timer); // <-- BAD_ACCESS
}
My end goal is to extend the lifetime of the local id variable with the lifetime of the wrapper (later the wrapper pointer will be stored inside another global variable). Of course when the wrapper is deleted I would like the timer reference count to be decreased to 0.
Here's the stacktrace which looks like a recursive call to retain (stackoverflow):
Trying to bridge retain the timer also crashes:
-(void)test {
id timer = [NSTimer alloc];
CFTypeRef retained = (__bridge_retained CFTypeRef)timer; // <-- BAD_ACCESS
}
Trying to create an std::unique_ptr also will crash:
-(void)test {
id timer = [NSTimer alloc];
std::unique_ptr<id> ptr = std::make_unique<id>(timer); // <-- BAD_ACCESS
}
The code works if I initialize the NSTimer instance:
-(void)test {
id timer = [[NSTimer alloc] init];
Wrapper* w = new Wrapper(timer); // <-- OK
}
I also noticed that other Objective-C types work (such as NSObject, NSString, NSDictionary, NSArray, ...):
-(void)test {
id timer = [NSObject alloc];
Wrapper* w = new Wrapper(timer); // <-- OK
}
So what is special about NSTimer and what would be the proper way to store such instance inside my C++ wrapper? Are there any other examples such as NSTimer that would exhibit similar behaviour?
And a very important detail: this code only crashes iOS 10 (iOS > 10 works fine).

Answer 1

One of golden rule in software development is to follow contracts. For this particular case API states never initialize an object without reassigning any pointer to that object:
Note: It’s possible for init to return a different object than was created by alloc, so it’s best practice to nest the calls as shown.
Never initialize an object without reassigning any pointer to that object. As an example, don’t do this:
NSObject *someObject = [NSObject alloc];
[someObject init];
If the call to init returns some other object, you’ll be left with a pointer to the object that was originally allocated but never initialized.
I should admit though that it doesn't prohibit storing instance returned by the alloc method elsewhere, but Objective-C peculiarities make any use of such instances (apart from initialization) extremely error prone.
First, treat whatever you get from alloc and init... family of methods two different instances to be safe. That comes down to the fact that you have a possibility to return completely different object (even of different class) from an Objective-C constructor. It's one of the reasons why you see expression like self = [super init] (and not just [super init]) in subclassing documentation.
Second, Foundation framework uses Class Cluster design pattern heavily. It's the worst scenario of the previous point and the vast majority of the framework classes are abstract interfaces which hide the actual concrete classes returned by constructors (and even by the alloc method itself).
Thus storing instances returned by alloc essentially means storing abstract factories and it doesn't meet requirements you set for your wrapper (extending lifetime of local variables). Instead you want to keep instances of concrete classes, so wrap instances returned from constructors.
You already found that [[NSTimer alloc] init] doesn't make the code crash but it doesn't look quite correct to me either because the class API doesn't offer argument-less constructor, (it's impossible to get rid of default init from base NSObject in Objective-C, so you need to refer to API documentation to ensure what set of instance initialization is actually available).
What is special about NSTimer?
As i mentioned above Foundation framework classes are all special. And every class is special in its particular way. It's hard to say what exactly is different for NSTimer, however when passing Objective-C instance to a C++ function it follows the same rules, and ARC adds retain/release boilerplate for us, so we can inspect these variables from this standpoint.
I also noticed that other Objective-C types work (such as NSObject,
NSString, NSDictionary, NSArray, ...)
Here is a function which has variables of the given classes:
- (void) listVariables {
NSObject *allocObject = [NSObject alloc];
NSObject *initObject = [allocObject init];
NSString *allocString = [NSString alloc];
NSString *initString = [allocString init];
NSArray *allocArray = [NSArray alloc];
NSArray *initArray = [allocArray init];
NSDictionary *allocDictionary = [NSDictionary alloc];
NSDictionary *initDictionary = [allocDictionary init];
NSTimer *allocTimer = [NSTimer alloc];
NSTimer *initTimer = [allocTimer init];
NSTimer *properlyInitTimer = [allocTimer initWithFireDate:[NSDate date] interval:10 repeats:YES block:nil];
return;
}
Let's see what lldb debugger can reveal when stopped at the line with return expression:
(lldb) frame variable
...
(NSObject *) allocObject = 0x00006000025a0070
(NSObject *) initObject = 0x00006000025a0070
(NSPlaceholderString *) allocString = 0x00007fff801d75e8 class name = NSPlaceholderString
(__NSCFConstantString *) initString = 0x00007fff801dcfa0 ""
(__NSPlaceholderArray *) allocArray = 0x00007fff80198af0
(__NSArray0 *) initArray = 0x00007fff8002e970 0 elements
(__NSPlaceholderDictionary *) allocDictionary = 0x00007fff801a6a40
(__NSDictionary0 *) initDictionary = 0x00007fff8019fb60 0 key/value pairs
(NSCFTimer *) allocTimer = 0x00006000025a02f0
(NSTimer *) initTimer = nil
(__NSCFTimer *) properlyInitTimer = 0x00006000012a8180
Here you can see what these variables are turned into under the hood. This are private classes of course and they may change in future release but i would not expect drastic changes. The most simple is NSObject, an instance returned from alloc matches the instance returned from a constructor (this is part of API description, btw, so i would expect the same transparency for this project in all releases). If i print retain count for this instance, it gives pretty much expected value:
(lldb) po [allocObject retainCount]
2
(lldb) po [initObject retainCount]
2
If i print retainCount value for any of NSString, NSArray or NSDictionary variables in this frame, they all are equal to 2^64-1.
(lldb) po [initString retainCount]
18446744073709551615
Such a huge value essentially means that this instance is a singleton object. Such objects have release and retain methods overridden in a way that it doesn't affect their referenceCount and they exist within entire application life. That is a special kind of optimization for these objects.
From frame command output we can see that initTimer is nil and it doesn't make much sense to check its retain count or how retain works with it - this is a null object. If i print retainCount for the properlyInitTimer, it's quite straightforward:
(lldb) po [properlyInitTimer retainCount]
1
If i do the same for the allocTimer variable the result is kind of unexpected. The debugger gets frozen and entire process starts consuming 100% of CPU. My best bet it could be the reason behind the BAD_ACCESS error. (some kind of Reference Counting suppression introduced as part of the NSTimer abstract factory instance so it could not be removed) and Apple just made it less harmful in latest releases, after iOS 10, but of course i cannot know what exactly is there. (you can freely use retain and release methods on this instance but it apparently cannot be destroyed)