Monthly Archives: July 2010

There are two great things about Xcode 4 that mean I had to download and try it right away

It runs side-by-side on the same machine as Xcode 3.2

It uses the exact same project file format

This hasn’t been the case in the last few major upgrades from what I remember, and I was really glad to read that in the release notes.

My first impressions after an hour or so:

Putting the view in Assistant mode (Opt-Cmd-Enter) is really nice. Shows the .m when editing the .h and vice versa. When editing an .xib file, it shows the ViewController.

Keeping the Interface Builder dialogs organized as parts of a single window is also a big win. It’s confusing having them as free dialogs. Specifically, having the parts of the main dialog (File’s Owner, First Responder, View, etc) as just part of the chrome (and always visible) is nice.

I think I’ll really like the Log Navigator — especially for debugging. I am constantly clearing the console, but this saves each one in a separate view so I can keep them around.

The Project Navigator is so much cleaner (replaces the Groups and Files tree). It always felt like Xcode just stuffed everything there instead of organizing it elsewhere in the GUI. However, it took me a long time to figure out where Build Settings were (click the project name in the Project Navigator), but it seems obvious now.

The entire point of the LGPL is to give closed source applications access to an open-source library in a way that maintains the freedom of the library. Specifically, the user of the application must be able to change the LGPL library and have the application use it.

To achieve this, the LGPL gives you a few options for compliance. I am not a lawyer, but I believe that all of them are incompatible with iPhone apps delivered legally through the AppStore. I will lay out my reasoning here:

Section 4d gives two options for compliance: Either provide the source or object files suitable for relinking (4d0) or use a shared library (4d1).

Shared libraries are out, because Apple does not permit their use in the AppStore.

Section 4d0 is a little more complicated. For an application targeted to a PC or Mac, it would be easy to comply by just packaging up your .o files, the LGPL library, a makefile, and documentation. However there are subclauses in section 4 that make me believe that there is no way to comply on the iPhone. Specifically:

Section 4d0 not only specifies that you must convey the minimal source and object files, but you must also provide terms. Together they must “permit the user to recombine or relink the Application with a modified version of the Linked Version to produce a modified Combined Work”

Section 4e requires that you provide instructions that allows some to change the LGPL portions, create a new combined work and install and execute that combined work.

To do either of these things, the user would need to be enrolled in Apple’s developer program which costs $99/year. These terms are implicitly part of your terms, meaning that it’s basically equivalent to you charging $99/year for the user to make modifications.

The GPL allows you to charge what you want to convey the Combined Work to begin with, but section 10 of the GPL (which I think still applies to the LGPL) states:

You may not impose any further restrictions on the exercise of the rights granted or affirmed under this License. For example, you may not impose a license fee, royalty, or other charge for exercise of rights granted under this License.

Now, obviously, being able to develop isn’t free, but those costs are not as directly related to exercising your rights as the $99/year is. Specifically, you cannot create an executable or put in on a device without the certificates you obtain from the program.

Here’s an alternative view from Huy Zing — I think the “Spirit of the LPGL” section in the blog is actually required by the text of the license.

Here’s a discussion on the cocos2d forum about switching away from LGPL. They tried adding to the license at first and then moved to an MIT license.

A couple of days ago, I wrote about how to debug a crash that reports EXC_BAD_ACCESS. One thing I didn’t cover is what EXC_BAD_ACCESS means, which I’ll try to do now, as it will clear up a lot of the questions I’m getting about the previous blog.

The description here is a high-level way of thinking about it. The details are quite a bit more complicated, so I’m simplifying it.

On the iPhone (and most modern OS’s), your application is given memory as you need it. The memory is given in chunks that are bigger than your request, and then the unused parts are parceled out over the next few requests.

When you deallocate an object, that chunk can’t be returned to the OS right away. It has to wait until all of the memory in the chunk is deallocated.

Inside all of this memory is a complex data structure that is maintained by the alloc and dealloc messages to organize how each part of the allocated memory is being used. The pointers you hold are just part of that datastructure (where the object is), there are other parts that are only used by the allocator.

