My attempts at doing things with OpenFrameworks on MacOS X have been mildly disastrous. This is a bit of a shame, because I was really starting to like OpenFrameworks and it was not tough to pick up after being familiar with Processing.
I’m pretty new to XCode, but it’s the “official” environment for OpenFrameworks on OS X, so it’s the first thing I tried. The first few attempts at things (whether built-in examples, or my own code) went just fine, but today I started trying some things that were a little more complex - i.e. saving the last 30 frames from the camera and using them for some filtering operations. My code probably had some mistakes in it, I’m sure, and that’s to be expected. The part where things became incredibly stupid was somewhere around when the mistakes caused the combination of XCode, GDB, and OpenFrameworks to hose the system in various ways.
First, it was the Dock taking between 15 and 30 seconds to respond just so I could force-quit the application. Then it was the debugger taking several seconds to do 100 iterations of a loop that had nothing more than an array member assignment inside of it (and it had 640x480x3 = 921,600 iterations total) if I tried to set breakpoints, thus basically making interactive debugging impossible. The debugging was already a pain in the ass; I had reduced some code down to something like this:
int size = cam_width * cam_height * 3;
for(int i = 0; i < frame_count; ++i) {
unsigned char * blah = new unsigned char[size];
for(int j = 0; j < size; ++j) blah[j] = 0;
}
…after a nearly identical memset call was smashing the stack and
setting frame_count to a value in the billions, so I was really
getting quite frazzled at this.
Running it a few minutes ago without breakpoints enabled led to a bunch of extreme sluggishness, then flickering and flashing on the monitor and I was not able to interact with anything in the GUI (which was the 3rd or 4th time this had happened today, with all the Code::Blocks nonsense below). I SSHed in from another machine and killed XCode, but the monitor just continued to show the same image, and it appeared that the GUI was completely unresponsive except for a mouse cursor. I had to hold the power button to reboot, and saw this in the Console but nothing else clear before it:
6/13/11 1:11:19 AM [0x0-0x24024].com.google.Chrome[295] [463:24587:11560062687119:ERROR:gpu_watchdog_thread.cc(236)] The GPU process hung. Terminating after 10000 ms.
A little before trying XCode for a 2nd time, I had also attempted to set up Code::Blocks since it’s OpenFrameworks' “official” IDE for Linux and Windows and XCode was clearly having . First I painstakingly made it built from an SVN copy and finally got it to run (had to disable FileManager and NassiShneiderman plugins which would not build and make sure it was building for the same architecture as wxWidgets was built for). As soon as I tried to quit it, the Dock became totally unresponsive, then Finder itself followed along with the menu bar for the whole system. I was not able to SSH in. Despite the system being mostly responsive, I had to hard reset. I found a few things in the console:
6/12/11 9:43:54 PM com.apple.launchd[1] (com.apple.coreservicesd[66]) Job appears to have crashed: Segmentation fault
6/12/11 9:43:54 PM com.apple.audio.coreaudiod[163] coreaudiod: CarbonCore.framework: coreservicesd process died; attempting to reconnect but future use may result in erroneous behavior
6/12/11 9:43:55 PM com.apple.ReportCrash.Root[18181] 2011-06-12 21:43:55.011 ReportCrash[18181:2803] Saved crash report for coreservicesd[66] version ??? (???) to /Library/Logs/DiagnosticReports/coreservicesd_2011-06-12-214355_localhost.crash
6/12/11 9:44:26 PM com.apple.Dock.agent[173] Sun Jun 12 21:44:26 hodapple2.local Dock[173] Error: kCGErrorIllegalArgument: CGSSetWindowTransformsAtPlacement: Singular matrix at index 2: [0.000 0.000 0.000 0.000]
It started up properly after a reset, but I couldn’t do anything useful with it because despite there being a script that was supposed to take care of this while building the bundle the application was not able to see any of its plugins, which included a compiler plugin. I attempted a binary OS X release which had a functioning set of plugins, but was missing other dependencies set in the projects, which were Linux-specific. I could probably put together a working configuration if I worked in Code::Blocks a bit, but I have not tried yet.
This is all incredibly annoying. There is no reason a user process should be capable of taking down the whole system like this, especially inside of a debugger, yet apparently it’s pretty trivial to make this happen. I’ve written more than enough horrible code in various different environments (CUDA-GDB on a Tesla C1060, perhaps?) to know what to expect. I guess I can try developing on Linux instead, and/or using Processing. I know it’s not quite the same, but I’ve never had a Processing sketch hose the whole system at least.
Later addition (2011-06-20, but not written here until November because I’d buried the notes somewhere):
I attempted to make an OpenFrameworks project built with Qt Creator (which of course uses QMake. OpenFrameworks relies on QuickTime, and as it happens, QuickTime is 32-bit only. If you take a look at some of the headers, the majority of it is just #ifdef’ed away if you try to build 64-bit and this completely breaks the OpenFrameworks build.
Ordinarily, this would not be an issue as I would just do a 32-bit
build of everything else too. However, QMake refuses to do a 32-bit
build on OS X for some unknown reason (and, yes, I talked to some Qt
devs about this). It’ll gladly do it on most other platforms, but not
on OS X. Now, GCC has no problems building 32-bit, but this does no
good when QMake keeps adding -arch x86_64 no matter what. I
attempted all sorts of options such as CONFIG += x86, CONFIG -= x86_64, QMAKE_CXXFLAGS -= -arch x86_64, or += -m32, or += -arch i386…
but none of them to any avail.