Delayed signals in the REPL on OpenBSD (possibly libpthread related)

[skrah]

BPO	8714
Nosy	@vstinner, @skrah

^{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:

assignee = None
closed_at = <Date 2013-01-17.12:13:33.250>
created_at = <Date 2010-05-14.16:26:02.762>
labels = ['interpreter-core', 'type-bug']
title = 'Delayed signals in the REPL on OpenBSD (possibly libpthread related)'
updated_at = <Date 2013-01-17.12:13:33.249>
user = 'https://github.com/skrah'

bugs.python.org fields:

activity = <Date 2013-01-17.12:13:33.249>
actor = 'skrah'
assignee = 'none'
closed = True
closed_date = <Date 2013-01-17.12:13:33.250>
closer = 'skrah'
components = ['Interpreter Core']
creation = <Date 2010-05-14.16:26:02.762>
creator = 'skrah'
dependencies = []
files = []
hgrepos = []
issue_num = 8714
keywords = []
message_count = 6.0
messages = ['105720', '106124', '140972', '141007', '141012', '180124']
nosy_count = 5.0
nosy_names = ['vstinner', 'djmdjm', 'henry.precheur', 'skrah', 'neologix']
pr_nums = []
priority = 'normal'
resolution = 'out of date'
stage = None
status = 'closed'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue8714'
versions = ['Python 3.1', 'Python 2.7']

[skrah]

On OpenBSD, SIGINT handling in the REPL is delayed until further input:

Python 2.7b2+ (trunk:81162, May 14 2010, 14:47:52) 
[GCC 3.3.5 (propolice)] on openbsd4
Type "help", "copyright", "credits" or "license" for more information.
>>>  <= here Ctrl-C is pressed but nothing appears
Only after hitting <Return> a traceback appears:
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
KeyboardInterrupt

This behavior was introduced (exposed by?) r68460.

When Python is compiled without threads, the behavior is normal.

[henryprecheur]

The bug is also present with Python 3.1 on OpenBSD 4.7-current.

[neologix]

This behavior was introduced (exposed by?) r68460.

After a quick look, I don't see anything wrong with r68460, but it might very well have exposed this problem which was lurking before.

When Python is compiled without threads, the behavior is normal.

We've already had some problems - especially on *BSD - when mixing signals and threads (and it might be even worse on OpenBSD, since pthreads are implemented in user-space). However, IIUC, in this case you only have a single thread, right?

Could you post the output of an strace (well, ktrace on OpenBSD)?
Is Python compiled with readline support?

[skrah]

I know, the OpenBSD libpthread has problems. I listed some possible
candidates in bpo-8712.

For instance:

http://www.openbsd.org/cgi-bin/cvsweb/~checkout~/ports/lang/python/2.6/patches/Attic/patch-Lib_test_test_signal_py?rev=1.3;content-type=text%2Fplain

The comment says: "siginterrupt not reliable (does not mix well with threading"

To answer your questions:

1. Yes, there is only a single thread.

2. I only have an old OpenBSD 4.5, so it's not so useful to test
   there; I know Philip Guenther fixed some libpthread problems
   in the meantime.

[skrah]

I forgot: readline support is enabled, and there are known problems:

http://marc.info/?t=128327329300003&r=1&w=2

[skrah]

Fixed in OpenBSD 5.2.