iPhone Simulator crash with WebPreferences in the thread list

Question

Apple Developer Reference Library has a class reference for WebPreferences

I've searched SO, Dev Forums and Googled without any relevant results.

EXC_BAD_ACCESS signal is generated.

I can't find a crash report.. its happening on the simulator. The debugger is called, and I don't get a crash report.

EDIT

This is triggered when tapping a UITextField, leaving a UITextField or if a UITextField is set as first responder when loading a view (push on by a navigation controller).

It is not easy to reproduce. I can go for a hundred app-launch/debug cycles before it will happen again. And then it might happen 3 times in 5 launches.

---

I do have a thread list in the debugger that shows several references to WebPreferences.

Answer 1

You're on the right track if you are using NSZombie. EXEC_BAD_ACCESS is caused by accessing released objects.

It is normal for EXEC_BAD_ACCESS to "crash" in code paths that do not belong to you. Most likely your code created the over-released object.

The key part of using NSZombie is running the malloc_history on the command line. You'll get the call stack showing where the over-released object originated from. For example: alt text http://static.benford.name/malloc_history.png

The screenshot shows my app crashing at [NSString stringByTrimmingCharactersInSet:] but that is certainly not who caused the crash.

I technique I use is to look at the earliest code path that you own. Most of the time the mistake lies there.

In this case, the object originated from the class [JTServiceHttpRequest requestFinished], in which I was not properly retaining a object.

If all else fails, go through all your code paths listed and verify your use of proper memory management rules.

My bet is that WebPreferences and UITextField behavior have nothing to do with the crash.

Answer 2

For any EXC_BAD_ACCESS errors, you are usually trying to send a message to a released object. The BEST way to track these down is use NSZombieEnabled.

This works by never actually releasing an object, but by wrapping it up as a "zombie" and setting a flag inside it that says it normally would have been released. This way, if you try to access it again, it still know what it was before you made the error, and with this little bit of information, you can usually backtrack to see what the issue was.

It especially helps in background threads when the Debugger sometimes craps out on any useful information.

VERY IMPORTANT TO NOTE however, is that you need to 100% make sure this is only in your debug code and not your distribution code. Because nothing is ever released, your app will leak and leak and leak. To remind me to do this, I put this log in my appdelegate:

if(getenv("NSZombieEnabled") || getenv("NSAutoreleaseFreedObjectCheckEnabled"))
  NSLog(@"NSZombieEnabled/NSAutoreleaseFreedObjectCheckEnabled enabled!");

If you need help finding the exact line, Do a Build-and-Debug (CMD-Y) instead of a Build-and-Run (CMD-R). When the app crashes, the debugger will show you exactly which line and in combination with NSZombieEnabled, you should be able to find out exactly why.