Debian Bug report logs - #265631
libncurses5: race condition between setting up default SIGWINCH handler and TIOCGWINSZ

version graph

Package: libncurses5; Maintainer for libncurses5 is Craig Small <csmall@debian.org>; Source for libncurses5 is src:ncurses.

Reported by: Marc Lehmann <debian-reportbug@plan9.de>

Date: Sat, 14 Aug 2004 05:18:02 UTC

Severity: normal

Found in version 5.4-4

Fixed in version ncurses/5.4-5

Done: Daniel Jacobowitz <dan@debian.org>

Bug is archived. No further changes may be made.

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to debian-bugs-dist@lists.debian.org, Daniel Jacobowitz <ncurses-maint@debian.org>:
Bug#265631; Package libncurses5. Full text and rfc822 format available.

Acknowledgement sent to Marc Lehmann <debian-reportbug@plan9.de>:
New Bug report received and forwarded. Copy sent to Daniel Jacobowitz <ncurses-maint@debian.org>. Full text and rfc822 format available.

Message #5 received at submit@bugs.debian.org (full text, mbox):

From: Marc Lehmann <debian-reportbug@plan9.de>
To: Debian Bug Tracking System <submit@bugs.debian.org>
Subject: libncurses5: race condition between setting up default SIGWINCH handler and TIOCGWINSZ
Date: Sat, 14 Aug 2004 07:00:24 +0200
Package: libncurses5
Version: 5.4-4
Severity: normal

While investigating debian bug #202497 and reading pages such as
http://wiki.ael.be/ion/index.php/FrequentlyAskedQuestions, I took a look
at libncurses, which many programs that misbehave use.

The problem is that libncurses sets up a (helpful) SIGWINCH handler, but
it does so only _after_ fetching the screen size using TIOCGWINSZ.

This effectively creates a race condition: if the program receives a
SIGWINCH after TIOCGWINSZ but before it installs a SIGWINCH handler, the
resize will go undetected.

The reason why this is seen rarely in practise is manyfold:

1. many (but not all) terminal emulators use various tricks to get
   around these problems. xterm re-sets the window size on the first refresh,
   beta versions of rxvt do the same upon receiving the first line of 
   program output. In the worst case this leads to two resizes, which
   is harmless, but still the workaround punishes correctly written programs
   and forces terminal emulators to implement hacks.

2. this only happens when the window is resized quickly after opening. in
   most cases (window manager doesn't forcefully resize or the window fits
   on the screen), this does not happen. But many window managers resize
   geometries that wouldn't fit on the screen, and some basically always
   resize (e.g. ion). In these cases the problem happens frequently (jed
   under rxvt-unicode under ion gets the initial screensize wrong about
   every 3rd time on my system. sending a sigwinch works around this issue).

3. earlier xterm and rxvt (+clones) releases had a different race
   condition where the child and the parent set the window size, and
   depending on who runs first, the outcome was unpredictable. This is a
   difefrent bug, though.

The fix (for ncurses) would be to set the signal handler before using
TIOCGWINSZ. This should have no effect on correctly-written programs (such
as mutt), but will automatically fix most curses users who do not install
their own sigwinch handler, or do so very late.

