[Python-bugs-list] [Bug #110611] Signal processing bug (Linux threads, readline, whatever else) (PR#196)
noreply@sourceforge.net
noreply@sourceforge.net
Wed, 9 Aug 2000 09:04:03 -0700
Bug #110611, was updated on 2000-Jul-31 14:05
Here is a current snapshot of the bug.
Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: Signal processing bug (Linux threads, readline, whatever else) (PR#196)
Details: 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>=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--
====================================================================
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
Follow-Ups:
Date: 2000-Jul-31 14:05
By: none
Comment:
From: "Tim Peters" <tim_one@email.msn.com>
Subject: RE: [Python-bugs-list] Signal processing bug (Linux threads, readline, whatever else) (PR#196)
Date: Wed, 2 Feb 2000 03:04:04 -0500
[flight@mathi.uni-heidelberg.de]
> this must be the strangest bug report ever sent to bugs-py ;-).
No, but I don't recall one that evidenced more hard & tedious work! Wow.
Thank you. Switch to Windows -- it's so much more reliable <wink>.
If you haven't already done so, may I suggest building Python from the
current CVS development source tree instead?
http://www.python.org/download/cvs.html
This may be a waste of effort, but I'd hate to see you pour more time
tracking down obscure bugs that may already have been fixed. Contrarily, if
the current CVS version still displays the problems, more work devoted to
tracking them down is certain not to be a waste.
-------------------------------------------------------
Date: 2000-Jul-31 14:05
By: none
Comment:
From: Gregor Hoffleit <flight@mathi.uni-heidelberg.de>
Subject: RE: [Python-bugs-list] Signal processing bug (Linux threads, readline, whatever else) (PR#196)
Date: Wed, 2 Feb 2000 14:25:07 +0100
Hi,
> If you haven't already done so, may I suggest building Python from the
> current CVS development source tree instead?
sorry, I forgot to mention that I tried that. Didnt't change the behavior
at all (I also saw that there were no big changes to the readline nor to
the threading code since 1.5.2).
Gregor
-------------------------------------------------------
Date: 2000-Jul-31 14:05
By: none
Comment:
From: Gregor Hoffleit <flight@mathi.uni-heidelberg.de>
Subject: Returned mail: User unknown
Date: Thu, 3 Feb 2000 11:46:44 +0100 (MET)
This is a MIME-encapsulated message
--LAA26536.949574804/relay.uni-heidelberg.de
The original message was received at Thu, 3 Feb 2000 11:46:41 +0100 (MET)
from mailserver.mathi.uni-heidelberg.de [129.206.26.32]
----- The following addresses had permanent fatal errors -----
<bugs-by@python.org>
----- Transcript of session follows -----
.. while talking to parrot.python.org.:
>>> RCPT To:<bugs-by@python.org>
<<< 550 <bugs-by@python.org>... User unknown
550 <bugs-by@python.org>... User unknown
--LAA26536.949574804/relay.uni-heidelberg.de
Content-Type: message/delivery-status
Reporting-MTA: dns; relay.uni-heidelberg.de
Received-From-MTA: DNS; mailserver.mathi.uni-heidelberg.de
Arrival-Date: Thu, 3 Feb 2000 11:46:41 +0100 (MET)
Final-Recipient: RFC822; bugs-by@python.org
Action: failed
Status: 5.1.1
Remote-MTA: DNS; parrot.python.org
Diagnostic-Code: SMTP; 550 <bugs-by@python.org>... User unknown
Last-Attempt-Date: Thu, 3 Feb 2000 11:46:44 +0100 (MET)
--LAA26536.949574804/relay.uni-heidelberg.de
Content-Type: message/rfc822
Return-Path: <flight@mathi.uni-heidelberg.de>
Received: from mailserver.mathi.uni-heidelberg.de (mailserver.mathi.uni-heidelberg.de [129.206.26.32])
by relay.uni-heidelberg.de (8.9.3+Sun/8.9.3) with ESMTP id LAA26531
for <bugs-by@python.org>; Thu, 3 Feb 2000 11:46:41 +0100 (MET)
Received: from testserv.mathi.uni-heidelberg.de (testserv.mathi.uni-heidelberg.de [129.206.26.30])
by mailserver.mathi.uni-heidelberg.de (Postfix) with SMTP id CFF5512917
for <bugs-by@python.org>; Thu, 3 Feb 2000 11:48:11 +0100 (CET)
Received: by testserv.mathi.uni-heidelberg.de (sSMTP sendmail emulation); Thu, 3 Feb 2000 11:48:12 +0100
Date: Thu, 3 Feb 2000 11:48:12 +0100
From: Gregor Hoffleit <flight@mathi.uni-heidelberg.de>
To: bugs-by@python.org
Subject: RE: [Python-bugs-list] Signal processing bug (Linux threads, readline, whatever else) (PR#196)
Message-ID: <20000203114812.B18567@mathi.uni-heidelberg.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.0pre3i
Fredric Lundh pointed me to Alex Zbyslaw's posting regarding this topic
(http://x44.deja.com/getdoc.xp?AN=545159177).
Indeed Alex' patch1 (http://www.xfb52.dial.pipex.com/patches/python.shtml)
for FreeBSD (disabling the interrupt handler chanege in the readline module)
works for Debian, too, i.e. if I stick with the default inthandler in the
readline module, SIGINT doesn't kill the interpreter anymore.
Still, the drawback of this change is that I have to press RETURN before
a SIGINT is spotted by Python (btw, this is the same behavior as with 1.5.1
on the system with the same configuration).
Still, IMHO this behavior is preferable.
Gregor
--LAA26536.949574804/relay.uni-heidelberg.de--
-------------------------------------------------------
Date: 2000-Jul-31 14:05
By: none
Comment:
From: Gregor Hoffleit <flight@mathi.uni-heidelberg.de>
Subject: Re: [Python-bugs-list] Signal processing bug (Linux threads, readline, whatever else) (PR#196)
Date: Fri, 11 Feb 2000 14:52:42 +0100
--dDRMvlgZJXvWKvBx
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Ok, one more data point:
On Fri, Feb 11, 2000 at 08:29:43AM -0500, Randall Hopper wrote:
> You know, I think you may have it. On IRIX, I don't have Python built
> with threads. However, on FreeBSD at home I'd guess that it is (I built =
it
> from ports). My IRIX python has no problem with Ctrl-C while my FreeBSD
> version at home locks up with Ctrl-C. I rebuilt my IRIX Python
> --with-thread, and now it hangs when Ctrl-C is hit.
And now, we're three: When using threads and readline, Ctrl-C hangs IRIX and
FreeBSD and kills Linux Python.
This doesn't sound like a kernel problem, more like a problem with readline
not being thread-safe I guess.
Gregor
=20
--dDRMvlgZJXvWKvBx
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.1 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE4pBQq3eVfDf25G40RAUbSAJ41b+DgwHEmRUm0uQcJLjvZ3ROiSwCdH8Xq
jFH5J1TsLQBbQTPU5Xvv0Bo=
=0j16
-----END PGP SIGNATURE-----
--dDRMvlgZJXvWKvBx--
-------------------------------------------------------
For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110611&group_id=5470