Re: Intermittent failures retrieving process exit codes

2013-11-13 Thread Tom Honermann 

On 12/21/2012 01:30 AM, Tom Honermann wrote:

I spent most of the week debugging this issue.  This appears to be a
defect in Windows.  I can reproduce the issue without Cygwin.  I can't
rule out other third party kernel mode software possibly contributing to
the issue.  A simple change to Cygwin works around the problem for me.

I don't know which Windows releases are affected by this.  I've only
reproduced the problem (outside of Cygwin) with Wow64 processes running
on 64-bit Windows 7.  I haven't yet tried elsewhere.

The problem appears to be a race condition involving concurrent calls to
TerminateProcess() and ExitThread().  The example code below minimally
mimics the threads created and exit process/thread calls that are
performed when running Cygwin's false.exe.  The primary thread exits the
process via TerminateProcess() ala pinfo::exit() in
winsup/cygwin/pinfo.cc.  The secondary thread exits itself via
ExitThread() ala Cygwin's signal processing thread function, wait_sig(),
in winsup/cygwin/sigproc.cc.

When the race condition results in the undesirable outcome, the exit
code for the process is set to the exit code for the secondary thread's
call to ExitThread().  I can only speculate at this point, but my guess
is that the TerminateProcess() code disassociates the calling thread
from the process before other threads are stopped such that
ExitThread(), concurrently running in another thread, may determine that
the calling thread is the last thread of the process and overwrite the
process exit code.

The issue also reproduces if ExitProcess() is called in place of
TerminateProcess().  The test case below only uses TerminateProcess()
because that is what Cygwin does.

Source code to reproduce the issue follows.  Again, Cygwin is not
required to reproduce the problem.  For my own testing, I compiled the
code using Microsoft's Visual Studio 2010 x86 compiler with the command
'cl /Fetest-exit-code.exe test-exit-code.cpp'

test-exit-code.cpp:

#include 
#include 
#include 

DWORD WINAPI SecondaryThread(
 LPVOID lpParameter)
{
 Sleep(1);
 ExitThread(2);
}

int main() {
 HANDLE hSecondaryThread = CreateThread(
 NULL,   // lpThreadAttributes
 0,  // dwStackSize
 SecondaryThread,// lpStartAddress
 (LPVOID)0,  // lpParameter
 0,  // dwCreationFlags
 NULL);  // lpThreadId
 if (!hSecondaryThread) {
 fprintf(stderr, "CreateThread failed.  GLE=%lu\n",
 (unsigned long)GetLastError());
 exit(127);
 }

 Sleep(1);

 if (!TerminateProcess(GetCurrentProcess(), 1)) {
 fprintf(stderr, "TerminateProcess failed.  GLE=%lu\n",
 (unsigned long)GetLastError());
 exit(127);
 }

 return 0;
}


To run the test, a simple .bat file is used:

test.bat:

@echo off
setlocal

:loop
echo test...
test-exit-code.exe
if %ERRORLEVEL% NEQ 1 (
 echo test-exit-code.exe returned %ERRORLEVEL%
 exit /B 1
)
goto loop


test.bat should run indefinitely.  The amount of time it takes to fail
on my machine (64-bit Windows 7 running in a VMware Workstation 8 VM
under Kubuntu 12.04 on a Lenovo T420 Intel i7-2640M 2 processor laptop)
varies considerably.  I had one run fail in less than 10 iterations, but
most of the time it has taken upwards of 5 minutes to get a failure.

The workaround I implemented within Cygwin was simple and sloppy.  I
added a call to Sleep(1000) immediately before the call to ExitThread()
in wait_sig() in winsup/cygwin/sigproc.cc.  Since this thread (probably)
doesn't exit until the process is exiting anyway, the call to Sleep()
does not adversely affect shutdown.  The thread just gets terminated
while in the call to Sleep() instead of exiting before the process is
terminated or getting terminated while still in the call to
ExitThread().  A better solution might be to avoid the thread exiting at
all (so long as it can't get terminated while holding critical
resources), or to have the process exiting thread wait on it.  Neither
of these is ideal.  Orderly shutdown of multi-threaded processes is
really hard to do correctly on Windows.

