Debugging Your Object in Xcode

So you've managed to build your object. Now the fun comes of running it. And then...Max crashes. To fix the crash quickly, you might want to run your object in the debugger. This section discusses some of the issues to ensure debugging success with Xcode.

Creating a Patch for Your Object

First, you should know that you cannot run the regular version of Max/MSP in the debugger due to copy protection issues. So you'll need to create a patch with your object in it. This is tricky because if your object crashes on load and is in the search path, you'll never be able to create a patch and save it! Simply take your object out of the search path. Then launch Max and type the name of your object into an object box. You'll see an error and the box won't work, but you can still save the patch. Unfortunately you won't be able to connect any message boxes to the bogus object.

So, if you are first trying to get your object to instantiate, you'll need to have the patch with just the object in it to open inside MaxMSP Runtime inside the debugger. Then if you want to debug specific messages after you've managed to get your object to load, open your patch (with the loading object in the search path) in MaxMSP, add the message boxes, save, and reopen in MaxMSP Runtime in the debugger. Yes, it's a bit of an inconvenient cycle, but typically there aren't that all that many programming problems that you need to address with source level debugging.

One other idea is to produce a nice help file for your object, then use the help file as the patch you open for debugging.

Setting Up MaxMSP Runtime as an Executable

With your project window frontmost, choose New Custom Executable... from the Project menu. An executable is an application or other command that runs when you click Debug.

A window labeled Assistant appears. Set the Executable name to something like MaxMSP Runtime (it can be anything). Then click the Choose... button to locate your copy of MaxMSP Runtime that you want to use. This should be a copy that has your external object in its search path. You could even copy MaxMSP Runtime to your build folder if you wanted (or use the sysbuild provision discussion under Installing Your Object in the Build Settings section above).

Make sure that the menu next to Add To Project: shows the name of your project file.

Click Finish. You'll see the Exectuable "MaxMSP Runtime" Info window. Here you can customize settings, but all the default settings are fine, so just close the window.

Note: Any executable you set up is stored in the user preferences file of the project, not the main project file (project.pbxproj). Otherwise, we would have set this up for you in the example projects!

Launching the Debugger

Unlike Code Warrior, where the Debug command really meant "Build and Debug," in Xcode, you can choose not to build your object before debugging. This could be fairly useful if you are manually copying your object to some location before testing it out. (You can often use the Installation feature of Xcode to avoid this, but there might be some reason why this is not possible.) Another nice thing about the Xcode debugger is that it seems able to find your code even if it is not where the compiler and linker built it.

Before launching the executable you configured, you may want to add a breakpoint so that the debugger stops when your object is loading. Click in the narrow column to the left of the line of source where you want to stop. A rectangle-arrow thing should appear. If the rectangle-arrow is dark gray, this indicates that a breakpoint is set. Click the rectangle-arrow thing again to disable the breakpoint. You can also control-click on the breakpoint to get a contextual menu that lets you remove it.

With your project window frontmost, choose Debugger from the Debug menu. Click the Debug button. The executable you just set up should begin to launch. If necessary, open the patch containing your object in MaxMSP Runtime. The debugger should land at the breakpoint you set up.

Note that the Debugger will crash on launch from time to time, usually with a "corrupt stack" message. In our experience, if you run the debugger again it should be fine. This seems to happen more on Intel than on PowerPC.

Printing to the Console

One particularly useful thing you may want to while developing your object is print debug or status messages to the console. There is a built-in Max function cpost() that does this for both Mac and Windows, but if you're only debugging a Mac object, you can use the built-in UNIX library function fprintf to stderr as shown in this example:

fprintf(stderr,"variable is %ld",my_variable);

However, when posting to the console while inside the debugger, the output does not show up in the regular Console application. Instead it is redirected to the Debugger Console, which you can view by clicking the Console button in the Xcode Debugger window (if it's not visible, click the arrow thingie on the right side and choose Console from the menu -- did they design this UI based on the Max patcher window?)

There are also ways to get breakpoints to print to the console instead of stopping, which may be useful to you.

Next: Identifying Platforms in Your Source Code^?

Return to the Max/MSP Universal Binary SDK Table of Contents

-- DavidZicarelli - 05 Apr 2006
to top