On 2013-11-26 Denis Excoffier wrote:
> On 2013-11-25 à 21:58 +02:00, Lasse Collin wrote:
> > If you haven't already tried, please compile both 5.1.2alpha and
> > 5.1.3alpha from source while keeping everything else unchanged, and
> > see if the bug really only occurs with 5.1.3alpha.
> Already done
On Tue, Nov 26, 2013 at 10:09:19PM +0100, Denis Excoffier wrote:
>On 2013-11-26 00:11 +01:00, Denis Excoffier wrote:
>> Already done. I did some strace-ing, and since i?m not so fluent with the
>> result, i?ll send it there in a while (when i?m back on cygwin) if someone is
>> interested. But the b
On 2013-11-25 à 21:58 +02:00, Lasse Collin wrote:
> On 2013-11-15 Denis Excoffier wrote:
>> Very briefly, my problem is that when i "tar xf
>> —use-compress-program=xz", i get:
>> tar: Unexpected EOF in archive
>> tar: Unexpected EOF in archive
>> tar: Error is not recoverable: exiting now
>> and t
On 2013-11-15 Denis Excoffier wrote:
> Very briefly, my problem is that when i "tar xf
> —use-compress-program=xz", i get:
> tar: Unexpected EOF in archive
> tar: Unexpected EOF in archive
> tar: Error is not recoverable: exiting now
> and the last file of the archive is truncated at some 512bytes
On 2013-11-15 20:21, Christopher Faylor wrote:
> On Fri, Nov 15, 2013 at 07:53:26PM +0100, Denis Excoffier wrote:
>> On 2013-11-14 05:01, Tom Honermann wrote:
>>> On 12/21/2012 01:30 AM, Tom Honermann wrote:
The workaround I implemented within Cygwin was simple and sloppy. I
added
On 11/15/2013 01:53 PM, Denis Excoffier wrote:
On 2013-11-14 05:01, Tom Honermann wrote:
On 12/21/2012 01:30 AM, Tom Honermann wrote:
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 wi
On Fri, Nov 15, 2013 at 07:53:26PM +0100, Denis Excoffier wrote:
>On 2013-11-14 05:01, Tom Honermann wrote:
>> On 12/21/2012 01:30 AM, Tom Honermann wrote:
>>>
>>> The workaround I implemented within Cygwin was simple and sloppy. I
>>> added a call to Sleep(1000) immediately before the call to Ex
On 2013-11-14 05:01, Tom Honermann wrote:
> On 12/21/2012 01:30 AM, Tom Honermann wrote:
>>
>> 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 t
On 11/14/2013 04:19 AM, Corinna Vinschen wrote:
thanks for letting us know!
You're welcome :)
I'm very glad to read that this is an OS bug and a fix is available.
At least partially. I'm a bit confused. As far as I understand it this
is the situation now:
Vista/2008 and earlier: no fi
Hi Tom,
On Nov 13 23:01, Tom Honermann wrote:
> On 12/21/2012 01:30 AM, Tom Honermann wrote:
> >[...]
> >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
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 w
On Wed, Jan 02, 2013 at 12:53:11PM -0800, Daniel Colascione wrote:
>On 1/2/13 12:48 PM, Christopher Faylor wrote:
>> I managed to duplicate a hang by really stressing ctrl-c a loop. It
>> uncovers some rather amazing Windows behavior which I have to think
>> about. Apparently ExitThread can be ca
On 01/02/2013 03:48 PM, Christopher Faylor wrote:
I managed to duplicate a hang by really stressing ctrl-c a loop. It
uncovers some rather amazing Windows behavior which I have to think
about. Apparently ExitThread can be called recursively within the
thread that Windows creates to handle CTRL-
On 1/2/13 12:48 PM, Christopher Faylor wrote:
> I managed to duplicate a hang by really stressing ctrl-c a loop. It
> uncovers some rather amazing Windows behavior which I have to think
> about. Apparently ExitThread can be called recursively within the
> thread that Windows creates to handle CTR
I managed to duplicate a hang by really stressing ctrl-c a loop. It
uncovers some rather amazing Windows behavior which I have to think
about. Apparently ExitThread can be called recursively within the
thread that Windows creates to handle CTRL-C.
cgf
--
Problem reports: http://cygwin.com
On 01/01/2013 12:36 AM, Christopher Faylor wrote:
On Mon, Dec 31, 2012 at 08:44:56PM -0500, Tom Honermann wrote:
I'm still seeing hangs in the latest code from CVS. The stack traces
below are from WinDbg.
I'm not asking you to build this yourself. I have no way to know how
you are building t
On Mon, Dec 31, 2012 at 08:44:56PM -0500, Tom Honermann wrote:
>On 12/29/2012 04:57 PM, Christopher Faylor wrote:
>> On Thu, Dec 27, 2012 at 03:49:24PM -0500, Tom Honermann wrote:
>>> When interrupting the test run, I'll often (but not always) get the
>>> following error:
>>>
>>> c:\>test-strace.ba
On 12/29/2012 04:57 PM, Christopher Faylor wrote:
On Thu, Dec 27, 2012 at 03:49:24PM -0500, Tom Honermann wrote:
When interrupting the test run, I'll often (but not always) get the
following error:
c:\>test-strace.bat
test...
test...
test...
test...
--- Process 8092, exception 40010005 at 75E26
On Thu, Dec 27, 2012 at 03:49:24PM -0500, Tom Honermann wrote:
>When interrupting the test run, I'll often (but not always) get the
>following error:
>
>c:\>test-strace.bat
>test...
>test...
>test...
>test...
>--- Process 8092, exception 40010005 at 75E26D67
That is coming from strace and it's:
I've been doing some testing with the latest source (pulled updates
about 30 minutes ago). I'm no longer able to reproduce any problems
with incorrect exit codes (Yay! Thanks for the quick turn around on
that!), but I am seeing some new errors when terminating the infinite
loop via ctrl-c usi
On 12/23/2012 5:56 PM, Christopher Faylor wrote:
However lftp is still broken
$ lftp
lftp :~> open -u xxx matzeri.altervista.org
1 [main] lftp 1092 select_stuff::wait: WaitForMultipleObjects
failed, Win32 error 6
(I have the impression it worked after your last select changes, but
On Sat, Dec 22, 2012 at 12:50:41PM -0500, Christopher Faylor wrote:
>On Sat, Dec 22, 2012 at 10:06:32AM +0100, marco atzeri wrote:
>>On 12/22/2012 4:14 AM, Christopher Faylor wrote:
>>> On Fri, Dec 21, 2012 at 09:49:43PM -0500, Christopher Faylor wrote:
I actually tried Xserver before submitti
On Sat, Dec 22, 2012 at 10:06:32AM +0100, marco atzeri wrote:
>On 12/22/2012 4:14 AM, Christopher Faylor wrote:
>> On Fri, Dec 21, 2012 at 09:49:43PM -0500, Christopher Faylor wrote:
>>> I actually tried Xserver before submitting my change so it certainly isn't
>>> a consistent problem.
>>
>> Sorry
On 12/22/2012 4:14 AM, Christopher Faylor wrote:
On Fri, Dec 21, 2012 at 09:49:43PM -0500, Christopher Faylor wrote:
I actually tried Xserver before submitting my change so it certainly isn't
a consistent problem.
Sorry, I take that back. I tried Xserver before backing out parts of the
other
On Fri, Dec 21, 2012 at 09:49:43PM -0500, Christopher Faylor wrote:
>I actually tried Xserver before submitting my change so it certainly isn't
>a consistent problem.
Sorry, I take that back. I tried Xserver before backing out parts of the
other change and never retried it. Marco is right. It's
The documentation in MSDN is incorrect/incomplete with regards to
TerminateThread/TerminateProcess, both are definitely asynchronous.
I am not clear/confident on the behaviour of ExitProcess and
ExitThread, but will investigate with IDA and a test case later. I
suspect any locking/serialisation wi
On 12/21/2012 09:52 PM, Christopher Faylor wrote:
You're looking at the wrong changes.
I wasn't at the time that I wrote that :)
I noticed that you had reverted those changes. I haven't looked at the
new changes yet.
Tom.
--
Problem reports: http://cygwin.com/problems.html
FAQ:
On Fri, Dec 21, 2012 at 06:08:46PM -0500, Tom Honermann wrote:
>On 12/21/2012 05:23 PM, marco atzeri wrote:
>> On 12/21/2012 8:36 PM, Christopher Faylor wrote:
>>> I tested this lightly on Windows 7 and 32-bit XP but it would be nice to
>>> hear if multi-threaded things like X work on other platfor
On Fri, Dec 21, 2012 at 11:23:00PM +0100, marco atzeri wrote:
>On 12/21/2012 8:36 PM, Christopher Faylor wrote:
>> On Fri, Dec 21, 2012 at 06:02:19PM +0100, Corinna Vinschen wrote:
>>> On Dec 21 11:10, Christopher Faylor wrote:
On Fri, Dec 21, 2012 at 11:32:41AM +0100, Corinna Vinschen wrote:
On 12/21/2012 05:23 PM, marco atzeri wrote:
On 12/21/2012 8:36 PM, Christopher Faylor wrote:
I tested this lightly on Windows 7 and 32-bit XP but it would be nice to
hear if multi-threaded things like X work on other platforms too.
If you test a snapshot, note that I'm still tracking down Ken B
On 12/21/2012 8:36 PM, Christopher Faylor wrote:
On Fri, Dec 21, 2012 at 06:02:19PM +0100, Corinna Vinschen wrote:
On Dec 21 11:10, Christopher Faylor wrote:
On Fri, Dec 21, 2012 at 11:32:41AM +0100, Corinna Vinschen wrote:
Maybe the signal thread should really not exit by itself, but just
wai
On 12/21/2012 11:36 AM, Christopher Faylor wrote:
> On Fri, Dec 21, 2012 at 06:02:19PM +0100, Corinna Vinschen wrote:
>> On Dec 21 11:10, Christopher Faylor wrote:
>>> On Fri, Dec 21, 2012 at 11:32:41AM +0100, Corinna Vinschen wrote:
Maybe the signal thread should really not exit by itself, bu
On 12/21/2012 01:30 AM, Tom Honermann wrote:
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.
I was able to reproduce the issue with a 64-bit executab
On 12/21/2012 07:15 AM, Nick Lowe wrote:
Briefly casting my eye at the test case, as a general point, remember
that these termination APIs all complete asynchronously and I do not
believe it has ever been safe or correct to call another while one is
still pending - you are in undefined, edge case
On Fri, Dec 21, 2012 at 06:02:19PM +0100, Corinna Vinschen wrote:
>On Dec 21 11:10, Christopher Faylor wrote:
>> On Fri, Dec 21, 2012 at 11:32:41AM +0100, Corinna Vinschen wrote:
>> >Maybe the signal thread should really not exit by itself, but just
>> >wait until the TerminateThread is called. Ch
On Dec 21 11:10, Christopher Faylor wrote:
> On Fri, Dec 21, 2012 at 11:32:41AM +0100, Corinna Vinschen wrote:
> >Maybe the signal thread should really not exit by itself, but just
> >wait until the TerminateThread is called. Chris?
>
> If the analysis is correct, that just fixes one symptom does
On Fri, Dec 21, 2012 at 11:32:41AM +0100, Corinna Vinschen wrote:
>Maybe the signal thread should really not exit by itself, but just
>wait until the TerminateThread is called. Chris?
If the analysis is correct, that just fixes one symptom doesn't it?
There are potentially many threads running in
Briefly casting my eye at the test case, as a general point, remember
that these termination APIs all complete asynchronously and I do not
believe it has ever been safe or correct to call another while one is
still pending - you are in undefined, edge case behaviour territory
here.
Win32's Termina
On Dec 21 01:30, 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 wo
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 kn
On 12/07/2012 08:54 PM, Tom Honermann wrote:
I recently was able to produce a very small test case that reproduces this
issue reliably on some machines:
Your suspicion about a race condition may very well be correct: I can easily confirm the problem on both iron and virtual smp, but not on a
On 12/07/2012 02:54 PM, Tom Honermann wrote:
Likewise, I've reproduced this issue by replacing false.exe in the test
above with a custom false.exe (A C program that just returns 1). The
issue reproduces whether myfalse.exe is compiled with Cygwin gcc, MinGW
gcc (32-bit and 64-bit), and with MSVC
I've witnessed intermittent failures in multiple build systems while
working at multiple companies using Cygwin bash and make as part of the
build system but using non-Cygwin compilers and other tools. The
intermittent failures occur when a process appears to complete
successfully, but the pro
43 matches
Mail list logo
