Landon Fuller

Reliable Crash Reporting

Wed, 14 Sep 2011 16:09 PDT

Introduction

PLCrashReporter is a standalone open-source library for generating crash reports on iOS. When I first wrote the library in 2008, it was the only option for automatically generating and gathering crash reports from an iOS application. Apple's iOS crash reports were not available to developers, and existing crash reporters — such as Google's excellent Breakpad — were not supported on iOS (Breakpad still isn't). Since that time, quite a few crash reporters and crash reporting services have appeared: Apple now provides access to App Store crash reports, a number of 3rd-party products and services were built on PLCrashReporter (such as HockeyApp, JIRA Mobile Connect), and some services have chosen to write their own crash reporting library (TestFlight, Airbrake, and others).

Despite this obvious interest in adopting crash reporting from iOS developers, there has remained little understanding of the complexities and difficulties in implementing a reliable and safe crash reporter, and many of the custom crash reporting libraries have been implemented improperly. It's my intention to explore what makes crash reporting difficult (especially on iOS), and provide real-world examples of how an impoperly written crash reporter can fail — sometimes with little fanfare, and sometimes with surprising consequences.

A Hostile Environment

Implementing a reliable and safe crash reporter on iOS presents a unique challenge: an application may not fork() additional processes, and all handling of the crash must occur in the crashed process. If this sounds like a difficult proposition to you, you're right. Consider the state of a crashed process: the crashed thread abruptly stopped executing, memory might have been corrupted, data structures may be partially updated, and locks may be held by a paused thread. It's within this hostile environment that the crash reporter must reliably produce an accurate crash report.

To reliably execute within this hostile environment, code must be "async-safe": it must not rely on external, potentially inconsistent state. More concretely, this means that a crash reporter must avoid APIs that have not been written explicitly to be executed with a signal handler, in a potentially crashed process. This excludes everything from malloc — the heap may have been corrupted, or partially updated — to Objective-C — locks may be held in the runtime, or data structures might be partially initialized. In fact, there's so little that you can do safely within a signal handler, it's much easier to define what you *can* do safely — a minimum number of system calls and APIs are defined to be async-safe, and those are the only APIs you can reliably call.

Thus, to be reliable and safe, a crash reporter must be written with async-safety in mind, eliminating or minimizing the risk inherent in operating within a hostile and corrupt environment. At this point, you might ask what I mean by "reliable and safe" — after all, if the process has already crashed, what's the worst that could happen? It crashes again? In fact, there's quite a bit that can go wrong, largely depending on the non-async-safe APIs that an unreliable crash reporter might rely on.

First, do no harm

The mission of a crash reporter is simple: report crashes, and provide enough information to debug them. As it turns out, if you know how to read the report, just about everything you need to debug nearly all crashes can be found in the backtraces, register state, and a bit of intuition about your own code (look for a future blog post on this subject).

However, a crash reporter should never make things worse — I'll cover three major ways it can do that:

Relying on non-async-safe APIs: This can deadlock the process and cause a hang, resulting in a failure to report the crash. In the pathological case, this can result in corruption of users' data.
Using overly simple APIs like backtrace(3): Blinds the developer to specific problems --- such as a stack overflow -- by being unable to report them.
Discarding crashed thread's register state: Providing incomplete crash reports makes it practically impossible to debug certain classes of crashes.

Let's explore these failure cases with some real world examples.

Failure Case: Async-Safety and Deadlocking Objective-C

One of the more likely failure modes when dealing with a non-async-safe APIs is a deadlock. Imagine that the application has just acquired a lock prior to crashing. If the crash reporter's implementation then attempts to acquire the same lock, it will wait forever: the crashed thread is no longer running and will never release the lock. When a deadlock like this occurs on iOS, the application will appear unresponsive for 10-20 seconds until the system watchdog terminates the process, or the user force quits the application.

It is possible to trigger such a deadlock simply by using Objective-C within the signal handler. The Objective-C runtime itself maintains a number of internal locks, and if a thread happens to hold a runtime lock when a crash occurs, any use of Objective-C in the crash reporter itself will trigger a deadlock. This is dependent on timing, however — for the purposes of a providing a simple test case, I've created a contrived example that will reliably demonstrate the deadlock on ARM and x86:

static void unsafe_signal_handler (int signo) {
    /* Attempt to use ObjC to fetch a backtrace. Will trigger deadlock. */
    [NSThread callStackSymbols];
    exit(1);
}
 
int main(int argc, char *argv[]) {
    /* Remove this line to test your own crash reporter */
    signal(SIGSEGV, unsafe_signal_handler);
 
    /* Some random data */
    void *cache[] = {
        NULL, NULL, NULL
    };
 
    void *displayStrings[6] = {
        "This little piggy went to the market",
        "This little piggy stayed at home",
        cache, 
	"This little piggy had roast beef.",
        "This little piggy had none.",
        "And this little piggy went 'Wee! Wee! Wee!' all the way home",
    };
    
    /* A corrupted/under-retained/re-used piece of memory */
    struct {
        void *isa;
    } corruptObj;
    corruptObj.isa = displayStrings;
 
    /* Message an invalid/corrupt object. This will deadlock crash reporters
     * using Objective-C. */
    [(id)&corruptObj class];
     
    return 0;
}

If you run this code on iOS or the simulator, you'll reliably trigger a deadlock in any crash reporter using Objective-C in its signal handler. While this specific example is somewhat contrived for the sake of serving as reliable test case, any use of Objective-C or any other non-async-safe function in a signal handler has the potential to trigger such a deadlock, and should be avoided.

Failure Case: Async-Safety and Data Corruption

The risk of data corruption is a far more potent concern than a deadlock. There are a surprising number of ways that this can occur — but what might be the most likely (and dangerous) mechanism to trigger data corruption is the reentrant running of the application's event loop.

Some crash reporters attempt to submit the crash report over the network immediately upon program termination. This introduces an interesting failure mode: spinning the runloop to handle network traffic may also trigger execution of the application's own code, and the application is then free to attempt to write potentially corrupt user data.

Consider a Core Data-based application, in which a model object is updated, and then saved:

person.name = name;
person.age = age; // a crash occurs here
person.birthday = birthday;
[context save: NULL];

At the time of the crash, the managed object context contains a partially updated record — certainly not something you want saved to the database. However, if the crash reporter then proceeds to reentrantly run the application's runloop, any network connections, timers, or other pending runloop dispatches in your application will also be run. If the application code dispatched from the runloop contains a call to -[NSManagedObjectContext save:], you'll write a partially updated record to the database, corrupting the user's data.

This approach of executing non-reentrant, non-async-safe code from a crash reporter is particularly dangerous. To avoid this, the signal handler can not make use of higher-level networking APIs at crash time, and crash report implementations must not attempt to submit a crash report until the application has started again.

If added to your UIApplicationDelegate, the following code will print a message to the console if your crash reporter spins the runloop after a crash has occurred:

dispatch_async(dispatch_get_main_queue(), ^{
    NSLog(@"APPLICATION CODE IS RUNNING - Crash reporter is spinning runloop");
});
*((int *)NULL) = 5; // trigger a crash

Failure Case: Stack Traces and Stack Overflow

There are two ways to implement backtrace support in a crash reporter (but only one of them is reliable):

Use high-level APIs such as backtrace(3) or -[NSThread callStackSymbols] to fetch a stack trace for the current thread
Implement custom stack walking to support fetching a backtrace for all threads (including the crashed thread)

The first solution is unreliable for a number of reasons, but the failure mode I'll be addressing here is a stack overflow. In the case of a stack overflow, a crash reporter that makes use of backtrace(3) or similar APIs will be entirely unable to report the crash. Here's a code example that will accidentally trigger an overflow:

/* A small typo can trigger infinite recursion ... */
NSArray *resultMessages = [NSMutableArray arrayWithObject: @"Error message!"];
NSMutableArray *results = [[NSMutableArray alloc] init];
 
for (NSObject *result in resultMessages)
    [results addObject: results]; // Whoops!
 
NSLog(@"Results: %@", results);

If the crash reporter makes use of backtrace(3), this crash will not be reported. The reason is straight-forward: These backtrace APIs must execute on on the crashed thread's stack, but that stack just overflowed. There is is no stack space within which the crash reporter's signal handler can be run.

However, if the crash reporter uses sigaltstack() to correctly execute on a different stack, the backtrace will be empty — the signal handler is running on a new stack!

In PLCrashReporter, this was solved by implementing custom stack walking for the supported platforms. This requires more complexity, but in addition to supporting the generation of reports in the case of stack overflow, also allows the crash reporter to provide stack traces for all running threads.

Conclusion

Implementing a reliable crash reporter is difficult, and these are only a brief overview of the potential pitfalls and complexities involved. I think Mike Ash best described the complexity of signal handlers in Friday Q&A:

There is very little that you can do safely. There is so little that I'm
not even going to discuss how to get anything done, because it's so impractical
to do so, and instead will simply tell you to avoid using signal handlers
unless you really know what you're doing and you enjoy pain.

While I can't claim that PLCrashReporter is perfect, great effort (and pain) have been expended in ensuring its reliability and correctness. If you're considering implementing your own ad-hoc reporter, I'd highly recommend reviewing the design decisions made in both Google Breakpad and PLCrashReporter, both of which are liberally licensed and may be included in any commercial and/or closed-source product.

As a developer considering the use of a crash reporter in your application, I hope this overview will provide a little more insight into their function (and design complexities), as well as providing you with some tools to evaluate the efficacy of the available solutions -- complex failure cases are often the time when you need accurate, reliable crash reporting the most.

Implementing imp_implementationWithBlock()

Thu, 14 Apr 2011 06:46 PDT

In iOS 4.3, Apple introduced a new API to support the use of blocks as Objective-C method implementations. The API provides similar functionality as Mike Ash's MABlockClosure, which uses libffi (or libffi-ios) to implement support for generating arbitrary function pointers that dispatch to a block.

However, Apple's new API differs from MABlockClosure in a few important ways:

Only Obj-C IMP-compatible function pointers may be generated.
No knowledge of the block's type signature is required (with some caveats we'll discuss below).
The trampoline is lightweight (just a few instructions), this is faster than libffi-based dispatch as used by MABlockClosure.

Today, I'll be discussing how block-based message dispatch is implemented by Apple, and how you can implement your own similar, custom trampolines on iOS and Mac OS X. Additionally, I've posted PLBlockIMP on github. This project provides:

An open-source implementation of imp_implementationWithBlock() for Mac OS X 10.6+ and iOS 4.0+ (ARM, i386, and x86-64).
Generalized code to support automated generation of arbitrary trampoline pages on Darwin, based on the trampoline allocator I wrote for libffi-ios.

In addition to this article, Bill Bumgarner has written an excellent introduction to imp_implementationWithBlock, and if you need a refresher in objective message dispatch, Mike Ash has a more in-depth explanation here.

This work has been funded by my employer, Plausible Labs. We specialize in Mac OS X, iOS, and Android development and we're available for hire.

Creating Trampolines without Writable Code

The implementation of imp_implementationWithBlock() relies on trampolines to convert between Objective-C method calls and block dispatch. Trampolines are small pieces of code that, when called, perform some intermediary operations and then jump to the actual target destination. When you call imp_implementationWithBlock(), a function pointer to a trampoline is returned; it's this trampoline's responsibility to modify the function arguments and then jump to the actual code corresponding to the block's implementation.

Trampolines often require more information than can be derived from their function parameters -- such is the case with our IMP trampolines, which must have a pointer to the target block that they should call. Historically, this type of trampoline has generally been implemented through the use of writable code pages; the instructions are written to a PROT_EXEC|PROT_WRITE page at runtime, with any additional context information included directly in the generated code.

