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
race condition in initstdio() (python aborts running under nohup) #69079
Comments
Looks like this bug https://bugs.python.org/issue7111 has resurfaced in python3 (python 2.6 works as far as I can tell) at least on Macs. I've attached a simple test script. Steps:
|
test.sh attached |
What sort of errors? |
I'm unable to reproduce the issue on Linux with Python 3.4.2. |
Fatal Python error: Py_Initialize: can't initialize sys standard streams |
That's from my nohup.out. It might be a Mac OS specific thing. |
I can reproduce the bug with gdb if the file descriptor 0 is closed before calling:
std = create_stdio(iomod, fd, 0, "<stdin>", encoding, errors);
and after the following lines were called:
fd = fileno(stdin);
if (!is_valid_fd(fd)) { In initstdio () at Python/pylifecycle.c:1156. create_stdio() fails in FileIO constructor, on the line: It's a corner case of the issue bpo-7111, I would call it a race condition. |
Python 2 is not affected, PyFile_FromFile() doesn't check if the file descriptor is valid. On Python 3, we call fstat() to check the block size of the file descriptor to optimize buffering. |
I'm not sure this is a race condition. There's a crash every single time python is started when running the test.sh script under nohup. If it's a race condition, it should only happen some of the time, not every single time. Can you reeevaluate the priority? |
Attaching a patch. Does it make any sense? |
ops wrong patch... trying again. |
Yes, it looks like a good approach. Some comments:
|
@Haypo thanks for the quick review. This new issue24891_2.patch covers all of the points you raised except the "check exception type" which I am still figuring out. |
See my patch issue24891_3.patch which calls PyErr_ExceptionMatches(PyExc_OSError). If you like it, I can push it to Python 3.4-3.6. |
@Haypo, yeah, definitely better than mine! All good for me. |
New changeset e67bf9c9a898 by Victor Stinner in branch '3.4': |
Ok. I added your name to Misc/ACKS. I had to do some tricks to apply the patch to Python 3.4 (code was in Python/pythonrun.c) and then to merge to Python 3.5 (code moved to Python/pylifecycle.c). But I checked the fix in each version using gdb:
Thanks for your patch Marco. I prefer to be extra safe by checking the raised exception to minimize the risk of regression. |
Thank you everyone! I will test the next rc of 3.5. |
I don't plan to send a pull request to the Python 3.5 release manager. |
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: