Category Archives: Software Development

Objective-C Warning: ‘class’ may not respond to ‘-message:’

If you get a warning of this form:

warning: ‘Class’ may not respond to ‘-message:’
(Messages without a matching method signature will be assumed to return 'id' and accept '...' as arguments.)

There are a few things to check:

  1. Make sure that you spelled the name of the message correctly, and that you matched all of the types of all of the arguments
  2. If the message is called in the same class, then the message you call must be higher in the class or the message must be declared in the header
  3. If you are calling it from a different class, then the message must be declared in the header

Remember, the declaration of the message must match the actual message signature. For example, if you have a message like this:

-(void) message:(NSString *)value
{
// message implementation
}

Then, you need this in your header:

-(void) message:(NSString *)value; // don’t forget the semicolon

Get iPhone programming tips in your inbox with my Beginner iPhone Programming Tips newsletter.

Inception Movie Review from a Data Security Perspective

This is part of my ongoing series of extremely limited perspective movie reviews:

Previous Reviews:

Like the previous ones: SPOILER ALERT. Inception is the kind of movie where you might not want to know anything going in. So, please don’t read further if you don’t want any part of the plot spoiled.

In Inception there’s an elite team that can infiltrate your subconscious while you’re dreaming and extract secret information while your defenses are down. The plot of the movie is set up when someone asks them if they can do an “inception” where they plant an idea into a victim’s subconscious. Since the idea is detrimental to the victim, they must somehow convince him that it is his, and that it will be good for him to follow through with it.

Obviously, extraction directly relates to data security, and the attacks and defenses that are discussed in the movie have analogous ones in the security world. An obvious one is a honeypot and how it relates to the labyrinths that the dream architects construct.

[Honeypots] computers run special software, designed to appear to an intruder as being important and worth looking into. In reality, these programs are dummies, and their patterns are constructed specifically to foster interest in attackers.

Creating a honeypot is like “taking two minutes to create a maze that takes a minute to solve.”

Things like a “militarized subconscious”, “totems”, and “forgers” have counterparts in the network security world.

But, what about “inception”? After thinking about it for a few minutes, I remembered this story from WWII. In 1943, the Allies wanted to convince the Germans that they would attack through Sardinia, not Sicily, so:

The idea, very simply, was to get a dead body, equip the dead body with false papers, and then drop it somewhere the Germans would find it

[…] And it was an elaborate creation: the fictitious Major Martin was equipped with ticket stubs, keys, a religious medal, letters from an imaginary father and fiancee, and unpaid bills. Cholmondeley and Montagu thought that the more convincing his personal story was, the more likely the Germans would be to believe the ruse. And along with the personal items, he carried carefully faked letters hinting that the Allies were planning to invade Greece and Sardinia, not Sicily.

But, this is not a computer attack. While the idea of data tampering is nothing new, I haven’t heard of a tampering attack with the intent to mislead someone into making a bad decision. Data tampering is often used to gain access for another purpose or to cover up tracks (e.g. log tampering).

But, I suspect that this is a real threat as well. One so good, that it  often goes undetected.

Making Xcode’s Build and Analyze much better

A few weeks ago, I discovered that the Build and Analyze in Xcode didn’t find as many problems as scan-build did directly when you turn all options on.

On the Clang analyzer site, they have instructions for setting up the latest analyzer so that Xcode would use it. Unfortunately, the settings that find some very common problems are off by default. Here are instructions for getting the Clang analyzer to run with those options on.

To make sure you are doing it right, make your project completely succeed a Build and Analyze, then comment out a release that you are doing in any dealloc. Rerun Build and Analyze — it should not find this problem.

Then,

1. If you don’t have it, download and untar the latest checker
2. Make a script file called full-analyze-clang and put it in the checker’s bin directory, with this code

#!/bin/bash
CLANG="`dirname $0`/clang"
CLANG_CMD="\"$CLANG\" -Xanalyzer -analyzer-check-objc-missing-dealloc -Xanalyzer -analyzer-check-objc-missing-dealloc -Xanalyzer -analyzer-experimental-internal-checks $*"
eval $CLANG_CMD

3. From the Terminal, run this command to make the script executable

chmod +x full-analyze-clang

4. In the checker root directory, there is a script called set-xcode-analyzer. Run it like this:

sudo ./set-xcode-analyzer --use-checker-build=FULL_PATH_TO_CHECKER/bin/full-analyze-clang

replacing FULL_PATH_TO_CHECKER with the path to the checker directory where you untarred it in step 1.

5. To test, Run the Build and Analyze on the project you set up with the bad dealloc. If it finds 0 errors, this could be because something is wrong with the way the script is set up.

Important parts if this stops working with a future clang:
The set-xcode-analyzer expects a directory or a full-path to clang. It checks to see it has a full-path by looking for a path ending with “clang”, which works for us because our script’s name ends in “clang”. If they change this script in the future, this might not work

