Debugging a Firefox Plugin

This entry will be so brief, it will rival a tweet, but this is pure gold.

If there is any one thing that I found helpful when I needed to debug a Firefox plugin, it was Chromebug. This is the debugger used to debug Firebug, so you know it has what it takes! (yes, I tried Venkman. Fine for some things… just no this) So, get it, follow the instructions and be happy!

Advertisements

How to find that sqlite file behind your CoreData

This is a quick thing. Hard to find unless you know where to look. When running a CoreData driven app, there are times when you’d like to just rest your data store and start again. Doing a schema change is one such case. Of course if you’re doing something really silly and mess up the data, again.. reset!

So, to do that, simply delete the .sqlite file for your app. Running in the simulator, that is stored in your home directory under ~/Library/Application Support/iPhone Simulator/User/Applications/<special app id>/Documents/<appname>.sqlite

Easy, huh? Deleting this is sure nicer than clearing all apps and data from the simulator.

Finding freed/deallocated instances of objects

This procedure has saved me more than once, so I need to document it throughly for everyone! There are cases where I see messages (in the debugger console) that are like this;

-[NSFetchedResultsController class]: message sent to deallocated instance 0x11957d0

Sometimes, it will talk about “freed” instead of deallocated. That address at the end is important. To track down the line of code where the object was allocated, you’ll need to set a couple environment settings. To do this, right click on the executable you’re trying to debug and select “get info”. Select the “arguments” tag and set the values shown below;

 

debug environment settings

debug environment settings

(be sure to disable these when you’re done. They should not be enabled for a production build!)

Next, run your program and test enough to generate the error. In the Debugger Console, copy that hex address value, then type the command;

(gdb) info malloc-history <paste-address-here>

 

You should see something like this;

 

Stack – pthread: 0xa0416720 number of frames: 28

    0: 0x9264382d in malloc_zone_calloc

    1: 0x92643782 in calloc

    2: 0x93611618 in _internal_class_createInstanceFromZone

    3: 0x9361ab08 in _internal_class_createInstance

    4: 0x3020275c in +[NSObject allocWithZone:]

    5: 0x3020264a in +[NSObject alloc]

    6: 0x3d92 in -[AMRAPViewController fetchedResultsController] at /Users/dkavanagh/CrossFit Timer/Classes/AMRAPViewController.m:146

    7: 0x3a18 in -[AMRAPViewController viewWillAppear:] at /Users/dkavanagh/CrossFit Timer/Classes/AMRAPViewController.m:96

    8: 0x3097c945 in -[UINavigationController _startTransition:fromViewController:toViewController:]

    9: 0x30977c33 in -[UINavigationController _startDeferredTransitionIfNeeded]

   10: 0x3097d01e in -[UINavigationController pushViewController:transition:forceImmediate:]

The first line below the object alloc (in my case, line 6) will show where the offending object was allocated and should really help in tracking down the free/dealloc problem.

The original solution was posted in the app dev forums. You’ll need a login to see this.

Using “autorelease” can really bite you!

This will be a short post, but there was a lot behind it. Trust me!

A few times, I’ve run into cases where my code didn’t run as expected. I’d initialize an object (sometimes in viewDidLoad()). Later, maybe in viewWillAppear(), or in a button delegate, I’d try to access that object and use it. The debugger would show an EXC_BAD_ACCESS. I’d step through the code and sometimes, the object would appear normal in the inspector. Other times, the debugger would think it was of a different type!?!

The cause, it seems was that when I initialized the object, I set autorelease, like this;

memberVariable = [[[MyObject alloc] initWithParam:param] autorelease];

I thought I was being smart by allow the object to be cleaned up for me. In fact, I was causing a problem because I apparently don’t understand the behavior of autorelease. It turns out it can cause objects to be released early. I would say avoid autorelease! It has bitten me several times now!

iPhone development – tracking down uncaught exceptions

In the iPhone work I’ve been doing (my app), I’ve seen one error a number of times.. with various causes that were hard to track down. I’d see TERMINATED_DUE_TO_UNCAUGHT_EXCEPTION and never got a good stack trace. I found the solution in an iPhone dev forum (here) and thought I’d write this up to share the answer in case it saves someone some time.

What you need to do is set a breakpoint in objc_throw_exception. To do that, create a .gdbinit file in your home directory. Add the following to that file (I think the last line is the most important, but I have all of this in mine).

fb -[NSException raise]
fb -[_NSZombie release]
fb szone_error
fb objc_exception_throw

Then, bring up the debugger and run your app. Once you get an exception raised, the debugger stops where that exception is about to be thrown and you can see exactly where, in your code the problem originated! Big help to me, I can tell you! (Thanks, PhoneyDeveloper@iphonedevsdk.com!)