Question

Anybody else having trouble with the 4.3 iPhone Simulator in XCode 4.2(lion) or 4.0.2?

I have code that has long been working, tested, and in production that uses blocks to specify completion actions. For example, I use UIView animate to fade out some text on top of the label as follows:

[UIView animateWithDuration: 0.0 
                      delay: 0.0 
                    options: (UIViewAnimationOptionCurveEaseInOut | UIViewAnimationOptionTransitionNone)
                 animations: ^{

                     videoTextLabel1.alpha = 0.0;
                     videoTextLabel2.alpha = 0.0;
                     videoTextLabel3.alpha = 0.0;
                 }

                 completion: ^(BOOL completed) {
                     [self fadeInNextMeditationLine: 0];
                 }];

I reliably get EXEC_BAD_ACCESS in the simulator — never a problem on the device.

In another place I use my own completion block implementation to take action after the user has dismissed a modal view.

    ValuePickerController *controller = 
    [[ValuePickerController alloc] 
        initWithNibName: kValuePickerXIBFileName
        bundle: nil
        labelText: @"prompt")
        value: alertSettings.frequency
        minimumValue: kMinimumFrequency
        maximumValue: kMaximumFrequency
     completionBlock: ^(NSInteger newValue) {
         [self updateFrequencyText: newValue];
         [self changeFrequencySetting];
     }];

There are no NSZombies showing up, and analyzer runs clean. Plus this code has been in production for 6 months with no crashes.

Anybody else having this trouble? It’s been happening since I upgraded XCode.

Answer 1

As far as I’m aware, it’s a known problem which only affects the 4.3 simulator. The 4.2 and prerelease 5.0 versions don’t appear to exhibit this problem. However it’s more of an issue now that Lion is out because the latest general release version of Xcode only supports the 4.3 simulator, where this problem occurs.

The actual cause is in the hooks between the Blocks and ObjC runtimes. Blocks themselves will work just fine, but any attempt to call an Objective-C message on them will result in a segfault. This is because the Blocks runtime contains a couple of uninitialized references to the relevant ObjC classes, and on the iOS 4.3 simulator these are never been initialized when the ObjC runtime loads (they’re only initialized if ObjC is being used at all– so the Blocks runtime doesn’t depend on having Foundation loaded). You can check this at runtime by looking at the value for _NSConcreteStackBlock, _NSConcreteGlobalBlock and _NSConcreteMallocBlock in the debugger. In the 4.2 simulator or on the device, these values will be non-nil, but on the 4.3 simulator they’re still zero.

I have a potential solution which I will link to here if necessary, but first I’m going to try & squeeze some information out of Apple as to whether they have a fix on the cusp of release or if they need some more info, etc.

UPDATE: PROBLEM SOLVED

I did lots of digging, and it ultimately boils down to this: don’t weak-link against libSystem.dylib using -weak_library. Instead, you should either not weak-link libSystem at all (I had to when supporting iOS 3.1.x, because compiler-generated Blocks code in some iOS4-specific conditional code was causing a link error at launch time, i.e. a bad bad crash), or you should use -weak lSystem instead, which the Simulator understands better.

When you’re running in the iOS Simulator, you can look at the loaded libraries (in Xcode: ‘Product->Debug->Shared Libraries…’) and if you search for ‘Blocks’ you’ll see two items: libsystem_blocks.dylib and libsystem_sim_blocks.dylib. The latter is the one linked by CoreFoundation, which initializes the ObjC runtime glue for the Blocks runtime. However, since you’re weak-linking the libSystem library as a whole, the symbols which are normally overridden by the Simulator’s version (since it loads later than libSystem) are actually overwritten at runtime from the first library which implements them. This means that you’ll find the system versions of _NSConcreteGlobalBlock and friends, which were not the ones initialized by the Simulator’s custom ObjC runtime.

For (lots!) more information on the problem, and to see how I tracked it down, check out the thread I made on the Apple Developer Forums.