Objective-C crash on __destroy_helper_block_

Question

I have an iOS application that's crashing on calls like __destroy_helper_block_253 and __destroy_helper_block_278 and I'm not really sure what either "destroy_helper_block" is referencing or what the number after it is supposed to point to.

Does anyone have any pointers for how to track down where exactly these crashes might be occuring?

Here's an example traceback (note that the lines with __destroy_helper_block only references the file it's contained in and nothing else, when normally the line number would be included as well).

Thread : Crashed: com.apple.root.default-priority
0  libdispatch.dylib              0x000000018fe0eb2c _dispatch_semaphore_dispose + 60
1  libdispatch.dylib              0x000000018fe0e928 _dispatch_dispose + 56
2  libdispatch.dylib              0x000000018fe0e928 _dispatch_dispose + 56
3  libdispatch.dylib              0x000000018fe0c10c -[OS_dispatch_object _xref_dispose] + 60
4  Example App                    0x00000001000fe5a4 __destroy_helper_block_278 (TSExampleApp.m)
5  libsystem_blocks.dylib         0x000000018fe53908 _Block_release + 256
6  Example App                    0x00000001000fda18 __destroy_helper_block_253 (TSExampleApp.m)
7  libsystem_blocks.dylib         0x000000018fe53908 _Block_release + 256
8  libdispatch.dylib              0x000000018fe0bfd4 _dispatch_client_callout + 16
9  libdispatch.dylib              0x000000018fe132b8 _dispatch_root_queue_drain + 556
10 libdispatch.dylib              0x000000018fe134fc _dispatch_worker_thread2 + 76
11 libsystem_pthread.dylib        0x000000018ffa16bc _pthread_wqthread + 356

Edit 1: Here's an example of one of the blocks defined in the file where the crash occurs (with application-specific code edited out).

- (void)doSomethingWithCompletion:(void (^)())completion {
    void (^ExampleBlock)(NSString *) = ^{
        NSNotification *notification = [NSNotification notificationWithName:kExampleNotificationName object:nil userInfo:nil];
        [[NSNotificationCenter defaultCenter] postNotification:notification];

        if (completion) {
            completion();
        }
    };

    // Async network call that calls ExampleBlock on either success or failure below...
}

There are many other blocks in the file, but most of them are provided as arguments to methods instead of being defined first and then referenced later.

Edit 2: Added more context to above function.

Donau

See https://mcmap.net/q/502035/-blocks-within-nsoperation – Desdamona

Most likely you retained the block incorrectly. Make sure to copy it for storage. – Wayworn

@LeoNatan I assumed that much, but I was wondering how I could track down which block I should be looking at. There are dozens of them within this file. I was thinking that maybe that number suffix might be some indication but I can't figure out what it's supposed to mean. – Donau

The number is a compiler assigned identifier. And the number you have is of the destroyer helper block, not the block itself. I would enable zombies and try to reproduce the crash to see which object was released. May show you which block was released prematurely. – Wayworn

Did you try the static analyser? It's quite good at finding all kinds of problems. Do you have any retain properties containing blocks? Bad mistake, that will crash. Retaining any blocks instead of copying? – Bobble

@Bobble Haven't tried the static analyzer...will give that a shot. Re: retaining block properties, no. – Donau

Static analyzer found no issues in this file. I'll start a bounty. – Donau

What about enabling zombie objects? – Nonpartisan

I really recommend you to enable zombies as Rivera and LeoNathan suggested. Usually my my problems with block are due to zombies or by using a block even if I didn't set. If you use a block when it is NULL it launch an exception, always check they existence before launching them. – Alveolus

another suggestion: enable exception breakpoints – Scylla

@Alveolus The biggest problem is that I haven't been able to recreate the bug on my end. I need to use the traceback to track it down to a line number if possible. – Donau

do lines 278 and 253 correspond to line numbers containing blocks in TSExampleApp.m? – Demarcation

@BradAllred no, they do not – Donau

@Dan Sorry, I now realize you already had this thought. I will try to come back with something more helpful next time :) – Demarcation

@BradAllred no worries! – Donau

Code for your blocks would be helpful. Something such as not unregistering an observer or a not-invalidated timer could be some reasons. – Nonpartisan

can you post the code that creates the block in TSExampleApp.m? – Hairtail

Understanding and Analyzing iOS Application Crash Reports – Turnout

@Rivera Just posted some example code of the blocks that are defined explicitly instead of being passed right to other methods. – Donau

Maybe try posting to NSNotificationCenter in a dispatch_async on the main queue? – Demb

@Demb I'll give that a shot and follow up. Thanks! – Donau

What's the completion block and where is it defined? Looks unusual to call that block from inside your block. Maybe more code/context would help understanding. – Nonpartisan

@Rivera This block (ExampleBlock) is called after a network call, in the case of both success or failure. completion() is called to pass execution back to the original block. I'll add an edit to illustrate. – Donau

