New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Interrupted system calls are not retried #54076
Comments
Currently Python does not check fread and other IO calls for EINTR. This usually is not an issue, but on OS X a continued program will be sent an SIGCONT signal which causes fread to be interrupted. Testcase: mitsuhiko@nausicaa:~$ python2.7
Python 2.7 (r27:82508, Jul 3 2010, 21:12:11)
[GCC 4.0.1 (Apple Inc. build 5493)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from signal import SIGCONT, signal
>>> def show_signal(*args):
... print 'Got SIGCONT'
...
>>> signal(SIGCONT, show_signal)
0
>>> import sys
>>> sys.stdin.read()
^Z
[1]+ Stopped python2.7
mitsuhiko@nausicaa:~$ fg
python2.7
Got SIGCONT
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
IOError: [Errno 4] Interrupted system call
>>> Expected behavior: on fg it should continue to read. The solution would be to loop all calls to fread and friends until errno is no longer EINTR. Now the question is how to best do that. I can't think of a portable way to define a macro that continues to run an expression until errno is EINTR, maybe someone else has an idea. Otherwise it would be possible to just put the loops by hand around each fread/fgetc etc. call, but that would make the code quite a bit more ugly. Technically I suppose the problem applies to all platforms, on OS X it's just easier to trigger. |
The test fails exactly the same way using a python 2.6.6 on a current Debian (testing) Linux 2.6.32 so I think it better to remove the OS X from the title. Also the versions field refers to where a potential fix might be applied; that rules out 2.5 and 2.6 since it is not a security problem. I was also curious if calling signal.siginterrupt for SIGCONT had any effect on this. Neither False nor True on either OS X or linux seemed to change the behavior. |
I fail to see why this is a bug. If the system call is interrupted, why should Python not report that? |
One could argue of course that every user of Python should handle EINTR, but that's something I think should be solved in the IO library because very few people know that one is supposed to restart syscalls on EINTR on POSIX systems. Ruby for instance handles EINTR properly: mitsuhiko@nausicaa: So does perl: mitsuhiko@nausicaa: |
Interestingly even PHP handles that properly. |
Hmm. So under what conditions should it continue, and under what |
EINTR indicates a temporary failure. In that case it should always retry. A common macro for handling that might look like this: #define RETRY_ON_EINTR(x) ({ \
typeof(x) rv; \
do { rv = x; } while (rv < 0 && errno == EINTR); \
rv;\
}) But from what I understand, braces in parentheses are a GCC extension. |
Am 16.09.10 14:06, schrieb Armin Ronacher:
But Ruby doesn't. If you send SIGINT, it will print -e:1:in `read': Interrupt If you send SIGHUP, it will print Hangup So it is surely more complex than "always retry". |
Wouldn't retrying on EINTR cause havoc when you try to interrupt a process? That is: what would happen with the proposed patch when a python script does a read that takes a very long time and the user tries to interrupt the script (by using Ctrl+C to send a SIGTERM)? If I my understanding of is correct the patch will ensure that the process does not get interupted because the default SIGTERM handler just sets a flag that's periodicly checked in the python interpreter loop. With the proposed patch python would not get around to checking that flag until the I/O operation is finished. |
The following minimal C code shows how EINTR can be handled: #include <stdlib.h>
#include <stdio.h>
#include <errno.h>
#include <signal.h>
#define BUFFER_SIZE 1024
int
main()
{
char buffer[BUFFER_SIZE];
printf("PID = %d\n", getpid());
while (1) {
int rv = fgetc(stdin);
if (rv < 0) {
if (feof(stdin))
break;
if (errno == EINTR)
continue;
printf("Call failed with %d\n", errno);
return 1;
}
else
fputc(rv, stdout);
}
return 0;
} Test application: mitsuhiko@nausicaa:/tmp$ ./a.out mitsuhiko@nausicaa:/tmp$ ./a.out First signal sent was TERM, second was INT. Last case was sending to background, receiving the ignored SIGCONT signal, fgetc returning -1 and fgetc being called again because of errno being EINTR. |
All your C applications are doing it, why should Python cause havok there? Check the POSIX specification on that if you don't trust me.
Here a quick explanation from the GNU's libc manual: |
There is a funny story related to that though :) "BSD avoids EINTR entirely and provides a more convenient approach: BSD does, but the Mach/XNU kernel combo on OS X is not. Which is why all the shipped BSD tools have that bug, but if you run their GNU equivalents on OS X everything work as expected. |
Some parts of the stdlib already retry manually (such as SocketIO, subprocess, multiprocessing, socket.sendall), so it doesn't sound unreasonable for the IO lib to retry too. There are/were other people complaining in similar cases: bpo-7978, bpo-1628205. |
On 16 Sep, 2010, at 14:36, Armin Ronacher wrote:
You conveniently didn't quote the part of my message where I explained why I think there may be a problem. CPython's signal handlers just set a global flag to indicate that a signal occurred and run the actual signal handler later on from the main interpreter loop, see signal_handler in Modules/signal.c and intcatcher in Parser/intrcheck.c. The latter contains the default handler for SIGINT and that already contains code that deals with SIGINT not having any effect (when you sent SIGINT twice in a row without CPython running pending calls the interpreter gets aborted). Because Python's signal handlers only set a flag and do the actual action later on blindly rerunning system calls when errno == EINTR may result in programs that don't seem to react to signals at all. |
On 16 Sep, 2010, at 14:38, Armin Ronacher wrote:
setting the SA_RESTART in the call to sigaction should work (on OSX HAVE_SIGACTION is defined), unless the manpage is lying. Ronald |
You just need to call PyErr_CheckSignals() and check its result. |
It should work, haven't tried. From what I understand on a BSD system, retrying is the default. |
|
On 16 Sep, 2010, at 15:40, Armin Ronacher wrote:
This looks fine. Ronald |
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:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: