Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 6 Nov 2009 18:31:14 +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:  <c39ec84c0911060931p48de1ae6s2aedfa24d5c0e210@mail.gmail.com>
In-Reply-To: <7B9397B189EB6E46A5EE7B4C8A4BB7CB3394EDDF@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> <c39ec84c0911060743sce9de02n5acb19663cf880df@mail.gmail.com> <7B9397B189EB6E46A5EE7B4C8A4BB7CB3394EDDF@MBX03.exg5.exghost.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Nov 6, 2009 at 5:52 PM, Peter Steele <psteele@maxiscale.com> wrote:

> >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.
>
> This is why we switched to vsys/vfork, assuming it would effectively do the
> same thing as execve. Perhaps not not. I can give it a try. I am still
> curious though why only this one particular system call is causing a crash.
> We have many calls running in other threads and none have ever caused a
> problem. They all do the same thing, run a command and save the output in a
> file, and then we process the output. The only thing different is the
> command we run in this case-fstat.
>

Actually, i have just read the implementation of system() (
/usr/src/lib/libc/system.c ), It does fork() and then execl(). So my
suggestion is not going to work. Then i read some of the malloc code (
/usr/src/lib/libstd/malloc.c ). It uses spinlocks alright, and they need to
be initialized. My guess is that are not reinitialized in your forked
process. I have no clue how to fix that. Another thought was that your
application is compiled as multithreaded, but fstat, grep etc are probably
not. But from what i can see, they use the same malloc implementation.

I think the crash in the malloc is from a malloc in fstat or grep ( there is
no malloc in system() ).

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?c39ec84c0911060931p48de1ae6s2aedfa24d5c0e210>