Deallocated instance exception with threads - objective-c

I've a problem with an app for Mac that I'm writing in Objective-c.
I've this situation:
In main thread (GUI):
ftEngine = [[FileT alloc] init];
[ftEngine setParameters:searchWord selectedEngine:[[pbEngines selectedItem] title] actualPage:0];
NSThread* thFileT = [[NSThread alloc] initWithTarget:ftEngine selector:#selector(setTotalResult) object:nil]; [thFileT start];
In child (ftEngine previous declared):
-(void)setTotalResult {
NSError* nsError = nil;
NSURL* urlCompleteUrl = [NSURL URLWithString:m_completeSearchWord];
}
m_completeSearchWord is initialized by setParameters function previously utilized.
And now.. my problem is:
When thread is started, it call setTotalResult function and i'll get an exception when I try to use m_completeSearchWord.
It's strange becacuse if I don't use a thread, all works correctly!
Exception is:
2011-09-08 23:24:06.731 GUI[12935:1a07] *** -[CFString respondsToSelector:]: message sent to deallocated instance 0x1003cc650

It sounds like you may not have retained m_completeSearchWord correctly when you initialized it. Add the body of -setParameters if you want help confirming that.

When calling selectors in a new thread, make sure that the selector has been properly wrapped with an autorelease pool :
-(void) setTotalResult {
NSAutoreleasePool* pool = [[NSAutoreleasePool alloc] init];
...
[pool release];
}
I see all manner of memory related issues when I forget to add the pool and your error definitely rings a bell.

Related

iOS concurrency: NSOperationQueue and ARC issue

I am currently implementing a multithreaded application and I encounter a strange race condition (leading to an ARC problem: error for object 0x7f8bcbd6a1c0: pointer being freed was not allocated).
The app creates multiple NSOperations, each one is downloading and processing information. As in every one of these NSOperations an error may occur (e.g., the web service is not available), I want to propagate the error up so I can handle it. However, I seem to encounter a race condition and the operations try to access invalid memory.
A minimalistic example which shows the memory access problem is the following one:
- (void) createError: (NSError**) err {
*err = [[NSError alloc] initWithDomain:#"Test" code:12345 userInfo:nil];
}
- (void)viewDidLoad {
[super viewDidLoad];
__block NSError *globalError = nil;
NSOperationQueue *queue = [[NSOperationQueue alloc] init];
NSOperation *op = nil;
for (int i=0; i<10; i++) {
op = [NSBlockOperation blockOperationWithBlock:^{
NSError *err = nil;
[self createError:&err];
// This loop increases the chance to get the race condition
for (int j=0; j<10000;j++) {
#synchronized(globalError) {
globalError = err;
}
}
}];
[queue addOperation:op];
}
[queue waitUntilAllOperationsAreFinished];
if (globalError) {
NSLog(#"An error occured in at least one of the operations");
}
}
Whenever I run this program, I get an exception. Mostly it is error for object 0x7fc0b860e860: pointer being freed was not allocated, however, sometimes I also got an EXC_BAD_ACCESS (code=EXC_I386_GPFLT) break in the debugger.
I have added the for-Loop over 10000 iterations only to increase the chance that the race condition occurs. If I leave it, the error only occurs in rare occasions (but still has to be fixed, obviously I am doing something wrong here).
The #synchronized directive uses the object you pass to control the synchronization, so, as you note, you're trying to synchronize on nil. And even if it wasn't nil, the object referenced by the #synchronized directive is a different object every time, largely defeating the attempt to synchronize.
The easiest change is to use #synchronized(self), instead. Or, create a NSLock object and then lock and unlock it when you access globalError. Or, if this was a high demand situation, use GCD queue (either serial queue or reader-writer pattern).

Writing iPhone 6 altimeter readings to an array class property inside queue block?

New iOS developer here. I've been searching for an answer to this in documentation on blocks and the altimeter, but I'm coming up short. I assume there's some simple thing I'm missing, but can't figure it out.
I have a custom class called PressureSensor. Simplistically speaking, the class has a property:
#property (nonatomic, strong, readwrite) NSMutableArray *pressure;
I load NSNumber values from the altimeter into this array.
The initializer for the class is:
- (instancetype)init
{
self = [super init];
if (self)
{
if (self.altimeterIsAvailable)
{
NSOperationQueue *queue = [[NSOperationQueue alloc] init];
[self.altimeter startRelativeAltitudeUpdatesToQueue:queue withHandler:^(CMAltitudeData *altitudeData, NSError *error) {
dispatch_async(dispatch_get_main_queue(), ^ {
[self.pressure addObject:altitudeData.pressure];
NSLog(#"Pressure 1: %#", [self.pressure lastObject]);
});
}];
NSLog(#"Pressure 2: %#", [self.pressure lastObject]);
}
}
return self;
}
When I run the app on my phone, I assume that pressure is successfully added to the self.pressure array, because the pressure is printed to the console by the "Pressure 1" line, which accesses the lastObject of self.pressure. However, it seems that these changes don't hold outside this block, as the Pressure 2 line outputs (null) to the console, and it doesn't seem like I can do anything with self.pressure outside this block.
Am I missing something about how blocks work exactly? Do I just need a __block somewhere? I'm completely at a loss here.
Addendum: self.altimeterIsAvailable is defined elsewhere. That part of the code shouldn't have any issues.
EDIT: The error ended up being elsewhere. For future readers who browse this post, the above code should be a perfectly valid way to add to a property array in a block.
This is not an answer but I'd like to mention it.
NSOperationQueue *queue = [[NSOperationQueue alloc] init];
[self.altimeter startRelativeAltitudeUpdatesToQueue:queue withHandler:^(CMAltitudeData *altitudeData, NSError *error) {
dispatch_async(dispatch_get_main_queue(), ^ {
...
});
}];
Creating a queue, and dispatch_async to the main queue. It's redundant. You can use NSOperationQueue +mainQueue method for it directly.
NSOperationQueue *queue = [NSOperationQueue mainQueue];
[self.altimeter startRelativeAltitudeUpdatesToQueue:queue withHandler:^(CMAltitudeData *altitudeData, NSError *error) {
...
}];

iOS autoreleased with no pool in place - but I am creating ARP!

So, I am using [NSThread detachNewThreadSelector] to spawn a new thread and I am getting "autoreleased with no pool in place " errors in the console. I know this can happen if you fail to create an auto release pool, but the thing is, I am creating one. I use similar code in other parts of the same app and do NOT get these errors.
Here is the relevant code:
- (void) startThread:(NSString*)strURL
{
// start new thread to load image
NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
[NSThread detachNewThreadSelector:#selector(loadImageFromURL:) toTarget:self withObject:strURL];
[pool release];
}
- (void) loadImageFromURL:(NSString*)strURL
{
NSNumber* nn = [NSNumber numberWithInt:self.tag];
NSLog(#"loadURL: Tag number == %i", [nn intValue]);
// other code here actually does the work
}
Now, there was more code in loadImageFromURL which actually does the work (of loading an image from a remote server) - but the problem manifests itself without that code, so I've removed it (just so you don't think I have a pointless thread which does nothing!). I left in just one line of code which demonstrates the problem - it creates an autoreleased NSNumber object.
When this code runs, it reports this to the console:
__NSAutoreleaseNoPool(): Object 0x535c0e0 of class NSCFNumber autoreleased with no pool in place - just leaking
Of course, the real code creates many other AR objects and all of them get reported as well.
Would be grateful for any tips or pointers which might help!
Thanks!
When you create a new thread, you need to also create a new autorelease pool for it. In your case, that looks as simple as adding:
NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
at the beginning of loadImageFromURL: and
[pool drain];
at the end.
You probably don't need or want the pool you're creating in startThread:. Check out the Threading Programming Guide, particularly the "Writing Your Thread Entry Routine" section.
On your code, - (void) startThread:(NSString*)strURL is running in the main thread, while - (void) loadImageFromURL:(NSString*)strURL is running on the background thread you are detaching.
The main thread already has a NSAutoreleasePool, so the one you are creating in startThread: is probably unneeded. However, the background thread will not create a NSAutoreleasePool, so you'd need to create it yourself.
In your code, that would look like:
- (void) startThread:(NSString*)strURL
{
// start new thread to load image
[NSThread detachNewThreadSelector:#selector(loadImageFromURL:) toTarget:self withObject:strURL];
}
- (void) loadImageFromURL:(NSString*)strURL
{
NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
NSNumber* nn = [NSNumber numberWithInt:self.tag];
NSLog(#"loadURL: Tag number == %i", [nn intValue]);
// other code here actually does the work
[pool drain];
}
Also, as #Carl Norum suggested, you should use drain instead of release when you are done using the autorelelase pool.
Solution for a similar problem but using ARC.
If using ARC, you could get an error "'NSAutoreleasePool' is unavailable: not available in automatic reference counting mode".
Use:
- (void) startThread:(NSString*)strURL
{
// start new thread to load image
[NSThread detachNewThreadSelector:#selector(loadImageFromURL:) toTarget:self withObject:strURL];
}
- (void) loadImageFromURL:(NSString*)strURL
{
#autoreleasepool {
NSNumber* nn = [NSNumber numberWithInt:self.tag];
NSLog(#"loadURL: Tag number == %i", [nn intValue]);
// other code here actually does the work
}
}

releasing NSInvocationOperation causes app to crash

Hi I have the following code
NSString *analyticsStr = [[NSString alloc] initWithString:[self constructXMLMessage:TagObj]];
NSInvocationOperation *operation = [[NSInvocationOperation alloc] initWithTarget:self
selector:#selector(sendAnalyticsString:)
object:analyticsStr];
[operationQueue addOperation:operation];
[analyticsStr release];
//[operation release];
when I uncomment [operation release] my app crashes. And I get this error :
malloc: * error for object 0x726ed50: pointer being freed was not allocated
* set a breakpoint in malloc_error_break to debug
I was of view that NSOperationQueue takes care of retaining objects. is there something I am doing wrong or not aware of.
Use Instruments's Zombies template to debug this. A flag will appear in the timeline when you send an object a message after it should have deallocated; you can click the button in that flag to begin investigating what unduly released the object.
By the way, you don't need to create that string object. The string that constructXMLMessage: returns will last as long as the current autorelease pool, which should be all the time you need to work with it. It won't suddenly die on you.

NSThread, AsyncSocket and object deallocation

I have a piece of network code that uses AsyncSocket but moves it to a separate runloop. I'm creating this runloop with the following piece of code:
[NSThread detachNewThreadSelector:#selector(_workerLoop) toTarget:self withObject:nil];
and here's how my _workerLoop looks like (they're both in the same class):
-(void)_workerLoop {
workerLoop = [[NSRunLoop currentRunLoop] retain];
while(keepWorkerLoopRunning) {
NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
[workerLoop runMode:NSDefaultRunLoopMode beforeDate:[NSDate dateWithTimeIntervalSinceNow:0.5f]];
[pool release];
}
[workerLoop release];
workerLoop = nil;
}
Now, according to the docs, the NSThread will retain the target, and as this thread will only terminate when AsyncSocket disconnects, it's impossible to release and deallocate this object until the socket disconnects.
How can I fix this or maybe I'm doing something wrong?
I've solved this by refactoring the runloop constructor out into own class, referenced by parent class that handles the networking code. This way, parent object is being deallocated, it can stop the thread and release the runloop