On Monday 20 October 2008 00:47:31 Ming-Ching Tiew wrote: > Rob Landley wrote: > > Ok, it's sounding like a race condition in uClibc's current daemon() > > implementation, triggered by the parent exiting before the child > > finishes whatever it's doing in daemon(). > > > > However, it doesn't sound like the child process _dies_. Your > > original bug report involved asterisk creating _lots_ of child > > processes, when it should only create 3. I'm not sure what the > > failure behavior is, and would love to be able to recreate it so I > > can debug it. > > No. That's not what I meant. > > The bug report was about asterisk ***NOT**** creating lots of > child processes or threads where it should be. > > The asterisk, when invoked :- > > # asterisk > > will call daemon() to fork to the background and the child will > then supposed to create many child processs or threads. When > in the bugged case, the child also died, so it left behind only > 3 processes. > > When asterisk is invoked > > # asterisk -v > > It will not call daemon(), so it will work correctly and it managed > to create many child process or threads.
Ah, that makes more sense. > > Do you have a small test case that's not part of the asterisk package > > but just a program we can compile and run on our own systems? > > I will try to write one to see if it is repeatable. I have heard people > having this problem with 'dropbear' but I have not seen it myself. It sounds serious and definitely in need of fixing. I just can't do anything about it yet because I haven't reproduced it. > Regards. Rob _______________________________________________ uClibc mailing list [email protected] http://busybox.net/cgi-bin/mailman/listinfo/uclibc
