* fork() fails if it is called recursively from a child thread.
@ 2017-03-09 11:40 Takashi Yano
2017-03-09 13:53 ` Eliot Moss
` (2 more replies)
0 siblings, 3 replies; 9+ messages in thread
From: Takashi Yano @ 2017-03-09 11:40 UTC (permalink / raw)
To: cygwin
[-- Attachment #1: Type: text/plain, Size: 1017 bytes --]
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.
Is this the known issue?
--
Takashi Yano <takashi.yano@nifty.ne.jp>
[-- Attachment #2: fk.c --]
[-- Type: text/x-csrc, Size: 550 bytes --]
#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>
#include <signal.h>
#include <pthread.h>
void MoveToChild(int n)
{
pid_t pid;
if ( (pid = fork()) == -1 ) {
perror("fork()");
_exit(1);
} else if ( pid != 0 ) {
printf("Parent %d [%d] exit.\n", n, getpid());
_exit(0);
}
printf("Child %d [%d] works.\n", n, getpid());
}
void *thread_main(void *args)
{
int i;
for (i=0; i<5; i++) MoveToChild(i);
return NULL;
}
int main()
{
pthread_t t;
pthread_create(&t, NULL, thread_main, NULL);
pthread_join(t, NULL);
return 0;
}
[-- Attachment #3: Type: text/plain, Size: 219 bytes --]
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: fork() fails if it is called recursively from a child thread.
2017-03-09 11:40 fork() fails if it is called recursively from a child thread Takashi Yano
@ 2017-03-09 13:53 ` Eliot Moss
2017-03-09 16:16 ` Takashi Yano
2017-03-09 17:06 ` Achim Gratz
2017-03-10 20:10 ` Corinna Vinschen
2 siblings, 1 reply; 9+ messages in thread
From: Eliot Moss @ 2017-03-09 13:53 UTC (permalink / raw)
To: cygwin
On 3/9/2017 6:39 AM, 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.
>
> Is this the known issue?
This strikes me as either BLODA (interfering software) or a need to
rebase some dll(s). That's what I most commonly see that causes that
fork error.
Regards - Eliot Moss
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: fork() fails if it is called recursively from a child thread.
2017-03-09 13:53 ` Eliot Moss
@ 2017-03-09 16:16 ` Takashi Yano
0 siblings, 0 replies; 9+ messages in thread
From: Takashi Yano @ 2017-03-09 16:16 UTC (permalink / raw)
To: cygwin
On Thu, 9 Mar 2017 08:53:19 -0500 Eliot Moss wrote:
Thank you for response.
> This strikes me as either BLODA (interfering software) or a need to
> rebase some dll(s). That's what I most commonly see that causes that
> fork error.
This occurs even under newly installed windows 10 & 7.
Moreover, rebaseall does not help.
Couldn't you reproduce the problem in your environment with my test case?
Release note of iperf 2.0.5-1 says:
Note that a currently known limitation of the Cygwin version is that
running as a daemon (with the -D option) is not currently functional.
The previous version (2.0.4) also had this limitation.
This is also the reason why I think this problem causes commonly
with cygwin.
--
Takashi Yano <takashi.yano@nifty.ne.jp>
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: fork() fails if it is called recursively from a child thread.
2017-03-09 11:40 fork() fails if it is called recursively from a child thread Takashi Yano
2017-03-09 13:53 ` Eliot Moss
@ 2017-03-09 17:06 ` Achim Gratz
2017-03-09 17:33 ` Takashi Yano
2017-03-10 20:10 ` Corinna Vinschen
2 siblings, 1 reply; 9+ messages in thread
From: Achim Gratz @ 2017-03-09 17:06 UTC (permalink / raw)
To: cygwin
Takashi Yano writes:
> 0 [main] a 4668 fork: child -1 - forked process 8456 died unexpectedly, retry 0, exit code 0xC0000142, errno 11
Not sure if that helps, but that error says that some DLL could not be
initialized.
Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
Wavetables for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: fork() fails if it is called recursively from a child thread.
2017-03-09 11:40 fork() fails if it is called recursively from a child thread Takashi Yano
2017-03-09 13:53 ` Eliot Moss
2017-03-09 17:06 ` Achim Gratz
@ 2017-03-10 20:10 ` Corinna Vinschen
2017-03-11 1:29 ` Takashi Yano
2 siblings, 1 reply; 9+ messages in thread
From: Corinna Vinschen @ 2017-03-10 20:10 UTC (permalink / raw)
To: cygwin
[-- Attachment #1: Type: text/plain, Size: 1654 bytes --]
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 #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: fork() fails if it is called recursively from a child thread.
2017-03-10 20:10 ` Corinna Vinschen
@ 2017-03-11 1:29 ` Takashi Yano
2017-03-21 15:05 ` Erik Bray
0 siblings, 1 reply; 9+ messages in thread
From: Takashi Yano @ 2017-03-11 1:29 UTC (permalink / raw)
To: cygwin
Hello,
On Fri, 10 Mar 2017 21:10:36 +0100 Corinna Vinschen wrote:
> 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...
I tested the new snapshot, and confirmed the issue was fixed.
The test case as well as iperf 2.0.5 with options -s -D works
without problem.
At least in my short test, I couldn't find any other hidden
problems.
Thank you very much!
--
Takashi Yano <takashi.yano@nifty.ne.jp>
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: fork() fails if it is called recursively from a child thread.
2017-03-11 1:29 ` Takashi Yano
@ 2017-03-21 15:05 ` Erik Bray
0 siblings, 0 replies; 9+ messages in thread
From: Erik Bray @ 2017-03-21 15:05 UTC (permalink / raw)
To: cygwin
On Sat, Mar 11, 2017 at 2:29 AM, Takashi Yano wrote:
> Hello,
>
> On Fri, 10 Mar 2017 21:10:36 +0100 Corinna Vinschen wrote:
>> 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...
>
> I tested the new snapshot, and confirmed the issue was fixed.
> The test case as well as iperf 2.0.5 with options -s -D works
> without problem.
>
> At least in my short test, I couldn't find any other hidden
> problems.
>
> Thank you very much!
Thanks for this! I found the same bug a few weeks ago but never got
around to finding a simple-enough way to reproduce it so I didn't
report it yet. But this fixed the test code I did have, and from
looking at the description it should be the same bug. Very subtle.
Thanks,
Erik
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2017-03-21 15:05 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-03-09 11:40 fork() fails if it is called recursively from a child thread Takashi Yano
2017-03-09 13:53 ` Eliot Moss
2017-03-09 16:16 ` Takashi Yano
2017-03-09 17:06 ` Achim Gratz
2017-03-09 17:33 ` Takashi Yano
2017-03-09 19:48 ` cyg Simple
2017-03-10 20:10 ` Corinna Vinschen
2017-03-11 1:29 ` Takashi Yano
2017-03-21 15:05 ` Erik Bray
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).