To expand on Leo Natan's comment: Is it possible that this happens: (1) doSomethingWithCompletion: creates ExampleBlock. (2) You start some asynchronous network operation. (3) doSomethingWithCompletion: returns, and ExampleBlock is released. (4) The asynchronous network operation finishes, and calls ExampleBlock. In this case, the pointer to the block would get dereferenced after it's been deallocated. (Perhaps this is intermittent based on whether the autorelease pool has drained.) In other words: do you guarantee that each block is retained until it's no longer needed? – Kayekayla

In your crash logs, do you see anything resembling "Semaphore/group object deallocated while in use"? – Cariole

@Cariole -- no, unfortunately not – Donau

@AaronBrager I believe that may be possible... – Donau

Then are you keeping around a queue or semaphore as an iVar somewhere for this object or for an object in the frame? – Cariole

@Cariole Nope, not that I can see. No semaphores / queues are instantiated in this frame. Just this block. – Donau

Answer 1

Each frame of the stack trace should give you a clue as to what libDispatch is doing to cause the crash. Working our way from the bottom:

11 libsystem_pthread.dylib        0x000000018ffa16bc _pthread_wqthread
10 libdispatch.dylib              0x000000018fe134fc _dispatch_worker_thread2 + 76

These two functions spin up a worker thread and runs it. In the process, it also sets up an autorelease pool for the thread.

9  libdispatch.dylib              0x000000018fe132b8 _dispatch_root_queue_drain + 556

This function signals the start of the queue destruction process. The thread-specific autorelease pool is drained, and in the process all variables referenced by that particular queue are released. Because this is libDispatch, that means the underlying mach object and the work block you submitted have got to go...

7  libsystem_blocks.dylib         0x000000018fe53908 _Block_release + 256
6  Example App                    0x00000001000fda18 __destroy_helper_block_253 (TSExampleApp.m)
5  libsystem_blocks.dylib         0x000000018fe53908 _Block_release + 25
4  Example App                    0x00000001000fe5a4 __destroy_helper_block_278 (TSExampleApp.m)

which is precisely what happens here. Number 7 is the outer block and because it contains a nontrivial object to destroy (yet another block), the compiler generated a destructor (__destroy_helper_block_253) to get rid of that inner block too. Applying the same line of logic, we can deduce that the inner block has yet another bit of nontrivial destroying to do.

3  libdispatch.dylib              0x000000018fe0c10c -[OS_dispatch_object _xref_dispose] + 60
2  libdispatch.dylib              0x000000018fe0e928 _dispatch_dispose + 56
1  libdispatch.dylib              0x000000018fe0e928 _dispatch_dispose + 56

These lines are the root cause of all your troubles. For some reason, you've either captured the queue you're calling back on, or you've captured an object that holds a reference to a queue weakly such that when it goes the way of the dinosaur, it takes its queue with it. This causes libDispatch to assume the queue is done for and it keeps on dealloc'ing until it reaches the semaphore-specific dispose

0  libdispatch.dylib              0x000000018fe0eb2c _dispatch_semaphore_dispose + 60

With no semaphore to release, mach will complain enough not to return KERN_SUCCESS on semaphore destruction, which is a fatal error in libDispatch. In fact, it will abort() in such a case -well, technically __builtin_trap(), but they accomplish the same goal. Because there's no debugger attached, down goes your app.

So this raises the question then: how do you fix this? Well, first you need to find what, if anything is referencing a dispatch object. You mentioned that you were doing some asynchronous networking, so that would be the place to check first. If any of those objects happens to hold a queue or semaphore, or references an object that does, and you aren't capturing it strongly in any of those blocks, this is precisely what happens when the block passes out of scope along with the object.

Cariole

Is it correct that your analysis says, that the crash occurs while deallocating the block completion? (IMHO, this is the case). – Distract

Yes and no. The root block is a dispatch block, but it's possible that either the completion or the example block is the inner one capturing the queue or semaphore. You're right about us needing to see more code to provide a better diagnosis. – Cariole

Great answer. Even though I can't extract a line number from this, your analysis seems to be the closest as I can get. Thanks! – Donau

No problem. It's always unfortunate when we can't provide more information without seeing potentially NDA'd or private source code, but I gave it my best given the information I had – Cariole

I still cannot understand from the stack traces above. So, what was the actual issue ? Not copying the block or strong pointers inside block. I have exact same scenario and your input would help me to get insight of the problem that I am facing. – Manasseh

@GeneratorOfOne Here, the issue is neither. By my analysis, the queue is being captured weakly in some way or another such that, when the object dies and takes the queue with it, it beats the destructor to the underlying mach object. – Cariole

Is it some how possible to reproduce this bug myself. Perhaps writing some kind of code to have this crash would help me to dig into the problem. – Manasseh

