* Please test snapshots @ 2012-08-06 3:53 Christopher Faylor 2012-08-06 5:14 ` Daniel Colascione ` (3 more replies) 0 siblings, 4 replies; 38+ messages in thread From: Christopher Faylor @ 2012-08-06 3:53 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Please test snapshots 2012-08-06 3:53 Please test snapshots Christopher Faylor @ 2012-08-06 5:14 ` Daniel Colascione 2012-08-06 8:59 ` Achim Gratz ` (2 subsequent siblings) 3 siblings, 0 replies; 38+ messages in thread From: Daniel Colascione @ 2012-08-06 5:14 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 347 bytes --] 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. [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 235 bytes --] ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Please test snapshots 2012-08-06 3:53 Please test snapshots Christopher Faylor 2012-08-06 5:14 ` Daniel Colascione @ 2012-08-06 8:59 ` Achim Gratz 2012-08-08 13:04 ` Achim Gratz 2012-08-06 15:31 ` Filipp Gunbin 2012-08-14 19:23 ` jojelino 3 siblings, 1 reply; 38+ messages in thread From: Achim Gratz @ 2012-08-06 8:59 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Please test snapshots 2012-08-06 8:59 ` Achim Gratz @ 2012-08-08 13:04 ` Achim Gratz 2012-08-09 8:07 ` Achim Gratz 0 siblings, 1 reply; 38+ messages in thread From: Achim Gratz @ 2012-08-08 13:04 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Please test snapshots 2012-08-08 13:04 ` Achim Gratz @ 2012-08-09 8:07 ` Achim Gratz 0 siblings, 0 replies; 38+ messages in thread From: Achim Gratz @ 2012-08-09 8:07 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Please test snapshots 2012-08-06 3:53 Please test snapshots Christopher Faylor 2012-08-06 5:14 ` Daniel Colascione 2012-08-06 8:59 ` Achim Gratz @ 2012-08-06 15:31 ` Filipp Gunbin 2012-08-06 23:27 ` Daniel Colascione 2012-08-14 19:23 ` jojelino 3 siblings, 1 reply; 38+ messages in thread From: Filipp Gunbin @ 2012-08-06 15:31 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Please test snapshots 2012-08-06 15:31 ` Filipp Gunbin @ 2012-08-06 23:27 ` Daniel Colascione 2012-08-07 0:39 ` Daniel Colascione 0 siblings, 1 reply; 38+ messages in thread From: Daniel Colascione @ 2012-08-06 23:27 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 732 bytes --] 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. [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 259 bytes --] ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Please test snapshots 2012-08-06 23:27 ` Daniel Colascione @ 2012-08-07 0:39 ` Daniel Colascione 2012-08-07 0:40 ` Daniel Colascione 2012-08-08 22:17 ` Christopher Faylor 0 siblings, 2 replies; 38+ messages in thread From: Daniel Colascione @ 2012-08-07 0:39 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 862 bytes --] 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; } [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 259 bytes --] ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Please test snapshots 2012-08-07 0:39 ` Daniel Colascione @ 2012-08-07 0:40 ` Daniel Colascione 2012-08-08 22:17 ` Christopher Faylor 1 sibling, 0 replies; 38+ messages in thread From: Daniel Colascione @ 2012-08-07 0:40 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 518 bytes --] 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. [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 259 bytes --] ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Please test snapshots 2012-08-07 0:39 ` Daniel Colascione 2012-08-07 0:40 ` Daniel Colascione @ 2012-08-08 22:17 ` Christopher Faylor 2012-08-09 6:35 ` Daniel Colascione 2012-08-09 12:29 ` Achim Gratz 1 sibling, 2 replies; 38+ messages in thread From: Christopher Faylor @ 2012-08-08 22:17 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Please test snapshots 2012-08-08 22:17 ` Christopher Faylor @ 2012-08-09 6:35 ` Daniel Colascione 2012-08-09 12:29 ` Achim Gratz 1 sibling, 0 replies; 38+ messages in thread From: Daniel Colascione @ 2012-08-09 6:35 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 1071 bytes --] 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. [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 259 bytes --] ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Please test snapshots 2012-08-08 22:17 ` Christopher Faylor 2012-08-09 6:35 ` Daniel Colascione @ 2012-08-09 12:29 ` Achim Gratz 2012-08-09 14:54 ` Christopher Faylor ` (2 more replies) 1 sibling, 3 replies; 38+ messages in thread From: Achim Gratz @ 2012-08-09 12:29 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Please test snapshots 2012-08-09 12:29 ` Achim Gratz @ 2012-08-09 14:54 ` Christopher Faylor 2012-08-09 15:06 ` Achim Gratz 2012-08-09 14:59 ` Daniel Colascione 2012-08-17 9:40 ` Achim Gratz 2 siblings, 1 reply; 38+ messages in thread From: Christopher Faylor @ 2012-08-09 14:54 UTC (permalink / raw) To: cygwin On Thu, Aug 09, 2012 at 09:21:47AM +0000, 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 ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Please test snapshots 2012-08-09 14:54 ` Christopher Faylor @ 2012-08-09 15:06 ` Achim Gratz 0 siblings, 0 replies; 38+ messages in thread From: Achim Gratz @ 2012-08-09 15:06 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Please test snapshots 2012-08-09 12:29 ` Achim Gratz 2012-08-09 14:54 ` Christopher Faylor @ 2012-08-09 14:59 ` Daniel Colascione 2012-08-10 7:15 ` Achim Gratz 2012-08-17 9:40 ` Achim Gratz 2 siblings, 1 reply; 38+ messages in thread From: Daniel Colascione @ 2012-08-09 14:59 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 647 bytes --] 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. [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 235 bytes --] ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Please test snapshots 2012-08-09 14:59 ` Daniel Colascione @ 2012-08-10 7:15 ` Achim Gratz 2012-08-10 14:36 ` Christopher Faylor 0 siblings, 1 reply; 38+ messages in thread From: Achim Gratz @ 2012-08-10 7:15 UTC (permalink / raw) To: cygwin 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: ... pty0 85441 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 ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Please test snapshots 2012-08-10 7:15 ` Achim Gratz @ 2012-08-10 14:36 ` Christopher Faylor 2012-08-10 18:12 ` Achim Gratz 2012-08-14 13:45 ` Adam Dinwoodie 0 siblings, 2 replies; 38+ messages in thread From: Christopher Faylor @ 2012-08-10 14:36 UTC (permalink / raw) To: cygwin On Fri, Aug 10, 2012 at 06:31:25AM +0000, 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: > >... pty0 85441 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 ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Please test snapshots 2012-08-10 14:36 ` Christopher Faylor @ 2012-08-10 18:12 ` Achim Gratz 2012-08-10 18:34 ` Christopher Faylor 2012-08-14 13:45 ` Adam Dinwoodie 1 sibling, 1 reply; 38+ messages in thread From: Achim Gratz @ 2012-08-10 18:12 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Please test snapshots 2012-08-10 18:12 ` Achim Gratz @ 2012-08-10 18:34 ` Christopher Faylor 2012-08-10 19:08 ` Achim Gratz 0 siblings, 1 reply; 38+ messages in thread From: Christopher Faylor @ 2012-08-10 18:34 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Please test snapshots 2012-08-10 18:34 ` Christopher Faylor @ 2012-08-10 19:08 ` Achim Gratz 2012-08-10 20:24 ` Christopher Faylor 0 siblings, 1 reply; 38+ messages in thread From: Achim Gratz @ 2012-08-10 19:08 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Please test snapshots 2012-08-10 19:08 ` Achim Gratz @ 2012-08-10 20:24 ` Christopher Faylor 2012-08-10 20:37 ` Achim Gratz 0 siblings, 1 reply; 38+ messages in thread From: Christopher Faylor @ 2012-08-10 20:24 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Please test snapshots 2012-08-10 20:24 ` Christopher Faylor @ 2012-08-10 20:37 ` Achim Gratz 2012-08-10 23:31 ` Christopher Faylor 0 siblings, 1 reply; 38+ messages in thread From: Achim Gratz @ 2012-08-10 20:37 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Please test snapshots 2012-08-10 20:37 ` Achim Gratz @ 2012-08-10 23:31 ` Christopher Faylor 0 siblings, 0 replies; 38+ messages in thread From: Christopher Faylor @ 2012-08-10 23:31 UTC (permalink / raw) To: cygwin, Achim Gratz 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 ^ permalink raw reply [flat|nested] 38+ messages in thread
* RE: Please test snapshots 2012-08-10 14:36 ` Christopher Faylor 2012-08-10 18:12 ` Achim Gratz @ 2012-08-14 13:45 ` Adam Dinwoodie 2012-08-16 19:01 ` Christopher Faylor 1 sibling, 1 reply; 38+ messages in thread From: Adam Dinwoodie @ 2012-08-14 13:45 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 2159 bytes --] Christopher Faylor wrote: >On Fri, Aug 10, 2012 at 06:31:25AM +0000, 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. When I've hit this, I've been running bash inside screen inside MinTTY, which was started running with administrator permissions. I've attached cygcheck output, and am happy to keep experimenting if it'll be useful. I've not swapped to the latest snapshot yet, in case more repros with this snapshot would be useful, but I'm equally happy to change to the latest snapshot and/or the original cygwin1.dll to have a play around. Example below (the last command is just sitting there, the previous one quit immediately after ^C). Note it's still sitting there even though running `ping winston1` in a different screen at this point shows that system is now responding. ~ $ ping winston1 PING winston1.datcon.co.uk (10.236.0.21): 56 data bytes ----winston1.datcon.co.uk PING Statistics---- 3 packets transmitted, 0 packets received, 100.0% packet loss ~ $ ping winston1 PING winston1.datcon.co.uk (10.236.0.21): 56 data bytes Killing ping in Process Explorer unsurprisingly returns the bash prompt immediately. [-- Attachment #2: cygcheck.out --] [-- Type: application/octet-stream, Size: 52916 bytes --] [-- Attachment #3: Type: text/plain, Size: 218 bytes --] -- 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 ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Please test snapshots 2012-08-14 13:45 ` Adam Dinwoodie @ 2012-08-16 19:01 ` Christopher Faylor 2012-08-16 19:33 ` Ken Brown 2012-08-17 9:38 ` Adam Dinwoodie 0 siblings, 2 replies; 38+ messages in thread From: Christopher Faylor @ 2012-08-16 19:01 UTC (permalink / raw) To: cygwin On Tue, Aug 14, 2012 at 12:48:03PM +0000, Adam Dinwoodie wrote: >Christopher Faylor wrote: >>On Fri, Aug 10, 2012 at 06:31:25AM +0000, 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 ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Please test snapshots 2012-08-16 19:01 ` Christopher Faylor @ 2012-08-16 19:33 ` Ken Brown 2012-08-16 19:45 ` Christopher Faylor 2012-08-17 9:38 ` Adam Dinwoodie 1 sibling, 1 reply; 38+ messages in thread From: Ken Brown @ 2012-08-16 19:33 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 2203 bytes --] On 8/16/2012 2:37 PM, Christopher Faylor wrote: > On Tue, Aug 14, 2012 at 12:48:03PM +0000, Adam Dinwoodie wrote: >> Christopher Faylor wrote: >>> On Fri, Aug 10, 2012 at 06:31:25AM +0000, 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 [-- Attachment #2: gdb.txt --] [-- Type: text/plain, Size: 17941 bytes --] 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 0x00000000 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 0x000001b8 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 0x00000000 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 0x000001c4 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 read in psymtab, but not in symtab.) #4 0x042dac8c in ?? () No symbol table info available. #5 0x6100538d in _cygtls::call2 (this=<optimized out>, func=warning: (Internal error: pc 0x2 in read in psymtab, but not in symtab.) 0x2, arg=0x18c9908, buf=0x6100551b) at /netrel/src/cygwin-snapshot-20120816-1/winsup/cygwin/cygtls.cc:99 res = <optimized out> #6 0x042dff88 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 0x00000000 in ?? () No symbol table info available. Thread 7 (Thread 5884.0x15b0): #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 0x1e3 in read in psymtab, but not in symtab.) warning: (Internal error: pc 0x1e3 in read in psymtab, but not in symtab.) warning: (Internal error: pc 0x1e3 in read in psymtab, but not in symtab.) #3 0x000001e4 in ?? () warning: (Internal error: pc 0x1e3 in read in psymtab, but not in symtab.) No symbol table info available. warning: (Internal error: pc 0x1e3 in read in psymtab, but not in symtab.) #4 0x040dac8c in ?? () No symbol table info available. #5 0x6100538d in _cygtls::call2 (this=<optimized out>, func=warning: (Internal error: pc 0x2 in read in psymtab, but not in symtab.) 0x2, arg=0x18cae60, buf=0x6100551b) at /netrel/src/cygwin-snapshot-20120816-1/winsup/cygwin/cygtls.cc:99 res = <optimized out> #6 0x040dff88 in ?? () No symbol table info available. #7 0x74f3339a in KERNEL32!BaseCleanupAppcompatCacheSupport () from /c/windows/syswow64/kernel32.dll No symbol table info available. #8 0x018cae60 in ?? () No symbol table info available. #9 0x76f89ef2 in ntdll!RtlpNtSetValueKey () from /c/windows/SysWOW64/ntdll.dll No symbol table info available. #10 0x018cae60 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 0x00000000 in ?? () No symbol table info available. Thread 6 (Thread 5884.0x130c): #0 0x76f6f8b1 in ntdll!RtlUpdateClonedSRWLock () from /c/windows/SysWOW64/ntdll.dll No symbol table info available. #1 0x76f6f8b1 in ntdll!RtlUpdateClonedSRWLock () from /c/windows/SysWOW64/ntdll.dll No symbol table info available. #2 0x75590a91 in WaitForSingleObjectEx () from /c/windows/syswow64/KERNELBASE.dll No symbol table info available. warning: (Internal error: pc 0x31f in read in psymtab, but not in symtab.) warning: (Internal error: pc 0x31f in read in psymtab, but not in symtab.) warning: (Internal error: pc 0x31f in read in psymtab, but not in symtab.) #3 0x00000320 in ?? () warning: (Internal error: pc 0x31f in read in psymtab, but not in symtab.) No symbol table info available. warning: (Internal error: pc 0x31f in read in psymtab, but not in symtab.) #4 0x00000000 in ?? () No symbol table info available. Thread 5 (Thread 5884.0x294): #0 0x76f6f939 in ntdll!RtlUpdateClonedSRWLock () from /c/windows/SysWOW64/ntdll.dll No symbol table info available. #1 0x76f6f939 in ntdll!RtlUpdateClonedSRWLock () from /c/windows/SysWOW64/ntdll.dll No symbol table info available. #2 0x71ed635c in ?? () from /c/windows/System32/mswsock.dll No symbol table info available. #3 0x6100538d in _cygtls::call2 (this=<optimized out>, func=0x71ed62ee, arg=0x18d20a0, buf=0x6100551b) at /netrel/src/cygwin-snapshot-20120816-1/winsup/cygwin/cygtls.cc:99 res = <optimized out> #4 0x03cdff88 in ?? () No symbol table info available. #5 0x74f3339a in KERNEL32!BaseCleanupAppcompatCacheSupport () from /c/windows/syswow64/kernel32.dll No symbol table info available. #6 0x018d20a0 in ?? () No symbol table info available. #7 0x76f89ef2 in ntdll!RtlpNtSetValueKey () from /c/windows/SysWOW64/ntdll.dll No symbol table info available. #8 0x018d20a0 in ?? () No symbol table info available. #9 0x76f89ec5 in ntdll!RtlpNtSetValueKey () from /c/windows/SysWOW64/ntdll.dll No symbol table info available. #10 0x6107f110 in cygwin_inet_network () from /usr/bin/cygwin1.dll No symbol table info available. #11 0x00000000 in ?? () No symbol table info available. Thread 4 (Thread 5884.0x96c): #0 0x76f6f8b1 in ntdll!RtlUpdateClonedSRWLock () from /c/windows/SysWOW64/ntdll.dll No symbol table info available. #1 0x76f6f8b1 in ntdll!RtlUpdateClonedSRWLock () from /c/windows/SysWOW64/ntdll.dll No symbol table info available. #2 0x75590a91 in WaitForSingleObjectEx () from /c/windows/syswow64/KERNELBASE.dll No symbol table info available. warning: (Internal error: pc 0x2bb in read in psymtab, but not in symtab.) warning: (Internal error: pc 0x2bb in read in psymtab, but not in symtab.) warning: (Internal error: pc 0x2bb in read in psymtab, but not in symtab.) #3 0x000002bc in ?? () warning: (Internal error: pc 0x2bb in read in psymtab, but not in symtab.) No symbol table info available. warning: (Internal error: pc 0x2bb in read in psymtab, but not in symtab.) #4 0x00000000 in ?? () No symbol table info available. Thread 3 (Thread 5884.0xa84): #0 0x76f7013d in ntdll!RtlEnableEarlyCriticalSectionEventCreation () from /c/windows/SysWOW64/ntdll.dll No symbol table info available. #1 0x76f7013d in ntdll!RtlEnableEarlyCriticalSectionEventCreation () from /c/windows/SysWOW64/ntdll.dll No symbol table info available. #2 0x76fa2f51 in ntdll!RtlWeaklyEnumerateEntryHashTable () from /c/windows/SysWOW64/ntdll.dll No symbol table info available. warning: (Internal error: pc 0x2 in read in psymtab, but not in symtab.) warning: (Internal error: pc 0x0 in read in psymtab, but not in symtab.) warning: (Internal error: pc 0x2 in read in psymtab, but not in symtab.) warning: (Internal error: pc 0x3 in read in psymtab, but not in symtab.) warning: (Internal error: pc 0x2 in read in psymtab, but not in symtab.) warning: (Internal error: pc 0x2 in read in psymtab, but not in symtab.) #3 0x00000003 in ?? () warning: (Internal error: pc 0x2 in read in psymtab, but not in symtab.) No symbol table info available. #4 0x018cac28 in ?? () No symbol table info available. #5 0x74f3339a in KERNEL32!BaseCleanupAppcompatCacheSupport () from /c/windows/syswow64/kernel32.dll No symbol table info available. #6 0x00000000 in ?? () No symbol table info available. Thread 2 (Thread 5884.0xc28): #0 0x76f6f99e in ntdll!RtlUpdateClonedSRWLock () from /c/windows/SysWOW64/ntdll.dll No symbol table info available. #1 0x76f6f99e in ntdll!RtlUpdateClonedSRWLock () from /c/windows/SysWOW64/ntdll.dll No symbol table info available. #2 0x75593a5e in SetThreadPriority () from /c/windows/syswow64/KERNELBASE.dll No symbol table info available. #3 0x610873cd in yield () at /netrel/src/cygwin-snapshot-20120816-1/winsup/cygwin/miscfuncs.cc:252 prio = 2 #4 0x610d6714 in _cygtls::lock() () from /usr/bin/cygwin1.dll No symbol table info available. #5 0x61030124 in setup_handler (sig=14, handler=0x592ca0, siga=..., tls=0x28ce64) at /netrel/src/cygwin-snapshot-20120816-1/winsup/cygwin/exceptions.cc:836 res = <optimized out> hth = 0x80013000 i = <optimized out> cx = {ContextFlags = 0, Dr0 = 0, Dr1 = 0, Dr2 = 0, Dr3 = 0, Dr6 = 0, Dr7 = 0, FloatSave = {ControlWord = 0, StatusWord = 0, TagWord = 0, ErrorOffset = 0, ErrorSelector = 0, DataOffset = 0, DataSelector = 0, RegisterArea = '\000' <repeats 79 times>, Cr0NpxState = 0}, SegGs = 0, SegFs = 0, SegEs = 51489176, SegDs = 1627912124, Edi = 0, Esi = 2031619, Ebx = 51489116, Edx = 1, Ecx = 0, Eax = 0, Ebp = 0, Eip = 0, SegCs = 0, EFlags = 0, Esp = 0, SegSs = 0, ExtendedRegisters = '\000' <repeats 12 times>, "\030", '\000' <repeats 31 times>"\340, ", '\000' <repeats 20 times>"\244, \030a\000\000\000\000È«\021\003^\370\aaL\310\031a", '\000' <repeats 152 times>"\320, \b'a\016\000\000\000\320\b'a\320\b'a\261=\000at\330(\000\016", '\000' <repeats 31 times>, "t\252\021\003\320\b'al\243\030a\000\000\000\000\016\000\000\000d\316(\000\001\000\000\000P\252\021\003\302<\000a+\000S\000+\000+\000T\377\021\003", '\000' <repeats 120 times>"\345, \370\366vH\323Xu\240", '\000' <repeats 15 times>, "`\253\021\003\004\254\021\003\244", '\000' <repeats 18 times>} interrupted = false __PRETTY_FUNCTION__ = "int setup_handler(int, void*, sigaction&, _cygtls*)" #6 0x61030d77 in sigpacket::process (this=0x311ac04) at /netrel/src/cygwin-snapshot-20120816-1/winsup/cygwin/exceptions.cc:1239 continue_now = <optimized out> __PRETTY_FUNCTION__ = "int sigpacket::process()" thissig = @0x61272bd0: {{sa_handler = 0x592ca0 <alarm_signal_handler>, sa_sigaction = 0x592ca0 <alarm_signal_handler>}, sa_mask = 8192, sa_flags = 0} dummy = {{sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, sa_flags = 1342177280} rc = 1 handler = <optimized out> #7 0x610dd1c7 in wait_sig () at /netrel/src/cygwin-snapshot-20120816-1/winsup/cygwin/sigproc.cc:1439 sigres = <optimized out> sig = 14 bit = <optimized out> nb = 164 dummy_mask = 0 clearwait = false __PRETTY_FUNCTION__ = "void wait_sig(void*)" pack = {si = {si_signo = 14, si_code = 4, si_pid = 4764, si_uid = 1001, si_errno = 0, {__pad = {1629095104, 0 <repeats 31 times>}, _si_commune = {_si_code = 1629095104, _si_read_handle = 0x0, _si_write_handle = 0x0, _si_process_handle = 0x0, {_si_fd = 0, _si_pipe_fhandler = 0x0, _si_str = 0x0}}, {{{{ si_tid = 1629095104, si_overrun = 0}, si_sigval = { sival_int = 1629095104, sival_ptr = 0x611a04c0}, si_value = {sival_int = 1629095104, sival_ptr = 0x611a04c0}}}}, {si_status = 1629095104, si_utime = 0, si_stime = 0}, si_addr = 0x611a04c0}}, pid = 4764, tls = 0x28ce64, mask = 0x28d874, {wakeup = 0x0, thread_handle = 0x0, next = 0x0}} #8 0x61003e65 in cygthread::callfunc (this=0x6118a400, issimplestub=<optimized out>) at /netrel/src/cygwin-snapshot-20120816-1/winsup/cygwin/cygthread.cc:51 pass_arg = 0x6118a400 #9 0x61004401 in cygthread::stub (arg=0x6118a400) at /netrel/src/cygwin-snapshot-20120816-1/winsup/cygwin/cygthread.cc:99 notify = <optimized out> info = 0x6118a400 __PRETTY_FUNCTION__ = "static DWORD cygthread::stub(void*)" #10 0x6100538d in _cygtls::call2 (this=<optimized out>, func=0x610043a0 <cygthread::stub(void*)>, arg=0x6118a400, buf=0x6100551b) at /netrel/src/cygwin-snapshot-20120816-1/winsup/cygwin/cygtls.cc:99 res = <optimized out> #11 0x0311ff88 in ?? () No symbol table info available. #12 0x74f3339a in KERNEL32!BaseCleanupAppcompatCacheSupport () from /c/windows/syswow64/kernel32.dll No symbol table info available. #13 0x6118a400 in cygthread::exiting () from /usr/bin/cygwin1.dll No symbol table info available. #14 0x0311ffd4 in ?? () No symbol table info available. #15 0x76f89ef2 in ntdll!RtlpNtSetValueKey () from /c/windows/SysWOW64/ntdll.dll No symbol table info available. #16 0x6118a400 in cygthread::exiting () from /usr/bin/cygwin1.dll No symbol table info available. #17 0x7409eb34 in ?? () No symbol table info available. #18 0x00000000 in ?? () No symbol table info available. Thread 1 (Thread 5884.0xcfc): #0 0x7559317a in SleepEx () from /c/windows/syswow64/KERNELBASE.dll No symbol table info available. #1 0x1d044b61 in ?? () No symbol table info available. #2 0x00005d00 in ?? () No symbol table info available. #3 0x8024d110 in ?? () No symbol table info available. #4 0x610873a2 in yield () at /netrel/src/cygwin-snapshot-20120816-1/winsup/cygwin/miscfuncs.cc:250 i = 0 prio = 0 #5 0x610d65fc in _sigfe () from /usr/bin/cygwin1.dll No symbol table info available. #6 0x61083180 in reallocf () at /netrel/src/cygwin-snapshot-20120816-1/winsup/cygwin/malloc_wrapper.cc:96 No symbol table info available. warning: (Internal error: pc 0x0 in read in psymtab, but not in symtab.) warning: (Internal error: pc 0x0 in read in psymtab, but not in symtab.) warning: (Internal error: pc 0x0 in read in psymtab, but not in symtab.) warning: (Internal error: pc 0x1 in read in psymtab, but not in symtab.) warning: (Internal error: pc 0x0 in read in psymtab, but not in symtab.) warning: (Internal error: pc 0x0 in read in psymtab, but not in symtab.) #7 0x00000001 in ?? () warning: (Internal error: pc 0x0 in read in psymtab, but not in symtab.) No symbol table info available. warning: (Internal error: pc 0x1f in read in psymtab, but not in symtab.) warning: (Internal error: pc 0x0 in read in psymtab, but not in symtab.) warning: (Internal error: pc 0x1f in read in psymtab, but not in symtab.) warning: (Internal error: pc 0x20 in read in psymtab, but not in symtab.) warning: (Internal error: pc 0x1f in read in psymtab, but not in symtab.) warning: (Internal error: pc 0x1f in read in psymtab, but not in symtab.) #8 0x00000020 in ?? () warning: (Internal error: pc 0x1f in read in psymtab, but not in symtab.) No symbol table info available. warning: (Internal error: pc 0xf in read in psymtab, but not in symtab.) warning: (Internal error: pc 0x0 in read in psymtab, but not in symtab.) warning: (Internal error: pc 0xf in read in psymtab, but not in symtab.) warning: (Internal error: pc 0x10 in read in psymtab, but not in symtab.) warning: (Internal error: pc 0xf in read in psymtab, but not in symtab.) warning: (Internal error: pc 0xf in read in psymtab, but not in symtab.) #9 0x00000010 in ?? () warning: (Internal error: pc 0xf in read in psymtab, but not in symtab.) No symbol table info available. #10 0x00005d00 in ?? () No symbol table info available. #11 0x00000000 in ?? () No symbol table info available. A debugging session is active. Inferior 1 [process 5884] will be detached. Quit anyway? (y or n) Detaching from program: /usr/bin/emacs-X11.exe, Pid 5884 [-- Attachment #3: Type: text/plain, Size: 218 bytes --] -- 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 ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Please test snapshots 2012-08-16 19:33 ` Ken Brown @ 2012-08-16 19:45 ` Christopher Faylor 2012-08-16 20:11 ` Ken Brown 0 siblings, 1 reply; 38+ messages in thread From: Christopher Faylor @ 2012-08-16 19:45 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Please test snapshots 2012-08-16 19:45 ` Christopher Faylor @ 2012-08-16 20:11 ` Ken Brown 0 siblings, 0 replies; 38+ messages in thread From: Ken Brown @ 2012-08-16 20:11 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 38+ messages in thread
* RE: Please test snapshots 2012-08-16 19:01 ` Christopher Faylor 2012-08-16 19:33 ` Ken Brown @ 2012-08-17 9:38 ` Adam Dinwoodie 2012-08-17 14:37 ` Christopher Faylor 1 sibling, 1 reply; 38+ messages in thread From: Adam Dinwoodie @ 2012-08-17 9:38 UTC (permalink / raw) To: cygwin Christopher Faylor wrote: > On Tue, Aug 14, 2012 at 12:48:03PM +0000, 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 ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Please test snapshots 2012-08-17 9:38 ` Adam Dinwoodie @ 2012-08-17 14:37 ` Christopher Faylor 2012-08-17 17:46 ` Adam Dinwoodie 2012-08-17 19:32 ` Achim Gratz 0 siblings, 2 replies; 38+ messages in thread From: Christopher Faylor @ 2012-08-17 14:37 UTC (permalink / raw) To: cygwin On Fri, Aug 17, 2012 at 09:07:30AM +0000, Adam Dinwoodie wrote: >Christopher Faylor wrote: >> On Tue, Aug 14, 2012 at 12:48:03PM +0000, 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 ^ permalink raw reply [flat|nested] 38+ messages in thread
* RE: Please test snapshots 2012-08-17 14:37 ` Christopher Faylor @ 2012-08-17 17:46 ` Adam Dinwoodie 2012-08-17 18:08 ` Christopher Faylor 2012-08-17 19:32 ` Achim Gratz 1 sibling, 1 reply; 38+ messages in thread From: Adam Dinwoodie @ 2012-08-17 17:46 UTC (permalink / raw) To: cygwin Christopher Faylor wrote > On Fri, Aug 17, 2012 at 09:07:30AM +0000, 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 Version Status 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 ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Please test snapshots 2012-08-17 17:46 ` Adam Dinwoodie @ 2012-08-17 18:08 ` Christopher Faylor 0 siblings, 0 replies; 38+ messages in thread From: Christopher Faylor @ 2012-08-17 18:08 UTC (permalink / raw) To: cygwin On Fri, Aug 17, 2012 at 03:50:05PM +0000, Adam Dinwoodie wrote: >Christopher Faylor wrote >> On Fri, Aug 17, 2012 at 09:07:30AM +0000, 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 ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Please test snapshots 2012-08-17 14:37 ` Christopher Faylor 2012-08-17 17:46 ` Adam Dinwoodie @ 2012-08-17 19:32 ` Achim Gratz 1 sibling, 0 replies; 38+ messages in thread From: Achim Gratz @ 2012-08-17 19:32 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Please test snapshots 2012-08-09 12:29 ` Achim Gratz 2012-08-09 14:54 ` Christopher Faylor 2012-08-09 14:59 ` Daniel Colascione @ 2012-08-17 9:40 ` Achim Gratz 2012-08-17 10:47 ` Achim Gratz 2 siblings, 1 reply; 38+ messages in thread From: Achim Gratz @ 2012-08-17 9:40 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Please test snapshots 2012-08-17 9:40 ` Achim Gratz @ 2012-08-17 10:47 ` Achim Gratz 0 siblings, 0 replies; 38+ messages in thread From: Achim Gratz @ 2012-08-17 10:47 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Please test snapshots 2012-08-06 3:53 Please test snapshots Christopher Faylor ` (2 preceding siblings ...) 2012-08-06 15:31 ` Filipp Gunbin @ 2012-08-14 19:23 ` jojelino 2012-08-14 19:41 ` Corinna Vinschen 3 siblings, 1 reply; 38+ messages in thread From: jojelino @ 2012-08-14 19:23 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Please test snapshots 2012-08-14 19:23 ` jojelino @ 2012-08-14 19:41 ` Corinna Vinschen 2012-08-14 19:42 ` Christopher Faylor 0 siblings, 1 reply; 38+ messages in thread From: Corinna Vinschen @ 2012-08-14 19:41 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Please test snapshots 2012-08-14 19:41 ` Corinna Vinschen @ 2012-08-14 19:42 ` Christopher Faylor 0 siblings, 0 replies; 38+ messages in thread From: Christopher Faylor @ 2012-08-14 19:42 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 38+ messages in thread
end of thread, other threads:[~2012-08-17 18:15 UTC | newest] Thread overview: 38+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2012-08-06 3:53 Please test snapshots Christopher Faylor 2012-08-06 5:14 ` Daniel Colascione 2012-08-06 8:59 ` Achim Gratz 2012-08-08 13:04 ` Achim Gratz 2012-08-09 8:07 ` Achim Gratz 2012-08-06 15:31 ` Filipp Gunbin 2012-08-06 23:27 ` Daniel Colascione 2012-08-07 0:39 ` Daniel Colascione 2012-08-07 0:40 ` Daniel Colascione 2012-08-08 22:17 ` Christopher Faylor 2012-08-09 6:35 ` Daniel Colascione 2012-08-09 12:29 ` Achim Gratz 2012-08-09 14:54 ` Christopher Faylor 2012-08-09 15:06 ` Achim Gratz 2012-08-09 14:59 ` Daniel Colascione 2012-08-10 7:15 ` Achim Gratz 2012-08-10 14:36 ` Christopher Faylor 2012-08-10 18:12 ` Achim Gratz 2012-08-10 18:34 ` Christopher Faylor 2012-08-10 19:08 ` Achim Gratz 2012-08-10 20:24 ` Christopher Faylor 2012-08-10 20:37 ` Achim Gratz 2012-08-10 23:31 ` Christopher Faylor 2012-08-14 13:45 ` Adam Dinwoodie 2012-08-16 19:01 ` Christopher Faylor 2012-08-16 19:33 ` Ken Brown 2012-08-16 19:45 ` Christopher Faylor 2012-08-16 20:11 ` Ken Brown 2012-08-17 9:38 ` Adam Dinwoodie 2012-08-17 14:37 ` Christopher Faylor 2012-08-17 17:46 ` Adam Dinwoodie 2012-08-17 18:08 ` Christopher Faylor 2012-08-17 19:32 ` Achim Gratz 2012-08-17 9:40 ` Achim Gratz 2012-08-17 10:47 ` Achim Gratz 2012-08-14 19:23 ` jojelino 2012-08-14 19:41 ` Corinna Vinschen 2012-08-14 19:42 ` Christopher Faylor
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).