RE: Please test snapshots
Christopher Faylor wrote: On Tue, Aug 14, 2012 at 12:48:03PM +, Adam Dinwoodie wrote: I'm still using this snapshot (I've had no reason to stop until now), and have hit this issue two out of the last five times running Cygwin ping. The ping process is still visible in Process Explorer after hitting ^C. There's no obvious difference between when ^C terminates the process and when it doesn't. I managed to duplicate this once a couple of days ago in a mintty/tcsh process but I had a very hard time consistently hitting it. So I wrote a test case which ran ping repeatedly in a loop under mintty while another process killed it. Eventually, I could duplicate the problem in a few minutes. There were two problems, one illustrated by the sigwaitinfo mentioned in another thread and another caused by a race. I'm seeing this much more regularly than that; it's pretty readily reproducible for me. I've found leaving a couple of seconds between starting ping and trying to kill it, and leaving a couple of seconds between invocations, both help. I've not tested that thoroughly, though; it might be something to play with for trying to build a test case, but certainly not something I'd rely on as a symptom for debugging without further verification. After making some changes to signal handling, I ran the test case for an afternoon without issue. The current snapshot has these changes. I'd appreciate feedback on whether or not this fixes this problem. I'm still seeing exactly the same issue having taken the 20120816 snapshot. If anything, I've been hitting the problem more. -- 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: Please test snapshots
Achim Gratz Stromeko at NexGo.DE writes: With the latest snapshot (2012-08-07), pinging a dead machine (i.e. has a DNS entry but doesn't answer) from tcsh in mintty, I can't Ctrl-C ping and have to wait until it finally times out. # ping deadbeef PING deadbeef (xx.xx.xx.xx): 56 data bytes This is still happening with the 2012-08-16 19:31:57 UTC snapshot. The dead machine cannot be in the same local network or the fail is not happening. After Ctrl-C in the tcsh for ping, nothing happens and ps still shows ping as a running process. Killing that process ID from another shell kills the shell ping was started from along with the mintty it was running in. Trying to attach to the ping process with gdb recognizes it as tcsh rather than ping, which might explain why killing ping actually kills tcsh. Regards, Achim. -- 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: Please test snapshots
Achim Gratz Stromeko at NexGo.DE writes: This is still happening with the 2012-08-16 19:31:57 UTC snapshot. And now I see that all that killing business has left some tcsh processes in task manager with a size of 60k (much too small for both tcsh and ping) that ps in Cygwin doesn't show. I could terminate these from the task manger. Regards, Achim. -- 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: Please test snapshots
On Fri, Aug 17, 2012 at 09:07:30AM +, Adam Dinwoodie wrote: Christopher Faylor wrote: On Tue, Aug 14, 2012 at 12:48:03PM +, Adam Dinwoodie wrote: I'm still using this snapshot (I've had no reason to stop until now), and have hit this issue two out of the last five times running Cygwin ping. The ping process is still visible in Process Explorer after hitting ^C. There's no obvious difference between when ^C terminates the process and when it doesn't. I managed to duplicate this once a couple of days ago in a mintty/tcsh process but I had a very hard time consistently hitting it. So I wrote a test case which ran ping repeatedly in a loop under mintty while another process killed it. Eventually, I could duplicate the problem in a few minutes. There were two problems, one illustrated by the sigwaitinfo mentioned in another thread and another caused by a race. I'm seeing this much more regularly than that; it's pretty readily reproducible for me. Yes, I got the fact that other people were able to duplicate the problem easily. I've found leaving a couple of seconds between starting ping and trying to kill it, and leaving a couple of seconds between invocations, both help. I've not tested that thoroughly, though; it might be something to play with for trying to build a test case, but certainly not something I'd rely on as a symptom for debugging without further verification. After making some changes to signal handling, I ran the test case for an afternoon without issue. The current snapshot has these changes. I'd appreciate feedback on whether or not this fixes this problem. I'm still seeing exactly the same issue having taken the 20120816 snapshot. If anything, I've been hitting the problem more. I should have asked this before: I don't think anyone has made it clear if they are running the cygwin ping or the Windows one. I've been assuming Cygwin. Is that correct? 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: Please test snapshots
Christopher Faylor wrote On Fri, Aug 17, 2012 at 09:07:30AM +, Adam Dinwoodie wrote: I'm still seeing exactly the same issue having taken the 20120816 snapshot. If anything, I've been hitting the problem more. I should have asked this before: I don't think anyone has made it clear if they are running the cygwin ping or the Windows one. I've been assuming Cygwin. Is that correct? Yes, Cygwin ping. For paranoia's sake, you can check the output I pasted in my previous email, which should look like Cygwin ping rather than Windows ping output. Also: $ cygcheck -c ping Cygwin Package Information Package VersionStatus ping 1.0-1 OK $ cygcheck -f $(which ping) ping-1.0-1 $ which ping /usr/bin/ping $ cygcheck ping Found: C:\cygwin\bin\ping.exe Found: C:\Windows\system32\ping.exe C:\cygwin\bin\ping.exe C:\cygwin\bin\cygwin1.dll C:\Windows\system32\KERNEL32.dll C:\Windows\system32\API-MS-Win-Core-RtlSupport-L1-1-0.dll C:\Windows\system32\ntdll.dll ...blah blah blah... -- 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: Please test snapshots
On Fri, Aug 17, 2012 at 03:50:05PM +, Adam Dinwoodie wrote: Christopher Faylor wrote On Fri, Aug 17, 2012 at 09:07:30AM +, Adam Dinwoodie wrote: I'm still seeing exactly the same issue having taken the 20120816 snapshot. If anything, I've been hitting the problem more. I should have asked this before: I don't think anyone has made it clear if they are running the cygwin ping or the Windows one. I've been assuming Cygwin. Is that correct? Yes, Cygwin ping. For paranoia's sake, you can check the output I pasted in my previous email, which should look like Cygwin ping rather than Windows ping output. That's why I was assuming Cygwin ping. 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: Please test snapshots
Christopher Faylor writes: I should have asked this before: I don't think anyone has made it clear if they are running the cygwin ping or the Windows one. I've been assuming Cygwin. Is that correct? Cygwin's ping. I've removed any remnants of Windows' PATH from all Cygwin startup scripts... Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Factory and User Sound Singles for Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds -- 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: Please test snapshots
On Tue, Aug 14, 2012 at 12:48:03PM +, Adam Dinwoodie wrote: Christopher Faylor wrote: On Fri, Aug 10, 2012 at 06:31:25AM +, Achim Gratz wrote: Daniel Colascione writes: It works for me in bash. I don't have tcsh installed, but I don't see why SIGINT would work differently there. Yes, it works in bash for me, too. Tcsh does something that apparently breaks with the new snapshot, but since I don't get any error messages, it's hard to tell what that might be. You're not really giving us much to go on. I've tried ping (both Windows and Cygwin version) under tcsh and both work fine. And, the small snippet that you cut/paste in your original bug report clearly showed that ping was responding to CTRL-C. I'm still using this snapshot (I've had no reason to stop until now), and have hit this issue two out of the last five times running Cygwin ping. The ping process is still visible in Process Explorer after hitting ^C. There's no obvious difference between when ^C terminates the process and when it doesn't. I managed to duplicate this once a couple of days ago in a mintty/tcsh process but I had a very hard time consistently hitting it. So I wrote a test case which ran ping repeatedly in a loop under mintty while another process killed it. Eventually, I could duplicate the problem in a few minutes. There were two problems, one illustrated by the sigwaitinfo mentioned in another thread and another caused by a race. After making some changes to signal handling, I ran the test case for an afternoon without issue. The current snapshot has these changes. I'd appreciate feedback on whether or not this fixes this problem. 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: Please test snapshots
On 8/16/2012 2:37 PM, Christopher Faylor wrote: On Tue, Aug 14, 2012 at 12:48:03PM +, Adam Dinwoodie wrote: Christopher Faylor wrote: On Fri, Aug 10, 2012 at 06:31:25AM +, Achim Gratz wrote: Daniel Colascione writes: It works for me in bash. I don't have tcsh installed, but I don't see why SIGINT would work differently there. Yes, it works in bash for me, too. Tcsh does something that apparently breaks with the new snapshot, but since I don't get any error messages, it's hard to tell what that might be. You're not really giving us much to go on. I've tried ping (both Windows and Cygwin version) under tcsh and both work fine. And, the small snippet that you cut/paste in your original bug report clearly showed that ping was responding to CTRL-C. I'm still using this snapshot (I've had no reason to stop until now), and have hit this issue two out of the last five times running Cygwin ping. The ping process is still visible in Process Explorer after hitting ^C. There's no obvious difference between when ^C terminates the process and when it doesn't. I managed to duplicate this once a couple of days ago in a mintty/tcsh process but I had a very hard time consistently hitting it. So I wrote a test case which ran ping repeatedly in a loop under mintty while another process killed it. Eventually, I could duplicate the problem in a few minutes. There were two problems, one illustrated by the sigwaitinfo mentioned in another thread and another caused by a race. After making some changes to signal handling, I ran the test case for an afternoon without issue. The current snapshot has these changes. With the current snapshot (20120816 17:19:27), I have problems with emacs-X11.exe. When I start it under X (by typing 'emacs' in an xterm window), its CPU usage goes up to 50% and its window never displays. The attached file gives the result of attaching gdb and giving the command 'thread apply all bt full'. I reproduced this running emacs under mintty, but it took longer for it to happen. The problem doesn't occur with the 20120815 snapshot. Ken Thread 10 (Thread 5884.0x17c4): #0 0x76f6000d in ntdll!LdrFindResource_U () from /c/windows/SysWOW64/ntdll.dll No symbol table info available. #1 0x76fef896 in ntdll!RtlQueryTimeZoneInformation () from /c/windows/SysWOW64/ntdll.dll No symbol table info available. #2 0x7375eb68 in ?? () No symbol table info available. #3 0x in ?? () No symbol table info available. Thread 9 (Thread 5884.0x9a0): #0 0x76f71f26 in ntdll!LdrQueryProcessModuleInformation () from /c/windows/SysWOW64/ntdll.dll No symbol table info available. #1 0x76f71f26 in ntdll!LdrQueryProcessModuleInformation () from /c/windows/SysWOW64/ntdll.dll No symbol table info available. #2 0x76fa3352 in ntdll!RtlCreateTagHeap () from /c/windows/SysWOW64/ntdll.dll No symbol table info available. warning: (Internal error: pc 0x1b7 in read in psymtab, but not in symtab.) warning: (Internal error: pc 0x1b7 in read in psymtab, but not in symtab.) #3 0x01b8 in ?? () warning: (Internal error: pc 0x1b7 in read in psymtab, but not in symtab.) No symbol table info available. warning: (Internal error: pc 0x1b7 in read in psymtab, but not in symtab.) #4 0x044dac8c in ?? () No symbol table info available. #5 0x6100538d in _cygtls::call2 (this=optimized out, func=0x2, arg=0x18c9908, buf=0x6100551b) at /netrel/src/cygwin-snapshot-20120816-1/winsup/cygwin/cygtls.cc:99 res = optimized out #6 0x044dff88 in ?? () No symbol table info available. #7 0x74f3339a in KERNEL32!BaseCleanupAppcompatCacheSupport () from /c/windows/syswow64/kernel32.dll No symbol table info available. #8 0x018c9908 in ?? () No symbol table info available. #9 0x76f89ef2 in ntdll!RtlpNtSetValueKey () from /c/windows/SysWOW64/ntdll.dll No symbol table info available. #10 0x018c9908 in ?? () No symbol table info available. #11 0x76f89ec5 in ntdll!RtlpNtSetValueKey () from /c/windows/SysWOW64/ntdll.dll No symbol table info available. #12 0x6107f110 in cygwin_inet_network () from /usr/bin/cygwin1.dll No symbol table info available. #13 0x in ?? () No symbol table info available. Thread 8 (Thread 5884.0xc58): #0 0x76f71f26 in ntdll!LdrQueryProcessModuleInformation () from /c/windows/SysWOW64/ntdll.dll No symbol table info available. #1 0x76f71f26 in ntdll!LdrQueryProcessModuleInformation () from /c/windows/SysWOW64/ntdll.dll No symbol table info available. #2 0x76fa3352 in ntdll!RtlCreateTagHeap () from /c/windows/SysWOW64/ntdll.dll No symbol table info available. warning: (Internal error: pc 0x1c3 in read in psymtab, but not in symtab.) warning: (Internal error: pc 0x1c3 in read in psymtab, but not in symtab.) warning: (Internal error: pc 0x1c3 in read in psymtab, but not in symtab.) #3 0x01c4 in ?? () warning: (Internal error: pc 0x1c3 in read in psymtab, but not in symtab.) No symbol table info available. warning: (Internal error: pc 0x1c3 in
Re: Please test snapshots
On Thu, Aug 16, 2012 at 03:11:34PM -0400, Ken Brown wrote: With the current snapshot (20120816 17:19:27), I have problems with emacs-X11.exe. When I start it under X (by typing 'emacs' in an xterm window), its CPU usage goes up to 50% and its window never displays. The attached file gives the result of attaching gdb and giving the command 'thread apply all bt full'. I reproduced this running emacs under mintty, but it took longer for it to happen. The problem doesn't occur with the 20120815 snapshot. It's funny how the simple explanation of a problem can trigger a Oh #(*$. I know what I did. In this case, I made my standard reverse the sense of a ? operator mistake. I'm generating a new snapshot which seems to fix the problem. I meant to run my normal raft of exhaustive tests: - run bash in console - run mintty - run X - start emacs but I missed the last two. Duh. 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: Please test snapshots
On 8/16/2012 3:26 PM, Christopher Faylor wrote: On Thu, Aug 16, 2012 at 03:11:34PM -0400, Ken Brown wrote: With the current snapshot (20120816 17:19:27), I have problems with emacs-X11.exe. When I start it under X (by typing 'emacs' in an xterm window), its CPU usage goes up to 50% and its window never displays. The attached file gives the result of attaching gdb and giving the command 'thread apply all bt full'. I reproduced this running emacs under mintty, but it took longer for it to happen. The problem doesn't occur with the 20120815 snapshot. It's funny how the simple explanation of a problem can trigger a Oh #(*$. I know what I did. In this case, I made my standard reverse the sense of a ? operator mistake. I'm generating a new snapshot which seems to fix the problem. Confirmed. Thanks. Ken -- 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: Please test snapshots
Hi, I think i found a glitch in gmon.c
the testcase is following. and you can see it doesn't work.
int main()
{
char *proffile;
{
char gmon_out[] = gmon.out;
proffile = gmon_out;
}
printf(%s\n,proffile);
}
---
$ ./a
a(▒
Actually the above can't be expected to work. the above is exactly same
case with gmon.c:206
-- Regards.
--
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: Please test snapshots
On Aug 15 02:59, jojelino wrote:
Hi, I think i found a glitch in gmon.c
the testcase is following. and you can see it doesn't work.
int main()
{
char *proffile;
{
char gmon_out[] = gmon.out;
proffile = gmon_out;
}
printf(%s\n,proffile);
}
---
$ ./a
a(▒
Actually the above can't be expected to work. the above is exactly
same case with gmon.c:206
Fixed in CVS.
Thanks,
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
--
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: Please test snapshots
On Tue, Aug 14, 2012 at 09:39:14PM +0200, Corinna Vinschen wrote:
On Aug 15 02:59, jojelino wrote:
Hi, I think i found a glitch in gmon.c
the testcase is following. and you can see it doesn't work.
int main()
{
char *proffile;
{
char gmon_out[] = gmon.out;
proffile = gmon_out;
}
printf(%s\n,proffile);
}
---
$ ./a
a(???
Actually the above can't be expected to work. the above is exactly
same case with gmon.c:206
Fixed in CVS.
Btw, since this file hadn't changed in two years, it's unlikely
that this was a regression and probably deserved a new subject.
This really isn't an issue with the latest snapshot.
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: Please test snapshots
Daniel Colascione dancol at dancol.org writes: It works for me in bash. I don't have tcsh installed, but I don't see why SIGINT would work differently there. Yes, it works in bash for me, too. Tcsh does something that apparently breaks with the new snapshot, but since I don't get any error messages, it's hard to tell what that might be. I tried it again in tcsh, and the SIGINT clearly did not get delivered to ping (the process was still running) and I had to kill it from another shell. Once I did that, the prompt in tcsh came back. I can kill other processes in tcsh, but sometimes they are not properly terminated, like here: ... pty085441 08:14:58 /usr/bin/git defunct Regards, Achim. -- 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: Please test snapshots
On Fri, Aug 10, 2012 at 06:31:25AM +, Achim Gratz wrote: Daniel Colascione writes: It works for me in bash. I don't have tcsh installed, but I don't see why SIGINT would work differently there. Yes, it works in bash for me, too. Tcsh does something that apparently breaks with the new snapshot, but since I don't get any error messages, it's hard to tell what that might be. You're not really giving us much to go on. I've tried ping (both Windows and Cygwin version) under tcsh and both work fine. And, the small snippet that you cut/paste in your original bug report clearly showed that ping was responding to CTRL-C. I tried it again in tcsh, and the SIGINT clearly did not get delivered to ping (the process was still running) and I had to kill it from another shell. Once I did that, the prompt in tcsh came back. I can kill other processes in tcsh, but sometimes they are not properly terminated, like here: ... pty085441 08:14:58 /usr/bin/git defunct A defunct process doesn't mean that something is not properly terminated. Is this also a tcsh shell running git? -- 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: Please test snapshots
Christopher Faylor writes: You're not really giving us much to go on. I don't have anything else, these are the only two (small) issues I've seen after installation of the latest snapshot. A defunct process doesn't mean that something is not properly terminated. Is this also a tcsh shell running git? Actually it was make started in tcsh, which then forked git (I think it goes through bash for this, but I'm not sure). I've killed make while git was running. Anyway, the computer will be freshly booted on Monday, I'll see if that is still reproduceable then. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ SD adaptation for Waldorf microQ V2.22R2: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada -- 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: Please test snapshots
On Fri, Aug 10, 2012 at 07:57:24PM +0200, Achim Gratz wrote: Christopher Faylor writes: You're not really giving us much to go on. I don't have anything else, these are the only two (small) issues I've seen after installation of the latest snapshot. A defunct process doesn't mean that something is not properly terminated. Is this also a tcsh shell running git? Actually it was make started in tcsh, which then forked git (I think it goes through bash for this, but I'm not sure). I've killed make while git was running. Anyway, the computer will be freshly booted on Monday, I'll see if that is still reproduceable then. ...and those are the kind of details which allows us to at least make educated guesses about problems. Showing a defunct ps listing, not so much... It's probably too late to ask but is the make process still around? 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: Please test snapshots
Christopher Faylor writes: ...and those are the kind of details which allows us to at least make educated guesses about problems. Showing a defunct ps listing, not so much... You know this, but a defunct listing means that a process terminated, but wasn't reaped by it's parent process. Unless that parent process crashed hard I can't remember seeing that happen in Cygwin, which is why I thought it noteworthy. It's probably too late to ask but is the make process still around? I killed make because I forgot to add a variable definition on the command line. Only later did I find it left that zombie git process that should have been terminated with it (I know it was associated with that particular make invocation by its start time). 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: Please test snapshots
On Fri, Aug 10, 2012 at 08:33:36PM +0200, Achim Gratz wrote: Christopher Faylor writes: ...and those are the kind of details which allows us to at least make educated guesses about problems. Showing a defunct ps listing, not so much... You know this, but a defunct listing means that a process terminated, but wasn't reaped by it's parent process. Unless that parent process crashed hard I can't remember seeing that happen in Cygwin, which is why I thought it noteworthy. ...and that's why I asked: It's probably too late to ask but is the make process still around? I killed make because I forgot to add a variable definition on the command line. Only later did I find it left that zombie git process that should have been terminated with it (I know it was associated with that particular make invocation by its start time). So you don't know if the make process was actually still around. Got it. 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: Please test snapshots
Christopher Faylor writes: I killed make because I forgot to add a variable definition on the command line. Only later did I find it left that zombie git process that should have been terminated with it (I know it was associated with that particular make invocation by its start time). So you don't know if the make process was actually still around. Got it. For all I know it was gone. The shell had the control back and no process was showing in ps. I didn't think to look in process monitor, sorry. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Wavetables for the Terratec KOMPLEXER: http://Synth.Stromeko.net/Downloads.html#KomplexerWaves -- 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: Please test snapshots
On Fri, Aug 10, 2012 at 10:23:41PM +0200, Achim Gratz wrote: Christopher Faylor writes: I killed make because I forgot to add a variable definition on the command line. Only later did I find it left that zombie git process that should have been terminated with it (I know it was associated with that particular make invocation by its start time). So you don't know if the make process was actually still around. Got it. For all I know it was gone. The shell had the control back and no process was showing in ps. I didn't think to look in process monitor, sorry. Yep, I wouldn't have expected you to check. I wouldn't have either. 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: Please test snapshots
Achim Gratz Stromeko at NexGo.DE writes: The X server is still running as well as a number of other X applications. Something's wrong here with the new snapshot and signal handling / job control in conjunction with X and the newest snapshot... this morning the shell proclaimed (I left it running overnight) after the first command: [1] - Done gitk --all However, I have only started one gitk since starting X and it is still running. Regards, Achim. -- 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: Please test snapshots
Christopher Faylor cgf-use-the-mailinglist-please at cygwin.com writes: You mention generic signal handling rather than sigwaitinfo so I don't know if there are other issues. It doesn't seem like much would work if signal handling was completely broken, though. With the latest snapshot (2012-08-07), pinging a dead machine (i.e. has a DNS entry but doesn't answer) from tcsh in mintty, I can't Ctrl-C ping and have to wait until it finally times out. # ping deadbeef PING deadbeef (xx.xx.xx.xx): 56 data bytes deadbeef PING Statistics 2 packets transmitted, 0 packets received, 100.0% packet loss Regards, Achim. -- 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: Please test snapshots
On Thu, Aug 09, 2012 at 09:21:47AM +, Achim Gratz wrote: Christopher Faylor cgf-use-the-mailinglist-please at cygwin.com writes: You mention generic signal handling rather than sigwaitinfo so I don't know if there are other issues. It doesn't seem like much would work if signal handling was completely broken, though. With the latest snapshot (2012-08-07), pinging a dead machine (i.e. has a DNS entry but doesn't answer) from tcsh in mintty, I can't Ctrl-C ping and have to wait until it finally times out. # ping deadbeef PING deadbeef (xx.xx.xx.xx): 56 data bytes deadbeef PING Statistics 2 packets transmitted, 0 packets received, 100.0% packet loss Ping doesn't time out after only two packets. It sure looks like CTRL-C worked above. 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: Please test snapshots
On 8/9/12 2:21 AM, Achim Gratz wrote: Christopher Faylor cgf-use-the-mailinglist-please at cygwin.com writes: You mention generic signal handling rather than sigwaitinfo so I don't know if there are other issues. It doesn't seem like much would work if signal handling was completely broken, though. With the latest snapshot (2012-08-07), pinging a dead machine (i.e. has a DNS entry but doesn't answer) from tcsh in mintty, I can't Ctrl-C ping and have to wait until it finally times out. It works for me in bash. I don't have tcsh installed, but I don't see why SIGINT would work differently there. signature.asc Description: OpenPGP digital signature
Re: Please test snapshots
Christopher Faylor writes: deadbeef PING Statistics 2 packets transmitted, 0 packets received, 100.0% packet loss Ping doesn't time out after only two packets. It sure looks like CTRL-C worked above. Maybe ping got indeed interrupted, but I didn't get the shell prompt back for another two or three minutes. Also, when the shell receives the Ctrl-C (as it would when ping was already gone) it would normally produce another prompt for each Ctrl-C, but this did not happen even though I tried multiple times to interrupt ping. After a while I got a single prompt back. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Wavetables for the Terratec KOMPLEXER: http://Synth.Stromeko.net/Downloads.html#KomplexerWaves -- 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: Please test snapshots
I'm at the August 7th snapshot now and Emacs just died on me with this message: Connection lost to X server `:0.0' When compiled with GTK, Emacs cannot recover from X disconnects. This is a GTK bug: https://bugzilla.gnome.org/show_bug.cgi?id=85715 For details, see etc/PROBLEMS. The X server is still running as well as a number of other X applications. Regards, Achim. -- 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: Please test snapshots
On Mon, Aug 06, 2012 at 05:15:10PM -0700, Daniel Colascione wrote:
On 8/6/2012 2:07 PM, Daniel Colascione wrote:
I just saw a hang building Emacs (using make bootstrap)
Signal handling appears to be broken. Here's a simple testcase. Run the program
and hit control-c. It'll print got Alarm clock, then stop accepting any
signals at all, even SIGSTOP. The same program works fine on my Debian stable
box.
I forgot to send out a notice about this.
This particular issue should be fixed in the latest snapshot.
You mention generic signal handling rather than sigwaitinfo so I don't
know if there are other issues. It doesn't seem like much would work if
signal handling was completely broken, though.
Thanks for the test case.
cgf
#define _GNU_SOURCE 1
#include unistd.h
#include stdio.h
#include stdlib.h
#include signal.h
#include pthread.h
int
main()
{
sigset_t waitmask;
int sig;
sigemptyset (waitmask);
sigaddset (waitmask, SIGINT);
sigprocmask (SIG_BLOCK, waitmask, NULL);
for (;;) {
sig = sigwaitinfo (waitmask, NULL);
fprintf (stderr, got %s\n, sys_siglist[sig]);
if (sig == SIGINT) {
break;
}
}
return 0;
}
--
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: Please test snapshots
On 8/8/2012 2:59 PM, Christopher Faylor wrote: On Mon, Aug 06, 2012 at 05:15:10PM -0700, Daniel Colascione wrote: On 8/6/2012 2:07 PM, Daniel Colascione wrote: I just saw a hang building Emacs (using make bootstrap) Signal handling appears to be broken. Here's a simple testcase. Run the program and hit control-c. It'll print got Alarm clock, then stop accepting any signals at all, even SIGSTOP. The same program works fine on my Debian stable box. I forgot to send out a notice about this. This particular issue should be fixed in the latest snapshot. The latest snapshot seems to fix the issue. You mention generic signal handling rather than sigwaitinfo so I don't know if there are other issues. It doesn't seem like much would work if signal handling was completely broken, though. Apologies --- I should have been more specific. No, I haven't noticed any other signal breakage aside from the sigwaitinfo problem and the Emacs build hang. I can't reproduce either with the new snapshot. signature.asc Description: OpenPGP digital signature
Re: Please test snapshots
Christopher Faylor cgf-use-the-mailinglist-please at cygwin.com writes: So, if you haven't already, we'd appreciate having people try out the latest snapshot at: http://cygwin.com/snapshots/ . The August 3rd snapshot looks good so far in my testing. Regards, Achim. -- 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: Please test snapshots
Christopher Faylor writes: We're considering rolling a new release which fixes some of the problems which have cropped up here in the last few weeks. So, if you haven't already, we'd appreciate having people try out the latest snapshot at: http://cygwin.com/snapshots/ . cgf Seems ok after a day of use (including Emacs). Filipp -- 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: Please test snapshots
On 8/6/2012 7:37 AM, Filipp Gunbin wrote: Christopher Faylor writes: We're considering rolling a new release which fixes some of the problems which have cropped up here in the last few weeks. So, if you haven't already, we'd appreciate having people try out the latest snapshot at: http://cygwin.com/snapshots/ . cgf Seems ok after a day of use (including Emacs). I just saw a hang building Emacs (using make bootstrap). An emacs.exe process stopped and ignored SIGINT. Hitting C-z after that point didn't suspend the emacs build, but instead caused mintty to hang. The Emacs process didn't respond to signals at all, and I had to kill it manually from process explorer. signature.asc Description: OpenPGP digital signature
Re: Please test snapshots
On 8/6/2012 2:07 PM, Daniel Colascione wrote:
I just saw a hang building Emacs (using make bootstrap)
Signal handling appears to be broken. Here's a simple testcase. Run the program
and hit control-c. It'll print got Alarm clock, then stop accepting any
signals at all, even SIGSTOP. The same program works fine on my Debian stable
box.
#define _GNU_SOURCE 1
#include unistd.h
#include stdio.h
#include stdlib.h
#include signal.h
#include pthread.h
int
main()
{
sigset_t waitmask;
int sig;
sigemptyset (waitmask);
sigaddset (waitmask, SIGINT);
sigprocmask (SIG_BLOCK, waitmask, NULL);
for (;;) {
sig = sigwaitinfo (waitmask, NULL);
fprintf (stderr, got %s\n, sys_siglist[sig]);
if (sig == SIGINT) {
break;
}
}
return 0;
}
signature.asc
Description: OpenPGP digital signature
Re: Please test snapshots
On 8/6/2012 5:15 PM, Daniel Colascione wrote: On 8/6/2012 2:07 PM, Daniel Colascione wrote: I just saw a hang building Emacs (using make bootstrap) Signal handling appears to be broken. Here's a simple testcase. Run the program and hit control-c. It'll print got Alarm clock, then stop accepting any signals at all, even SIGSTOP. The same program works fine on my Debian stable box. By the way: this regression was introduced between the 2012-07-15 snapshot and the 2012-07-21 snapshot. signature.asc Description: OpenPGP digital signature
Please test snapshots
We're considering rolling a new release which fixes some of the problems which have cropped up here in the last few weeks. So, if you haven't already, we'd appreciate having people try out the latest snapshot at: http://cygwin.com/snapshots/ . 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: Please test snapshots
On 8/5/12 8:34 PM, Christopher Faylor wrote: We're considering rolling a new release which fixes some of the problems which have cropped up here in the last few weeks. So, if you haven't already, we'd appreciate having people try out the latest snapshot at: http://cygwin.com/snapshots/ . It's been working fine for me. signature.asc Description: OpenPGP digital signature
Re: please test snapshots: we'd like to release cygwin version 1.20
On Fri, Feb 24, 2006 at 06:59:50AM -0700, Eric Blake wrote: According to Christopher Faylor on 2/21/2006 6:06 PM: Please observe usual bug reporting rules when reporting on any results from testing a snapshot. I'm seeing a few regressions on Win98 with 20060220, 20060223. They are making it impossible for me to test CVS coreutils against the latest snapshot on Win98. I haven't had time to further track down where the regressions started, as I haven't otherwise used snapshots on Win98 since 1.5.19 came out. The new directory handling code had a problem on win9x. It would cause random memory corruption. The new snapshot should work better. I was able to configure and build bash with the equivalent of this snashot. Does it work any better for you, Eric? cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: please test snapshots: we'd like to release cygwin version 1.20
Eric Blake ebb9 at byu.net writes: In an effort to help the testing be easier to perform, I will soon be releasing an experimental coreutils-5.94-2 that uses the d_ino member in ls and also in /bin/pwd Now released, but it pointed out an upstream bug in coreutils - 'ls -i' currently stubbornly uses [l]stat(), even when d_ino is available. So ls is NOT (yet) a good test of the d_ino changes, after all (but it DOES remain a good test of readdir() refactoring). -- Eric Blake -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: please test snapshots: we'd like to release cygwin version 1.20
Christopher Faylor cgf-no-personal-reply-please at cygwin.com writes: Specifically, what needs testing is Corinna's new code which properly fills in d_ino into a dirent struct. I recently found that a samba bug caused strange behavior when performing an ls or a find in a directory on a samba share which had more than 128 files. In an effort to help the testing be easier to perform, I will soon be releasing an experimental coreutils-5.94-2 that uses the d_ino member in ls and also in /bin/pwd (yes, using readdir()/d_ino in pwd is less efficient than calling getpwd(), but it is a nice test of readdir). Neither coreutils-5.94-1 nor findutils-2.27-1 use d_ino at all, so while they do stress readdir, they are not very comprehensive test points of the combined readdir/d_ino changes. -- Eric Blake -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
please test snapshots: we'd like to release cygwin version 1.20
We're close to making a new cygwin release but the snapshot needs some testing. Specifically, what needs testing is Corinna's new code which properly fills in d_ino into a dirent struct. I recently found that a samba bug caused strange behavior when performing an ls or a find in a directory on a samba share which had more than 128 files. Corinna fixed the cygwin code and reported the problem upstream so samba should soon be fixed (not that we can rely on that). However, the changes required to fix this require some additional testing. So, I'd appreciate it if people would try out the latest snapshot, with an eye towards making sure that programs which use opendir/readir (find or ls are the most common examples) still work correctly on local and remote directories. http://cygwin.com/snapshots/ Please observe usual bug reporting rules when reporting on any results from testing a snapshot. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
