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
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 &= ~DISABLE_NEWLINE_AUTO_RETURN;
SetConsoleMode(GetStdHandle(STD_OUTPUT_HANDLE), mode);
GetConsoleMode(GetStdHandle(STD_INPUT_HANDLE), );
mode |= ENABLE_VIRTUAL_TERMINAL_INPUT;
SetConsoleMode(GetStdHandle(STD_INPUT_HANDLE), mode);
GetConsoleMode(GetStdHandle(STD_OUTPUT_HANDLE), );
mode &= ~DISABLE_NEWLINE_AUTO_RETURN;
SetConsoleMode(GetStdHandle(STD_OUTPUT_HANDLE), mode);
WriteConsole(GetStdHandle(STD_OUTPUT_HANDLE), "AAA\nBBB\n", 8, , 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.c_lflag &= ~(ECHO|ICANON|ISIG);
tcsetattr(STDIN_FILENO, TCSANOW, );
pid = fork();
if (pid == 0) {
/* Child */
usleep(10);
return 0;
}
printf("Start: %d\n", pid);
sigemptyset();
sigaddset(, SIGCHLD);
sigprocmask(SIG_BLOCK, , NULL);
pfd[0].fd = STDIN_FILENO;
pfd[0].events = POLLIN;
pfd[1].fd = signalfd(-1, , 0);
pfd[1].events = POLLIN;
do {
poll(pfd, 2, -1);
if (pfd[0].revents & POLLIN) {
char c;
int ret = read(pfd[0].fd, , 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, , 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.c_lflag |= ECHO|ICANON|ISIG;
tcsetattr(STDIN_FILENO, TCSANOW, );
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
