Date: Sun, 1 Nov 2009 14:17:34 +0100 From: usleepless@gmail.com To: Kris Kennaway <kris@freebsd.org> Cc: Peter Steele <psteele@maxiscale.com>, "freebsd-questions@freebsd.org" <freebsd-questions@freebsd.org> Subject: Re: system() call causes core dump Message-ID: <c39ec84c0911010517w5330f32bl55685417a152f9f4@mail.gmail.com> In-Reply-To: <4AEC5E02.8040705@FreeBSD.org> References: <7B9397B189EB6E46A5EE7B4C8A4BB7CB327D117F@MBX03.exg5.exghost.com> <4AEC5E02.8040705@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Oct 31, 2009 at 4:55 PM, Kris Kennaway <kris@freebsd.org> wrote:
> 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).
>
Are you saying system/popen can't be used in threads? Is there a
workaround? ( forking manual and executing exec? )
Would calling 'system("exec fstat | ... > result.txt")' make any difference?
just curious,
kind regards,
usleep
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?c39ec84c0911010517w5330f32bl55685417a152f9f4>