This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: Signal reception problem. FreeBSD 4.8 and 4.9 after forkpty
Type: Stage:
Components: None Versions:
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: Nosy List: aimacintyre, levis501, lukem
Priority: normal Keywords:

Created on 2004-04-29 01:05 by levis501, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
failure_demo.py levis501, 2004-04-29 01:05 Reproduction of FreeBSD 4.8/4.9 signal issue
failure_demo.c levis501, 2004-05-18 19:55 C version of failure_demo.py
Messages (9)
msg20615 - (view) Author: Steve Levis (levis501) Date: 2004-04-29 01:05
The attached python file reproduces a bug whereby
Python does not receive alarm signals from FreeBSD 4.9.
 This also appears to be the case in FreeBSD 4.8, and
may be related to the addition of HyperThreading in
FreeBSD 4.8.  If Python (either 2.2.3 or 2.3.3) is
configured with -–without-threads before compiling, the
bug does not exist.
msg20616 - (view) Author: Steve Levis (levis501) Date: 2004-05-05 16:59
Logged In: YES 
user_id=309698

I was apparently not running on a standard FreeBSD kernel. 
It's working now.
msg20617 - (view) Author: Steve Levis (levis501) Date: 2004-05-05 17:08
Logged In: YES 
user_id=309698

Ooops, again!  I ran on the standard kernel but had python
compiled --without-threads, so of course it worked.

So, to make a long story short, the bug exists -- ignore my
last post.
msg20618 - (view) Author: Andrew I MacIntyre (aimacintyre) * (Python triager) Date: 2004-05-18 09:03
Logged In: YES 
user_id=250749

Hmm...  are you in a position to write a C test case for this?

The reason I ask is that I have seen other signal related
problems involving a Python interpreter built --with-threads
on FreeBSD 4.x which were traced back to issues with libc_r,
and I suspect that this problem is similar.
msg20619 - (view) Author: Andrew I MacIntyre (aimacintyre) * (Python triager) Date: 2004-05-18 09:05
Logged In: YES 
user_id=250749

Hmm...  are you in a position to write a C test case for this?

The reason I ask is that I have seen other signal related
problems involving a Python interpreter built --with-threads
on FreeBSD 4.x which were traced back to issues with libc_r,
and I suspect that this problem is similar.
msg20620 - (view) Author: Steve Levis (levis501) Date: 2004-05-18 19:55
Logged In: YES 
user_id=309698

I've uploaded failure_demo.c, which can be compiled with gcc
-o failure_demo failure_demo.c -lutil.

Written in C, the signal is properly delivered, and the test
does not fail on either FreeBSD 4.7 or 4.9.
msg20621 - (view) Author: Andrew I MacIntyre (aimacintyre) * (Python triager) Date: 2004-05-23 07:58
Logged In: YES 
user_id=250749

There are a few things I haven't been able to figure out
with this problem, but I think this is what's going on:
- on FreeBSD the read(2) call is not interruptable, as ptys
appear not to be considered "slow devices" by the kernel
(whether this behavior is *BSD specific I don't really know;
ordinary files and pipes aresimilarly affected so forkpty()
is just the messenger here);
- Python's signal handling is documented to behave such that
signal handlers only get invoked between Python VM opcodes.

As the os.read() call is a single VM instruction, the nett
effect is that the signal handler will not execute until the
os.read() call/instruction completes... which it never does.

This also affects other signals, such as SIGINT :-(

The signal handler being invoked between opcodes explains
why the C version works and the Python version doesn't.

Using select.select() (or select.poll()) is one way of
avoiding this 
trap, as both select(2) and poll(2) are interruptable (in
addition to supporting timeouts directly).  I expect this
approach would also be considered to be generally portable.

I haven't dug into why a single-threaded build avoids the
Python VM opcode scheduling - I can only speculate that
because the VM doesn't have any thread locking, it can
actually execute the signal handler while the os.read() call
is still pending.

I don't expect there to be a practical solution to this, and
so I'm 
suggesting that the bug be closed as "Won't fix" (read
"Can't fix").
msg20622 - (view) Author: Luke Mewburn (lukem) Date: 2004-08-22 01:08
Logged In: YES 
user_id=135998

Please try the patch I provided in patch 975056; it fixes up
various signal lossage on NetBSD & FreeBSD caused by
python's intermixed use of signal(3) and sigaction(3).
python wants non-SA_RESTART-able signals, yet signal(3) on
*BSD traditionally sets SA_RESTART, and the mechanism that
python uses to unset SA_RESTART when using sigaction(3) is
flawed.  It's quite possible that the os.read()
non-interruptability you're noticing on FreeBSD is being
caused by this issue.
msg20623 - (view) Author: Steve Levis (levis501) Date: 2004-12-15 21:05
Logged In: YES 
user_id=309698

The system in question has been upgraded to FreeBSD 5.2 and
this problem no longer exists.

Thanks aimacintyre and lukem.
History
Date User Action Args
2022-04-11 14:56:03adminsetgithub: 40196
2004-04-29 01:05:21levis501create