Why can setting a Block variable inside an if statement cause a carsh?

Question

I found an block example in the book "Effective Objective-C 2.0"

void (^block)();
if (/* some condition */) {
    block = ^ {
        NSLog(@"Block A");
    };
} else {
    block = ^ {
        NSLog(@"Block B");
    };
}
block();

The code is dangerous, and here is the explanation in the book:

The two blocks that are defined within the if and else statements are allocated within stack memory. When it allocates stack memory for each block, the compiler is free to overwrite this memory at the end of the scope in which that memory was allocated. So each block is guaranteed to be valid only within its respective if-statement section. The code would compile without error but at runtime may or may not function correctly. If it didn’t decide to produce code that overwrote the chosen block, the code would run without error, but if it did, a crash would certainly occur.

I don't understand the meaning of "If it didn’t decide to produce code that overwrote the chosen block, the code would run without error, but if it did, a crash would certainly occur."

Can someone explain and give examples?

Answer 1

The issue is similar to that of a C array being created locally to a function and then used after the function returns:

#import <Foundation/Foundation.h>

dispatch_block_t global_block;
int * global_arr;

void set_globals(void)
{
    if( YES ){
        global_block = ^{
            NSLog(@"Summer is butter on your chin and corn mush between every tooth.");
        };
        int arr[5] = {1, 2, 3, 4, 5};
        global_arr = arr;
    }
}

void write_on_the_stack(int i)
{
    int arr[5] = {64, 128, 256, 512, 1024};
    int v = arr[3];

    dispatch_block_t b = ^{
        int j = i + 10;
        j += v;
    };

    b();
}


int main(int argc, const char * argv[])
{

    @autoreleasepool {

        set_globals();

        write_on_the_stack();

        global_block();

        NSLog(@"%d", global_arr[0]);    // Prints garbage
    }
    return 0;
}

The space on the stack that was used to store the values of the array may be re-used for any purpose. I use the separate function here because it most reliably demonstrates the problem. For your exact case, with the if block and the access in the same function, the compiler is still free to re-use the stack space. It may not, but you can't rely on that. You're breaking the scope rules of the language (derived from C).

As Jesse Rusak and CrimsonChris pointed out in comments, though, with a Block-type variable compiled under ARC, the Block is created on the stack like the array, but copied off the stack (to the heap) when it's stored in a strong pointer. All object pointers, including your global, are strong by default.

If you were not compiling with ARC, this would be unreliable. I can't come up with a failing example with my current compiler, but again, it's breaking the rules and the compiler is under no obligation to do what you want.

Answer 2

Essentially what this is saying is that if there's code running on a separate thread, and something gets assigned to the area of memory currently used by block but before the block() call, then bad things will happen.

void (^block)();
if (/* some condition *)) {
    block = ^ {
        NSLog(@"Block A");
    }
} else {
    block = ^ {
        NSLog(@"Block B");
    }
}
<--- another thread overwrites the **block** block
block(); <--- runtime error since **block** has been dereferenced.