If you are experiencing MacOS X or Darwin errors that report "fork: resource temporarily unavailable" or "vfork: resource temporarily unavailable" this web page may be able to help you. The next few paragraphs contain a detailed description of the problem and the solution. Please read them before trying the fix. It is important to understand the tradeoffs between using and not using the fix.

In MacOS X version 10.2.3 the vfork system call has an accounting bug. Processes created with vfork don't decrease the active process count when they exit. This bug has been discussed in the darwin development mail list in this thread. The operating system also enforces per-user and per-system process limits. After vfork has been call enough times the system refuses to create additional processes, and reports the "resource temporarly unavailable" error. Once the process limit has been reached both fork and vfork will fail. In this state the computer is almost useless.

The main difference between vfork and fork, the typical process creation function, is performance. vfork is a special, speed optimized, version of fork that can be used in place of a large subset of fork calls.

The temporary solution to the problem is replace all calls to vfork with calls to fork. This avoids the vfork accounting bug altogether. But there are two downsides. First, fork is slower. The speed difference can be noticable if you are creating a large number of processes (for example, when you compile a large program). The second problem is correctness. While fork should be a drop-in replacement for vfork, in fact Apple's own developer documentation states this, there is a slight possibility that one or two applications behave poorly when vfork is replaced by fork. Please keep these tradeoffs in mind while you try the kernel extension; if overall system performance is too bad, or applications start malfunctioning, stop using the extension.

That said, I have developed a kernel extension (kext) that replaces all calls to vfork with fork. It works by replacing the SYS_vfork entry in kernel's system call entry point table with the entry for SYS_fork. The kernel extension, along with the source and project builder project, can be downloaded here. You need to load the extension manually using the "kextload" command (type "man kextload" at the command prompt for more details). When unloaded (via "kextunload") the extension restores the syscall table to its original state. I have not packaged the kext in a startup item, but you may wish to do it yourself if you reboot frequently. My experience using the extension has been positive thusfar. I've been able to compile the program that I couldn't before and have not seen any programs misbehave.

Also be advised that this code and accompanying binary come with no warranty whatsoever. I am not responsible for any damages caused by any use of this code. Use at your own risk.

-John