system() call causes core dump

[usleepless at gmail.com]

On Fri, Nov 6, 2009 at 5:52 PM, Peter Steele <psteele at 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 at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-questions
> To unsubscribe, send any mail to "
> freebsd-questions-unsubscribe at freebsd.org"
>