Blog

Some time ago I was trying to remember a method name that I wanted to call in order to achieve the desired effect. Usually the Xcode app is able to list all the possible methods, but I had some errors in the file, so Xcode was confused and I could not fix all of it at the same time. So I decided, that I should implement a method, that lists all possible methods of a given class.

This is relatively easy in Objective-C, since the method names are inside every program, because the name resolution is done at runtime in Objective-C. All I had to do was implement some code fragment like this:

 #import <objc/runtime.h>
 ... 
 Class elem = [objectToBeListed class]; 
 while (elem) {
     NSLog(@"%s", class_getName( elem ));
     unsigned int numMethods = 0;
     Method *mList = class_copyMethodList(elem, &numMethods);
     if (mList) {
         for (int j=0; j < numMethods; j++) {
             NSLog(@" %s", 
                 sel_getName(method_getName(mList[j])));
         }
         free(mList);
     }
     if (elem == [NSObject class]) {
         break;
     }
     elem = class_getSuperclass(elem);
 }

This gives a fairly long listing of all methods of your class and all its super classes.

And it also revealed some humor from the Apple guys, when I listed a UIViewController Class. Because in the listing there I found the following class name (broken in to smaller pieces for better readability):

attentionClassDumpUser:yesItsUsAgain:
althoughSwizzlingAndOverridingPrivateMethodsIsFun:
itWasntMuchFunWhenYourAppStoppedWorking:
pleaseRefrainFromDoingSoInTheFutureOkayThanksBye:

If you find that hard to read, here is the readable version of that “sentence”:
attention Class Dump User: yes Its Us Again: although Swizzling And Overriding Private Methods Is Fun: it Wasnt Much Fun When Your App Stopped Working: please Refrain From Doing So In The Future Okay Thanks Bye:

To swizzle is computer-speak for changing something, for “messing around”. Although I had not planned to swizzle with any pointer or to override any method, I did feel like this sentence was directed to people like me, dumping the list of methods.

Of course, the documentation does not list this function. And there is no such function in Mac OS X, so this is an iPhone “feature”.

First, I wanted to name this article Correct program crashes at Apple, but then I realized that this was not a story about the APPLE review team but a story about the apple REVIEW TEAM. And of course about a bug, but mentioning that in the title would spoil the milk before the end of the story. So let’s get started.

I had submitted a new version of Regattakalender. As a sailor, one of my hobbyist side-projects had been this iOS app, that lists all sailing regattas of Germany that want to get listed in order to help me or other sailors plan their sailing season. Of course, the app is only available in German due to it’s regional character.

When the app got rejected because of crashing on an “iPad3,3” I was shocked. I had tested all available hardware versions EXCEPT the “new iPad” – simply because I do not own one. So was there something different? I had used parallel processing, synchronization with semaphores and other tricks to make sure that the customer gets the quickest possible response. And when this crash message came, my immediate reaction was: Let’s search for the race condition. This machine is faster than anything I have – this may have revealed a race condition in my parallel programming, that I simply hadn’t been aware of. I have seen so many examples of this problem pattern, that I spent a whole night looking through my code. I found nothing.

Some days later, when an iPad3 crossed my paths, I pulled out my Laptop and tested for the bug. The party guests at this birthday party where not amused of me showing my “nerdiest face”, but, hey, iPads from party visitors come and go, so you better use your time while you can. It turned out – in no way I could reproduce the error. It just did not fail. No crashes. It ran better than on the other apple products I had tested it before. So much for my theory.

In a very depressed mood, I wrote the apple review team, that I could not find any error and that I had no idea what to do. I had corrected an error that the iPad showed a different icon than I wanted, but this was very likely not the reason for the crash. Unnecessary to say that this message from me was not helpful, but I obviously wrote it for personal relief. After a few minutes a message arrived from the review team. They had made a video of the app trying to start and crashing on their iPad. You could see the person filming it with a black iPhone 4 / 4S running the app on the iPad and being reflected in the iPad screen. And you could see that he (it looked more like a male person) had a cubicle with a bookshelf. I was positively motivated to try harder to find the error – much to the discomfort of all the other party guests.

When I had corrected the icon error, I was getting aware of the configuration being different for the iPad than for the iPhone. So I went through all the configurations and configuration files to check whether they contained some things that were “looking suspicious”. Since an iOS configuration consists of so many details, there is a lot to be looked at, but I was trying to find something that would be different for the iPad or for the review version, when compared to the version I was using for testing.

When I stumbled over the optimizer settings, some hope returned: The crash logs that the review team had sent me had strange numbering for the lines, may be the optimizer had mixed something up? I tested with the optimizer settings turned the same for testing and distribution: Nothing, still everything was working. I put the settings back to original settings (always only change one parameter at a time for testing, else you will never know which one was the reason for the cure) and scrolled down.

And then it hit me: The setting for automatic reference counting (ARC) being applied was different for distribution! I could resist my urge to test the corrected settings, because I know the law of error testing:

You can not prove the absence of an error. You can prove its existence. And when the error is gone after the change, then it is plausible, that the change made the error go away. But it is only plausible, not proven.

And in order to see the error go away, you have to be able to reproduce it first. You have to. Else you have no reason to believe that the error was fixed. So I changed the setting for “Objective-C Automatic Reference Co…” (so I had to guess what this means until I saw the help text at the right hand side: “CLANG_ENABLE_OBJC_ARC”) to: “NO” for testing as well. And guess what? It crashed! Yippie!

So I corrected me settings, recompiled submitted and … started to party again.

So I am happy that the review team exists and I did not ship a broken app to my customers. And that they took the time for the video, which motivated me.

So what did I learn from this?
– When I agree to upgrade my project to whatever “new”, I will double check the settings afterwards to find any glitches
– When I prepare my program for submission, I will now test the distribution version and not only test the debug version and then compile for distribution. Anyone any ideas how to run the .app file in the .xcarchive file?
– The guys from the app store test team are not only useful (I knew that before), but actually helpful.

Lately, we had the following error:
*** -[NSKeyedUnarchiver initForReadingWithData:]: data is NULL

What had we done to get this error?
It turned out, that the reason was a loop in which multiple calls of

UIImageWriteToSavedPhotosAlbum ([assets objectAtIndex:currentIndex], self, @selector(image:didFinishSavingWithError:contextInfo:), nil);

had been sitting. We checked the documentation – not a single mention, that multiple calls could be a problem. On the other hand – that it is asynchronous, that was clear through the callback. And thus we decided to “serialize” our problem, as can be seen below. Problem gone.

Explanation: The action starts with saveButtonPressed, when the call to UIImageWriteToSavedPhotosAlbum is ready it sends a image:didFinishSavingWithError:contextInfo: method-message to the given class and in that method we trigger the next write, if there still is one…

Have a look yourself:

- (void) image: (UIImage image didFinishSavingWithError: (NSError error contextInfo: (void contextInfo {
NSLog(@"didFinishSavingWithError");
if (error != NULL) {
NSLog(@"error");
}
currentIndex++;
if (currentIndex < [assets count]) { UIImageWriteToSavedPhotosAlbum ([assets objectAtIndex:currentIndex], self, @selector(image:didFinishSavingWithError:contextInfo:), nil); NSLog(@"currentIndex %i",currentIndex); } } -(IBAction)saveButtonPressed:(id)sender{ NSLog(@"saveButtonPressed"); currentIndex = 0; UIImageWriteToSavedPhotosAlbum ([assets objectAtIndex:currentIndex], self, @selector(image:didFinishSavingWithError:contextInfo:), nil); NSLog(@"photos saved"); }