Re: [ANNOUNCEMENT] TEST: Cygwin 3.1.0-0.1
On Aug 18 16:29, Achim Gratz wrote: > Corinna Vinschen writes: > > There's no xlocale.h on Linux either. What do these packages do in > > that case? > > I've dug a little bit deeper. The trouble is that perl.h has picked up > xlocale.h as the location of some of the interfaces it wants to use > during configuration, so that means you can't compile any XS modules > after the update to 3.1.0 anymore. We discussed this on IRC. Bottom line is that perl.h should not have picked up xlocale.h in the first place. This requires some new perl packages. Corinna -- Corinna Vinschen Cygwin Maintainer signature.asc Description: PGP signature
Re: [ANNOUNCEMENT] TEST: Cygwin 3.1.0-0.1
Corinna Vinschen writes: > There's no xlocale.h on Linux either. What do these packages do in > that case? I've dug a little bit deeper. The trouble is that perl.h has picked up xlocale.h as the location of some of the interfaces it wants to use during configuration, so that means you can't compile any XS modules after the update to 3.1.0 anymore. 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: [ANNOUNCEMENT] TEST: Cygwin 3.1.0-0.1
On Aug 18 14:06, Achim Gratz wrote: > Corinna Vinschen writes: > > - Eliminate a header file name collision with on case > > insensitive filesystems by reverting back to . > > What's the suggested way to deal with software that expects to be able > to "#include "? I think I'll see that more often than X11 > applications that have their include directives set up wrongly. There's no xlocale.h on Linux either. What do these packages do in that case? Corinna -- Corinna Vinschen Cygwin Maintainer signature.asc Description: PGP signature
Re: [ANNOUNCEMENT] TEST: Cygwin 3.1.0-0.1
Corinna Vinschen writes: > - Eliminate a header file name collision with on case > insensitive filesystems by reverting back to . What's the suggested way to deal with software that expects to be able to "#include "? I think I'll see that more often than X11 applications that have their include directives set up wrongly. I guess I could make a symlink, but that's iffy. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf rackAttack: 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: [ANNOUNCEMENT] TEST: Cygwin 3.1.0-0.1
On Aug 18 01:43, Takashi Yano wrote: > Hi Corinna, > > On Fri, 16 Aug 2019 16:48:11 +0200 > Corinna Vinschen wrote: > > I now had an idea, but I'm not entirely sure if it's the right thing to > > do. Can you please test this? It consists of two patches, one with the > > revamped signalfd handling, and one with the revert of the signalfd > > patch I applied a couple of days ago. > > > > Quick description: I dropped signalfd_select_wait entirely. Instead, > > wait_sig sets or resets a manual event object to indicate if there are > > signals pending in the queue, even after trying to handle them the > > normal way. That usually means they are blocked. > > > > select() uses the event to wake up from WFMO, if at least one signalfd > > is present in the read descriptor set. The rest is done via the peek > > and verify functions in select, which basically just check if this > > signalfd is waiting for one of the pending signals. > > > > The reversion of my patch from a couple days ago is not required as > > such, but after thinking about this a while I'm convinced that this was > > just me not getting the full picture. Also, reverting this patch would > > revert to seeing a SEGV in your testcase and thus a bug in the new code, > > too. > > > > I attached both patches. It would be pretty nice if you could test them > > and point out any problems you get with this new code. > > > > Please note that you should ideally perform a full rebuild due to the > > slight change in TLS layout. > > I confirmed that my STC and script command works as expected with these > patches. > > Thank you for greate work! Great, thank you, and thanks for testing! Corinna -- Corinna Vinschen Cygwin Maintainer signature.asc Description: PGP signature
Re: [ANNOUNCEMENT] TEST: Cygwin 3.1.0-0.1
Hi Corinna, On Fri, 16 Aug 2019 16:48:11 +0200 Corinna Vinschen wrote: > I now had an idea, but I'm not entirely sure if it's the right thing to > do. Can you please test this? It consists of two patches, one with the > revamped signalfd handling, and one with the revert of the signalfd > patch I applied a couple of days ago. > > Quick description: I dropped signalfd_select_wait entirely. Instead, > wait_sig sets or resets a manual event object to indicate if there are > signals pending in the queue, even after trying to handle them the > normal way. That usually means they are blocked. > > select() uses the event to wake up from WFMO, if at least one signalfd > is present in the read descriptor set. The rest is done via the peek > and verify functions in select, which basically just check if this > signalfd is waiting for one of the pending signals. > > The reversion of my patch from a couple days ago is not required as > such, but after thinking about this a while I'm convinced that this was > just me not getting the full picture. Also, reverting this patch would > revert to seeing a SEGV in your testcase and thus a bug in the new code, > too. > > I attached both patches. It would be pretty nice if you could test them > and point out any problems you get with this new code. > > Please note that you should ideally perform a full rebuild due to the > slight change in TLS layout. I confirmed that my STC and script command works as expected with these patches. Thank you for greate work! -- Takashi Yano -- 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: [ANNOUNCEMENT] TEST: Cygwin 3.1.0-0.1
Hi Takashi, On Aug 15 17:09, Corinna Vinschen wrote: > On Aug 15 17:04, Corinna Vinschen wrote: > > On Aug 15 12:36, Corinna Vinschen wrote: > > > On Aug 15 09:49, Corinna Vinschen wrote: > > > > On Aug 15 04:21, Takashi Yano wrote: > > > > > On Wed, 14 Aug 2019 15:49:00 +0200 > > > > > Corinna Vinschen wrote: > > > > > > The only reason I can see is if sigwait_common() returns EINTR > > > > > > because > > > > > > it was interrupted by an unrelated signal. This in turn lets the > > > > > > read() > > > > > > call fail with EINTR and that should be expected by the callers, in > > > > > > theory. > > > > > > > > > > Strangely, this problem also disappears with this patch. > > > > > > > > > > diff --git a/winsup/cygwin/select.cc b/winsup/cygwin/select.cc > > > > > index 9cf892801..82ac0674f 100644 > > > > > --- a/winsup/cygwin/select.cc > > > > > +++ b/winsup/cygwin/select.cc > > > > > @@ -1869,7 +1869,7 @@ thread_signalfd (void *arg) > > > > >switch (WaitForSingleObject (si->evt, INFINITE)) > > > > > { > > > > > case WAIT_OBJECT_0: > > > > > - tls->signalfd_select_wait = NULL; > > > > > + //tls->signalfd_select_wait = NULL; > > > > > event = true; > > > > > break; > > > > > default: > > > > > > > > The problem with not setting signalfd_select_wait to NULL here is that > > > > only a subsequent read or sigwaitinfo will do, so there's a time > > > > post-select which will reroute the signal wrongly. > > > > > > Worse, thread_signalfd() closes the handle on exit, so keeping > > > signalfd_select_wait set may result in strange behaviour after select > > > returns. > > > > > > > Any ideas greatly appreciated. > > [...] I now had an idea, but I'm not entirely sure if it's the right thing to do. Can you please test this? It consists of two patches, one with the revamped signalfd handling, and one with the revert of the signalfd patch I applied a couple of days ago. Quick description: I dropped signalfd_select_wait entirely. Instead, wait_sig sets or resets a manual event object to indicate if there are signals pending in the queue, even after trying to handle them the normal way. That usually means they are blocked. select() uses the event to wake up from WFMO, if at least one signalfd is present in the read descriptor set. The rest is done via the peek and verify functions in select, which basically just check if this signalfd is waiting for one of the pending signals. The reversion of my patch from a couple days ago is not required as such, but after thinking about this a while I'm convinced that this was just me not getting the full picture. Also, reverting this patch would revert to seeing a SEGV in your testcase and thus a bug in the new code, too. I attached both patches. It would be pretty nice if you could test them and point out any problems you get with this new code. Please note that you should ideally perform a full rebuild due to the slight change in TLS layout. Thanks a lot, Corinna -- Corinna Vinschen Cygwin Maintainer From 0169458101d1c9e915f842a765a9afe4ee69867e Mon Sep 17 00:00:00 2001 From: Corinna Vinschen Date: Fri, 16 Aug 2019 16:36:06 +0200 Subject: [PATCH 1/2] Cygwin: select: revamp non-polling code for signalfd Rather than waiting for signalfd_select_wait in a thread, which is racy, create a global event "my_pendingsigs_evt" which is set and reset by wait_sig depending on the fact if signals are pending because they are blocked and no thread cares. This in turn allows to WFMO on this event in select as soon as signalfds are present in the read descriptor set, and the peek and verify functionality will then check if one of the present signalfds is affected. Signed-off-by: Corinna Vinschen --- winsup/cygwin/cygtls.h | 2 +- winsup/cygwin/exceptions.cc | 8 winsup/cygwin/select.cc | 80 ++-- winsup/cygwin/select.h | 11 + winsup/cygwin/signal.cc | 1 - winsup/cygwin/sigproc.cc | 17 winsup/cygwin/tlsoffsets.h | 16 winsup/cygwin/tlsoffsets64.h | 16 8 files changed, 40 insertions(+), 111 deletions(-) diff --git a/winsup/cygwin/cygtls.h b/winsup/cygwin/cygtls.h index 65a905c32078..a2e3676fc722 100644 --- a/winsup/cygwin/cygtls.h +++ b/winsup/cygwin/cygtls.h @@ -189,8 +189,8 @@ public: stack_t altstack; siginfo_t *sigwait_info; HANDLE signal_arrived; - HANDLE signalfd_select_wait; bool will_wait_for_signal; + long __align;/* Needed to align context to 16 byte. */ /* context MUST be aligned to 16 byte, otherwise RtlCaptureContext fails. If you prepend cygtls members here, make sure context stays 16 byte aligned. */ diff --git a/winsup/cygwin/exceptions.cc b/winsup/cygwin/exceptions.cc index 9bdf9f054c0a..f35411e3bb0e 100644 --- a/winsup/cygwin/exceptions.cc +++ b/winsup/cygwin/exceptions.cc @@ -1469,14 +1469,6 @@ sigpacket::process () if (iss
Re: [ANNOUNCEMENT] TEST: Cygwin 3.1.0-0.1
On Aug 15 17:04, Corinna Vinschen wrote: > On Aug 15 12:36, Corinna Vinschen wrote: > > On Aug 15 09:49, Corinna Vinschen wrote: > > > On Aug 15 04:21, Takashi Yano wrote: > > > > On Wed, 14 Aug 2019 15:49:00 +0200 > > > > Corinna Vinschen wrote: > > > > > The only reason I can see is if sigwait_common() returns EINTR because > > > > > it was interrupted by an unrelated signal. This in turn lets the > > > > > read() > > > > > call fail with EINTR and that should be expected by the callers, in > > > > > theory. > > > > > > > > Strangely, this problem also disappears with this patch. > > > > > > > > diff --git a/winsup/cygwin/select.cc b/winsup/cygwin/select.cc > > > > index 9cf892801..82ac0674f 100644 > > > > --- a/winsup/cygwin/select.cc > > > > +++ b/winsup/cygwin/select.cc > > > > @@ -1869,7 +1869,7 @@ thread_signalfd (void *arg) > > > >switch (WaitForSingleObject (si->evt, INFINITE)) > > > > { > > > > case WAIT_OBJECT_0: > > > > - tls->signalfd_select_wait = NULL; > > > > + //tls->signalfd_select_wait = NULL; > > > > event = true; > > > > break; > > > > default: > > > > > > The problem with not setting signalfd_select_wait to NULL here is that > > > only a subsequent read or sigwaitinfo will do, so there's a time > > > post-select which will reroute the signal wrongly. > > > > Worse, thread_signalfd() closes the handle on exit, so keeping > > signalfd_select_wait set may result in strange behaviour after select > > returns. > > > > > Any ideas greatly appreciated. > > Here's a vague idea: > > Right now, signalfd_select_wait is not only used to signal select/poll, > but also to keep the signal in the queue for the next call to read. > This read call then calls sigwait_common under the hood. > > Afaics, the problem here is that the signal is still in the queue > even after it has been, basically, assigned to the signalfd. Because > of that, any subsequent signal dispatch trigger will fire, in the above > case select's own signal handling. > > My (really still vague) idea would be to remove the signalfd_select_wait > code and call sigwait_common from select instead. If it catched a > signal, the signal will have been dequeued, as usual. However, the > select thread function thread_signalfd() would just call sigwait_common, > too, then create a signalfd_siginfo record which gets assigned to the > signalfd fhandler. The read function would check if the record is > valid and return that as first record in the read buffer, and only > then it would fall back to sigwait_common calls itself. > > Does that sound feasible? Reply to self: Not really because calling sigwait_common from the thread_signalfd() function will run in the wrong thread with the wrong tls. Bummer again. Corinna -- Corinna Vinschen Cygwin Maintainer signature.asc Description: PGP signature
Re: [ANNOUNCEMENT] TEST: Cygwin 3.1.0-0.1
On Aug 15 12:36, Corinna Vinschen wrote: > On Aug 15 09:49, Corinna Vinschen wrote: > > On Aug 15 04:21, Takashi Yano wrote: > > > On Wed, 14 Aug 2019 15:49:00 +0200 > > > Corinna Vinschen wrote: > > > > The only reason I can see is if sigwait_common() returns EINTR because > > > > it was interrupted by an unrelated signal. This in turn lets the read() > > > > call fail with EINTR and that should be expected by the callers, in > > > > theory. > > > > > > Strangely, this problem also disappears with this patch. > > > > > > diff --git a/winsup/cygwin/select.cc b/winsup/cygwin/select.cc > > > index 9cf892801..82ac0674f 100644 > > > --- a/winsup/cygwin/select.cc > > > +++ b/winsup/cygwin/select.cc > > > @@ -1869,7 +1869,7 @@ thread_signalfd (void *arg) > > >switch (WaitForSingleObject (si->evt, INFINITE)) > > > { > > > case WAIT_OBJECT_0: > > > - tls->signalfd_select_wait = NULL; > > > + //tls->signalfd_select_wait = NULL; > > > event = true; > > > break; > > > default: > > > > The problem with not setting signalfd_select_wait to NULL here is that > > only a subsequent read or sigwaitinfo will do, so there's a time > > post-select which will reroute the signal wrongly. > > Worse, thread_signalfd() closes the handle on exit, so keeping > signalfd_select_wait set may result in strange behaviour after select > returns. > > > Any ideas greatly appreciated. Here's a vague idea: Right now, signalfd_select_wait is not only used to signal select/poll, but also to keep the signal in the queue for the next call to read. This read call then calls sigwait_common under the hood. Afaics, the problem here is that the signal is still in the queue even after it has been, basically, assigned to the signalfd. Because of that, any subsequent signal dispatch trigger will fire, in the above case select's own signal handling. My (really still vague) idea would be to remove the signalfd_select_wait code and call sigwait_common from select instead. If it catched a signal, the signal will have been dequeued, as usual. However, the select thread function thread_signalfd() would just call sigwait_common, too, then create a signalfd_siginfo record which gets assigned to the signalfd fhandler. The read function would check if the record is valid and return that as first record in the read buffer, and only then it would fall back to sigwait_common calls itself. Does that sound feasible? Corinna -- Corinna Vinschen Cygwin Maintainer signature.asc Description: PGP signature
Re: [ANNOUNCEMENT] TEST: Cygwin 3.1.0-0.1
On Aug 15 09:49, Corinna Vinschen wrote: > On Aug 15 04:21, Takashi Yano wrote: > > On Wed, 14 Aug 2019 15:49:00 +0200 > > Corinna Vinschen wrote: > > > The only reason I can see is if sigwait_common() returns EINTR because > > > it was interrupted by an unrelated signal. This in turn lets the read() > > > call fail with EINTR and that should be expected by the callers, in > > > theory. > > > > Strangely, this problem also disappears with this patch. > > > > diff --git a/winsup/cygwin/select.cc b/winsup/cygwin/select.cc > > index 9cf892801..82ac0674f 100644 > > --- a/winsup/cygwin/select.cc > > +++ b/winsup/cygwin/select.cc > > @@ -1869,7 +1869,7 @@ thread_signalfd (void *arg) > >switch (WaitForSingleObject (si->evt, INFINITE)) > > { > > case WAIT_OBJECT_0: > > - tls->signalfd_select_wait = NULL; > > + //tls->signalfd_select_wait = NULL; > > event = true; > > break; > > default: > > The problem with not setting signalfd_select_wait to NULL here is that > only a subsequent read or sigwaitinfo will do, so there's a time > post-select which will reroute the signal wrongly. Worse, thread_signalfd() closes the handle on exit, so keeping signalfd_select_wait set may result in strange behaviour after select returns. > Any ideas greatly appreciated. Corinna -- Corinna Vinschen Cygwin Maintainer signature.asc Description: PGP signature
Re: [ANNOUNCEMENT] TEST: Cygwin 3.1.0-0.1
On Aug 15 04:21, Takashi Yano wrote: > On Wed, 14 Aug 2019 15:49:00 +0200 > Corinna Vinschen wrote: > > The only reason I can see is if sigwait_common() returns EINTR because > > it was interrupted by an unrelated signal. This in turn lets the read() > > call fail with EINTR and that should be expected by the callers, in > > theory. > > Strangely, this problem also disappears with this patch. > > diff --git a/winsup/cygwin/select.cc b/winsup/cygwin/select.cc > index 9cf892801..82ac0674f 100644 > --- a/winsup/cygwin/select.cc > +++ b/winsup/cygwin/select.cc > @@ -1869,7 +1869,7 @@ thread_signalfd (void *arg) >switch (WaitForSingleObject (si->evt, INFINITE)) > { > case WAIT_OBJECT_0: > - tls->signalfd_select_wait = NULL; > + //tls->signalfd_select_wait = NULL; > event = true; > break; > default: The problem with not setting signalfd_select_wait to NULL here is that only a subsequent read or sigwaitinfo will do, so there's a time post-select which will reroute the signal wrongly. > Moreover, this EINTR is not set by sigwait_common() but set by > select_stuff::wait(). > > With following debug print, the message shows: > 1 [main] script 1082 select_stuff::wait: signal = 20 > script: poll failed: Interrupted system call > Script done, file is typescript > > however, the signal 20 (SIGCHLD) is registered to signalfd by > script and should be caught. > > diff --git a/winsup/cygwin/select.cc b/winsup/cygwin/select.cc > index 9cf892801..adcc75ad3 100644 > --- a/winsup/cygwin/select.cc > +++ b/winsup/cygwin/select.cc > @@ -446,6 +446,7 @@ next_while:; > unconditionally, ignoring any SA_RESTART detection by > call_signal_handler(). */ >_my_tls.call_signal_handler (); > + system_printf ("signal = %d\n", _my_tls.infodata.si_signo); >set_sig_errno (EINTR); >res = select_signalled; /* Cause loop exit in cygwin_select */ >break; So the signal is then caught in the wrong spot. Bummer. Perhas the entire signalfd_select_wait idea was flawed from the beginning. I guess the signalfd implementation needs a restart, but I only have a week left before I'll be mostly abroad for a couple of weeks. Any ideas greatly appreciated. Corinna -- Corinna Vinschen Cygwin Maintainer signature.asc Description: PGP signature
Re: [ANNOUNCEMENT] TEST: Cygwin 3.1.0-0.1
On Wed, 14 Aug 2019 15:49:00 +0200 Corinna Vinschen wrote: > The only reason I can see is if sigwait_common() returns EINTR because > it was interrupted by an unrelated signal. This in turn lets the read() > call fail with EINTR and that should be expected by the callers, in > theory. Strangely, this problem also disappears with this patch. diff --git a/winsup/cygwin/select.cc b/winsup/cygwin/select.cc index 9cf892801..82ac0674f 100644 --- a/winsup/cygwin/select.cc +++ b/winsup/cygwin/select.cc @@ -1869,7 +1869,7 @@ thread_signalfd (void *arg) switch (WaitForSingleObject (si->evt, INFINITE)) { case WAIT_OBJECT_0: - tls->signalfd_select_wait = NULL; + //tls->signalfd_select_wait = NULL; event = true; break; default: Moreover, this EINTR is not set by sigwait_common() but set by select_stuff::wait(). With following debug print, the message shows: 1 [main] script 1082 select_stuff::wait: signal = 20 script: poll failed: Interrupted system call Script done, file is typescript however, the signal 20 (SIGCHLD) is registered to signalfd by script and should be caught. diff --git a/winsup/cygwin/select.cc b/winsup/cygwin/select.cc index 9cf892801..adcc75ad3 100644 --- a/winsup/cygwin/select.cc +++ b/winsup/cygwin/select.cc @@ -446,6 +446,7 @@ next_while:; unconditionally, ignoring any SA_RESTART detection by call_signal_handler(). */ _my_tls.call_signal_handler (); + system_printf ("signal = %d\n", _my_tls.infodata.si_signo); set_sig_errno (EINTR); res = select_signalled; /* Cause loop exit in cygwin_select */ break; -- Takashi Yano -- 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: [ANNOUNCEMENT] TEST: Cygwin 3.1.0-0.1
On Aug 14 20:47, Takashi Yano wrote: > On Wed, 14 Aug 2019 20:41:00 +0900 > Takashi Yano wrote: > > Hi Corinna, > > > > On Tue, 13 Aug 2019 12:47:53 +0200 > > Corinna Vinschen wrote: > > > I created a patch which *seems* to do the right thing. I'm not > > > yet sure it's the best solution, but it seems to do the trick, at > > > least. > > > > > > I'm just creating new developer snapshots, please try. I'll > > > create another test release later this week. > > > > I confirmed the STC works as expected. Thank you. > > > > However, it seems that signalfd still has a problem. > > > > If script command (from util-linux) is terminated by '^D', > > the following error message is sometimes shown. > > > > script: poll failed: Interrupted system call > > > > I have confirmed this in 32bit cygwin with bash as login shell. > > This rarely occurs in real machine, however, often occurs in > > virtual machine in VirtualBox. > > Sorry, I forgot to mention important thing. > > This occurs only in cygwin on command prompt. Not in mintty. The only reason I can see is if sigwait_common() returns EINTR because it was interrupted by an unrelated signal. This in turn lets the read() call fail with EINTR and that should be expected by the callers, in theory. Corinna -- Corinna Vinschen Cygwin Maintainer signature.asc Description: PGP signature
Re: [ANNOUNCEMENT] TEST: Cygwin 3.1.0-0.1
On Wed, 14 Aug 2019 20:41:00 +0900 Takashi Yano wrote: > Hi Corinna, > > On Tue, 13 Aug 2019 12:47:53 +0200 > Corinna Vinschen wrote: > > I created a patch which *seems* to do the right thing. I'm not > > yet sure it's the best solution, but it seems to do the trick, at > > least. > > > > I'm just creating new developer snapshots, please try. I'll > > create another test release later this week. > > I confirmed the STC works as expected. Thank you. > > However, it seems that signalfd still has a problem. > > If script command (from util-linux) is terminated by '^D', > the following error message is sometimes shown. > > script: poll failed: Interrupted system call > > I have confirmed this in 32bit cygwin with bash as login shell. > This rarely occurs in real machine, however, often occurs in > virtual machine in VirtualBox. Sorry, I forgot to mention important thing. This occurs only in cygwin on command prompt. Not in mintty. -- Takashi Yano -- 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: [ANNOUNCEMENT] TEST: Cygwin 3.1.0-0.1
Hi Corinna, On Tue, 13 Aug 2019 12:47:53 +0200 Corinna Vinschen wrote: > I created a patch which *seems* to do the right thing. I'm not > yet sure it's the best solution, but it seems to do the trick, at > least. > > I'm just creating new developer snapshots, please try. I'll > create another test release later this week. I confirmed the STC works as expected. Thank you. However, it seems that signalfd still has a problem. If script command (from util-linux) is terminated by '^D', the following error message is sometimes shown. script: poll failed: Interrupted system call I have confirmed this in 32bit cygwin with bash as login shell. This rarely occurs in real machine, however, often occurs in virtual machine in VirtualBox. -- Takashi Yano -- 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: [ANNOUNCEMENT] TEST: Cygwin 3.1.0-0.1
On Tue, 13 Aug 2019 23:50:54 +0200 Thorsten Kampe wrote: > > I compiled tree > > (http://mama.indstate.edu/users/ice/tree/src/tree-1.8.0.tgz). > > > > Mintty: 2.5s > > Cmd: 122s > > > > Make clean[1]: > > Mintty: 0.3s > > Cmd: 60,3s > > A second compile took even three minutes: > real3m1,822s > user0m1,158s > sys 0m0,751s > > The times in Mintty: > real0m2,281s > user0m1,006s > sys 0m0,844s I cannot reproduce this. [In command prompt] yano@Express5800-S70 ~/tree/tree-1.8.0 $ time make gcc -ggdb -pedantic -Wall -DLINUX -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -c -o tree.o tree.c gcc -ggdb -pedantic -Wall -DLINUX -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -c -o unix.o unix.c gcc -ggdb -pedantic -Wall -DLINUX -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -c -o html.o html.c gcc -ggdb -pedantic -Wall -DLINUX -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -c -o xml.o xml.c gcc -ggdb -pedantic -Wall -DLINUX -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -c -o json.o json.c gcc -ggdb -pedantic -Wall -DLINUX -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -c -o hash.o hash.c gcc -ggdb -pedantic -Wall -DLINUX -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -c -o color.o color.c gcc -ggdb -pedantic -Wall -DLINUX -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -c -o file.o file.c gcc -o tree tree.o unix.o html.o xml.o json.o hash.o color.o file.o real0m2.240s user0m0.943s sys 0m1.186s yano@Express5800-S70 ~/tree/tree-1.8.0 $ time make clean if [ -x tree ]; then rm tree; fi if [ -f tree.o ]; then rm *.o; fi rm -f *~ real0m0.241s user0m0.030s sys 0m0.261s [In mintty] yano@Express5800-S70 ~/tree/tree-1.8.0 $ time make gcc -ggdb -pedantic -Wall -DLINUX -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -c -o tree.o tree.c gcc -ggdb -pedantic -Wall -DLINUX -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -c -o unix.o unix.c gcc -ggdb -pedantic -Wall -DLINUX -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -c -o html.o html.c gcc -ggdb -pedantic -Wall -DLINUX -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -c -o xml.o xml.c gcc -ggdb -pedantic -Wall -DLINUX -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -c -o json.o json.c gcc -ggdb -pedantic -Wall -DLINUX -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -c -o hash.o hash.c gcc -ggdb -pedantic -Wall -DLINUX -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -c -o color.o color.c gcc -ggdb -pedantic -Wall -DLINUX -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -c -o file.o file.c gcc -o tree tree.o unix.o html.o xml.o json.o hash.o color.o file.o real0m2.264s user0m1.130s sys 0m1.059s yano@Express5800-S70 ~/tree/tree-1.8.0 $ time make clean if [ -x tree ]; then rm tree; fi if [ -f tree.o ]; then rm *.o; fi rm -f *~ real0m0.229s user0m0.015s sys 0m0.199s The results are almost same. -- Takashi Yano -- 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: [ANNOUNCEMENT] TEST: Cygwin 3.1.0-0.1
* Takashi Yano (Tue, 13 Aug 2019 04:44:51 +0900) > I looked into this problem, and found that this is due to a > bug of ConEmu. > > Attached is the simple test case (conemu-chk.c). > In command prompt, the output of this program is: > AAA > BBB > > However, in ConEmu, the output is: > AAA >BBB > > If ENABLE_VIRTUAL_TERMINAL_INPUT flag is set to console input, > it affects to console output and becomes so that the newline '\n' > does not cause carriage return. This is weird. > > Thorsten, could you please report this bug to ConEmu developers? Thanks, I've opened #1966 (https://github.com/Maximus5/ConEmu/issues/1966) Thorsten -- 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: [ANNOUNCEMENT] TEST: Cygwin 3.1.0-0.1
* Thorsten Kampe (Tue, 13 Aug 2019 23:45:14 +0200) > The issue is definitely not just with ConEmu but also with a > standard Windows console (cmd.exe). > > I compiled tree > (http://mama.indstate.edu/users/ice/tree/src/tree-1.8.0.tgz). > > Mintty: 2.5s > Cmd: 122s > > Make clean[1]: > Mintty: 0.3s > Cmd: 60,3s A second compile took even three minutes: real3m1,822s user0m1,158s sys 0m0,751s The times in Mintty: real0m2,281s user0m1,006s sys 0m0,844s Note that user and sys are almost identical in Cmd and Mintty. Only real differs. Thorsten -- 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: [ANNOUNCEMENT] TEST: Cygwin 3.1.0-0.1
* Corinna Vinschen (Mon, 12 Aug 2019 15:01:52 +0200) > > On Aug 11 09:27, Thorsten Kampe wrote: > > * Corinna Vinschen (Fri, 9 Aug 2019 20:53:38 +0200) > > > I uploaded a new Cygwin test release 3.1.0-0.1 > > > > > > This release comes with a couple of new features and quite a few > > > bug fixes. > > > > > > The most interesting change, courtesy Ken Brown, is a revamp of the > > > old FIFO code. It should now be possible to open FIFOs multiple times > > > for writing, something the old code failed on. > > > > I've noticed two things in connection with pspg > > (https://github.com/okbob/pspg) - a pager for tables: > > Nobody from the dev team uses this application, afaics. > > To help tracking down the cause for the problems, can you bisect > Cygwin or at least check which of the snapshots from > http://www.cygwin.com/snapshots/ introduces the problem? The issue is definitely not just with ConEmu but also with a standard Windows console (cmd.exe). I compiled tree (http://mama.indstate.edu/users/ice/tree/src/tree-1.8.0.tgz). Mintty: 2.5s Cmd: 122s Make clean[1]: Mintty: 0.3s Cmd: 60,3s Thorsten [1] if [ -x tree ]; then rm tree; fi if [ -f tree.o ]; then rm *.o; fi rm -f *~ -- 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: [ANNOUNCEMENT] TEST: Cygwin 3.1.0-0.1
On Aug 12 17:36, Corinna Vinschen wrote: > On Aug 12 22:44, Takashi Yano wrote: > > [...] > > (4) Segmentation fault occurs in some cases regarding signalfd. > > [...] > > However, I can not find out the cause of problem (4). This seems > > to affect only 32bit version of cygwin. > > > > To reproduce (4), use a simple test case attached (signalfd-chk.c). > > Compile it and execute, then type 'q' or '^C' to stop it. > > This causes segmentation fault. > > > > I am not sure why, but, the patch attached (signalfd-segfault.diff) > > resolves the problem (4). > > > > Could you please have a look? > > Will do. The place where it supposedly crashes looks weird. But > I don't see how your patch should be the right thing to do. I created a patch which *seems* to do the right thing. I'm not yet sure it's the best solution, but it seems to do the trick, at least. I'm just creating new developer snapshots, please try. I'll create another test release later this week. Thanks, Corinna -- Corinna Vinschen Cygwin Maintainer signature.asc Description: PGP signature
Re: [ANNOUNCEMENT] TEST: Cygwin 3.1.0-0.1
On Mon, 12 Aug 2019 15:01:52 +0200 Corinna Vinschen wrote: > On Aug 11 09:27, Thorsten Kampe wrote: > > * Corinna Vinschen (Fri, 9 Aug 2019 20:53:38 +0200) > > > I uploaded a new Cygwin test release 3.1.0-0.1 > > > > > > This release comes with a couple of new features and quite a few > > > bug fixes. > > > > > > The most interesting change, courtesy Ken Brown, is a revamp of the > > > old FIFO code. It should now be possible to open FIFOs multiple times > > > for writing, something the old code failed on. > > > > > > > > > Please test. > > > > I've noticed two things in connection with pspg > > (https://github.com/okbob/pspg) - a pager for tables: > > Nobody from the dev team uses this application, afaics. > > To help tracking down the cause for the problems, can you bisect > Cygwin or at least check which of the snapshots from > http://www.cygwin.com/snapshots/ introduces the problem? > > > 1. Configuring the source takes ages (for instance "checking > > whether the C compiler works..."). This is only in ConEmu, not > > in MinTTY. > > > > 2. Pager output is completely distorted: > > > > Before: > > > SELECT ArtistId FROM Chinook.dbo.Album WHERE ArtistId = 78 > > ++ > > | ArtistId | > > || > > | 78 | > > ++ > > (1 row affected) > > Time: 0.356s > > > > After: > > > SELECT ArtistId FROM Chinook.dbo.Album WHERE ArtistId = 78 > > ++ > > | ArtistId | > > || > > | 78 | > > If this all occurs in ConEmu only, it may be one of the end of March > patches which may introduce incompatibilities with ConEmu's Windows > API hooking, but that's just a blind guess: > > 6a06c6bc8f84 Cygwin: console: fix key input for native console application > f4b47827cf87 Cygwin: console: Make I/O functions thread-safe > 8382778cdb57 Cygwin: console: fix select() behaviour > bd627864ab41 Cygwin: console: support 24 bit color I looked into this problem, and found that this is due to a bug of ConEmu. Attached is the simple test case (conemu-chk.c). In command prompt, the output of this program is: AAA BBB However, in ConEmu, the output is: AAA BBB If ENABLE_VIRTUAL_TERMINAL_INPUT flag is set to console input, it affects to console output and becomes so that the newline '\n' does not cause carriage return. This is weird. Thorsten, could you please report this bug to ConEmu developers? -- Takashi Yano #include #ifndef DISABLE_NEWLINE_AUTO_RETURN #define DISABLE_NEWLINE_AUTO_RETURN 0x0008 #endif #ifndef ENABLE_VIRTUAL_TERMINAL_INPUT #define ENABLE_VIRTUAL_TERMINAL_INPUT 0x0200 #endif int main() { DWORD mode; DWORD len; GetConsoleMode(GetStdHandle(STD_OUTPUT_HANDLE), &mode); mode &= ~DISABLE_NEWLINE_AUTO_RETURN; SetConsoleMode(GetStdHandle(STD_OUTPUT_HANDLE), mode); GetConsoleMode(GetStdHandle(STD_INPUT_HANDLE), &mode); mode |= ENABLE_VIRTUAL_TERMINAL_INPUT; SetConsoleMode(GetStdHandle(STD_INPUT_HANDLE), mode); GetConsoleMode(GetStdHandle(STD_OUTPUT_HANDLE), &mode); mode &= ~DISABLE_NEWLINE_AUTO_RETURN; SetConsoleMode(GetStdHandle(STD_OUTPUT_HANDLE), mode); WriteConsole(GetStdHandle(STD_OUTPUT_HANDLE), "AAA\nBBB\n", 8, &len, 0); 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: [ANNOUNCEMENT] TEST: Cygwin 3.1.0-0.1
On Aug 12 22:44, Takashi Yano wrote: > [...] > (4) Segmentation fault occurs in some cases regarding signalfd. > [...] > However, I can not find out the cause of problem (4). This seems > to affect only 32bit version of cygwin. > > To reproduce (4), use a simple test case attached (signalfd-chk.c). > Compile it and execute, then type 'q' or '^C' to stop it. > This causes segmentation fault. > > I am not sure why, but, the patch attached (signalfd-segfault.diff) > resolves the problem (4). > > Could you please have a look? Will do. The place where it supposedly crashes looks weird. But I don't see how your patch should be the right thing to do. Corinna -- Corinna Vinschen Cygwin Maintainer signature.asc Description: PGP signature
Re: [ANNOUNCEMENT] TEST: Cygwin 3.1.0-0.1
Hi Corinna, On Fri, 9 Aug 2019 20:53:38 +0200 Corinna Vinschen wrote: > Hi folks, > > > I uploaded a new Cygwin test release 3.1.0-0.1 > > This release comes with a couple of new features and quite a few > bug fixes. > > The most interesting change, courtesy Ken Brown, is a revamp of the > old FIFO code. It should now be possible to open FIFOs multiple times > for writing, something the old code failed on. > > > Please test. I tested this test release, and found a few problems. (1) The cursor position is not restored correctly after screen alternation in the case of xterm compatible mode is enabled. (2) fork() on console ocasionally falls into deadlock. (3) Horizontal tab setting on console is broken after resizing console window if xterm compatible mode is enabled. (4) Segmentation fault occurs in some cases regarding signalfd. I will propose patches for (1),(2) and (3) in the other posts. However, I can not find out the cause of problem (4). This seems to affect only 32bit version of cygwin. To reproduce (4), use a simple test case attached (signalfd-chk.c). Compile it and execute, then type 'q' or '^C' to stop it. This causes segmentation fault. I am not sure why, but, the patch attached (signalfd-segfault.diff) resolves the problem (4). Could you please have a look? #include #include #include #include #include #include int run() { struct termios tt; sigset_t sigset; pid_t pid; struct pollfd pfd[2]; int running = 1; tcgetattr(STDIN_FILENO, &tt); tt.c_lflag &= ~(ECHO|ICANON|ISIG); tcsetattr(STDIN_FILENO, TCSANOW, &tt); pid = fork(); if (pid == 0) { /* Child */ usleep(10); return 0; } printf("Start: %d\n", pid); sigemptyset(&sigset); sigaddset(&sigset, SIGCHLD); sigprocmask(SIG_BLOCK, &sigset, NULL); pfd[0].fd = STDIN_FILENO; pfd[0].events = POLLIN; pfd[1].fd = signalfd(-1, &sigset, 0); pfd[1].events = POLLIN; do { poll(pfd, 2, -1); if (pfd[0].revents & POLLIN) { char c; int ret = read(pfd[0].fd, &c, 1); if (ret == 0 || c == 'q' || c == '\003') { running = 0; break; } } if (pfd[1].revents & POLLIN) { struct signalfd_siginfo info; int ret = read(pfd[1].fd, &info, sizeof(info)); if (ret) printf("Signal: %d\r\n", info.ssi_signo); if (info.ssi_signo == SIGCHLD) break; } } while (1); waitpid(pid, NULL, 0); printf("End: %d\n", pid); tcgetattr(STDIN_FILENO, &tt); tt.c_lflag |= ECHO|ICANON|ISIG; tcsetattr(STDIN_FILENO, TCSANOW, &tt); return running; } int main() { while (run()); return 0; } diff --git a/winsup/cygwin/select.cc b/winsup/cygwin/select.cc index 1bb143a23..91c0bcc53 100644 --- a/winsup/cygwin/select.cc +++ b/winsup/cygwin/select.cc @@ -1887,7 +1887,7 @@ thread_signalfd (void *arg) switch (WaitForSingleObject (si->evt, INFINITE)) { case WAIT_OBJECT_0: - tls->signalfd_select_wait = NULL; + //tls->signalfd_select_wait = NULL; event = true; break; default: -- 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: [ANNOUNCEMENT] TEST: Cygwin 3.1.0-0.1
On Aug 11 09:27, Thorsten Kampe wrote: > * Corinna Vinschen (Fri, 9 Aug 2019 20:53:38 +0200) > > I uploaded a new Cygwin test release 3.1.0-0.1 > > > > This release comes with a couple of new features and quite a few > > bug fixes. > > > > The most interesting change, courtesy Ken Brown, is a revamp of the > > old FIFO code. It should now be possible to open FIFOs multiple times > > for writing, something the old code failed on. > > > > > > Please test. > > I've noticed two things in connection with pspg > (https://github.com/okbob/pspg) - a pager for tables: Nobody from the dev team uses this application, afaics. To help tracking down the cause for the problems, can you bisect Cygwin or at least check which of the snapshots from http://www.cygwin.com/snapshots/ introduces the problem? > 1. Configuring the source takes ages (for instance "checking > whether the C compiler works..."). This is only in ConEmu, not > in MinTTY. > > 2. Pager output is completely distorted: > > Before: > > SELECT ArtistId FROM Chinook.dbo.Album WHERE ArtistId = 78 > ++ > | ArtistId | > || > | 78 | > ++ > (1 row affected) > Time: 0.356s > > After: > > SELECT ArtistId FROM Chinook.dbo.Album WHERE ArtistId = 78 > ++ > | ArtistId | > || > | 78 | If this all occurs in ConEmu only, it may be one of the end of March patches which may introduce incompatibilities with ConEmu's Windows API hooking, but that's just a blind guess: 6a06c6bc8f84 Cygwin: console: fix key input for native console application f4b47827cf87 Cygwin: console: Make I/O functions thread-safe 8382778cdb57 Cygwin: console: fix select() behaviour bd627864ab41 Cygwin: console: support 24 bit color Thanks, Corinna -- Corinna Vinschen Cygwin Maintainer signature.asc Description: PGP signature
Re: [ANNOUNCEMENT] TEST: Cygwin 3.1.0-0.1
* Corinna Vinschen (Fri, 9 Aug 2019 20:53:38 +0200) > I uploaded a new Cygwin test release 3.1.0-0.1 > > This release comes with a couple of new features and quite a few > bug fixes. > > The most interesting change, courtesy Ken Brown, is a revamp of the > old FIFO code. It should now be possible to open FIFOs multiple times > for writing, something the old code failed on. > > > Please test. I've noticed two things in connection with pspg (https://github.com/okbob/pspg) - a pager for tables: 1. Configuring the source takes ages (for instance "checking whether the C compiler works..."). This is only in ConEmu, not in MinTTY. 2. Pager output is completely distorted: Before: > SELECT ArtistId FROM Chinook.dbo.Album WHERE ArtistId = 78 ++ | ArtistId | || | 78 | ++ (1 row affected) Time: 0.356s After: > SELECT ArtistId FROM Chinook.dbo.Album WHERE ArtistId = 78 ++ | ArtistId | || | 78 | Regards, Thorsten -- 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