Bug#619355: #619355 - lynx fails to stop on SIGTSTP (C-z)
I've not been able to reproduce this. -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net signature.asc Description: Digital signature
Bug#619355: #619355 lynx fails to stop on SIGTSTP (C-z)
On Tue, 5 Jul 2011, Ivan Shmakov wrote:
Thomas Dickey writes:
[…]
> Lynx is using ncurses for handling SIGTSTP most of the time. It
> sets/unsets a handler when it is doing a system() call. If your test
> scenario doesn't run any external programs, then perhaps the problem
> is in ncurses (or the way lynx uses it).
Somehow, “ncurses” is synonymous with “environment variables” to
me. Indeed, running lynx within a clean environment, via either
schroot(1) or env(1) ($ env -i TERM="$TERM" lynx), resulted in
apparently correct SIGTSTP handling.
Several iterations after, I've found a minimal ${LYNX_CFG}
example that leads to the problem I've described:
$ cat < "$LYNX_CFG"
INCLUDE:/etc/lynx-cur/lynx.cfg
USE_MOUSE:TRUE
$
(I've added USE_MOUSE:TRUE to my ${LYNX_CFG} almost five years
ago, and it was there ever since, even though I haven't actually
used it much.)
thanks (will experiment and see if I can reproduce this).
--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net
Bug#619355: #619355 lynx fails to stop on SIGTSTP (C-z)
> Thomas Dickey writes:
[…]
> Lynx is using ncurses for handling SIGTSTP most of the time. It
> sets/unsets a handler when it is doing a system() call. If your test
> scenario doesn't run any external programs, then perhaps the problem
> is in ncurses (or the way lynx uses it).
Somehow, “ncurses” is synonymous with “environment variables” to
me. Indeed, running lynx within a clean environment, via either
schroot(1) or env(1) ($ env -i TERM="$TERM" lynx), resulted in
apparently correct SIGTSTP handling.
Several iterations after, I've found a minimal ${LYNX_CFG}
example that leads to the problem I've described:
$ cat < "$LYNX_CFG"
INCLUDE:/etc/lynx-cur/lynx.cfg
USE_MOUSE:TRUE
$
(I've added USE_MOUSE:TRUE to my ${LYNX_CFG} almost five years
ago, and it was there ever since, even though I haven't actually
used it much.)
--
FSF associate member #7257
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#619355: #619355 lynx fails to stop on SIGTSTP (C-z)
On Tue, Jul 05, 2011 at 01:33:22PM +0700, Ivan Shmakov wrote:
> > Ivan Shmakov writes:
>
> > I should probably try to compare strace(1)'s???
>
> I've grep'ed the strace for ???rt_sig???. The results for the first
> and second SIGTSTP are MIME'd.
>
> And there's a difference:
>
> ??? first SIGTSTP:
>
> rt_sigaction(SIGTSTP, {0x7f061efbf800, [], SA_RESTORER|SA_RESTART,
> 0x7f061e5461e0}, NULL, 8) = 0
>
> ??? second SIGTSTP:
>
> rt_sigaction(SIGTSTP, {SIG_IGN}, NULL, 8) = 0
>
> Do I understand it correctly that the SIGTSTP signal handler is
> not properly reset in the latter case?
Perhaps - lynx is calling sigaction, which in turn calls rt_sigaction.
But you may be looking at the initialization section, since that's also
where SIGWINCH is setup.
Lynx is using ncurses for handling SIGTSTP most of the time.
It sets/unsets a handler when it is doing a system() call.
If your test scenario doesn't run any external programs, then
perhaps the problem is in ncurses (or the way lynx uses it).
--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net
signature.asc
Description: Digital signature
Bug#619355: #619355 lynx fails to stop on SIGTSTP (C-z)
> Thomas Dickey writes: > On Thu, 19 May 2011, Ivan Shmakov wrote: > Thomas Dickey writes: >>> This seems to work for me (trying both tcsh and bash). Can you >>> provide more details (perhaps locale, shell/version, etc). >> I cannot reproduce the issue on a few of fresh Squeeze incarnations, >> either. >> However, the issue readily manifests itself on a Squeeze system >> which still has some Lenny packages yet to be upgraded. (Of those, >> only debconf is in the lynx-cur Depends: list.) So, I guess that >> there's some library package used by Lynx that causes the problem. >> I'm going to try my luck tracking it down. > thanks - it doesn't sound simple to track down (though I'd assume > it's either in the bash dependencies, or lynx's). Well, on a host on which such an condition occurs, I also have a chroot environment with Debian Squeeze installed. Unsurprisingly, running Lynx there doesn't lead to the problem. What I've found surprising, however, is that if I run chroot environment's Lynx (using all the libraries installed there) without actually chroot'ing, it also fails to respond to SIGTSTP correctly! I've run chroot'ed Lynx) like: • using schroot(1) (reacts to SIGTSTP): $ LC_ALL=C schroot -c squeeze -- /usr/bin/lynx (note that no Shell is involved there); • using LD_LIBRARY_PATH (fails to react to SIGTSTP): $ LC_ALL=C LD_LIBRARY_PATH="$p"/lib:"$p"/usr/lib \ "$p"/lib/ld-linux-x86-64.so.2 "$p"/usr/bin/lynx.cur (locale is disabled so that the base system's /usr/lib/gconv/ isn't used; I've also used ld-linux.so from chroot.) I've also MIME'd the /proc/LYNXID/maps file for the latter case. Seemingly, the above rules out the possibility of a broken Shell or library. I should probably try to compare strace(1)'s… […] -- FSF associate member #7257 0040-00537000 r-xp fc:0d 24726 /srv/chroot/2011-01-25/usr/bin/lynx.cur 00737000-00764000 rw-p 00137000 fc:0d 24726 /srv/chroot/2011-01-25/usr/bin/lynx.cur 00764000-007d3000 rw-p 00764000 00:00 0 7f6f15957000-7f6f1595c000 r-xp fc:0d 8473 /srv/chroot/2011-01-25/usr/lib/libgpm.so.2.0.0 7f6f1595c000-7f6f15b5c000 ---p 5000 fc:0d 8473 /srv/chroot/2011-01-25/usr/lib/libgpm.so.2.0.0 7f6f15b5c000-7f6f15b5d000 rw-p 5000 fc:0d 8473 /srv/chroot/2011-01-25/usr/lib/libgpm.so.2.0.0 7f6f15b5d000-7f6f15b6 rw-p 7f6f15b5d000 00:00 0 7f6f15b6-7f6f15b63000 r-xp fc:0d 8693 /srv/chroot/2011-01-25/usr/lib/libgpg-error.so.0.4.0 7f6f15b63000-7f6f15d62000 ---p 3000 fc:0d 8693 /srv/chroot/2011-01-25/usr/lib/libgpg-error.so.0.4.0 7f6f15d62000-7f6f15d63000 rw-p 2000 fc:0d 8693 /srv/chroot/2011-01-25/usr/lib/libgpg-error.so.0.4.0 7f6f15d63000-7f6f15d73000 r-xp fc:0d 8698 /srv/chroot/2011-01-25/usr/lib/libtasn1.so.3.1.9 7f6f15d73000-7f6f15f72000 ---p 0001 fc:0d 8698 /srv/chroot/2011-01-25/usr/lib/libtasn1.so.3.1.9 7f6f15f72000-7f6f15f73000 rw-p f000 fc:0d 8698 /srv/chroot/2011-01-25/usr/lib/libtasn1.so.3.1.9 7f6f15f73000-7f6f15f74000 rw-p 7f6f15f73000 00:00 0 7f6f15f74000-7f6f15f76000 r-xp fc:0c 26726 /srv/chroot/2011-01-25/lib/libdl-2.11.2.so 7f6f15f76000-7f6f16176000 ---p 2000 fc:0c 26726 /srv/chroot/2011-01-25/lib/libdl-2.11.2.so 7f6f16176000-7f6f16177000 r--p 2000 fc:0c 26726 /srv/chroot/2011-01-25/lib/libdl-2.11.2.so 7f6f16177000-7f6f16178000 rw-p 3000 fc:0c 26726 /srv/chroot/2011-01-25/lib/libdl-2.11.2.so 7f6f16178000-7f6f162d r-xp fc:0c 26728 /srv/chroot/2011-01-25/lib/libc-2.11.2.so 7f6f162d-7f6f164cf000 ---p 00158000 fc:0c 26728 /srv/chroot/2011-01-25/lib/libc-2.11.2.so 7f6f164cf000-7f6f164d3000 r--p 00157000 fc:0c 26728 /srv/chroot/2011-01-25/lib/libc-2.11.2.so 7f6f164d3000-7f6f164d4000 rw-p 0015b000 fc:0c 26728 /srv/chroot/2011-01-25/lib/libc-2.11.2.so 7f6f164d4000-7f6f164d9000 rw-p 7f6f164d4000 00:00 0 7f6f164d9000-7f6f164e2000 r-xp fc:0c 26695 /srv/chroot/2011-01-25/lib/libbsd.so.0.2.0 7f6f164e2000-7f6f166e2000 ---p 9000 fc:0c 26695 /srv/chroot/2011-01-25/lib/libbsd.so.0.2.0 7f6f166e2000-7f6f166e3000 rw-p 9000 fc:0c 26695 /srv/chroot/2011-01-25/lib/libbsd.so.0.2.0 7f6f166e3000-7f6f166e4000 rw-p 7f6f166e3000 00:00 0 7f6f166e4000-7f6f16758000 r-xp fc:0d 8691 /srv/chroot/2011-01-25/usr/lib/libgcrypt.so.11.5.3 7f6f16758000-7f6f16958000 -
Bug#619355: #619355 lynx fails to stop on SIGTSTP (C-z)
> Ivan Shmakov writes:
[…]
> I should probably try to compare strace(1)'s…
I've grep'ed the strace for “rt_sig”. The results for the first
and second SIGTSTP are MIME'd.
And there's a difference:
• first SIGTSTP:
rt_sigaction(SIGTSTP, {0x7f061efbf800, [], SA_RESTORER|SA_RESTART,
0x7f061e5461e0}, NULL, 8) = 0
• second SIGTSTP:
rt_sigaction(SIGTSTP, {SIG_IGN}, NULL, 8) = 0
Do I understand it correctly that the SIGTSTP signal handler is
not properly reset in the latter case?
--
FSF associate member #7257
rt_sigprocmask(SIG_BLOCK, [ALRM WINCH], [TSTP], 8) = 0
rt_sigprocmask(SIG_BLOCK, [TTOU], NULL, 8) = 0
rt_sigprocmask(SIG_UNBLOCK, [TSTP TTOU], NULL, 8) = 0
rt_sigaction(SIGTSTP, {SIG_DFL}, {0x7f061efbf800, [], SA_RESTORER|SA_RESTART,
0x7f061e5461e0}, 8) = 0
rt_sigaction(SIGTSTP, {0x7f061efbf800, [], SA_RESTORER|SA_RESTART,
0x7f061e5461e0}, NULL, 8) = 0
rt_sigaction(SIGTSTP, {SIG_IGN}, {0x7f061efbf800, [], SA_RESTORER|SA_RESTART,
0x7f061e5461e0}, 8) = 0
rt_sigaction(SIGWINCH, {0x7f0617332330, [], SA_RESTORER, 0x7f061e5461e0},
{0x443ee0, [WINCH], SA_RESTORER|SA_RESTART, 0x7f061e5461e0}, 8) = 0
rt_sigaction(SIGTSTP, {SIG_IGN}, {SIG_IGN}, 8) = 0
rt_sigaction(SIGTSTP, {0x7f061efbf800, [], SA_RESTORER|SA_RESTART,
0x7f061e5461e0}, NULL, 8) = 0
rt_sigprocmask(SIG_SETMASK, [TSTP], NULL, 8) = 0
rt_sigreturn(0x2) = 0
rt_sigprocmask(SIG_BLOCK, [ALRM WINCH], [TSTP], 8) = 0
rt_sigprocmask(SIG_BLOCK, [TTOU], NULL, 8) = 0
rt_sigaction(SIGTSTP, {SIG_IGN}, NULL, 8) = 0
rt_sigaction(SIGWINCH, {0x443ee0, [WINCH], SA_RESTORER|SA_RESTART,
0x7f061e5461e0}, NULL, 8) = 0
rt_sigprocmask(SIG_UNBLOCK, [TSTP TTOU], NULL, 8) = 0
rt_sigaction(SIGTSTP, {SIG_DFL}, {SIG_IGN}, 8) = 0
rt_sigaction(SIGTSTP, {SIG_IGN}, NULL, 8) = 0
rt_sigaction(SIGTSTP, {SIG_IGN}, {SIG_IGN}, 8) = 0
rt_sigaction(SIGWINCH, {0x7f0617332330, [], SA_RESTORER, 0x7f061e5461e0},
{0x443ee0, [WINCH], SA_RESTORER|SA_RESTART, 0x7f061e5461e0}, 8) = 0
rt_sigaction(SIGTSTP, {SIG_IGN}, {SIG_IGN}, 8) = 0
rt_sigaction(SIGTSTP, {SIG_IGN}, NULL, 8) = 0
rt_sigprocmask(SIG_SETMASK, [TSTP], NULL, 8) = 0
rt_sigreturn(0x2) = 0
Bug#619355: #619355 lynx fails to stop on SIGTSTP (C-z)
On Thu, 19 May 2011, Ivan Shmakov wrote: Thomas Dickey writes: > This seems to work for me (trying both tcsh and bash). Can you > provide more details (perhaps locale, shell/version, etc). I cannot reproduce the issue on a few of fresh Squeeze incarnations, either. However, the issue readily manifests itself on a Squeeze system which still has some Lenny packages yet to be upgraded. (Of those, only debconf is in the lynx-cur Depends: list.) So, I guess that there's some library package used by Lynx that causes the problem. I'm going to try my luck tracking it down. thanks - it doesn't sound simple to track down (though I'd assume it's either in the bash dependencies, or lynx's). Thanks. (The report should probably downgraded to Severity: minor, as it seemingly may only cause an inconvenience after upgrade, and only if something went wrong, or if for some reason some packages were left not upgraded.) -- FSF associate member #7257 -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#619355: #619355 lynx fails to stop on SIGTSTP (C-z)
> Thomas Dickey writes: > This seems to work for me (trying both tcsh and bash). Can you > provide more details (perhaps locale, shell/version, etc). I cannot reproduce the issue on a few of fresh Squeeze incarnations, either. However, the issue readily manifests itself on a Squeeze system which still has some Lenny packages yet to be upgraded. (Of those, only debconf is in the lynx-cur Depends: list.) So, I guess that there's some library package used by Lynx that causes the problem. I'm going to try my luck tracking it down. Thanks. (The report should probably downgraded to Severity: minor, as it seemingly may only cause an inconvenience after upgrade, and only if something went wrong, or if for some reason some packages were left not upgraded.) -- FSF associate member #7257 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#619355: #619355 lynx fails to stop on SIGTSTP (C-z)
This seems to work for me (trying both tcsh and bash). Can you provide more details (perhaps locale, shell/version, etc). thanks -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net signature.asc Description: Digital signature
