system() call causes core dump

[Peter Steele]

> 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....