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

Reply via email to