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/libthr.so.3
#1 0x00000008011d0afb in _malloc_postfork () from /lib/libc.so.7
#2 0x000000080105c5fb in fork () from /lib/libthr.so.3
#3 0x0000000801191aae in system () from /lib/libc.so.7
#4 0x00000008010553aa in system () from /lib/libthr.so.3
#5 0x000000000040b6f9 in mythread at myapp.c:461
#6 0x0000000801056a88 in pthread_getprio () from /lib/libthr.so.3
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).
Kris
_______________________________________________
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
