Date: Fri, 6 Nov 2009 16:43:18 +0100 From: usleepless@gmail.com To: Peter Steele <psteele@maxiscale.com> Cc: "freebsd-questions@freebsd.org" <freebsd-questions@freebsd.org> Subject: Re: system() call causes core dump Message-ID: <c39ec84c0911060743sce9de02n5acb19663cf880df@mail.gmail.com> In-Reply-To: <7B9397B189EB6E46A5EE7B4C8A4BB7CB3394ED41@MBX03.exg5.exghost.com> References: <7B9397B189EB6E46A5EE7B4C8A4BB7CB327D117F@MBX03.exg5.exghost.com> <4AEC5E02.8040705@FreeBSD.org> <7B9397B189EB6E46A5EE7B4C8A4BB7CB327D11A9@MBX03.exg5.exghost.com> <200911040149.48701.mel.flynn%2Bfbsd.questions@mailing.thruhere.net> <7B9397B189EB6E46A5EE7B4C8A4BB7CB3394ED41@MBX03.exg5.exghost.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Nov 6, 2009 at 4:19 PM, Peter Steele <psteele@maxiscale.com> wrote:
> > Either I'm very lucky, or popen is better suited for this, as I have this
> running on various machines, 24/7:
> ...
>
> I could try popen as a next step. What we tried first was to replace our
> system calls with a function called vsys() which does exactly the same thing
> but uses vfork() underneath instead of fork(). If this problem had been due
> to resource conflicts due to the fork() performed by system(), we figured
> this would solve the problem. Unfortunately, we are still getting the exact
> same core with the identical stack trace.
>
> #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
>
> I don't know much about the internal implementation of popen but I suspect
> that at its core it still likely ends up doing a fork(). Still, it's worth a
> try. Curiously, we have several other threads in our application running in
> threads that periodically make system calls. For some reason only this call
> to fstat causes a core to occur. Seems that something fishy is going on
> here....
>
>
I am following this thread since i find it interesting ( playing around with
popen & threads at times ).
I am still trying to understand what Kris said. He says it is not safe to
fork from a multithread proces. And he suggests using execve.
You stacktrace btw is consistent with what Kris says: "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". -> that's probably the
spinlock in malloc.
I think you need to 1. (v)fork, 2. run execve on your fstat ( make it a sh
script )
Something along the lines of this
<< your current thread code here >>
// rc = system(fstatCmd);
childpid = fork();
if (childpid >= 0) /* fork succeeded */
{
if (childpid == 0) /* fork() returns 0 to the child process */
{
execve("/usr/local/app/myscript", NULL, NULL);
}
}
else
{
// didn't work, log something
}
<< rest of your code here >>
regards,
usleep
> _______________________________________________
> freebsd-questions@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-questions
> To unsubscribe, send any mail to "
> freebsd-questions-unsubscribe@freebsd.org"
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?c39ec84c0911060743sce9de02n5acb19663cf880df>