-- System Information:
Debian Release: 3.1
  APT prefers testing
  APT policy: (700, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.6
Locale: LANG=C, LC_CTYPE=de_DE.UTF-8

Versions of packages libncurses5 depends on:
hi  libc6                       2.3.2.ds1-11 GNU C Library: Shared libraries an

-- no debconf information



Message sent on to Marc Lehmann <debian-reportbug@plan9.de>:
Bug#265631. Full text and rfc822 format available.

Message #8 received at 265631-submitter@bugs.debian.org (full text, mbox):

From: Thomas Dickey <dickey@radix.net>
To: 265631-submitter@bugs.debian.org
Subject: Re: Bug#265631: libncurses5: race condition between setting up default SIGWINCH handler and TIOCGWINSZ
Date: Sat, 14 Aug 2004 10:45:28 -0400
[Message part 1 (text/plain, inline)]
On Sat, Aug 14, 2004 at 07:30:09AM +0200, Marc Lehmann wrote:
> Package: libncurses5
> Version: 5.4-4
> Severity: normal
> 
> While investigating debian bug #202497 and reading pages such as
> http://wiki.ael.be/ion/index.php/FrequentlyAskedQuestions, I took a look
> at libncurses, which many programs that misbehave use.

That faq would actually be useful if the people who maintain it would
report things as bugs rather than advertise them.  (Perhaps that would
require some work).
 
> The problem is that libncurses sets up a (helpful) SIGWINCH handler, but
> it does so only _after_ fetching the screen size using TIOCGWINSZ.
> 
> This effectively creates a race condition: if the program receives a
> SIGWINCH after TIOCGWINSZ but before it installs a SIGWINCH handler, the
> resize will go undetected.

perhaps.  But that's unrelated to the capability of the TIOCGWINSZ ioctl,
which is supposed to return the screen size whether or not a SIGWINCH
handler is in place.  What you probably meant to say was that there's
no subsequent information that would tell ncurses to readjust the screen
structures.

-- 
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net
[Message part 2 (application/pgp-signature, inline)]

Message sent on to Marc Lehmann <debian-reportbug@plan9.de>:
Bug#265631. Full text and rfc822 format available.

Message #11 received at 265631-submitter@bugs.debian.org (full text, mbox):

From: Thomas Dickey <dickey@radix.net>
To: 265631-submitter@bugs.debian.org
Subject: Re: Bug#265631: libncurses5: race condition between setting up default SIGWINCH handler and TIOCGWINSZ
Date: Sat, 14 Aug 2004 15:32:12 -0400
[Message part 1 (text/plain, inline)]
On Sat, Aug 14, 2004 at 07:30:09AM +0200, Marc Lehmann wrote:
> Package: libncurses5
> Version: 5.4-4
> Severity: normal
 
I spent a while looking into this, but changing the behavior is not simple.
(will think about it).

-- 
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net
[Message part 2 (application/pgp-signature, inline)]

Information stored:
Bug#265631; Package libncurses5. Full text and rfc822 format available.

Acknowledgement sent to <pcg( Marc)@goof(A.).(Lehmann )com>:
Extra info received and filed, but not forwarded. Full text and rfc822 format available.

Message #16 received at 265631-quiet@bugs.debian.org (full text, mbox):

From: <pcg( Marc)@goof(A.).(Lehmann )com>
To: Thomas Dickey <dickey@radix.net>, 265631-quiet@bugs.debian.org
Cc: 265631-submitter@bugs.debian.org
Subject: Re: Bug#265631: libncurses5: race condition between setting up default SIGWINCH handler and TIOCGWINSZ
Date: Mon, 23 Aug 2004 00:06:39 +0200
On Sat, Aug 14, 2004 at 10:45:28AM -0400, Thomas Dickey <dickey@radix.net> wrote:
> > This effectively creates a race condition: if the program receives a
> > SIGWINCH after TIOCGWINSZ but before it installs a SIGWINCH handler, the
> > resize will go undetected.
> 
> perhaps.  But that's unrelated to the capability of the TIOCGWINSZ ioctl,

TIOCGWINSZ is of course not a problem here, the information reported by it
is correct and up-to-date, at leats in the split second where it is beign
requested *g*.

> which is supposed to return the screen size whether or not a SIGWINCH
> handler is in place.

However, TIOCGWINSZ and SIGWINCH are not independent, as a SIGWINCH is
automatically generated by (at least currently in-use) kernels when the
information given by TIOCGWINSZ changes using TIOCSWINSZ.

> What you probably meant to say was that there's no subsequent
> information that would tell ncurses to readjust the screen structures.

In the example there *is* information that would tell ncurses to readjust
the screen structure, namely the SIGWINCH generated by the TIOCSWINSZ. The
problem is that ncurses fetches the size information and then ignores
changes in that info for a (very very little) while.

On Sat, Aug 14, 2004 at 03:32:12PM -0400, Thomas Dickey <dickey@radix.net> wrote:
> I spent a while looking into this, but changing the behavior is not simple.
> (will think about it).

Interesting, I would have assumed that changing it is very easy (just
do it earlier). If that isn't possible for some reasons, then maybe
checking TIOCGWINSZ info twice, once at the beginning and once just after
installing the sigwinch handler, might do the trick?

That is because the problem seems to be limited to the initial
size. However, the bug I late reported against mutt might indicate sth.
else, although I have not the slightets idea what happens in mutt, as this
doesn't happen with other full-screen programs that I have tried (and mutt
doesn't exhibit the race condition reported against ncurses, probably due
to it installing a SIGWINCH handler very early).

I assume that there is no standard on when an application-supplied
sigwinch handler should be installed, and it's probably best to declare
apps that install such a handler very late (after ncurses) to be broken
with respect to dynamic resizes.

(As far as I understand the code, which is admittedly very little, it
seems that ncurses installs a handler if it's still on SIG_DFL. In that
case even apps which install their handler very late would get the benefit
of curses knowing what's going on, at least).

In the meantime, I am experimenting with sending the extra SIGWINCH on the
first escape sequence received, which at least helps fullscreen programs
that output sth. before going to full screen mode, which is the main target
audience for the workaround.

-- 
                The choice of a                              |
      -----==-     _GNU_                                     |
      ----==-- _       generation     Marc Lehmann         +--
      ---==---(_)__  __ ____  __      pcg@goof.com         |e|
      --==---/ / _ \/ // /\ \/ /      http://schmorp.de/   --+
      -=====/_/_//_/\_,_/ /_/\_\      XX11-RIPE            |
                                                           |



Message sent on to Marc Lehmann <debian-reportbug@plan9.de>:
Bug#265631. Full text and rfc822 format available.

Message sent on to Marc Lehmann <debian-reportbug@plan9.de>:
Bug#265631. Full text and rfc822 format available.

Message #22 received at 265631-submitter@bugs.debian.org (full text, mbox):

From: Thomas Dickey <dickey@radix.net>
To: 265631-submitter@bugs.debian.org
Subject: Re: Bug#265631: libncurses5: race condition between setting up default SIGWINCH handler and TIOCGWINSZ
Date: Sun, 22 Aug 2004 19:54:30 -0400
[Message part 1 (text/plain, inline)]
On Mon, Aug 23, 2004 at 12:06:39AM +0200,  Marc A. Lehmann  wrote:
> 
> Interesting, I would have assumed that changing it is very easy (just
> do it earlier). If that isn't possible for some reasons, then maybe
> checking TIOCGWINSZ info twice, once at the beginning and once just after
> installing the sigwinch handler, might do the trick?

I did something like that (setting the flag which tells ncurses
that a SIGWINCH arrived) in last week's (20040814) patch.
 
> I assume that there is no standard on when an application-supplied
> sigwinch handler should be installed, and it's probably best to declare
> apps that install such a handler very late (after ncurses) to be broken
> with respect to dynamic resizes.

That's documented (I'd thought it was in the manpage, but see it is in
the NEWS file):

970906
        + add SIGWINCH handler to ncurses library which is used if there is no
	  application SIGWINCH handler in effect when the screen is
	  initialized.
 
