This is the mail archive of the cygwin mailing list for the Cygwin project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
Hi, On Mar 9 20:39, Takashi Yano wrote: > Hello, > > I found fork() fails if it is called recursively from a child thread. > > Simple test case, attached (fk.c), reproduces this problem. > > Expected result: > Parent 0 [22034] exit. > Child 0 [22036] works. > Parent 1 [22036] exit. > Child 1 [22038] works. > Parent 2 [22038] exit. > Child 2 [22039] works. > Parent 3 [22039] exit. > Child 3 [22040] works. > Parent 4 [22040] exit. > Child 4 [22041] works. > > Result in cygwin 2.7.0: > Child 0 [4668] works. > Parent 0 [7188] exit. > 0 [main] a 4668 fork: child -1 - forked process 8456 died unexpectedly, retry 0, exit code 0xC0000142, errno 11 > fork(): Resource temporarily unavailable > > Strictly speaking, the test case is not safe because it calls functions > which are not async-signal-safe from forked child process, i.e. printf() > and perror(), in spite of multi-thread. However the same happens even > without printf() and perror(). > > This is the cause of which iperf 2.0.5 with option -s -D fails to start > as daemon. Thanks for the report and especially the testcase. It was a tricky problem to debug so it took me a while, but I think I got it now. I uploaded new developer snapshots to https://cygwin.com/snapshots/ Please give them a try. I'd be also interested if that fixes the iperf problem. Can you check? There's always a chance that this uncovers another problem hidden under this one... Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat
Attachment:
signature.asc
Description: PGP signature
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |