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 repo
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 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 int
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 re
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 (fo
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 descri
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&#x
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
+--- sh.exe (PID=
On 01/13/2014 11:06 AM, tedno...@bellsouth.net wrote:
...
switch (fork()) {
/* error */
case -1:
...
/* child */
case 0:
fprin
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
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
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 C
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/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/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 that this
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
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 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 is
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 o
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 expect
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 ex
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
proc
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/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) runn
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
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 that
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 01:05 PM, Earnie Boyd wrote:
On Wed, Jan 16, 2013 at 12:42 PM, Tom Honermann 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 a shell from the
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.
This will
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 was
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/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 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 ar
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 400
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/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 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 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 issu
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
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 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
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
44 matches
Mail list logo