Since the exit code for the signal processing thread is not used, having
the wait_sig() thread (and any other threads that could potentially
concurrently exit with another thread) exit with a special status value
such as STATUS_THREAD_IS_TERMINATING (0xC04BL) would enable
diagnosis of this issue as any process exit code matching this would be
a likely indicator that this issue was encountered.

As is, when this race condition results in the undesirable outcome,
since the signal processing thread exits with a status of 0, the exit
status of the process is 0.  This explains why false.exe works so well
to reproduce the issue.  It would be impossible to produce a negative
test using true.ex

Re: something is wrong with cygwin's mirror checker

2013-11-13 Thread Wm. David Bentlage 
On Wed, Nov 13, 2013 at 5:20 PM, Buchbinder, Barry (NIH/NIAID) [E]  wrote:

> It is probably just a coincidence, but my usual mirror,
> , has disappeared, not just from

I got the following from the ANL mailing list.

> Hello,
>
> The ANL Public Mirror Service (mirror.anl.gov) is currently not in service.
>
> We apologize for any inconvenience this outage may cause.
>
> When servicing is complete and the service is restored we will send out an 
> update to this list.
>
> Thank you for your Patience
>
> ANL Free Software Mirror Admins.

--
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: something is wrong with cygwin's mirror checker

2013-11-13 Thread Buchbinder, Barry (NIH/NIAID) [E] 
Christopher Faylor sent the following at Tuesday, November 12, 2013 1:30 PM
>On Tue, Nov 12, 2013 at 01:08:37PM -0500, Christopher Faylor wrote:
>>I don't know why but the mirror checker is screwed up.  The last email I
>>got from the system said that the mirrors were in good shape but
>>http://cygwin.com/mirrors.html tells another story.
>>
>>Just a heads up.  I'm investigating.
>
>Problem identified and (I hope) fixed. It will take a few hours for the
>system to correct itself so mirrors will be scarce until that happens.

This list has recovered a bit but is still very sparse.

It is probably just a coincidence, but my usual mirror,
, has disappeared, not just from
, but when accessed directly with Firefox,
not setup.  Usually it is very reliable.  I doubt that there's anything
that you can do, but I wonder if anl.gov cannot find something that it is
looking for at the cygwin/sourceware end and that that has contributed to
this problem at anl.gov and at least some of the other mirrors.

Best wishes,

- Barry
  Disclaimer: Statements made herein are not made on behalf of NIAID.


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

x86_64-pc-cygwin directory

2013-11-13 Thread Wm. David Bentlage 
Greetings,

I've recently run setup-x86.exe on an AMD Operton machine running
Windows Server 2003 to install in a directory /w/latest.  (I installed
more than just the baseline.)  Setup created the following
setup-x86.exe directories.  Is that normal?  What are they for?  The
files in the directories listed look like they're for development.

user@local /w/latest
$ ls
bin  etc  home  lib  opt  tmp  usr  var  x86_64-pc-cygwin

user@local /w/latest
$ cd x86_64-pc-cygwin/

user@local /w/latest/x86_64-pc-cygwin
$ ls
bin  include  lib  lib64  libexec  share  x86_64-pc-cygwin

user@local /w/latest/x86_64-pc-cygwin
$ cd x86_64-pc-cygwin/

user@local /w/latest/x86_64-pc-cygwin/x86_64-pc-cygwin
$ ls
bin  include  lib

Thanks,
Dave

--
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: C++11 program link failure under GCC 4.8.2-1

2013-11-13 Thread Christopher Faylor 
On Wed, Nov 13, 2013 at 04:19:15PM +0100, Corinna Vinschen wrote:
>On Nov 13 09:01, Christopher Faylor wrote:
>> On Wed, Nov 13, 2013 at 10:15:02AM +0100, Corinna Vinschen wrote:
>> >On Nov 12 18:37, Ryan Johnson wrote:
>> >> On 12/11/2013 5:30 PM, JonY wrote:
>> >> >Right now, it is guarded by:
>> >> >#if !defined(__STRICT_ANSI__) || (__STDC_VERSION__ >= 199901L)
>> >> >
>> >> >Which means non-strict mode and C99 mode, snprintf was not part of
>> >> >C++03. I guess (__cplusplus >= 201103L) needs to be added to newlib.
>> >> Yes, this has come up before [1]. Several *printf variants are
>> >> affected IIRC.
>> >> 
>> >> [1] http://cygwin.com/ml/cygwin/2012-04/msg00140.html
>> >
>> >I wouldn't mind to see patch submissions fixing stuff like that on the
>> >newlib mailing list.  Not at all.
>> 
>> What an odd notion.
>
>Yeah, I'm that crazy sometimes.

