On 2/9/2019 9:51 AM, Corinna Vinschen wrote:
> On Feb 8 22:25, Tom Honermann wrote:
>> The following program demonstrates the problem.
>> [...]
>> Here is where things go bananas. If the program is run with stdout
>> initially redirected to a pipe, then the st
This is a follow up to a bug originally reported as
https://cygwin.com/ml/cygwin/2015-05/msg00140.html. We continue to face this
issue and recently spent some time trying to further isolate it. We now have a
better reproducer (below) that does not require GNU make.
>From the original bug
On 02/20/2015 04:56 AM, Corinna Vinschen wrote:
Lastly, running cygserver to cache the LDAP data has another side-effect
when using VPN. Since the cygserver is usually started before you've
dialed into the VPN, your username and some groups will get reported as
DOM+User(12345). You have to
On 02/20/2015 11:24 AM, Corinna Vinschen wrote:
On Feb 20 11:07, Tom Honermann wrote:
On 02/20/2015 04:56 AM, Corinna Vinschen wrote:
Lastly, running cygserver to cache the LDAP data has another side-effect
when using VPN. Since the cygserver is usually started before you've
dialed
On 02/20/2015 12:03 PM, Corinna Vinschen wrote:
Maybe it is actually simpler than that. Invalidating the cache as a
whole probably never makes sense. In fact there are two reasons for
invalidation:
- The pw_name, pw_shell, pw_home, pw_gecos settings for a user changed.
- The interface to the
On 12/10/2014 07:33 AM, Corinna Vinschen wrote:
On Dec 9 17:06, Tom Honermann wrote:
This sounds like something I diagnosed a while back. I see you have Lenovo
utilities in your PATH. There is a defect in Lenovo's RapidBoot Shield
Version 1.23 that results in process handles (for all
This sounds like something I diagnosed a while back. I see you have
Lenovo utilities in your PATH. There is a defect in Lenovo's RapidBoot
Shield Version 1.23 that results in process handles (for all processes)
not getting closed. This causes these processes to remain in memory as
you
On 01/31/2014 03:11 PM, Darrel Laursen wrote:
Hey Darrel! Nice to see you popping up here!
Below is the relevant process tree.
make.exe (PID=77256) launches sh.exe -c pscl.exe . || (shopt -s nullglob rm -f
xxx.obj; exit 1)
+--- sh.exe (PID=94584) launches sh.exe no command line given
On 02/03/2014 12:13 PM, Tom Honermann wrote:
$ cat doit.sh
#!/bin/sh
while [ 1 ]; do
make || {
echo make failed unexpectedly
break
}
done
$ cat Makefile
all:
cl.exe /c t.cpp || (shopt -s nullglob rm -f t.obj; exit 1)
$ cat t.cpp
int i;
I've been running five copies
On 01/13/2014 11:06 AM, tedno...@bellsouth.net wrote:
...
switch (fork()) {
/* error */
case -1:
...
/* child */
case 0:
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
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
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
On 07/26/2013 01:58 PM, Tom Honermann wrote:
On 07/26/2013 01:38 PM, Christopher Faylor wrote:
On Thu, Jul 25, 2013 at 02:16:04PM -0400, Christopher Faylor wrote:
On Thu, Jul 25, 2013 at 09:21:31AM -0400, Charles Wilson wrote:
On 7/25/2013 4:28 AM, Corinna Vinschen wrote:
On Jul 24 22:38
On 07/26/2013 01:38 PM, Christopher Faylor wrote:
On Thu, Jul 25, 2013 at 02:16:04PM -0400, Christopher Faylor wrote:
On Thu, Jul 25, 2013 at 09:21:31AM -0400, Charles Wilson wrote:
On 7/25/2013 4:28 AM, Corinna Vinschen wrote:
On Jul 24 22:38, Tom Honermann wrote:
My suspicion
On 07/25/2013 02:15 PM, Buchbinder, Barry (NIH/NIAID) [E] wrote:
Tom Honermann sent the following at Thursday, July 25, 2013 1:53 PM
Does this (or a variation thereof) do what you want?
c:\cygwin\bin\procps -A --format cmd
Thank you for the suggestion, but no. My use case really does
On 07/25/2013 09:21 AM, Charles Wilson wrote:
On 7/25/2013 4:28 AM, Corinna Vinschen wrote:
On Jul 24 22:38, Tom Honermann wrote:
My suspicion that this started with 1.7.21 is based on Corinna's
comments in http://cygwin.com/ml/cygwin/2013-07/msg00343.html and
other anecdotal evidence of new
On 07/25/2013 11:10 AM, Christopher Faylor wrote:
On Thu, Jul 25, 2013 at 10:19:16AM -0400, Tom Honermann wrote:
On 07/25/2013 09:21 AM, Charles Wilson wrote:
On 7/25/2013 4:28 AM, Corinna Vinschen wrote:
On Jul 24 22:38, Tom Honermann wrote:
My suspicion that this started with 1.7.21
On 07/25/2013 11:21 AM, Christopher Faylor wrote:
On Thu, Jul 25, 2013 at 11:10:50AM -0400, Christopher Faylor wrote:
It's not strace that's broken. That's just a simple fix to the DLL.
Actually, nevermind. It's not a bug.
Could you elaborate? Prior to 1.7.21, strace provided the command
On 07/25/2013 01:18 PM, Christopher Faylor wrote:
On Thu, Jul 25, 2013 at 11:44:07AM -0400, Tom Honermann wrote:
On 07/25/2013 11:21 AM, Christopher Faylor wrote:
On Thu, Jul 25, 2013 at 11:10:50AM -0400, Christopher Faylor wrote:
It's not strace that's broken. That's just a simple fix
It seems that process command lines for Cygwin processes are no longer
viewable in Windows task manager, SysInternals Process Explorer, or
other similar tools. I suspect, but have not verified, that this change
occurred with the Cygwin 1.7.21 release. Process command lines do
appear as
On 04/22/2013 05:26 AM, Corinna Vinschen wrote:
I just released Cygwin 1.7.18.
Yay! Thank you!
Bug fixes:
==
...
- Fix bug where dup2 segv'ed on negative fd.
See: http://cygwin.com/ml/cygwin/2012-12/msg00377.html
- Work around problem of erratic exit codes caused by a thread
On 01/23/2013 12:26 AM, Christopher Faylor wrote:
On Tue, Jan 22, 2013 at 10:20:20PM -0500, Tom Honermann wrote:
However, just as I was about to give up testing, I hit one more new
issue. One of the ctrl-c events sent bash into what appeared to be an
infinite loop emitting error messages like
On 01/23/2013 01:35 PM, Christopher Faylor wrote:
On Wed, Jan 23, 2013 at 01:17:45PM -0500, Tom Honermann wrote:
I see you checked in a change to detect the infinite recursion. I'd
call that good enough.
That probably is relatively ok given that you're trying to terminate the
process anyway
On 01/20/2013 05:08 PM, Tom Honermann wrote:
However, I was still able to reproduce another case. As before, one of
the processes is being left running when the rest are terminated. The
abandoned process appears to be in a live-lock state with two threads
(threads 1 and 2) running at 100
On 01/19/2013 12:58 AM, Christopher Faylor wrote:
On Fri, Jan 18, 2013 at 03:11:03PM -0500, Tom Honermann wrote:
On 01/16/2013 05:23 PM, Christopher Faylor wrote:
On Wed, Jan 16, 2013 at 03:18:47PM -0500, Tom Honermann wrote:
I managed to duplicate a hang by changing your .bat file to use
On 01/16/2013 05:23 PM, Christopher Faylor wrote:
On Wed, Jan 16, 2013 at 03:18:47PM -0500, Tom Honermann wrote:
I managed to duplicate a hang by changing your .bat file to use sleep
2 rather than false. I'm investigating now.
I noticed that you checked in some additional changes on the 16th
On 01/15/2013 09:04 PM, Christopher Faylor wrote:
On Tue, Jan 15, 2013 at 05:16:57PM -0500, Tom Honermann wrote:
I noticed that some changes were checked in related to signal handling
and process termination recently, so I downloaded the most recent
snapshot (20130114) and tested again. I
On 01/16/2013 11:53 AM, marco atzeri wrote:
On 1/16/2013 5:37 PM, Tom Honermann wrote:
4) Launch mintty using an existing Cygwin installation. Naturally, this
will run a shell from the existing Cygwin install.
5) Change directories to the usr/bin directory of the snapshot
On 01/16/2013 01:05 PM, Earnie Boyd wrote:
On Wed, Jan 16, 2013 at 12:42 PM, Tom Honermann thonerm...@coverity.com wrote:
On 01/16/2013 11:53 AM, marco atzeri wrote:
On 1/16/2013 5:37 PM, Tom Honermann wrote:
4) Launch mintty using an existing Cygwin installation. Naturally, this
will run
On 01/16/2013 01:59 PM, Christopher Faylor wrote:
On Wed, Jan 16, 2013 at 01:51:11PM -0500, Tom Honermann wrote:
Can you elaborate on what resources you are referring to? I fail to
see how the Cygwin binaries run via the .bat file could conflict with
mintty (or the top level bash process
On 01/16/2013 02:14 PM, Christopher Faylor wrote:
Again, if I hit CTRL-C while running ./test.bat in mintty then test.bat
exits immediately, as expected. Hitting ctrl-c repeatedly after that
point gives me a new bash prompt.
Yes, that is what is expected to happen. What I am reporting is
On 01/02/2013 04:24 PM, Tom Honermann wrote:
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
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
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
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
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
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
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
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
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:
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
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
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
44 matches
Mail list logo
