[Python-bugs-list] Signal processing bug (Linux threads, readline, whatever else) (PR#196)
flight@mathi.uni-heidelberg.de
flight@mathi.uni-heidelberg.de
Wed, 2 Feb 2000 02:47:09 -0500 (EST)
--FL5UXtIhxfXey3p5
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Hi,
this must be the strangest bug report ever sent to bugs-py ;-).
I don't expect a resolution for this bug from you, I just wanted to make
sure this thing is recorded and the BTS. Perhaps somebody could give me a
hint where I could look for the misbehavior. Candidates seem to be glibc,
LinuxThreads, GNU readline, the Python readline module and the Python thread
support ;-)
In 1.5.2, there's a strange problem with signals on Linux systems. This has
been discussed before on the mailing list, probably it even has a relation
to Bug#102 ("incorrect signal processing"), but IMHO this reports adds a few
other aspects. Definitely it is a (platform-specific) problem in 1.5.2.
I have problems describing the bug, since the behavior seems to depend on so
many parameters. The most obvious incarnation of the problem is probably
this:
In the Python 1.5.2 interpreter included with Debian 2.2 ("potato"), if you
press Control-C on the command line (or send a SIGINT), the interpreter
exits to the shell:
freefly;104> python
Python 1.5.2 (#0, Sep 13 1999, 09:12:57) [GCC 2.95.1 19990816 (release)]=
on
linux2=20
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>>> [Ctrl-C]
freefly;105>=20
Normally, you'd expect a KeyboardInterrupt exception here.
Now I tried and compiled different configurations of Python (each from a
pristine source tree) on this Debian system:
(151+t+rl) Python 1.5.1 (threads, readline)
(152) Python 1.5.2 (no threads, no readline) =20
(152+rl) Python 1.5.2 (no threads, readline)
(152+t) Python 1.5.2 (threads, no readline)
(152+t+rl) Python 1.5.2 (threads, readline)
(152+pth+rl) Python 1.5.2 (GNU Pth threads, readline)
Thread support was realized with glibc 2.1.2's LinuxThreads, i.e. pthreads.
readline was GNU readline 2.1 (for the record, I also tried 4.1beta3, but
this made no difference).
When I refer to Debian 2.1 ("slink"), this is a system with glibc 2.0.7 and
the same GNU readline version 2.1.
The following tables show the output of some experiments with those
configurations. The [] brackets show the keys pressed. Note that a line like
"[Ctrl-C][Enter]" implies that the interpreter showed no visible reaction to
the first Ctrl-C! "----" lines mean that I started up a new clean session.
(1) This is what happens when you start up a new interpreter and press
Ctrl-C once, twice and so on, while on the command line:
152,152+t 152+rl,152+pth+rl 152+t+rl 151+t+rl
=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D
------------------ ---------------- ------------- ----------------
>>> [Ctrl-C][Ctrl-C] >>> [Ctrl-C] >>> [Ctrl-C] >>> [Ctrl-C][Ct...]
KeyboardInterrupt KeyboardInterrupt freefly:5> ----------------
>>> [Ctrl-C] >>> [Ctrl-C] -------------
KeyboardInterrupt KeyboardInterrupt
>>> [Ctrl-C] >>> [Ctrl-C]
KeyboardInterrupt KeyboardInterrupt
>>> [Ctrl-C] >>> [Ctrl-C]
KeyboardInterrupt KeyboardInterrupt
------------------ ----------------
152+t+rl (on a Debian 2.1 system)
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
---------------------
>>> [Ctrl-C]
KeyboardInterrupt
>>> [Ctrl-C][Ctr...]
---------------------
-> 1.5.2 with readline but without LinuxThreads is right.
-> For some reason, 1.5.2 without readline ignores the first SIGINT.
-> 1.5.2 with both readline and LinuxThreads kill the interpreter.
-> 1.5.1 seems to ignore all SIGINTs's. =20
-> For 1.5.2 running glibc 2.0.7 (instead of 2.1.2) and readline, the
interpreter doesn't get killed, but still after the first SIGINT all
following SIGINTs are ignored.
=20
-> It's worth a note that with only one of readline or thread support, the
package seems to behave more reasonable; have both enabled is bad.
=20
-> With threading support by means of GNU Pth (instead of the native libc6
LinuxThreads), the package behaves more correctly, too!
=20
(2) Now on those systems who seemed to ignore the first SIGINT, I pressed
Enter after it:
152,152+t 151+t+rl
=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=
=3D
--------------------- --------------------
>>> [Ctrl-C][Enter] >>> [Ctrl-C][Enter]
Traceback (innermost last): Traceback (innermost last):
File "<stdin>", line 0, in ? File "<stdin>", line 0, in ?
KeyboardInterrupt KeyboardInterrupt
>>> [Ctrl-C] >>> [Ctrl-C][Enter]
KeyboardInterrupt Traceback (innermost last):
--------------------- File "<stdin>", line 0, in ?
KeyboardInterrupt
>>>
--------------------
=20
-> Obviously, the interpreter *DID* record the SIGINT in the first place,
it just didn't provoke any immediate action=20
-> On 1.5.2 without readline, the second and all following SIGINTs are
handled as one would expect.
-> 1.5.1 with thread and readline shows this strange behavior not only for
the first, but also for the second and any following SIGINT.
=20
(3) On the glibc 2.0.7 system, I verified that indeed all subsequent SIGINTs
are ignored. You're not able even to interrupt a loop, after the
interpreter has received a SIGINT while he was on the command line:
=20
152+t+rl (on a Debian 2.1 system)
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D
---------------------
>>> [Ctrl-C]
KeyboardInterrupt
>>> [Ctrl-C][Enter]
>>> [Ctrl-C][Enter]
{kein weiteres SIGINT
wird akzeptiert, auch im Laufen:}
>>> for i in xrange(1000): print i
=2E..
1
2
=2E..
[Ctrl-C]
400
401
=2E..
999
>>>
---------------------
---------------------
>>> for i in xrange(1000): print i
=2E..
1
2
=2E..
[Ctrl-C]
400
401
Traceback (innermost last):
File "<stdin>", line 1, in ?
KeyboardInterrupt
>>> for i in xrange(1000): print i
=2E..
1
2
=2E..
[Ctrl-C]
400
401
Traceback (innermost last):
File "<stdin>", line 1, in ?
KeyboardInterrupt
>>> [Ctrl-C]
KeyboardInterrupt
>>> for i in xrange(1000): print i
=2E..
1
2
=2E..
[Ctrl-C]
400
401
=2E..
999
>>>
---------------------
-> Note that it didn't hurt to break multiple times into a loop;
only SIGINTs on the command line do mess up the interpreter!
=20
=20
(4) In the Debian 2.2 Python package, you have to be careful not to kill the
interpreter; that's especially a problem when you try to break into a
loop--if you hold down Ctrl-C for too long, the interpreter quits!
=20
152+t+rl (Debian 2.2 package)
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D
---------------------
>>> [Ctrl-C]
freefly:5>
---------------------
---------------------
>>> for i in xrange(1000): print i
=2E..
1
2
=2E..
[Ctrl-C]
400
401
KeyboardInterrupt
>>>
---------------------
---------------------
>>> for i in xrange(1000): print i
=2E..
1
2
=2E..
[Ctrl-C pressed down for a longer time]
400
401
freefly;19>=20
---------------------
(5) The Debian 2.2 package behaves more reasonable when the readline module
has been moved out of the way:
152+t (Debian 2.2 package, readline module moved out of the way)
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
---------------------
>>> [Ctrl-C][Ctrl-C]
KeyboardInterrupt
>>> ... (vgl. 152, 152+t)
---------------------
>>> for i in xrange(1000): print i
=2E..
1
2
=2E..
[Ctrl-C]
400
401
40[Enter]
Traceback (innermost last):
File "<stdin>", line 0, in ?
KeyboardInterrupt
>>> for i in xrange(1000): print i
=2E..
1
2
=2E..
[Ctrl-C]
400
401
KeyboardInterrupt
>>>
--FL5UXtIhxfXey3p5
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.1 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE4luLt3eVfDf25G40RAQw9AKDhLyI7RDYt3G85Rxet2ZlK1b1nKwCg3zl/
tasWxAOGLUK3K3ucMBbhBag=
=PTOI
-----END PGP SIGNATURE-----
--FL5UXtIhxfXey3p5--