Re: system() call causes core dump
On Saturday 31 October 2009 21:52:37 Peter Steele wrote:
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).
I am not calling fork explicitly. The thread I'm running in was created
with pthread_create(). The fork() in the stack trace in my original email
is being called by the system() function as it spawns off the process it
is supposed want to run. Is there a safe way to call system() within a
pthread?
Either I'm very lucky, or popen is better suited for this, as I have this
running on various machines, 24/7:
#define PING_CMD \
ping -n -c 50 %s 2/dev/null|egrep 'round-trip|packets received'
/* worker thread main loop */
void *monitor_host(void *data)
{
...
if( -1 == asprintf(cmd, PING_CMD, ip) )
{
warnl(Failed to construct command);
*ex = EX_OSERR;
return(ex);
}
while( !signalled )
{
if( (cmd_p = popen(cmd, r)) == NULL )
{
warnl(Failed to run command %s, cmd);
*ex = EX_OSERR;
return(ex);
}
EV_SET(ch, fileno(cmd_p), EVFILT_READ, EV_ADD|EV_ENABLE,
0, 0, NULL);
for( ;; )
{
int nev;
if( signalled ||
(nev = kevent(kq, ch, 1, ev, 1, timeout)) == -1 )
{
if( signalled == SIGHUP )
goto closeproc;
else
goto cleanup;
}
if( nev )
break;
}
/* read fp, store in db */
}
}
--
Mel
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: system() call causes core dump
On Sat, Oct 31, 2009 at 4:55 PM, Kris Kennaway k...@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 0x000801058307 in _spinunlock () from /lib/libthr.so.3 #1 0x0008011d0afb in _malloc_postfork () from /lib/libc.so.7 #2 0x00080105c5fb in fork () from /lib/libthr.so.3 #3 0x000801191aae in system () from /lib/libc.so.7 #4 0x0008010553aa in system () from /lib/libthr.so.3 #5 0x0040b6f9 in mythread at myapp.c:461 #6 0x000801056a88 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 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: system() call causes core dump
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 0x000801058307 in _spinunlock () from /lib/libthr.so.3 #1 0x0008011d0afb in _malloc_postfork () from /lib/libc.so.7 #2 0x00080105c5fb in fork () from /lib/libthr.so.3 #3 0x000801191aae in system () from /lib/libc.so.7 #4 0x0008010553aa in system () from /lib/libthr.so.3 #5 0x0040b6f9 in mythread at myapp.c:461 #6 0x000801056a88 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 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
RE: system() call causes core dump
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). I am not calling fork explicitly. The thread I'm running in was created with pthread_create(). The fork() in the stack trace in my original email is being called by the system() function as it spawns off the process it is supposed want to run. Is there a safe way to call system() within a pthread? The app has several such threads doing various monitoring actions, some calling functions using system(), others invoking various C library routines. The parent process where these threads were spawned from is basically sleeping, waking up only periodically to check for shutdown events. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