Unfortunately, iOS has instituted a restriction on the use of writable, executable pages (although there are signs that this may eventually be lifted), necessitating the use of an alternative mechanism for implementing trampoline-specific context data. While iOS does not allow the use of writable code, we can leverage a combination of vm_remap() and PC-relative addressing to implement configurable trampolines without writable code.

On Darwin, vm_remap() provides support for mapping an existing code page at new address, while retaining the existing page protections; using vm_remap(), we can create multiple copies of existing, executable code, placed at arbitrary addresses. If we generate a template page filled with trampolines at build time, we can create arbitrary duplicates of that page at runtime. This allows us to allocate an arbitrary number of trampolines using that template without requiring writable code:

Figure 1: vm_remap()

However, executable trampoline allocation only solves half the problem -- we still need a way to configure each trampoline.

The solution is PC-relative addressing. The processor's program counter register indicates the address of the currently executing instruction; PC-relative addressing uses the program counter to address memory relative to the currently executing instruction. When we remap our trampolines and then jump to them, each trampoline is executing at a unique address. If we then map a writable data page next to our trampoline page, we can use PC-relative addressing to load per-trampoline data from adjacent writable data page:

Figure 2: vm_remap() with writable data pages

Once a full page of trampolines are allocated, we simply need to provide the individual trampolines on request, and allocate additional pages if the pool of trampolines is exhausted. A full implementation of a trampoline allocator is available in PLBlockIMP; refer to pl_trampoline_alloc(), pl_trampoline_data_ptr(), and pl_trampoline_free().

