CODEWITHSUNDEEP
iosobjective-c
BugaBuga
BugaBuga

Reputation: 509

Why sometime variable become NULL in block

I have some event from C++ written library which works in background thread:

virtual void OnData(const char* data)
{
    NSLog(@"Here 'data' string is present %s", data);
    @autoreleasepool {
        NSString* sData= [NSString stringWithCString:data encoding:NSUTF8StringEncoding];
        dispatch_async(dispatch_get_main_queue(), ^{
            NSLog(@"Here _sometimes_ 'data'(%s) is nil (\0). But sData is always present %@", data, sData);
            [callback OnData:sData];
        });
    };
}

And sometimes I have NULL(I suspect its garbage actually) in dispatch_async block in argument variable. But local NSString variable is always here. Why?

P.S. Do I actually must use @autoreleasepool in this situation?

Upvotes: 1

Views: 260

Answers (2)

Rob
Rob

Reputation: 437612

You have no assurances about the lifespan of the buffer that const char *data was pointing to by the time the async block is performed. The data could be dangling pointer by that point (and should be assumed to be so). It's very dangerous to use C-style pointers in any asynchronous references or outside the context they were originally created.

You should either use memory managed objects (e.g. NSData, NSString, etc.) or, if you insist on using C-style pointers and need to reference this pointer in the asynchronous block, copy the data to your own buffer, use that buffer, and then free it when you're done using that buffer in your asynchronous routine. In this case, you have your sData, so just don't refer to data after that point, and you'll be fine.

P.S. You later ask whether you must use @autoreleasepool in this situation.

In short, in most cases, no additional autorelease pool is needed. Notably, when using Grand Central Dispatch (e.g. dispatch_async), it has its own autorelease pools, so you don't have to create one. And, when your main thread yield back to its run loop, again, it's pool is drained. In short, you only need manually created autorelease pools when instantiating your own NSThread objects.

Having said that, sometimes you will introduce autorelease pools if doing significant memory intensive operations prior to yielding back to the run loop. In that case, you'll add autorelease pools in order to reduce the peak memory usage of the app. But this would not appear to be one of those cases.

Upvotes: 3

Fostah
Fostah

Reputation: 11776

If you had something like this:

void CallOnData()
{
    char *test = malloc(5 * sizeof(char));
    strcpy(test, "test");
    OnData(test);
    free(test);
}

You should expect data to be "NULL" in the block.

And autorelease is not needed, assuming you're using ARC, which you should be.

Upvotes: 1

Related Questions