system() call causes core dump

Kris Kennaway kris at
Sat Oct 31 15:55:33 UTC 2009

Peter Steele wrote:
> I have an application running a number of threads. I've had recent instances where the code below is causing a core dump to occur:
> char fstatCmd[200];
> char *fstatOut = "/tmp/fstat.out";
> sprintf(fstatCmd, "fstat | grep -v USER | wc -l >%s", fstatOut);
> rc = system(fstatCmd);
> The call is simply intended to get a count of the current open handles. The system call though causes a core:
> #0 0x0000000801058307 in _spinunlock () from /lib/
> #1 0x00000008011d0afb in _malloc_postfork () from /lib/
> #2 0x000000080105c5fb in fork () from /lib/
> #3 0x0000000801191aae in system () from /lib/
> #4 0x00000008010553aa in system () from /lib/
> #5 0x000000000040b6f9 in mythread at myapp.c:461
> #6 0x0000000801056a88 in pthread_getprio () from /lib/
> There appears to be some kind of thread-safe issue going on. I have a number of threads that are monitoring various items, waking up a differing intervals to do their respective tasks. Do I need to put in a global mutex so that the threads never attempt to make simultaneous system() calls? Curiously, only this particular system() call appears to be causing a core.

In UNIX it is not safe to perform arbitrary actions after forking a 
multi-threaded process.  You're basically expected to call exec soon 
after the fork, although you can do certain other work if you are very 

The reason for this is that after the fork, only one thread will be 
running in the child, and if that thread tries to acquire a lock or 
other formerly-shared resource it may deadlock or crash, because the 
child process is no longer accessing the same memory location as the 
threads in the parent process (it gets a separate copy of the address 
space at the time of fork, which may not be in a consistent state from 
the point of view of the thread library).


More information about the freebsd-questions mailing list