Date: Sat, 31 Oct 2009 15:55:46 +0000 From: Kris Kennaway <kris@FreeBSD.org> To: Peter Steele <psteele@maxiscale.com> Cc: "freebsd-questions@freebsd.org" <freebsd-questions@freebsd.org> Subject: Re: system() call causes core dump Message-ID: <4AEC5E02.8040705@FreeBSD.org> In-Reply-To: <7B9397B189EB6E46A5EE7B4C8A4BB7CB327D117F@MBX03.exg5.exghost.com> References: <7B9397B189EB6E46A5EE7B4C8A4BB7CB327D117F@MBX03.exg5.exghost.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4AEC5E02.8040705>