Evilog

XCode not recognizing your iPhone?

Harold — Sun, 21 Jun 2009 05:09:14 +0000

Recently XCode began to have problems with debugging apps on a connected, provisioned iPhone. The problems began with recieving a message after hitting the ‘ Build and Go’ button in XCode, The message was similar to something like ‘No provisioned devices found.’ When selecting the troublesome device in XCode’s Organizer the following error was displayed:

Your mobile device has encountered an unexpected error (0xE8000075)

Try disconnecting and powering off the device; then power the device on and reconnect it.

I first followed the directions, but only half way; I disconnected it and hit the sleep button. Then I tried debugging again with no luck. Then I realized that I was retarded and actually followed the directions; I disconnected it and then powered it off by holding the front and top button until the ‘power off’ slider appeared. After powering it off and then powering back on everything worked perfectly.

Just an FYI for those that run into the same problems and long hours of coding have made their brains numb. Read and following the refreshingly helpful error message and everything will be cool.

Till next time.

BAD_ACCESS, Thumbs and Zombies

Harold — Sun, 19 Apr 2009 05:07:47 +0000

I’ve run into a few problems during my short time developing for iPhone. Luckily the problems have not been with the iPhone device itself or the SDK, but mostly the tools; specifically the simulator. One of the more annoying problems occurs while running the Simulator. When launching an application a bad memory access is thrown and results in a “BAD_ACCESS” error message in the console. Most of the time is happens for what seems like totally random reasons.

Always it is while running a release build on the simulator. Obviously release mode on the simulator isn’t very useful for anything; however I am a bit anal and like to keep it compiling on any platform I can. I feel like if I have a problem on the simulator then it might be hinting at an underlying problem elsewhere. But I am beginning to believe the simulator is just a bit too buggy to care about.

The BAD_ACCESS always occurs right after the autorelease pool is created and the application is launched via a call to UIApplicationMain. I haven’t tracked down the actually cause but have come up with some strange workarounds to get it to go away.

#1 Mixed Thumb Compiling: One of the more difficult causes to track down was a case when I had the executable linking to several libraries, and the libraries had mixed Thumb Mode settings. The application and most of the libraries were compiled without Thumb support. However, on a single library I hadn’t disabled Thumb mode. When I disabled thumb mode on that library and recompiled, the BAD_ACCESS then went away. However, I don’t know if the mixed thumb mode setting was the actual cause of the problem, because it seems like changing just about anything can cure the BAD_ACCESS.

#2 Change Something… Anything: After fixing the BAD_ACCESS several times over a month using several different fixes, I ended up in a situation that I couldn’t resolve quickly. So I started searching the Internet to see if I could find a solution. That is when I ran across this Cocoa Nut post. It sounded like it might help me track down the root cause. However, when I set the NSZombieEnabled variable and relaunch the application I no longer received any BAD_ACCESS.

But that is not the strange part. I kept playing around with this and realized if I added any environment variable at all, then the BAD_ACCESS went away. The NSZombieEnabled variable didn’t matter. For example, I made the variable name ‘ThisVariableIsLying’ and set the value to ‘FALSE’ and when I relaunched the app the BAD_ACCESS did not occur. Removing the variable caused it to come back.

Anyway, I thought I would mention it as perhaps it might be useful to someone else, or maybe someone could shine some light on what might actually be going on.

Till next time,

Good luck.

Xcode: Link to different library depending on configuration

Harold — Mon, 23 Feb 2009 05:59:24 +0000

How do you link different libraries depending on the current configuration in XCode? First, spend a few hours believing you are smart enough to figure it out and that the XCode designers will have made this an intuitive and transparent feature. Second realize that your first assumption was wrong. Then resort to a frustrating hour or so mastering your search-fu in order to Google the correct page with all the answers. Maybe that is how you ended up here. So without further hesitation here is the magic link that answered my questions. Read that to find a quick answer and continue reading if you want to hear a short rant over the way this works in XCode: Version 3.1.2

The linked solution basicly decribes an unintuitive and undocumented (if its documented then they hid it very well) feature to accomplish something large projects are almost always going to have to deal with. An example of the basic problem is you want to link to a library that has both a Debug and a Release version. So in your application you want your Debug version to link to the Debug version of the library, and you want your Release version to link the Release version of the library. It makes sense and happens all the time.

Despite that the given solution does actually work, and forgetting that it is a pain to figure out, it has a couple problems that really bug me:

My main gripe is that XCode doesn’t play nice with other build systems. The linked solution basically means you need an additional XCode project for any libs you plan to link that have multiple configurations. If you have a lib built with a supplied makefile all setup just to build with gcc and is ready to go? Then too bad, you’ll have to create a new XCode project just to link to it.
Additionally, I am assuming this means that the two projects need to have matching configurations. Maybe you have three or four configurations for your Application but the library only has two distinct configurations. Then too bad, you’ll have to create additional configurations so XCode can figure out which lib to link.
Finally, it just feels bad. I hate relying on this automagic feature. A feature that has a bug (mentioned in the link) making it appear that it doesn’t work at all. Even though the bug is just ‘graphical’ it still makes the whole process feel flimsy. I would have much rather preferred a text field where I simply listed which libs to link to.

Well it works, so I suppose I should quit griping. If anyone has a more elegant solution within XCode then let me know.

Let the Evil Begin

Harold — Tue, 10 Feb 2009 04:17:30 +0000

In my Todo list I had ‘Choose and setup a blogging package.’ I started at Wordpress’s installation page and now, twenty minutes later, I’m typing this first entry. A surprisingly quick and easy task: done. So to the future visitors of Evilog, welcome.