---
title: OpenFrameworks, try 1...
date: "2011-06-13"
author: Chris Hodapp
tags:
- Technobabble
- rant
---

My attempts at doing things with
[OpenFrameworks](http://openframeworks.cc/) 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](https://processing.org/).

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:

```c
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](http://doc.qt.nokia.com/latest/qmake-manual.html). 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.