-- 
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net
[Message part 2 (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Daniel Jacobowitz <ncurses-maint@debian.org>:
Bug#265631; Package libncurses5. Full text and rfc822 format available.

Acknowledgement sent to <pcg( Marc)@goof(A.).(Lehmann )com>:
Extra info received and forwarded to list. Copy sent to Daniel Jacobowitz <ncurses-maint@debian.org>. Full text and rfc822 format available.

Message #27 received at 265631@bugs.debian.org (full text, mbox):

From: <pcg( Marc)@goof(A.).(Lehmann )com>
To: Thomas Dickey <dickey@radix.net>
Cc: 265631@bugs.debian.org
Subject: Re: Bug#265631: libncurses5: race condition between setting up default SIGWINCH handler and TIOCGWINSZ
Date: Thu, 26 Aug 2004 09:40:17 +0200
On Sun, Aug 22, 2004 at 07:54:30PM -0400, Thomas Dickey <dickey@radix.net> wrote:
> > Interesting, I would have assumed that changing it is very easy (just
> > do it earlier). If that isn't possible for some reasons, then maybe
> > checking TIOCGWINSZ info twice, once at the beginning and once just after
> > installing the sigwinch handler, might do the trick?
> 
> I did something like that (setting the flag which tells ncurses
> that a SIGWINCH arrived) in last week's (20040814) patch.

I am just reading (and compiling) it, I guess it's this patch:

        + fake a SIGWINCH in newterm() to accommodate buggy terminal
          emulators and window managers (Debian #265631).

I am not sure what to make of it, as it's clearly a bug in ncurses,
neither terminal emulators nor window managers are to blame, as they work
correctly, namely sending SIGWINCH after every window size change (as a
workaround to accomodate this bug in ncurses, many terminal emulators send
extra SIGWINCH signals, but the point of the bugreport is to fix the real bug
in ncurses instead of having to implement a workaround in each and every
terminal emulator).

Again, the problem is that ncurses _ignores_ SIGWINCH and keeps working
with the wrong screensize. There is nothing that a window manager or
terminal emulator can do about this, as it's ncurses that ignores the
window change event, sth. that the terminal emulator (or window manager)
can't force: it can only send the sigwinch, if ncurses opts to ignore the
event and work with old (and thus wrong) size data, then this is an issue
in ncurses.

Given that description, I am not sure wether you understood the bug at
all, but I have no idea how I could have explained this better. What could
possibly be unclear about this race bug?

I also don't understand the purpose of a "fake SIGWINCH", either. Wouldn't
it be more logical just to use the real SIGWINCH that is being delivered
to ncurses instead of ignoring it and faking one? As it seems to fake one
every time, this also seems to be rather wasteful, as the actual event that
causes the bug is rare, and forcing an extra "fake sigwinch" in every case
doesn't make sense.

I would have hoped just fixing the race condition instead would be
easiest, and cleanest.

In any case, the above patch description is at best misleading, and if
this is thought of a kind of workaround around bugs elsewhere then it is
possible that the real bug in ncurses is not being addressed by it. One
might want to look deeper into this issue then.

Looking at the patch, the core seems to be this:

+#if USE_SIZECHANGE
+    /*
+     * Pretend we received a SIGWINCH, just in case we're starting up in a
+     * terminal that cannot initialize its size properly (Debian #265631).
+     */
+    SP->_sig_winch = TRUE;
+#endif

Which might or might not work, but it's wasteful, as it forces an
unneccessary sigwinch, and the comment is entirely wrong: it's a bug in
ncurses that keeps it from getting the correct size information. Again,
this happens with _ALL_ terminal emulators, as this is a classical race
bug within ncurses (first fetching info, then installing a handler to
get info updates), and not a bug in any terminal emulator (or a window
manager).

The description is also misleading in another way: there is no reason
to pretend that ncurses received a SIGWINCH, as in the bug case the
process *did* receive a SIGWINCH signal, but due to the wrong order of
initializations it ignored the SIGWINCH.

Again, the terminal emulator behaviour is completely correct: the window size
is being initialized completely correctly, and size changes are also being
reported correctly.

If you really think that this is a bug in the temrinal emulator then I would
happy to hear what the fix would be. In rxvt-unicode, I just send an extra
SIGWINCH on first program output, which works in most but not all cases. rxvt
does the same.

xterm does not implement any ncurses workaround, and thus would belong
into the category of "terminal that cannot initialize its size properly"
(again, I think xterm is not to blame, it's just that you seem to think
that way).

I still think it is both easier, more correct and less wasteful of
resources if the bug would be fixed properly in ncurses, instead of having
to workaround it in xterm, rxvt etc, or causing extra sigwinch signalling
even if not required (as in the majority of cases).

-- 
                The choice of a                              |
      -----==-     _GNU_                                     |
      ----==-- _       generation     Marc Lehmann         +--
      ---==---(_)__  __ ____  __      pcg@goof.com         |e|
      --==---/ / _ \/ // /\ \/ /      http://schmorp.de/   --+
      -=====/_/_//_/\_,_/ /_/\_\      XX11-RIPE            |
                                                           |



Information forwarded to debian-bugs-dist@lists.debian.org, Daniel Jacobowitz <ncurses-maint@debian.org>:
Bug#265631; Package libncurses5. Full text and rfc822 format available.

Acknowledgement sent to <pcg( Marc)@goof(A.).(Lehmann )com>:
Extra info received and forwarded to list. Copy sent to Daniel Jacobowitz <ncurses-maint@debian.org>. Full text and rfc822 format available.

Message #32 received at 265631@bugs.debian.org (full text, mbox):

From: <pcg( Marc)@goof(A.).(Lehmann )com>
To: Thomas Dickey <dickey@radix.net>
Cc: 265631@bugs.debian.org
Subject: Re: Bug#265631: libncurses5: race condition between setting up default SIGWINCH handler and TIOCGWINSZ
Date: Thu, 26 Aug 2004 09:52:34 +0200
On Sun, Aug 22, 2004 at 07:54:30PM -0400, Thomas Dickey <dickey@radix.net> wrote:
> > Interesting, I would have assumed that changing it is very easy (just
> > do it earlier). If that isn't possible for some reasons, then maybe
> > checking TIOCGWINSZ info twice, once at the beginning and once just after
> > installing the sigwinch handler, might do the trick?
> 
> I did something like that (setting the flag which tells ncurses
> that a SIGWINCH arrived) in last week's (20040814) patch.

I just tried ncurses-20040821 (0711 rollup + 0718, 0724, 0731, 0807, 0814
and 0828 patches, I hope this was the correct order and complete), and the
fix does not seem to fix the bug.

   xterm -e jed # under ion3

Still show the jed screen too small in about one out of 20 starts.

Right now, xterm is the only terminal I can reproduce this with, as all
the rxvt clones implement a workaround and gnome-terminal or konsole are
way too slow to exhibit this problem.

I verified that the jed process indeed has the patched ncurses mapped and
not the system one.

(I originally thought xterm would also implement a workaround, but I
misread it's sources, which is a treasure of portability hints that I
often consult :)

It is possible that the number of occurrences of the problem is smaller
with the patch, but as the behaviour is timing-dependent this could be
just pure chance.

-- 
                The choice of a                              |
      -----==-     _GNU_                                     |
      ----==-- _       generation     Marc Lehmann         +--
      ---==---(_)__  __ ____  __      pcg@goof.com         |e|
      --==---/ / _ \/ // /\ \/ /      http://schmorp.de/   --+
      -=====/_/_//_/\_,_/ /_/\_\      XX11-RIPE            |
                                                           |



Information forwarded to debian-bugs-dist@lists.debian.org, Daniel Jacobowitz <ncurses-maint@debian.org>:
Bug#265631; Package libncurses5. Full text and rfc822 format available.

Acknowledgement sent to <pcg( Marc)@goof(A.).(Lehmann )com>:
Extra info received and forwarded to list. Copy sent to Daniel Jacobowitz <ncurses-maint@debian.org>. Full text and rfc822 format available.

Message #37 received at 265631@bugs.debian.org (full text, mbox):

From: <pcg( Marc)@goof(A.).(Lehmann )com>
To: Thomas Dickey <dickey@radix.net>
Cc: 265631@bugs.debian.org
Subject: Re: Bug#265631: libncurses5: race condition between setting up default SIGWINCH handler and TIOCGWINSZ
Date: Thu, 26 Aug 2004 10:03:53 +0200
On Sun, Aug 22, 2004 at 07:54:30PM -0400, Thomas Dickey <dickey@radix.net> wrote:
> > Interesting, I would have assumed that changing it is very easy (just
> > do it earlier). If that isn't possible for some reasons, then maybe
> > checking TIOCGWINSZ info twice, once at the beginning and once just after
> > installing the sigwinch handler, might do the trick?
> 
> I did something like that (setting the flag which tells ncurses
> that a SIGWINCH arrived) in last week's (20040814) patch.

Sorry for the many mails... but thinking about this issue it (and wehy you
said it is complicated to fix this), I wondered wether you just couldn't
block the sigwinch signal before initialisation and unblock it near the
end, after the signal handler is installed?

Unless the issues are vastly more complex than it looks like, this should
fix the bug nicely, without complicating the initialisation code.

-- 
                The choice of a                              |
      -----==-     _GNU_                                     |
      ----==-- _       generation     Marc Lehmann         +--
      ---==---(_)__  __ ____  __      pcg@goof.com         |e|
      --==---/ / _ \/ // /\ \/ /      http://schmorp.de/   --+
      -=====/_/_//_/\_,_/ /_/\_\      XX11-RIPE            |
                                                           |



Message sent on to Marc Lehmann <debian-reportbug@plan9.de>:
Bug#265631. Full text and rfc822 format available.

Message #40 received at 265631-submitter@bugs.debian.org (full text, mbox):

From: Thomas Dickey <dickey@his.com>
To: 265631-submitter@bugs.debian.org
Subject: Re: Bug#265631: libncurses5: race condition between setting up default SIGWINCH handler and TIOCGWINSZ
Date: Thu, 26 Aug 2004 05:02:15 -0400 (EDT)
On Thu, 26 Aug 2004, Marc wrote:

> On Sun, Aug 22, 2004 at 07:54:30PM -0400, Thomas Dickey <dickey@radix.net> wrote:
> > > Interesting, I would have assumed that changing it is very easy (just
> > > do it earlier). If that isn't possible for some reasons, then maybe
> > > checking TIOCGWINSZ info twice, once at the beginning and once just after
> > > installing the sigwinch handler, might do the trick?
> >
> > I did something like that (setting the flag which tells ncurses
> > that a SIGWINCH arrived) in last week's (20040814) patch.
>
> Sorry for the many mails... but thinking about this issue it (and wehy you
> said it is complicated to fix this), I wondered wether you just couldn't
> block the sigwinch signal before initialisation and unblock it near the
> end, after the signal handler is installed?

no - signals are done in a different module, and their internals aren't
that portable.  So I didn't want to touch it.

-- 
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net



Message sent on to Marc Lehmann <debian-reportbug@plan9.de>:
Bug#265631. Full text and rfc822 format available.

Message #43 received at 265631-submitter@bugs.debian.org (full text, mbox):

From: Thomas Dickey <dickey@his.com>
To: 265631-submitter@bugs.debian.org
Subject: Re: Bug#265631: libncurses5: race condition between setting up default SIGWINCH handler and TIOCGWINSZ
Date: Thu, 26 Aug 2004 05:38:34 -0400 (EDT)
On Thu, 26 Aug 2004, Marc wrote:

> I just tried ncurses-20040821 (0711 rollup + 0718, 0724, 0731, 0807, 0814
> and 0828 patches, I hope this was the correct order and complete), and the
> fix does not seem to fix the bug.
>
>    xterm -e jed # under ion3
>
> Still show the jed screen too small in about one out of 20 starts.

jed doesn't use ncurses.

-- 
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net



Information stored:
Bug#265631; Package libncurses5. Full text and rfc822 format available.

Acknowledgement sent to <pcg( Marc)@goof(A.).(Lehmann )com>:
Extra info received and filed, but not forwarded. Full text and rfc822 format available.

Message #48 received at 265631-quiet@bugs.debian.org (full text, mbox):

From: <pcg( Marc)@goof(A.).(Lehmann )com>
To: Thomas Dickey <dickey@his.com>, 265631-quiet@bugs.debian.org
Cc: 265631-submitter@bugs.debian.org
Subject: Re: Bug#265631: libncurses5: race condition between setting up default SIGWINCH handler and TIOCGWINSZ
Date: Thu, 26 Aug 2004 16:14:31 +0200
On Thu, Aug 26, 2004 at 05:38:34AM -0400, Thomas Dickey <dickey@his.com> wrote:
> On Thu, 26 Aug 2004, Marc wrote:
> 
> > I just tried ncurses-20040821 (0711 rollup + 0718, 0724, 0731, 0807, 0814
> > and 0828 patches, I hope this was the correct order and complete), and the
> > fix does not seem to fix the bug.
> >
> >    xterm -e jed # under ion3
> >
> > Still show the jed screen too small in about one out of 20 starts.
> 
> jed doesn't use ncurses.

Sorry, but that's just bullshit. You simply do not want to fix bugs, do
you?

Adding sigprocmask in ncurses fixes the jed problem, which is linked
against libncurses and obviously calls into it during startup, as placing
abort()'s strategically in newterm proves. That's the standard jed package
from debian, even, not something I compiled or changed myself.

This is not the first time that you ignore problems by outrageous and
wrong claims (like the changes entries). Why do you do this?

And yes, slowly I am getting fed up. If you can't acknowledge bugs in
your software, that's your problem. But trying to impress people by just
claiming, well, things that you can either look up and find to be wrong
yourself, or simply claiming things that you didn't bother to verify is not
professional. Worse, it doesn't look good either.

I'll spare you with bug reports and descriptions in the future. Obviously
it's not appreciated.

-- 
                The choice of a                              |
      -----==-     _GNU_                                     |
      ----==-- _       generation     Marc Lehmann         +--
      ---==---(_)__  __ ____  __      pcg@goof.com         |e|
      --==---/ / _ \/ // /\ \/ /      http://schmorp.de/   --+
      -=====/_/_//_/\_,_/ /_/\_\      XX11-RIPE            |
                                                           |



Message sent on to Marc Lehmann <debian-reportbug@plan9.de>:
Bug#265631. Full text and rfc822 format available.

Message sent on to Marc Lehmann <debian-reportbug@plan9.de>:
Bug#265631. Full text and rfc822 format available.

Message #54 received at 265631-submitter@bugs.debian.org (full text, mbox):

From: Thomas Dickey <dickey@his.com>
To: 265631-submitter@bugs.debian.org
Subject: Re: Bug#265631: libncurses5: race condition between setting up default SIGWINCH handler and TIOCGWINSZ
Date: Thu, 26 Aug 2004 14:11:31 -0400 (EDT)
On Thu, 26 Aug 2004, Marc wrote:

> On Thu, Aug 26, 2004 at 05:38:34AM -0400, Thomas Dickey <dickey@his.com> wrote:
> > On Thu, 26 Aug 2004, Marc wrote:
> >
> > > I just tried ncurses-20040821 (0711 rollup + 0718, 0724, 0731, 0807, 0814
> > > and 0828 patches, I hope this was the correct order and complete), and the
> > > fix does not seem to fix the bug.
> > >
> > >    xterm -e jed # under ion3
> > >
> > > Still show the jed screen too small in about one out of 20 starts.
> >
> > jed doesn't use ncurses.
>
> Sorry, but that's just bullshit. You simply do not want to fix bugs, do
> you?

sorry, but when you say something that's completely absurd, it's worth
pointing out.

(try reading the source for jed - sometime ;-)

-- 
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net



Information forwarded to debian-bugs-dist@lists.debian.org, Daniel Jacobowitz <ncurses-maint@debian.org>:
Bug#265631; Package libncurses5. Full text and rfc822 format available.

Acknowledgement sent to Daniel Jacobowitz <drow@false.org>:
Extra info received and forwarded to list. Copy sent to Daniel Jacobowitz <ncurses-maint@debian.org>. Full text and rfc822 format available.

Message #59 received at 265631@bugs.debian.org (full text, mbox):

From: Daniel Jacobowitz <drow@false.org>
To: "Marc A. Lehmann" <pcg@goof.com>, 265631@bugs.debian.org, Thomas Dickey <dickey@his.com>
Subject: Status of this bug
Date: Sat, 11 Jun 2005 00:53:38 -0400
I've read over the log of this bug report as part of an updated ncurses
package that I'm preparing.  My impression is that some changes were
made to ncurses, but they didn't fix Marc's problem with jed.

I have to agree with Thomas on one thing - jed doesn't use libncurses,
even in Debian.  At that point in time (last year), jed's GPM
dependency may have caused libncurses to be loaded and initialized, but
it doesn't today, so I can't check that.

So I don't think there's anything we can do about the jed problem, if
that still exists.  It looks like the change that Thomas made would
handle this problem, whether or not it's overkill.

Is there still an ncurses bug here?

-- 
Daniel Jacobowitz
CodeSourcery, LLC



Information forwarded to debian-bugs-dist@lists.debian.org, Daniel Jacobowitz <ncurses-maint@debian.org>:
Bug#265631; Package libncurses5. Full text and rfc822 format available.

Acknowledgement sent to Marc Lehmann <schmorp@schmorp.de>:
Extra info received and forwarded to list. Copy sent to Daniel Jacobowitz <ncurses-maint@debian.org>. Full text and rfc822 format available.

Message #64 received at 265631@bugs.debian.org (full text, mbox):

From: Marc Lehmann <schmorp@schmorp.de>
To: Daniel Jacobowitz <drow@false.org>
Cc: 265631@bugs.debian.org, Thomas Dickey <dickey@his.com>
Subject: Re: Status of this bug
Date: Sat, 11 Jun 2005 12:10:43 +0200
On Sat, Jun 11, 2005 at 12:53:38AM -0400, Daniel Jacobowitz <drow@false.org> wrote:
> I have to agree with Thomas on one thing - jed doesn't use libncurses,
> even in Debian.

   ldd /usr/bin/jed
           libncurses.so.5 => /usr/lib/libncurses.so.5 (0x00002aaaab40e000)

(this is on my amd64 machine with debian unstable)

   ii  jed                           0.99.16-5                     editor for programmers (textmode version)

I have no idea to what extent jed uses ncurses, but it's linked against it
in debain for sure.

> At that point in time (last year), jed's GPM
> dependency may have caused libncurses to be loaded and initialized, but
> it doesn't today, so I can't check that.

Unfortunately, I can not reproduce this problem with jed anymore, but as
this was a very time-sensitive race condition and I upgraded my machine
recently this isn't very conclusive.

I am happy to disregard jed, however, if it is just linked against ncurses
and doesn't use it for screen sizing purposes.

> So I don't think there's anything we can do about the jed problem, if
> that still exists.  It looks like the change that Thomas made would
> handle this problem, whether or not it's overkill.
> 
> Is there still an ncurses bug here?

I am not sure, the only thing in the changelog of ncurses seems to be this
change:

         + fake a SIGWINCH in newterm() to accommodate buggy terminal                                                                         
           emulators and window managers (Debian #265631).                                                                                    

however, this seems unrelated as there it's not a bug in any terminal
emulator or window manager, but in ncurses. As such, I cannot verify that the
fix actually fixes the ncurses bug instead of sth. else.

I think I clearly documented the bug in ncurses, and as I understand the
mechanism well, so I can elaborate further if anything is still unclear.

Unfortunately, reproducing this is a bit difficult, as it depeQnds on
external timing factors and the race is very short.

-- 
                The choice of a
      -----==-     _GNU_
      ----==-- _       generation     Marc Lehmann
      ---==---(_)__  __ ____  __      pcg@goof.com
      --==---/ / _ \/ // /\ \/ /      http://schmorp.de/
      -=====/_/_//_/\_,_/ /_/\_\      XX11-RIPE



Information forwarded to debian-bugs-dist@lists.debian.org, Daniel Jacobowitz <ncurses-maint@debian.org>:
Bug#265631; Package libncurses5. Full text and rfc822 format available.

Acknowledgement sent to Daniel Jacobowitz <drow@false.org>:
Extra info received and forwarded to list. Copy sent to Daniel Jacobowitz <ncurses-maint@debian.org>. Full text and rfc822 format available.

Message #69 received at 265631@bugs.debian.org (full text, mbox):

From: Daniel Jacobowitz <drow@false.org>
To: Marc Lehmann <schmorp@schmorp.de>
Cc: 265631@bugs.debian.org, Thomas Dickey <dickey@his.com>
Subject: Re: Status of this bug
Date: Sun, 12 Jun 2005 00:31:52 -0400
On Sat, Jun 11, 2005 at 12:10:43PM +0200, Marc Lehmann wrote:
> On Sat, Jun 11, 2005 at 12:53:38AM -0400, Daniel Jacobowitz <drow@false.org> wrote:
> > I have to agree with Thomas on one thing - jed doesn't use libncurses,
> > even in Debian.
> 
>    ldd /usr/bin/jed
>            libncurses.so.5 => /usr/lib/libncurses.so.5 (0x00002aaaab40e000)
> 
> (this is on my amd64 machine with debian unstable)
> 
>    ii  jed                           0.99.16-5                     editor for programmers (textmode version)
> 
> I have no idea to what extent jed uses ncurses, but it's linked against it
> in debain for sure.

ii  jed                  0.99.16-5            editor for programmers (textmode version)
drow@nevyn:~% ldd =jed
        libslang.so.1 => /lib/libslang.so.1 (0xb7f58000)
        libgpm.so.1 => /usr/lib/libgpm.so.1 (0xb7f51000)
        libutil.so.1 => /lib/tls/i686/cmov/libutil.so.1 (0xb7f4e000)
        libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0xb7f2c000)
        libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7df7000)
        libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0xb7df4000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0xb7fea000)

Not on i386/unstable it isn't.  I presume you have gpm << 1.19.6-20
installed.  Then libgpm will have a dependency on ncurses - it does not
come from jed.

> I am not sure, the only thing in the changelog of ncurses seems to be this
> change:
> 
>          + fake a SIGWINCH in newterm() to accommodate buggy terminal                                                                         
>            emulators and window managers (Debian #265631).                                                                                    
> 
> however, this seems unrelated as there it's not a bug in any terminal
> emulator or window manager, but in ncurses. As such, I cannot verify that the
> fix actually fixes the ncurses bug instead of sth. else.
> 
> I think I clearly documented the bug in ncurses, and as I understand the
> mechanism well, so I can elaborate further if anything is still unclear.

Did you look at the change?  Description aside, both Thomas and I
believe there is no remaining way to trigger this problem.  If you
can explain a path through the code that still has a race, we can fix
it.

[Sorry for the delay.  Your outgoing mail goes as root, which is weird,
and triggers my spam filters.]

-- 
Daniel Jacobowitz
CodeSourcery, LLC



Information forwarded to debian-bugs-dist@lists.debian.org, Daniel Jacobowitz <ncurses-maint@debian.org>:
Bug#265631; Package libncurses5. Full text and rfc822 format available.

Acknowledgement sent to Marc Lehmann <schmorp@schmorp.de>:
Extra info received and forwarded to list. Copy sent to Daniel Jacobowitz <ncurses-maint@debian.org>. Full text and rfc822 format available.

Message #74 received at 265631@bugs.debian.org (full text, mbox):

From: Marc Lehmann <schmorp@schmorp.de>
To: Daniel Jacobowitz <drow@false.org>
Cc: 265631@bugs.debian.org, Thomas Dickey <dickey@his.com>
Subject: Re: Status of this bug
Date: Sun, 12 Jun 2005 15:39:10 +0200
On Sun, Jun 12, 2005 at 12:31:52AM -0400, Daniel Jacobowitz <drow@false.org> wrote:
> On Sat, Jun 11, 2005 at 12:10:43PM +0200, Marc Lehmann wrote:
> > On Sat, Jun 11, 2005 at 12:53:38AM -0400, Daniel Jacobowitz <drow@false.org> wrote:
> 
> > I think I clearly documented the bug in ncurses, and as I understand the
> > mechanism well, so I can elaborate further if anything is still unclear.
> 
> Did you look at the change?

No. I am the wrong person to ask anyways, as, as I wrote, I tried to
understand the ncurses code but failed to follow it completely, otherwise I
would have described the race in ncurses better.
   
> Description aside, both Thomas and I believe there is no remaining way
> to trigger this problem.

I fully trust you, then. I'd still sugegst to fix the description then, as it
is simply misleading. It's better not to describe the fix at all than to
describe it wrongly.

> If you can explain a path through the code that still has a race, we can
> fix it.

I couldn't explain the original race path either, so, no, I cannot. I do
trust that someone with working knowledge of the code can fix the bug with
realtive ease.

If you think it's fixed then just claim the bug closed => it can easily be
reopened in case there is a bug left...

> [Sorry for the delay.  Your outgoing mail goes as root, which is weird,
> and triggers my spam filters.]

I don't understand why that would be weird, but it doesn't matter. In any
case, this looks like it's time to improve the filters :)

-- 
                The choice of a
      -----==-     _GNU_
      ----==-- _       generation     Marc Lehmann
      ---==---(_)__  __ ____  __      pcg@goof.com
      --==---/ / _ \/ // /\ \/ /      http://schmorp.de/
      -=====/_/_//_/\_,_/ /_/\_\      XX11-RIPE



Information forwarded to debian-bugs-dist@lists.debian.org, Daniel Jacobowitz <ncurses-maint@debian.org>:
Bug#265631; Package libncurses5. Full text and rfc822 format available.

Acknowledgement sent to Daniel Jacobowitz <drow@false.org>:
Extra info received and forwarded to list. Copy sent to Daniel Jacobowitz <ncurses-maint@debian.org>. Full text and rfc822 format available.

Message #79 received at 265631@bugs.debian.org (full text, mbox):

From: Daniel Jacobowitz <drow@false.org>
To: Marc Lehmann <schmorp@schmorp.de>
Cc: 265631@bugs.debian.org, Thomas Dickey <dickey@his.com>
Subject: Re: Status of this bug
Date: Sun, 12 Jun 2005 10:31:42 -0400
On Sun, Jun 12, 2005 at 03:39:10PM +0200, Marc Lehmann wrote:
> I fully trust you, then. I'd still sugegst to fix the description then, as it
> is simply misleading. It's better not to describe the fix at all than to
> describe it wrongly.

There's a reference to this bug report in the message, so I think we're
OK.  If someone wants the details then they can find them here.

> > [Sorry for the delay.  Your outgoing mail goes as root, which is weird,
> > and triggers my spam filters.]
> 
> I don't understand why that would be weird, but it doesn't matter. In any
> case, this looks like it's time to improve the filters :)

Hint: It matches procmail's predefined FROM_MAILER.

-- 
Daniel Jacobowitz
CodeSourcery, LLC



Reply sent to Daniel Jacobowitz <dan@debian.org>:
You have taken responsibility. Full text and rfc822 format available.

Notification sent to Marc Lehmann <debian-reportbug@plan9.de>:
Bug acknowledged by developer. Full text and rfc822 format available.

Message #84 received at 265631-close@bugs.debian.org (full text, mbox):

From: Daniel Jacobowitz <dan@debian.org>
To: 265631-close@bugs.debian.org
Subject: Bug#265631: fixed in ncurses 5.4-5
Date: Sun, 12 Jun 2005 12:47:06 -0400
Source: ncurses
Source-Version: 5.4-5

We believe that the bug you reported is fixed in the latest version of
ncurses, which is due to be installed in the Debian FTP archive:

libncurses5-dbg_5.4-5_i386.deb
  to pool/main/n/ncurses/libncurses5-dbg_5.4-5_i386.deb
libncurses5-dev_5.4-5_i386.deb
  to pool/main/n/ncurses/libncurses5-dev_5.4-5_i386.deb
libncurses5_5.4-5_i386.deb
  to pool/main/n/ncurses/libncurses5_5.4-5_i386.deb
libncursesw5-dbg_5.4-5_i386.deb
  to pool/main/n/ncurses/libncursesw5-dbg_5.4-5_i386.deb
libncursesw5-dev_5.4-5_i386.deb
  to pool/main/n/ncurses/libncursesw5-dev_5.4-5_i386.deb
libncursesw5_5.4-5_i386.deb
  to pool/main/n/ncurses/libncursesw5_5.4-5_i386.deb
ncurses-base_5.4-5_all.deb
  to pool/main/n/ncurses/ncurses-base_5.4-5_all.deb
ncurses-bin_5.4-5_i386.deb
  to pool/main/n/ncurses/ncurses-bin_5.4-5_i386.deb
ncurses-term_5.4-5_all.deb
  to pool/main/n/ncurses/ncurses-term_5.4-5_all.deb
ncurses_5.4-5.diff.gz
  to pool/main/n/ncurses/ncurses_5.4-5.diff.gz
ncurses_5.4-5.dsc
  to pool/main/n/ncurses/ncurses_5.4-5.dsc



A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 265631@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Daniel Jacobowitz <dan@debian.org> (supplier of updated ncurses package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.7
Date: Sun, 12 Jun 2005 11:17:54 -0400
Source: ncurses
Binary: ncurses-base lib64ncurses5 libncursesw5-dev libncursesw5-dbg ncurses-bin libncurses5 libncursesw5 libncurses5-dev ncurses-term libncurses5-dbg lib64ncurses5-dev
Architecture: source i386 all
Version: 5.4-5
Distribution: unstable
Urgency: low
Maintainer: Daniel Jacobowitz <ncurses-maint@debian.org>
Changed-By: Daniel Jacobowitz <dan@debian.org>
Description: 
 libncurses5 - Shared libraries for terminal handling
 libncurses5-dbg - Debugging/profiling libraries for ncurses
 libncurses5-dev - Developer's libraries and docs for ncurses
 libncursesw5 - Shared libraries for terminal handling (wide character support)
 libncursesw5-dbg - Debugging/profiling libraries for ncurses
 libncursesw5-dev - Developer's libraries for ncursesw
 ncurses-base - Descriptions of common terminal types
 ncurses-bin - Terminal-related programs and man pages
 ncurses-term - Additional terminal type definitions
Closes: 55637 110586 254316 257872 259253 265631 265784 273463 280687 283059 295083 301376 305704
Changes: 
 ncurses (5.4-5) unstable; urgency=low
 .
   * Use quilt to manage patches.
   * Update to upstream patch level 20050604.
     - Hurd build fix merged upstream.
     - Part of explicitly signed character patch merged upstream.
     - Corrected man page for mouseinterval (Closes: #280687).
     - Improved support for the zn_CH.GBK locale (Closes: #301376).
     - Improved terminfo entry for putty (Closes: #305704).
     - Explain the reference to ded(1) on the default_colors(3ncurses)
       man page (Closes: #295083).
     - Reset xterm mouse mode in various terminfo entries (Closes: #55637).
     - Check the size of the terminal after newterm() (Closes: #265631).
   * Updated xterm terminfo entry from xterm 200.  Combined with the
     upstream patch level, this (Closes: #254316).
   * Install the examples in libncurses5-dev again (Closes: #257872).
   * Remove use of test -a in ncurses-base and ncurses-term preinsts
     (Closes: #259253).
   * Enable gpm support (Closes: #110586).
   * Load libgpm.so.1 instead of libgpm.so.
   * Merge the Debian rxvt terminfo entry with upstream changes.
     - Upstream added cnorm to rxvt's reset string, so that the block cursor
       is restored if civis was used (Closes: #265784).
   * Fix the default bindings for F1-F4 in rxvt.
   * Use smkx instead of rmkx in rxvt's reset string, so that reset does
     not leave the keypad in the wrong state.
   * Move libncursesw.so.5 to /lib (Closes: #273463).
   * Added a patch from NIIBE Yutaka to support cross-compilation between
     two Debian systems (Closes: #283059).
   * Correct the section for the inwstr(3ncurses) man page.
   * Add myself to Uploaders.
   * Correct sections on the tack(1) man page.
   * Use symlinks instead of hardlinks for the terminfo database.
   * Remove a four-year-old workaround for an ia64 gcc bug.
   * Update shlibs file to (>= 5.4-5).
   * Configure using --disable-lp64 for compatibility on 64-bit architectures.
Files: 
 ed9623c2b270a187fa46c0b3cc04eb12 883 libs standard ncurses_5.4-5.dsc
 435ba55597cb03d7b09f97933d0be1dd 799336 libs standard ncurses_5.4-5.diff.gz
 5b37214b39694b3d0369c136f3cc893a 288672 base required libncurses5_5.4-5_i386.deb
 6d4bfb5f1ed426a74d7c6532213761ab 1247002 libdevel optional libncurses5-dev_5.4-5_i386.deb
 926a22295e7753f9f3c947d536ff5a56 5266072 libdevel extra libncurses5-dbg_5.4-5_i386.deb
 dd88ae6881a696c2391c78a11b05a675 304144 libs standard libncursesw5_5.4-5_i386.deb
 61b9db3fa98029e1c58e097b9f999876 416970 libdevel optional libncursesw5-dev_5.4-5_i386.deb
 123e8306059e277951db311ef3b00dfe 5800478 libdevel extra libncursesw5-dbg_5.4-5_i386.deb
 e4bd77cd68251ec9e0b8c71fad38b877 207632 base required ncurses-bin_5.4-5_i386.deb
 83464ad6d36b54aadb09d4061182fcc6 12170 base required ncurses-base_5.4-5_all.deb
 5d9a94886bc9d4268c50b088c62e20b8 277774 admin standard ncurses-term_5.4-5_all.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFCrGOEbgOPXuCjg3cRAugAAJwNh4F07jmdbfRxOG4WGlUZL8pVQwCfQxhr
+9+y4ZMP3m44B/knpDOzB/c=
=mIcU
-----END PGP SIGNATURE-----




Send a report that this bug log contains spam.


Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Sun Apr 20 21:16:02 2014; Machine Name: buxtehude.debian.org

Debian Bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.