system() crashes in __libc_fork

[Norbert van Bolhuis]

Our C/C++ application calls system() to do all kinds
of tiny things.
On one occasion the child process that is created
(because system() does a fork()) crashes in __libc_fork
Btw. the main application (which called system()) continues to
run. So it's the child that crashes.

Here's the crash info:

*** Segmentation fault
Register dump:
fp0-3:   0000000000000000 0000000000000000 0000000000000000 0000000000000000
fp4-7:   0000000000000000 0000000000000000 0000000000000000 0000000000000000
fp8-11:  0000000000000000 0000000000000000 0000000000000000 0000000000000000
fp12-15: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
fp16-19: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
fp20-23: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
fp24-27: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
fp28-31: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
r0 =00000000 sp =489f9780 r2 =48a01930 r3 =489999f8  trap=00000300
r4 =0fb8bae4 r5 =28000462 r6 =00000000 r7 =0fb8bb18   sr0=0fb8bbc0 sr1=0000d032
r8 =00000000 r9 =00000000 r10=00000000 r11=00000000   dar=00000000 dsi=22000000
r12=0fb8bb90 r13=11771740 r14=0f7f9000 r15=0f7edf90   r3*=01200011
r16=0f7e79f4 r17=00000000 r18=1009d7d0 r19=11094edc
r20=11094c78 r21=11094ed0 r22=11094ec4 r23=11094e80    lr=0fb8bba4 xer=00000000
r24=114a6884 r25=00000008 r26=00000000 r27=0fc13cd0    mq=00000000 ctr=00000000
r28=489f9790 r29=489999f8 r30=0fc3e8d8 r31=489f97c0  fscr=00000000 ccr=28000468

Backtrace:
/lib/libSegFault.so[0xffdd464]
[0x100344]
/lib/libc.so.6(__libc_fork+0xe0)[0xfb8bae4]
/lib/libc.so.6[0xfb29610]
/lib/libc.so.6(__libc_system+0x68)[0xfb29870]
/lib/libpthread.so.0(system+0x10)[0xff1b3e4]
/mountedisd/isd/mainctrl[0x1001bf54]
/mountedisd/isd/mainctrl[0x100172fc]
/mountedisd/isd/mainctrl[0x10017524]
/mountedisd/isd/mainctrl[0x1001834c]
/mountedisd/isd/mainctrl[0x100188b4]
/mountedisd/isd/mainctrl[0x100192a0]
/mountedisd/isd/mainctrl[0x109b4c74]
/mountedisd/isd/mainctrl[0x109b5958]
/mountedisd/isd/mainctrl[0x1099705c]
/lib/libpthread.so.0[0xff10aa4]
/lib/libc.so.6(clone+0x8c)[0xfbbf7d0]


I'm using libc-2.7 and linux kernel 2.6.28
This is on powerpc 32.


I obviously want to prevent the crash.

Is there something stupid our app can do which causes this ?

I checked out the libc-2.7 sources for __libc_fork:

134   if (pid == 0)
135     {
136       struct pthread *self = THREAD_SELF;
137
138       assert (THREAD_GETMEM (self, tid) != ppid);
139
140       if (__fork_generation_pointer != NULL)
141         *__fork_generation_pointer += 4;
142
143       /* Adjust the PID field for the new process.  */
144       THREAD_SETMEM (self, pid, THREAD_GETMEM (self, tid));
145
146 #if HP_TIMING_AVAIL
147       /* The CPU clock of the thread and process have to be set to zero.  */
148       hp_timing_t now;
149       HP_TIMING_NOW (now);
150       THREAD_SETMEM (self, cpuclock_offset, now);
151       GL(dl_cpuclock_offset) = now;
152 #endif
153
154       /* Reset the file list.  These are recursive mutexes.  */
155       fresetlockfiles ();
156
157       /* Reset locks in the I/O code.  */
158       _IO_list_resetlock ();
159
160       /* Reset the lock the dynamic loader uses to protect its data.  */
161       __rtld_lock_initialize (GL(dl_load_lock));
162
163       /* Run the handlers registered for the child.  */
164       while (allp != NULL)
165         {
166           if (allp->handler->child_handler != NULL)
167             allp->handler->child_handler ();
168
169           /* Note that we do not have to wake any possible waiter.
170              This is the only thread in the new process.  The count
171              may have been bumped up by other threads doing a fork.
172              We reset it to 1, to avoid waiting for non-existing
173              thread(s) to release the count.  */
174           allp->handler->refcntr = 1;
175
"nptl/sysdeps/unix/sysv/linux/fork.c" line 120 of 216 --55%-- col 7

I wonder what handlers registered for the child are being called ?
We do have specific fatal signal handler installed (which are thus inherited
by the child) could this cause this problem ?

Should I (also) investigate our application for doing stupid things ?

Or should I consider making my own system() wrapper (with fork() and execl())
and retry ?

Thanks,
Norbert van Bolhuis.