Yeah, I know.  Crazy cat lady.

cgf

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

Latest Ghostscript 9.10 issue when using tiff output filter

2013-11-13 Thread Stefan Ziegler 
Converting a PDF to tiff using Ghostscript results in an error. All tiff
devices can't be used.
I've used a fresh Cygwin with the latest Ghostsscript.

Command used:
gs -dNOPAUSE -dBATCH -dSAFER -sDEVICE=tiff24nc -sOutputFile=test.tiff
test.pdf

Error:
Error writing data for field "BitsPerSample"

Used Ghostscript version:
GPL Ghostscript 9.10 (2013-08-30)
Copyright (C) 2013 Artifex Software, Inc.  All rights reserved.
This software comes with NO WARRANTY: see the file PUBLIC for details.


Seems to be a problem with the cygtiff-5 library. If I overwrite the
cygtiff-5.dll with the cygtiff-6.dll the error is away and the tiff file is
generated. Other software like imagemagic seems to have no problems with the
cygtiff-5.dll.

What's going wrong?


--
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: C++11 program link failure under GCC 4.8.2-1

2013-11-13 Thread Corinna Vinschen 
On Nov 13 09:01, Christopher Faylor wrote:
> On Wed, Nov 13, 2013 at 10:15:02AM +0100, Corinna Vinschen wrote:
> >On Nov 12 18:37, Ryan Johnson wrote:
> >> On 12/11/2013 5:30 PM, JonY wrote:
> >> >Right now, it is guarded by:
> >> >#if !defined(__STRICT_ANSI__) || (__STDC_VERSION__ >= 199901L)
> >> >
> >> >Which means non-strict mode and C99 mode, snprintf was not part of
> >> >C++03. I guess (__cplusplus >= 201103L) needs to be added to newlib.
> >> Yes, this has come up before [1]. Several *printf variants are
> >> affected IIRC.
> >> 
> >> [1] http://cygwin.com/ml/cygwin/2012-04/msg00140.html
> >
> >I wouldn't mind to see patch submissions fixing stuff like that on the
> >newlib mailing list.  Not at all.
> 
> What an odd notion.

Yeah, I'm that crazy sometimes.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


pgpsdKAN3To88.pgp
Description: PGP signature

Re: C++11 program link failure under GCC 4.8.2-1

2013-11-13 Thread Christopher Faylor 
On Wed, Nov 13, 2013 at 10:15:02AM +0100, Corinna Vinschen wrote:
>On Nov 12 18:37, Ryan Johnson wrote:
>> On 12/11/2013 5:30 PM, JonY wrote:
>> >Right now, it is guarded by:
>> >#if !defined(__STRICT_ANSI__) || (__STDC_VERSION__ >= 199901L)
>> >
>> >Which means non-strict mode and C99 mode, snprintf was not part of
>> >C++03. I guess (__cplusplus >= 201103L) needs to be added to newlib.
>> Yes, this has come up before [1]. Several *printf variants are
>> affected IIRC.
>> 
>> [1] http://cygwin.com/ml/cygwin/2012-04/msg00140.html
>
>I wouldn't mind to see patch submissions fixing stuff like that on the
>newlib mailing list.  Not at all.

What an odd notion.

cgf

--
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: C++11 program link failure under GCC 4.8.2-1

2013-11-13 Thread Corinna Vinschen 
On Nov 12 18:37, Ryan Johnson wrote:
> On 12/11/2013 5:30 PM, JonY wrote:
> >Right now, it is guarded by:
> >#if !defined(__STRICT_ANSI__) || (__STDC_VERSION__ >= 199901L)
> >
> >Which means non-strict mode and C99 mode, snprintf was not part of
> >C++03. I guess (__cplusplus >= 201103L) needs to be added to newlib.
> Yes, this has come up before [1]. Several *printf variants are
> affected IIRC.
> 
> [1] http://cygwin.com/ml/cygwin/2012-04/msg00140.html

I wouldn't mind to see patch submissions fixing stuff like that on the
newlib mailing list.  Not at all.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


pgpvU9RIv_PgK.pgp
Description: PGP signature