Hi @Cariole how would we need to capture a queue weekly? It doesn't make sense to me. – Candlestick

Answer 2

There's not a lot to go on here, but my suspicion is that the block is never getting moved to the heap. Blocks are created on the stack by default. The compiler can often figure out when to move them to heap, but the way you're handing this one from block to block probably is never doing that.

I would add a completionCopy = [completion copy] to force it onto the heap. Then work with completionCopy. See bbum's answer regarding storing blocks in dictionaries. With ARC, you don't need to call Block_copy() and Block_release() anymore, but I think you still want to call -copy here.

Rivalee

Wouldn't that cause KERN_INVALID_ADDRESSes to crop up when the dtor tries to grab something out of frame? The block is alive, the things referenced by the block aren't. – Cariole

The block ExampleBlock will be copied to the heap when it is captured by another block (unless it is already on the heap). Since there is some completion handler which - as the OP states - "calls this block" and if this completion handler is a Block itself, then we can be pretty sure that the block ExampleBlockis on the heap. – Distract

Answer 3

Hypothesis:

1. doSomethingWithCompletion: creates ExampleBlock.
2. You start some asynchronous network operation.
3. doSomethingWithCompletion: returns, and ExampleBlock is released.
4. The asynchronous network operation finishes, and calls ExampleBlock.

In this case, the pointer to the block would get dereferenced after it's been deallocated. (Perhaps this is intermittent based on whether the autorelease pool has drained, or whether other nearby memory areas have been released.)

3 possible solutions:

1. Store the Block in a property

Store the block in a property:

@property (nonatomic, copy) returnType (^exampleBlock)(parameterTypes);

Then in code,

self.exampleBlock = …

One problem with this approach is that you can only ever have one exampleBlock.

2. Store the Block in an array

To work around this problem, you can store the blocks in a collection (like NSMutableArray):

@property (nonatomic, strong) NSMutableArray *blockArray;

then in code:

self.blockArray = [NSMutableArray array];

// Later on…
[self.blockArray addObject:exampleBlock];

You can remove the block from the array when it's OK to deallocate it.

3. Work around the storage problem by simply passing the block around

Instead of managing storing and destroying your blocks, refactor your code so exampleBlock is passed around between the various methods until your operation finishes.

Alternatively, you could use NSBlockOperation for the asynchronous code, and set its completionBlock for the response-finished code, and add it to an NSOperationQueue.

Kayekayla

It's unlikely, that your hypothesis holds true: If the block ExampleBlock is executed in another block (the completion block of the network request (and I suppose, this is indeed the case) then the block ExampleBlock will be retained at the time when the completion-block literal expression will be evaluated, and released when the completion block finished. (Unless ARC is disabled or a Block isn't an object (prior to iOS 6). – Distract

Answer 4

I think the completion gets released in your async call that might be causing the crash.

Lop

Answer 5

I would suspect, the issue is not in your code but elsewhere.

One possible issue is this:

IFF there are UIKit objects which are captured in the Block completion you possibly get a subtle bug when the block is executed on a non-main thread AND this block keeps the last strong reference to those UIKit objects:

When the Block completion finishes, it's block get deallocated and along with this, all imported variables get "destroyed" which means in case of retainable pointers, that they receive a release message. If this was the last strong reference, the captured object gets deallocated which will happen in a non-main thread - and this can be fatal for UIKit objects.

Distract

Wouldn't UIKit frames show up in the trace then? This looks like a libDispatch worker thread failing to spin down. UIKit doesn't forbid threading, it just keeps around so much lockless global state that threading makes access and modification exceptionally unstable. – Cariole

@Cariole Wouldn't UIKit frames show up in the trace then? Possibly yes, but not necessarily due to some subtle side effects from race conditions. But in order to investigate the issue, we would need more code, and a way to debug it. – Distract

Answer 6

I don't see anything wrong with the code posted and think that the bug is somewhere else.

Also nesting blocks seems unnecessary and complicates memory management and probably makes finding the cause of the crash more difficult.

Why don't you begin by moving the code in your ExampleBlock directly to the completion block?

Nonpartisan

The logic in this block is repeated twice (once for success and once for failure) and I'm trying to avoid duplicating the code. – Donau

@Dan perhaps you should still try it for the sake of narrowing the problem? – Demarcation

Answer 7

what about this solution: if you will call some block later not in current scope, then you ought to call copy on it to move this block to the heap from the stack

- (void)doSomethingWithCompletion:(void (^)())completion {
    void (^ExampleBlock)(NSString *) = [^{
        NSNotification *notification = [NSNotification notificationWithName:kExampleNotificationName object:nil userInfo:nil];
        [[NSNotificationCenter defaultCenter] postNotification:notification];

        if (completion) {
            completion();
        }
    } copy];

    // Async network call that calls ExampleBlock on either success or failure below...
}

Wellrounded