Hi, I did a test on the Coldfire V3 uClinux. I changed the "execve("/bin/ls",NULL)" to "execve("/bin/ps",NULL)", because of some problem to exec the busybox linked "ls". However, I did get exactly same behavior as you described.
My first suspection is using the LinuxThread in the uClibc means any thread is treated almost same as process. So the child process SIGCHLD would never deliver to the SigHandler thread, instead the signal go to the main process which is doing the sleep(1) loop (by default, SIGCHLD is ignored). On MMU linux, they use the NPTL thread which means the thread can choose to listen a signal. Cheers Xin -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Williams Sent: Tuesday, 1 April 2008 11:09 AM To: uClinux development list Subject: [uClinux-dev] pthreads, vfork and signals Hi, We've had a problem reported on MicroBlaze arch and I was wondering if someone with access to another NOMM Uarch could run the same test, see if the result is duplicated. It's a simple test case attached (don't forget to link pthreads library). Basically we have parent that 1. blocks all signals 2. spawns a thread (SigHandler) 3. vforks() - child does execve("/bin/ls",NULL) - parent sleep() loops forever The SigHandler thread 1. blocks all signals 2. does a sigwait() loop if SIGCHLD delivered, _exit() On regular PC, this runs as expected - as soon as 'ls' completes, everything shuts down. However on MicroBlaze / noMMU, the child of the vfork() ('ls') becomes a Zombie and never exits, thus SIGCHLD never gets raised, and it all hangs. Reports of behaviour on another noMMU arch would be greatly appreciated. Is this a noMMU-ism? If so, any simple workarounds ? Otherwise, I'll have to go digging in arch/microblaze :( Thanks, John _______________________________________________ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev