I've got a project that builds, installs, and runs perfectly on an iPad using the developer certificate with no problems at all. It runs on the simulator just fine as well.

The problem is with Ad-Hoc distribution. I have everything set up exactly according to how every guide I can find suggests. I've tried everything.

The archive completes successfully with no problems and appears in the archives list of the organizer. Clicking distribute, I select the valid and correct provision and save my ipa no problems. I double click the ipa in the Finder and open up iTunes and the app installs onto the iPad with no problems.

The problem is when I load the app. It loads and starts off and then crashes immediately. Regardless of my approach this happens consistently. It must be a configuration issue, but I don't know what else I can do. Any help is greatly appreciated. Much thanks in advance.

I was hoping this would be one of those quick and simple, "oh I had that happen to me, it's because..." things.

I did look at the crash log and could make neither head nor tail of it. I'll make a nice fresh and smelly one and paste it here when I get to work with hopes that somebody may be able to help me make sense of it.

I'm going to take a wild guess that the observer which gets added on line 3 is gone, and may have been released by the OS because it is part of a view which is hidden, and was released for memory conservation.

The operating system flushes out views that aren't visible (i.e. not part of the current view hierarchy). Be sure to implement didReceiveMemoryWarning.

I don't think it always sends a release message. My recollection is fuzzy since I haven't dealt with this in quite some time, but I seem to recall that nib objects are simply flushed without a release. What I do recall is that this is a great way to have mystery crashes on iOS.

So you think that it could be a flushed out invisible view that is only flushed out when running an ad-hoc build, but not when running in debug mode, whether on the iPad as a developer or in the Simulator?

I wonder if I could reproduce the crash in the debugger if I changed the optimization settings... Hmmm

I've got many view controllers. They all appear to be implementing the didReceiveMemoryWarning, but what should I be doing in that method that would help me?

(May 9, 2012 10:37 AM)bmantzey Wrote: So you think that it could be a flushed out invisible view that is only flushed out when running an ad-hoc build, but not when running in debug mode, whether on the iPad as a developer or in the Simulator?

It's possible. I've seen several bugs which only manifest under certain settings on the device. One of which was actually a compiler bug, so anything is possible. In that case, I was able to avoid the bug by setting optimization to -O0 until they fixed it after I filed the bug report. So yeah, changing your settings around in the different builds might give you a hint.

There is also something like a "Simulate memory warning" in the simulator in one of the menus which you could try.

(May 9, 2012 10:37 AM)bmantzey Wrote: I've got many view controllers. They all appear to be implementing the didReceiveMemoryWarning, but what should I be doing in that method that would help me?

I wish I could recall exactly what I've done in the past to track these buggers down. One inelegant technique I suppose, would be to comment out [super didReceiveMemoryWarning] in each didReceiveMemoryWarning method and see if the crash goes away.

Take this all with a grain of salt too. My hunch that it's an OS memory management issue really is just a hunch after all.

Maybe there's something else I can do to that log file to symbolicate it further. I found 2 files, one was even less readable than the one I posted above and this one was in the MyIPadName.symbolicated folder while the less readable one was in the MyIPadName folder.

We spent a while trying to symbolicate it. This is what we did:

1) Archive once -> distribute and provision -> save as ipa.
2) Archive again -> Export as Xcode Archive -> go into the archive, find the Dsym file, apply the symbolicate command to the log generated by the above saved ipa.
• We get the same log. :| Are we doing something silly with it? I would like to know how to properly symbolicate a log file.

I will take a close look at everything we're doing with the Notification Center. Thanks!!

I just wanted to give a courtesy update to this issue. We found what was causing the problem. Strangely, it was with the formatting of an NSLog call. Now we have another issue, but at least we know it's not the build process that's the problem.

The strange thing is, what was indicated by the crash log had absolutely nothing to do with the crash (that we can tell).

I'd still like to know how to symbolicate that crash log a little better, if possible. I know it is getting symbolicated. It's just not really giving much helpful detail.

Odd that a broken NSLog would trash memory, rather than simply crashing.

Unfortunately, the shipping versions of clang (except maybe that in Xcode 4.4) don't provide the same typechecking for NSLog/[NSString stringWithFormat:] that they do for printf. If you compile with GCC or a sufficiently recent clang you should get warnings for broken NSLog calls.