Category Archives: Mac OS X

Avoiding memory leak in OpenAL and crash in OpenAL for Mac

UPDATE: We’re still seeing the crash on Mac. Procedure described does fix the memory leak, though.

UPDATE 2: Crash on Mac is caused by what appears to be a bug in Apple’s code relating to queueing commands for execution on dedicated audio thread, and mutex lock breaking down. Since mutex lock seems to stop working, it’s only natural that a threading-related crash occurs.


When calling alSourceStop(), you might forget to unbind a buffer from the source. Did you unbind it?

alSourcei(this->sourceId, AL_BUFFER, AL_NONE);

If you get a crash on Mac with call stack containing OALSource::Play() and/or ending with OALSource::PrepBufferQueueForPlayback(), this is most probably a good fix. Looks like OpenAL on Mac might have a race condition somewhere unless you do this.

See difference between revision 293 and 294 in libxal, in file audiosystems/OpenAL/OpenAL_Player.cpp.

Simple multiuser chat for POSIX systems

Here’s a little multiuser chat server written for various POSIX-compatible operating systems. Written and tested on Mac OS X 10.6, but it should work on your favorite Linux, too.

Placed in public domain, use it for whatever you want (since it’s so simple). 177 lines of pure C powah, dood.

Code follows after the break.
Continue reading

Some tips on building fuse-python on Mac OS X

I can’t document everything from scratch since I don’t have a machine that’s “virgin” enough for me to document that. This machine has been touched by Fink, MacPorts, Rudix, and several hand-build packages; I’m not sure if MacFUSE installs the necessary stuff for pkg-config.

But, let’s presume you:
a) installed macfuse,
b) fetched pkg-config source code from freedesktop.org (I took 0.25)
c) built it and installed it (./configure, make, sudo make install)
d) switched to pristine Python 2.6 that Apple ships with Snow Leopard.

I’m also obviously using Snow Leopard, so no guarantees about other OS X versions.

Ok, and now come the tips…
Continue reading

Single Xcode project for iOS and Mac OS X

In Xcode 3.2.4, it’s trivial to create same project for iOS and Mac OS X. Just add a new target into your existing project; if your project is for OS X, then create a new Cocoa Touch Application target. If your project is for iPhone, obviously, craete a new Cocoa Application target. Then do a Get Info on your new target, and choose the appropriate Base SDK. For simplicity, let’s presume you’re adding an OS X target to an iPhone project.

However, after doing this, you’ll quite probably find that despite the choice of Base SDK in your target (you used Get Info on it, didn’t you?), Xcode has locked the target SDK onto whatever your project originally used. That is, now you’ll find it locked onto iPhone, despite switching to the OS X target using the Overview dropdown (in the top left of your Xcode project).

So how do you actually switched the now-locked SDK? Quite simple. Hold the option key while clicking in the Overview box. Instead of only two-entries device list (if you have an iPhone target selected), and then Active Configuration, Active Target, Active Executable and Active Architecture, by holding the option key while clicking on Overview you’ll also find the Active SDKs list. By switching it to the appropriate OS, you’ll be able to compile the application.

Of course, now comes the hard part: actually porting the code to the new platform.
E49PEQSG669E

After MySQL upgrade on OS X, all tables are missing

When upgrading MySQL on OS X (anno domini 2010),  I learned the hard way that the “data” folder containing your databases and tables does not get moved. Look into /usr/local; you will probably have the old mysql-* folder there containing just the “data” folder. /usr/local/mysql is a symlink to the current MySQL installation, so move its data folder elsewhere, and put the old one in there.

PHP on Mac no longer able to connect to MySQL

It’s been a while since I did web development on my Mac, and MySQL ceased to work. Could be related to that one time that I accidentally removed a bunch of dot-files from my home directory, could be related to MySQL upgrade. In any case, it no longer worked.
What I figured out was that the /var/mysql/mysql.sock UNIX domain socket was no longer generated. The /var/mysql folder was missing. When just creating it and assigning it to user _mysql (chown _mysql /var/mysql) did not help, I knew something was wrong with configuration.

MySQL tries to read configuration from /etc/my.cnf. To get its UNIX domain socket where PHP expects it, this needs to be contained in this configuration file:

[client]
port = 3306
socket = /var/mysql/mysql.sock


[mysqld]
port = 3306
basedir = /usr/local/mysql/
socket = /var/mysql/mysql.sock
; datadir = /servers/raiddrive/databases/

Please read the manual for details, and this is not administration advice; I’m not sure if this opens security holes, but I only use MySQL for development purposes. (Because you should know better than letting programmers near mission critical production servers.)