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 careful.

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).

_______________________________________________ mailing list
To unsubscribe, send any mail to ""

Reply via email to