Re: fork() fails if it is called recursively from a child thread.

[Erik Bray]

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

Re: fork() fails if it is called recursively from a child thread.

[Takashi Yano]

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 

--
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

Re: fork() fails if it is called recursively from a child thread.

[Corinna Vinschen]

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 0xC142, 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


signature.asc
Description: PGP signature

Re: fork() fails if it is called recursively from a child thread.

[cyg Simple]

On 3/9/2017 12:33 PM, Takashi Yano wrote:
> Thanks for your reply.
> 
> On Thu, 09 Mar 2017 18:06:44 +0100 Achim Gratz wrote:
> 
>> Takashi Yano writes:
>>>   0 [main] a 4668 fork: child -1 - forked process 8456 died 
>>> unexpectedly, retry 0, exit code 0xC142, errno 11
>>
>> Not sure if that helps, but that error says that some DLL could not be
>> initialized.
> 
> Error code: 0xC142 means as you mentioned.
> 
> Error code is 0xC142 under windows 10, while it is 0xC005
> under windows 7.
> 
> 0xC005 means access violation.
> 
> I'm not sure why the error code is different depend on OS version.
> 


Fails for me too.  The "Error code" is actually 11 or 0xB

ERROR_BAD_FORMAT
11 (0xB)
An attempt was made to load a program with an incorrect format.

The 0xC142 is an exit code.  Here is a developer blog on this exit code.

https://blogs.msdn.microsoft.com/winsdk/2015/06/03/what-is-up-with-the-application-failed-to-initialize-properly-0xc142-error/

-- 
cyg Simple

--
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

Re: fork() fails if it is called recursively from a child thread.

[Takashi Yano]

Thanks for your reply.

On Thu, 09 Mar 2017 18:06:44 +0100 Achim Gratz wrote:

> Takashi Yano writes:
> >   0 [main] a 4668 fork: child -1 - forked process 8456 died 
> > unexpectedly, retry 0, exit code 0xC142, errno 11
> 
> Not sure if that helps, but that error says that some DLL could not be
> initialized.

Error code: 0xC142 means as you mentioned.

Error code is 0xC142 under windows 10, while it is 0xC005
under windows 7.

0xC005 means access violation.

I'm not sure why the error code is different depend on OS version.

-- 
Takashi Yano 

--
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

Re: fork() fails if it is called recursively from a child thread.

[Achim Gratz]

Takashi Yano writes:
>   0 [main] a 4668 fork: child -1 - forked process 8456 died unexpectedly, 
> retry 0, exit code 0xC142, 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

Re: fork() fails if it is called recursively from a child thread.

[Takashi Yano]

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 

--
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

Re: fork() fails if it is called recursively from a child thread.

[Eliot Moss]

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 
0xC142, 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