What EXC_BAD_ACCESS is saying is that you did something that caused a pointer (yours, one internal to the iPhone, or one that the allocator is using) to be dereferenced and that memory location isn’t inside one of the chunks assigned to your program.

This could be because

The pointer used to point to memory that was ok, but its chunk was deallocated.

The pointer is corrupt.

The line of code that your app crashes on is not the root cause of the problem. The problem in #1 is whatever line of code caused the premature deallocation, and the problem in #2 is whatever line of code corrupted the pointer.

Your goal in debugging this is to make the problem line of code be flagged by either the compiler or debugger.

If you do that, then fixing it becomes a lot easier.

Of the two possible problems, #1 is far easier to find. It’s almost definitely because you didn’t use retain/release correctly and there where either too many releases or too few retains.

Do this:

Run Build and Analyze. Make sure you fix or understand every single error it flags. I personally have 0 Build and Analyze errors in every project I have and I go out of my way to keep it that way. If I ever get a false positive, I figure out how to make Build and Analyze understand what is going on, so that it doesn’t flag it.

Run scan-build with all checks on. This isn’t built in, so if you’re in a hurry, skip this for now. scan-build is the project that Build and Analyze is based on. It can be run with much more thorough settings.

If you have a clean Build and Analyze and no Zombies complain of being accessed, and you still get EXC_BAD_ACCESS, then it’s a good bet that you are not accessing deallocated memory. It’s not a sure bet, because the iPhone SDK gives you access to the C library which uses a different kind of allocation, which you could be using wrong.

For #2, your task is harder. If a pointer is corrupt, there are lots of possible reasons

The pointer could have never been initialized.

The pointer could have been accidentally written over because you overstepped the bounds of an array

The pointer could be part of an object that was casted incorrectly, and then written to

Any of the above could have corrupted a different pointer that now points at or near this pointer, and using that one corrupts this one (and so on)

If this is the situation you are in, then these are the things that will help

Enable Guard Malloc (Tip #2) – this makes the datastructure that represents the allocations much more sensitive to corruption. You need to use the enhanced features of the debugger to get anything out of it (explained in the tip).

The line of code that triggers the crash is a clue to what pointer is corrupt. If you move it around it might be able to help you narrow down the point of corruption.

Once one of these methods gives you a different problem (either a warning or another EXC_BAD_ACCESS), don’t worry that it seems completely unrelated to your original problem — that’s a common problem with corruption.

Also, random changes to your program may make this problem “go away” — it’s not really fixed, though. Your corruption or early deallocation is still there, but it’s not triggering an EXC_BAD_ACCESS. Its effects could be far worse, however, so it’s a good idea to try to keep reproducing it until you are sure you addressed the problem.

Things to remember

Corrupting a pointer doesn’t immediately trigger EXC_BAD_ACCESS. Neither does using a corrupted pointer unless it’s specifically now pointing to memory that isn’t mapped to your application.

Deallocating an object doesn’t immediately release the memory to the operating system — only when the chunk is unused, can it be returned.

The line of code that is triggering the EXC_BAD_ACCESS might not be the problem. It can be a good clue, but don’t assume the problem is this code.

This is going to be a multi-part series on how to debug an iPhone crash.

This post is for how to debug crashes that show that the app received the signal EXC_BAD_ACCESS in the console. If you have this, the most likely thing that you are doing is sending a message to a released object. Another possibility is if you are using C/C++ allocations (or a library that uses it) and are overrunning memory or using freed memory.

Ever since I started using the latest Xcode, I’ve loved having scan-build built in as Build and Analyze. I did feel like it was less thorough, but I didn’t have time to prove it — now I have.

There is one kind of bug that scan-build was very good at finding — forgetting to set retained properties to nil in dealloc isn’t found by default in Build and Analyze. It’s not even part of the default scan-build any more (not sure why — it was great).

Anyway, I recommend using scan-build directly instead of Build and Analyze. Here’s how: