3772858d-27d8-44b0-a664-d68674859f36
commented
23 years ago Jitterbug-Id: 196 Submitted-By: Gregor Hoffleit \flight@mathi.uni-heidelberg.de\ Date: Tue, 1 Feb 2000 14:43:09 +0100 Version: None OS: None
--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>=20Normally, 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
401KeyboardInterrupt
>> --------------------- ---------------------
>> 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--
\==================================================================== Audit trail: Mon Feb 07 12:38:12 2000 guido changed notes Mon Feb 07 12:38:12 2000 guido moved from incoming to open
gvanrossum
558aa524-a6d3-4290-a7da-f9de71889aec
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields: ```python assignee = 'https://github.com/gvanrossum' closed_at =
created_at =
labels = ['interpreter-core']
title = 'Signal processing bug (Linux threads, readline, whatever else) (PR#196)'
updated_at =
user = 'https://bugs.python.org/anonymous'
```
bugs.python.org fields:
```python
activity =
actor = 'viznut'
assignee = 'gvanrossum'
closed = True
closed_date = None
closer = None
components = ['Interpreter Core']
creation =
creator = 'anonymous'
dependencies = []
files = []
hgrepos = []
issue_num = 210611
keywords = []
message_count = 8.0
messages = ['70', '71', '72', '73', '74', '75', '76', '77']
nosy_count = 3.0
nosy_names = ['gvanrossum', 'nobody', 'viznut']
pr_nums = []
priority = 'normal'
resolution = 'fixed'
stage = None
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue210611'
versions = []
```