Build and Analyze just reports a successful build if our script reports errors — it’s just looking for the existence of result files. You might need to add logging lines to the script to figure out what’s going on. Log to a full-path because the current directory is inside Xcode’s path somewhere when the script is run.

Use something like this as your last line to debug:

eval $CLANG_CMD > `dirname $0`/cl.out 2> `dirname $0`/cl.err

Get iPhone programming tips in your inbox with my Beginner iPhone Programming Tips newsletter.

Xcode 4

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

  1. It runs side-by-side on the same machine as Xcode 3.2
  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.

Build and Analyze still doesn’t find dealloc omissions of retained property releases. I would like the default to be set to finding these.

Some keyboard shortcut changes. The GUI is so radically different, so this is excusable. For the most part, things are the same.

Get iPhone programming tips in your inbox with my Beginner iPhone Programming Tips newsletter.

LGPL and the iPhone

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 someone 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.

I haven’t been able to find any official ruling on gnu.org, so I will write them and see if they can add to their FAQ (as they did for Java when it was an issue).

Get iPhone programming tips in your inbox with my Beginner iPhone Programming Tips newsletter.

Understanding EXC_BAD_ACCESS

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

  1. The pointer used to point to memory that was ok, but its chunk was deallocated.
  2. 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:

  1. 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.
  2. 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.
  3. Set up Xcode so that it never deallocates. Instead, it turns objects into Zombies that complain if they are used. See Tip #1 on this post for instructions.

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

  1. The pointer could have never been initialized.
  2. The pointer could have been accidentally written over because you overstepped the bounds of an array
  3. The pointer could be part of an object that was casted incorrectly, and then written to
  4. 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

  1. 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).
  2. 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.
  3. If all else fails and you are desperate, try Valgrind.

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

  1. 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.
  2. Deallocating an object doesn’t immediately release the memory to the operating system — only when the chunk is unused, can it be returned.
  3. 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.

How to Debug an iPhone App Crash, Part 1: EXC_BAD_ACCESS

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.

Update: I explain this much better in a follow-up to this blog

Here are a few ways to debug that:

  1. Run Build and Analyze: This kind of Build is very good at finding retain/release bugs. Take a good look at everything it flags.
  2. Even better, run scan-build. I did a test recently, and found that some common errors are off by default in Build and Analyze that can be turned on in scan-build.
  3. Choose Run > Enable Guard Malloc in the menu, and then re-run your application. This finds a whole class of buffer overrun issues. If this detects it, you’ll see a better error in the console. Read this to see how to use Guard Malloc once it’s enabled.
  4. You can instruct the compiler to ignore release calls and then report if anyone is sending messages to objects that would have been deallocated. This results in much better errors in the Console if it detects them.
  5. Valgrind is the gold standard for finding memory bugs on Linux, and here’s a way to get it working in the iPhone Simulator.

Get iPhone programming tips in your inbox with my Beginner iPhone Programming Tips newsletter.

scan-build finds things Build and Analyze does not

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:

  1. Download scan-build
  2. Just unpack it into any directory and add that directory to your PATH
  3. Open a Terminal and cd to your project’s root directory
  4. Run scan-build and view results

Here is a scan-build line that works for iOS 4.0:

scan-build -analyzer-check-objc-missing-dealloc -analyzer-check-llvm-conventions –experimental-checks -k -V -o scan-reports xcodebuild -configuration Debug -sdk iphonesimulator4.0 clean build

I’ve turned on all checks, and now it catches if you forget to set properties to nil in dealloc.

Run Build and Analyze often in Xcode, but every once and a while, run a full scan-build with the latest version as it finds problems that the Xcode version will not.

UPDATE: Instructions on getting this working in Xcode from the Build and Analyze menu

Get iPhone programming tips in your inbox with my Beginner iPhone Programming Tips newsletter.

Learning 80’s style programming today

There is an ongoing lament among programmers of a certain age that there are no entry-level programming environments for young kids and teenagers to learn on. Since I am of that age, I understand exactly what they mean, but I don’t agree that there are no choices.

Today, on Hacker News, this four-year old article by David Brin in Salon (Why Johnny Can‘t Code) made the first page. It’s a good read and an accurate overview of the debate— namely, computers from the 80’s came with BASIC, which was simple enough for anyone to pick up and learn how to program, and now, we don’t have an equivalent. Here’s a passage about the difference:

The “scripting” languages that serve as entry-level tools for today’s aspiring programmers — like Perl and Python — don’t make this experience accessible to students in the same way. BASIC was close enough to the algorithm that you could actually follow the reasoning of the machine as it made choices and followed logical pathways.

Luckily, I keep a Commodore 64 Programmer’s Reference Guide on my work bookshelf for nostalgic reasons. Here’s one of the first BASIC programs they list:

10 PRINT "YOUR NAME":INPUT N$
20 PRINT "HELLO," N$

Here it is in Python:

n = raw_input("YOUR NAME ")
print "HELLO, " + n

The Python version doesn’t have line numbers and doesn’t need you to use dollar signs to designate string values. I can’t imagine that anyone who could learn the first one would have any real problem with the second.

But the author is concerned with coding math problems like statistics.  Something where you can follow the logic. Here’s a BASIC program on page 20:

5 PRINT "♥"
10 PRINT "MONTHLY INCOME" : INPUT IN
20 PRINT
30 PRINT "EXPENSE CATEGORY 1" : INPUT E1$
40 PRINT "EXPENSE AMOUNT" : INPUT E1
50 PRINT
60 PRINT "EXPENSE CATEGORY 2" : INPUT E2$
70 PRINT "EXPENSE AMOUNT" : INPUT E2
80 PRINT
90 PRINT "EXPENSE CATEGORY 3" : INPUT E3$
100 PRINT "EXPENSE AMOUNT" : INPUT E3
110 PRINT "-----"
120 E=E1+E2+E3
130 EP=E/IN
140 PRINT "MONTHLY INCOME: $"IN
150 PRINT "TOTAL EXPENSES: $"E
160 PRINT "BALANCE EQUALS: $"IN-E
170 PRINT
180 PRINT E1$"="(E1/E)*100"% OF TOTAL EXPENSES" 
190 PRINT E2$"="(E2/E)*100"% OF TOTAL EXPENSES"
200 PRINT E3$"="(E3/E)*100"% OF TOTAL EXPENSES" 
210 PRINT 
220 PRINT "YOUR EXPENSES="EP*100"% OF TOTAL INCOME"
230 FOR X=1 TO 5000:NEXT:PRINT
240 PRINT "REPEAT? (Y/N)":INPUT Y$:IF Y$="Y" THEN 5
250 PRINT "-----":END

This example has looping, conditionals, and math. The reverse heart clears the screen (platform specific), line 230 is a delay, and line 240 uses a conditional goto for a loop.

Here it is in python (I tried to keep it as close as possible, also using a platform specific clear screen which will work on the Mac and Linux):

import os
import time

while True:
    os.system("clear")
    IN=float(raw_input("MONTHLY INCOME"))
    print ""
    E1CAT=raw_input("EXPENSE CATEGORY 1")
    E1=float(raw_input("EXPENSE AMOUNT"))
    print ""
    E2CAT=raw_input("EXPENSE CATEGORY 2")
    E2=float(raw_input("EXPENSE AMOUNT"))
    print ""
    E3CAT=raw_input("EXPENSE CATEGORY 3")
    E3=float(raw_input("EXPENSE AMOUNT"))
    os.system("clear")
    E=E1+E2+E3
    EP=E/IN
    print "MONTHLY INCOME: $",IN
    print "TOTAL EXPENSES: $",E
    print "BALANCE EQUALS: $",IN-E
    print ""
    print E1CAT,"=",(E1/E)*100,"% OF TOTAL EXPENSES"     
    print E2CAT,"=",(E2/E)*100,"% OF TOTAL EXPENSES"
    print E3CAT,"=",(E3/E)*100,"% OF TOTAL EXPENSES"     
    print ""     
    print "YOUR EXPENSES=",EP*100,"% OF YOUR INCOME"
    time.sleep(5)
    print ""
    Y=raw_input("REPEAT? (Y OR N)")
    if Y=="N": break
os.system("clear")

So, we have to introduce the concept of import and string to float conversion needs to be explicit, but is this much more difficult? I can tell you that flipping through the C64 programmer’s reference, it doesn’t try to coddle you (it wasn’t written for kids).

The first real program is:

10 OPEN 2,8,6,"0:STOCK FOLIO,S,W"
20 OPEN 1,1,2,"CHECKBOOK"
30 OPEN 3,4

This is under a heading, EXAMPLE OF ACTUAL STATEMENTS in the introduction, which is on the third page of text after the table of contents. To be fair, the syntax of OPEN is briefly discussed, but is this really the best first program?

The one real difference is that a C64 boots into BASIC and you can start typing a program as soon as it’s up. On a Mac, you have to understand how to make text files, open a Terminal, and run python.  After that hurdle, it’s very similar. On Windows, you need to install python.

I think a lot of the nostalgia of what it was like to program these old machines just doesn’t match what it was really like.  The included documentation wasn’t necessarily kid friendly, but there were other sources of information (I had a ton of Compute! magazines and other books).

If you are a beginner, please check out Learn Python the Hard Way. It doesn’t assume that you know anything—it covers getting python installed (not necessary on a Mac) and how to use a text editor. I think it closely matches the kind of experience I and other older programmers remember having in BASIC.

Trainers for Programmers

Anyone who is interested in teaching programming to novices or non-programmers should check out what Zed Shaw is doing:

I’ve had an idea for an introductory book on programming that follows the model of “trainer” books for learning a musical instrument. Most of these books are organized like this:

  1. There’s a bunch of exercises.
  2. Each exercise is 1 or 2 pages.
  3. There’s only a little bit of prose.
  4. You do each exercise exactly, then move on.

The results are at Learn Python the Hard Way.