To save space within our trampoline page, each individual trampoline saves the PC register, and then jumps to a common implementation at the start of the trampoline page. The ARM implementation of the individual trampoline stub is two instructions:

mov r12, pc
b _block_tramp_dispatch;

IMP->Block Dispatch (self, _cmd, and Block)

As noted in Bill Bumgarner's article on imp_implementationWithBlock, every Objective-C method has two implicit, pointer-sized arguments at the head of the method's argument list: self, and _cmd. Likewise, block implementations also have an implicit first argument; the block literal, which maintains the block's reference count, bock descriptor, references to captured variables, and other block data.

When called, a trampoline returned by imp_implementationWithBlock() is responsible for re-ordering its arguments to match those required by the block's implementation: the 'self' argument must be moved to second argument slot (overwriting _cmd), and the block literal moved to the (now vacated) first argument slot.

However, there is one wrinkle that Bill didn't touch on: structure return values. On the current architectures supported by Darwin, functions that return structures by value may have an additional pointer at the start of their argument list. This pointer is used to provide the address on the caller's stack at which the structure return value should be written.

In the case where structure return (stret) calling conventions are used, the structure return pointer in the first argument slot must remain unmodified, the block literal argument must be in the second argument slot, and the self pointer in the third. This requires that imp_implementationWithBlock() provide two different trampoline implementations to support both calling conventions, and that the requisite trampoline type for a block be determined when imp_implementationWithBlock is called.

There is no way to determine from a raw function pointer whether a function requires stret calling conventions -- to work around this, Apple's compilers set an additional flag, BLOCK_USE_STRET, when emitting a block that requires the stret calling conventions. This flag may be used to easily determine the necessarily trampoline type for a block.

As described in the previous section, the individual trampolines save their PC address and then immediately jump to a shared implementation at the start of the trampoline page. That shared implementation re-orders the existing arguments, loads the block literal from its PC-relative configuration data, and then jumps to the block's implementation -- on ARM, our non-stret shared implementation looks like this:

_block_tramp_dispatch:
    # trampoline address+8 is in r12 -- calculate our config page address
    sub r12, #0x8
    sub r12, #0x1000
    
    # Set the 'self' argument as the second argument
    mov r1, r0
    
    # Load the block pointer as the first argument
    ldr r0, [r12]
 
    # Jump to the block pointer
    ldr pc, [r0, #0xc]

Conclusion

While I still have my fingers crossed for PROT_EXEC|PROT_WRITE pages on iOS, vm_remap()-based trampolines can serve as a viable replacement for some tasks. If you have further questions, or ideas for other neat projects worth tackling, feel free to drop me an e-mail.

Work with Plausible Labs

Thu, 18 Feb 2010 10:26 PST

When I started Plausible Labs in 2008, we were working out of our homes, paying our rent out of savings while we figured out how to bootstrap worker-owned software cooperative without external funding.

A year or so later, I'm part of a three member team. We are all still working out of a home, but now it's a loft in the Mission with proper office space, Ikea desks, and even a few Aeron chairs. We've got the issue of self-sufficiency figured out, and now we're looking to the future -- how we'd like to grow our organization, what sort of software projects we'd like to tackle (both in-house and on contract), and how the co-operative experiment will scale past a few members.

We're ready to take on more (and larger) projects, and we’d like to find the right engineer for a contract-to-hire role to help us out. We’re particularly keen in finding someone genuinely interested in joining the co-operative, and open to working with us on either a part-time or full-time basis.

If you'd be interested in working with us, you can find the job posting here.

OpenJDK 7 on Leopard PPC

Wed, 16 Dec 2009 17:29 PST

Introduction

Thanks to the work of Gary Benson on implementing and merging the Zero-Assembler Project, and Greg Lewis' work bringing it to OpenJDK BSD Port, it's now possible to bootstrap OpenJDK 7 on Mac OS X 10.5/PPC.

Gary Benson's Zero Assembler provides a portable implementation of the JVM intepreter that -- unlike the existing JVM implementations -- relies on very little assembler to provide an acceptably performing but highly portable VM, opening the door to supporting Mac OS X PPC with very little additional work.

I've committed the few small fixes to get OpenJDK running on Mac OS X 10.5/PPC, and have bootstrapped an initial OpenJDK 7 binary using Havard Eidnes's bootstrap scripts. Bootstrapping the initial VM running is sufficiently involved that I would recommend using my binaries (openjdk7-macppc-2009-12-16-b4.tar.bz2).

Source Access

OpenJDK uses Mercurial with the Forest extension. Before checking out the BSD sources, you will need to install and configure Mercurial. See the OpenJDK Developer's Guide for more information.

To check out the BSD-Port forest:

hg fclone http://hg.openjdk.java.net/bsd-port/bsd-port

Building on Leopard/PPC

Building OpenJDK requires Java 6 or OpenJDK 7 -- on PPC, you will need to download or build an OpenJDK 7 bootstrap VM (openjdk7-macppc-2009-12-16-b4.tar.bz2).

To build the JDK in build/bsd-ppc/j2sdk-image:

make \
CC=gcc-4.0 \
CXX=g++-4.0 \
ALT_BOOTDIR=/usr/local/openjdk7-macppc-2009-12-16-b4
ANT_HOME=/usr/share/ant \
ALT_FREETYPE_HEADERS_PATH=/usr/X11/include \
ALT_FREETYPE_LIB_PATH=/usr/X11/lib \
ALT_CUPS_HEADERS_PATH=/usr/include \
ALT_CACERTS_FILE=/System/Library/Frameworks/JavaVM.framework/Home/lib/security/cacerts \
LIBFFI_CFLAGS="-I/usr/include/ffi" \
NO_DOCS=true \
ZERO_BUILD=true \
ZERO_ENDIANNESS=big \
ZERO_LIBARCH=ppc \
ZERO_ARCHDEF=PPC \
ZERO_ARCHFLAG=-m32

Be sure to set ALT_BOOTDIR to the path of your installed openjdk7-macppc-2009-12-16-b4 bootstrap JDK.

Once built, you should now have a JDK in build/bsd-ppc/j2sdk-image:

landonf@onefish:~/openjdk-ppc/bsd-port> ./build/bsd-ppc/j2sdk-image/bin/java -version
openjdk version "1.7.0-internal"
OpenJDK Runtime Environment (build 1.7.0-internal-landonf_2009_12_16_12_54-b00)
OpenJDK Zero VM (build 17.0-b05, interpreted mode)

For more information or assistance, please refer to the OpenJDK BSD-Port wiki and mailing list. My testing has been very limited -- if you run into issues, please report them on the development mailing list.

Using Blocks: Understanding the Memory Management Rules

Sat, 11 Jul 2009 18:09 PDT

Introduction

I just finished uploading PLBlocks 1.0-beta2, which adds support for iPhoneOS 2.2, iPhone 3GS armv7-optimized binaries, and host support for PPC systems (release announcement). This seems like a good time a good time to continue with my ad-hoc series on developing with Blocks (previous post).

I've fielded a number of questions regarding the memory management rules surrounding blocks; This article should help you understand the basic rules necessary to use blocks successfully.

I won't delve too deep into the describing the actual block implementation, as that's a topic well-covered by Clang's Block Implementation Specification Even if you don't have time to read the implementation specification, it's important to note that blocks are really just a few functions and structures implemented for you by the compiler, coupled with a runtime to help with managing setup and tear down. You could implement the same thing yourself in pure C -- but it would be so verbose as to not be useful.

The Memory Management Rules

Apple provides a set of straight-forward memory management rules for Objective-C. I've endeavoured to provide an equivalent set of rules for blocks in C and Objective-C.

This is the single fundamental memory management rule:

To take ownership of a block, you must copy that block via -copy or Block_copy(). You are responsible for relinquishing ownership of blocks you own using -release or Block_release().

The following rules derive from the fundamental rule, or cope with edge cases:

Block_copy() must be paired with Block_release(); likewise, the Objective-C -copy message must be paired with an Objective-C -release message.
By default, variables captured by a block are copied, and global variables are referenced directly. If a captured variable is marked with the __block storage specifier, the variable will be indirectly referenced and thus may be modified from within a block.
When a block is copied (or released):
- Any referenced (captured) Objective-C objects will be retained (or released).
- Any captured blocks will be copied (or released).

Block Ownership: Copy vs. Retain

All blocks have a valid class pointer, and appear to be Objective-C objects. According to the standard Objective-C memory management, to assume ownership of an object you must simply retain it. However, blocks differ from the standard Objective-C objects in at least one fundamental and very important way: blocks defined within a function are allocated on the stack, and will persist only until your function returns.

This is why it is necessary to copy a block, rather than retain it: If the block is stack allocated, it must be copied to a heap allocation to persist beyond the lifetime of the current stack frame. Once copied, the block will be heap allocated and persist like any other standard Objective-C object.

Thus, to ensure that you do not attempt to maintain ownership of a stack allocated block, you must always copy a block if you wish to reference it past the lifetime of your current function. As an optimization, if a block has already been copied to the heap copying will simply increment the block's reference count.

It should also be noted that there is one very real benefit to stack allocation of blocks: they are very cheap, and unless copied, require no allocations or cleanup.

Captured Variables: Copy vs. Reference

By default, local variables (variables of the "auto" storage class) are captured by your block as const copies, while global variables are accessed directly. The runtime automatically handles reference counting of captured blocks and Objective-C objects.

To allow you modify a local variable (rather than its copy), Apple has added the __block storage specifier. Any __block variables are accessed by referenced from within a block. This is best explained by example:

__block int i = 0;
int j = 0;
executeBlock(^{
    // Increments the stack allocated 'i' variable by 1.
    i++;

// 'j' is a const copy, and can not be modified from within the block / j++ });

If you copy a block, any captured __block variables will also be copied to the heap.

Blocks Examples: NSOperationQueue and UIActionSheet

Sat, 04 Jul 2009 18:25 PDT

Introduction

On Friday, Plausible Labs released PLBlocks, an SDK that allows you to immediately begin experimenting with blocks (also known as closures) on Mac OS X 10.5 and iPhone OS 3.0. While the original announcement included a very brief introduction to blocks, I thought it might be worthwhile to provide some concrete examples of using blocks in your own code.

Example Code

All the sample code and implementation classes for this article are available via my block_samples github repository. You may download the repository as an archive (no git required) by pressing the "download" button next to the repository name.

To get started with the PLBlocks SDK, check out the download and installation instructions on the project page. Please note that PLBlocks is still in beta.

NSOperationQueue

On Mac OS X and iPhoneOS, there are a variety of ways to schedule operations on a background thread. One method that's often used is calling -[NSObject performSelectorInBackground:withObject:] to execute a method in the background, and then -[NSObject performSelectorOnMainThread:withObject:waitUntilDone:] to provide the results to the primary thread.

This works, but it's not as convenient as it could be:

Every background task requires at least one new method definition.
Methods can only accept one (or two) arguments.
There's no easy way to provide the background method with additional state.

Using blocks -- and a few small extensions to NSOperationQueue and NSThread -- we can instead encapsulate this full exchange in one method, using a block to run the background operation, and a nested block to handle the response directly on the main thread:

- (void)applicationDidFinishLaunching:(NSNotification *)aNotification {
    // Allocated here for succinctness.
    NSOperationQueue *q = [[NSOperationQueue alloc] init];
 
    /* Data to process */
    NSData *data = [@"Hello, I'm a Block!" dataUsingEncoding: NSUTF8StringEncoding];
 
    /* Push an expensive computation to the operation queue, and then
     * display the response to the user on the main thread. */
    [q addOperationWithBlock: ^{
        /* Perform expensive processing with data on our background thread */
        NSString *string = [[NSString alloc] initWithData: data encoding: NSUTF8StringEncoding];
         
        /* This is the "expensive" part =) */
        sleep(5);
         
        /* Inform the user of the result on the main thread, where it's safe to play with the UI. */
        [[NSThread mainThread] performBlock: ^{
            NSAlert *alert = [[[NSAlert alloc] init] autorelease];
             
            [alert addButtonWithTitle: @"OK"];
            [alert setMessageText: [NSString stringWithFormat: @"Processing completed: %@", string]];
            [alert runModal];
        }];
 
        /* We don't need to hold a string reference anymore */
        [string release];
    }];
}

The first block is scheduled to run on the NSOperationQueue, and inside contains an additional nested block. When the operation has completed, it schedules its nested block to run on the main thread, where the result can be presented to the user, or passed on for further processing.

You can find the full NSOperationQueue and NSThread extensions -- including example usage -- here.

UIActionSheet

If you've done any iPhone development, you'll know that using UIActionSheet is a bit complicated -- more so if you want to share an action sheet implementation across view controllers, or display multiple UIActionSheets from a single view controller.

If you've used UIActionSheet in the past, you've had to do the following:

Create a UIActionSheet instance in your view controller.
Add the UIActionSheetDelegate protocol to your view controller.
Add the -[UIActionSheetDelegate actionSheet:clickedButtonAtIndex:] delegate method.
Match the button index and source action sheet to your intended action, fetch any state you need, and execute.

Using blocks, we can significant reduce the effort required to define and use a UIActionSheet. Instead of defining a delegate, and matching index values to your button actions, we can simply pass a block that implements the button's action directly:

- (void) displaySheet {
    PLActionSheet *sheet = [[PLActionSheet alloc] initWithTitle: @"Destination"];
    
    /* A re-usable block that simply displays an alert message */
    void (^alert)(NSString *) = ^(NSString *message) {
        UIAlertView *alert = [[UIAlertView alloc] initWithTitle: @"Destination Selected"
                                                        message: message
                                                       delegate: nil
                                              cancelButtonTitle: @"OK"
                                              otherButtonTitles: nil];
        
        [alert show];
        [alert release];
    };
    
    [sheet addButtonWithTitle: @"Work" block: ^{
        alert(@"Work selected");
    }];
    
    [sheet addButtonWithTitle: @"Home" block: ^{
        alert(@"Home selected");
    }];
    
    [sheet addButtonWithTitle: @"School" block: ^{
        alert(@"School selected");
    }];
    
    [sheet setCancelButtonWithTitle: @"Cancel" block: ^{}];
 
    [sheet showInView: self.window];
    [sheet release];
}

That's it -- there is nothing else. The blocks used for each button automatically have access to the enclosing method's variables, and we even use another block (alert) to avoid retyping the UIAlertView boilerplate or cluttering our class with an alert method.

You can find the full UIActionSheet wrapper -- including example usage -- here.

Conclusion

I hope you'll find these examples useful in experimenting with and incorporating blocks into your own software. There are quite a few other ways that blocks can be leveraged to decrease code size and complexity, and I'll plan on writing future articles on the subject.

If you'd like to discuss blocks, the PLBlocks implementation, or having any other questions, feel free to join the PLBlocks mailing list.

PLBlocks: Blocks for iPhoneOS 3.0 and Mac OS X 10.5

Thu, 02 Jul 2009 21:50 PDT

Over the weekend (and for some of the week) I've been working on back-porting block support from the Snow Leopard toolchain, with the goal of leveraging blocks for our iPhone and Mac OS X 10.5 development at Plausible Labs.

If you're unfamiliar with blocks, they're an implementation of closures for C, Objective-C, and provisionally C++. The full language specification and ABI specification are available from the LLVM/Clang project.

I've now published an initial beta release with support for iPhone OS 3.0 (armv6), and Mac OS X 10.5 (i386, x86-64, ppc) -- you can find the full announcement -- including download and usage instructions -- here.

New Plausible Labs Website

Wed, 20 May 2009 17:55 PDT

We just released a new design for the Plausible Labs website, home of the fine worker-owned cooperative that keeps me gainfully employed so that I can spend my free time (such as it exists) working on open source software.

Critical Mac OS X Java Vulnerabilities

Tue, 19 May 2009 14:42 PDT

Introduction

Five months ago, CVE-2008-5353 and other vulnerabilities were publicly disclosed, and fixed by Sun.

CVE-2008-5353 allows malicious code to escape the Java sandbox and run arbitrary commands with the permissions of the executing user. This may result in untrusted Java applets executing arbitrary code merely by visiting a web page hosting the applet. The issue is trivially exploitable.

Unfortunately, these vulnerabilities remain in Apple's shipping JVMs, as well as Soylatte 1.0.3. As Soylatte does not provide browser plugins, the impact of the vulnerability is reduced. The recent release of OpenJDK6/Mac OS X is not affected by CVE-2008-5353.

Work-Arounds

Mac OS X users should disable Java applets in their browsers and disable 'Open "safe" files after downloading' in Safari.
Soylatte users running untrusted code should upgrade to an OpenJDK6-based release, where possible. No future releases of the JRL-based Soylatte branch are planned at this time. If this is an issue for you, please feel free to contact me.

Patch

Update 06-15-2009: Apple has released Java for Mac OS X 10.5 Update 4, which contains a fix for this issue.

To update your system, run "Software Update" from the Apple menu.

Note: Safari users should leave 'Open "safe" files after download' permanently disabled. Similarly critical vulnerabilities unrelated to Java remain in Safari's handling of "Safe" files.

Proof of Concept

Unfortunately, it seems that many Mac OS X security issues are ignored if the severity of the issue is not adequately demonstrated. Due to the fact that an exploit for this issue is available in the wild, and the vulnerability has been public knowledge for six months, I have decided to release a my own proof of concept to demonstrate the issue.

If you visit the following page, "/usr/bin/say" will be executed on your system by a Java applet, with your current user permissions. This link will execute code on your system with your current user permissions. The proof of concept runs on fully-patched PowerPC and Intel Mac OS X systems.

Credit

Thanks to Jeffrey Czerniak for bringing this issue to my attention.

Update: Julien Tinnes e-mailed with a link to his in-depth discussion regarding the vulnerability available here.

OpenJDK 6 for Mac OS X

Sun, 17 May 2009 15:19 PDT

As part of the OpenJDK project, various organizations have been working on OpenJDK 6, a freely distributable Java 6 implementation based on the open source OpenJDK 7 code base. Most Linux distributions are now shipping OpenJDK 6 binaries.

Soylatte (Java 6 Port for Mac OS X) was originally based on the BSD port of the JRL licensed Java 6 code base, which significantly constrains end-user usage and distribution rights. With Sun's approved re-licensing of the BSD changes for use in OpenJDK 7, a backport to OpenJDK 6 was made possible.

I've added support for OpenJDK 6 on Mac OS X, based on Brian Gardner's work backporting the OpenJDK 7 BSD changes to OpenJDK6/FreeBSD. Unlike the legacy Soylatte builds, OpenJDK 6 is:

Open source and freely redistributable under the GPLv2 w/ ClassPath Exception license -- you may bundle the JDK/JRE with commerical products.
More up-to-date -- the current build of OpenJDK6/Mac OS X should be runtime equivalent to Java 6 Update 11 (Sun JRL source releases are sporadic).
Available as a binary package as well as installable via MacPorts.

The initial beta release is available for testing via the MacPorts openjdk6 port (Leopard only), or as a binary from the Soylatte web page (Leopard/Tiger, untested on Tiger). My ability to provide 10.4 support is constrained without access to a 10.4 machine, and any testing/development assistance is most welcome.

Landon Fuller

Reliable Crash Reporting

Introduction

A Hostile Environment

First, do no harm

Failure Case: Async-Safety and Deadlocking Objective-C

Failure Case: Async-Safety and Data Corruption

Failure Case: Stack Traces and Stack Overflow

Conclusion

Implementing imp_implementationWithBlock()

Creating Trampolines without Writable Code

IMP->Block Dispatch (self, _cmd, and Block)

Conclusion

Work with Plausible Labs

OpenJDK 7 on Leopard PPC

Introduction

Source Access

Building on Leopard/PPC

Using Blocks: Understanding the Memory Management Rules

Introduction

The Memory Management Rules

Block Ownership: Copy vs. Retain

Captured Variables: Copy vs. Reference

Further Reading

Blocks Examples: NSOperationQueue and UIActionSheet

Introduction

Example Code

NSOperationQueue

UIActionSheet

Conclusion

PLBlocks: Blocks for iPhoneOS 3.0 and Mac OS X 10.5

New Plausible Labs Website

Critical Mac OS X Java Vulnerabilities

Introduction

Work-Arounds

Patch

Proof of Concept

Credit

OpenJDK 6 for Mac OS X