New submission from Alexey Izbyshev <izbys...@ispras.ru>:
os.dup2(fd, fd, inheritable=False) may fail or change fd inheritability in
following ways:
1) POSIX without F_DUP2FD_CLOEXEC
1.1) dup3() is available (a common case for Linux): OSError (EINVAL, dup3()
doesn't allow equal descr
Change by Alexey Izbyshev <izbys...@ispras.ru>:
--
keywords: +patch
pull_requests: +5497
stage: -> patch review
___
Python tracker <rep...@bugs.python.org>
<https://bugs.pyt
New submission from Alexey Izbyshev <izbys...@ispras.ru>:
os.dup2() tests for dup3() system call availability at runtime, but doesn't
remember the result across calls, repeating the test on each call with
inheritable=False even if the test fails.
Judging by the code, 'dup3_works' was in
Alexey Izbyshev <izbys...@ispras.ru> added the comment:
Note that the PR doesn't attempt to fix leaking of low dup'ed fds to the child.
I'll file a separate report for that in a while.
--
___
Python tracker <rep...@bugs.python.or
Change by Alexey Izbyshev <izbys...@ispras.ru>:
--
keywords: +patch
pull_requests: +5482
stage: -> patch review
___
Python tracker <rep...@bugs.python.org>
<https://bugs.pyt
New submission from Alexey Izbyshev <izbys...@ispras.ru>:
When redirecting, subprocess attempts to achieve the following state: each fd
to be redirected to is less than or equal to the fd it is redirected from,
which is necessary because redirection occurs in the ascending
Alexey Izbyshev <izbys...@ispras.ru> added the comment:
> out of curiosity, did you actually diagnose a process deadlocked due to this
> or was it noted via code inspection?
The latter. I noted it while working on another issue. While it was easy to
trigger a malloc() in child_e
Change by Alexey Izbyshev <izbys...@ispras.ru>:
--
keywords: +patch
pull_requests: +5382
stage: -> patch review
___
Python tracker <rep...@bugs.python.org>
<https://bugs.pyt
New submission from Alexey Izbyshev <izbys...@ispras.ru>:
_Py_set_inheritable() raises a Python-level exception on error and thus is not
async-signal-safe, but child_exec() must use only async-signal-safe functions
because it's executed between fork() and exec().
Since a non-raising v
Alexey Izbyshev <izbys...@ispras.ru> added the comment:
Any objections to the PR?
--
nosy: +belopolsky, eric.araujo
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Alexey Izbyshev <izbys...@ispras.ru> added the comment:
Any feedback on the updated PR?
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Change by Alexey Izbyshev <izbys...@ispras.ru>:
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<https://bu
Change by Alexey Izbyshev <izbys...@ispras.ru>:
--
keywords: +patch
pull_requests: +4815
stage: -> patch review
___
Python tracker <rep...@bugs.python.org>
<https://bugs.pyt
Change by Alexey Izbyshev <izbys...@ispras.ru>:
--
nosy: +gregory.p.smith, pitrou
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
New submission from Alexey Izbyshev <izbys...@ispras.ru>:
The last part of test_close_fds() doesn't match its own comment. The following
assertion always holds because fds_to_keep and open_fds are disjoint by
construction.
self.assertFalse(remaining_fds & fds_to_keep
Alexey Izbyshev <izbys...@ispras.ru> added the comment:
I had similar thoughts when I was fixing tests that broke due to ValueError.
I've updated the PR to issue a RuntimeWarning instead.
--
___
Python tracker <rep...@bugs.python.or
Change by Alexey Izbyshev <izbys...@ispras.ru>:
--
pull_requests: +4732
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue21332>
___
Change by Alexey Izbyshev <izbys...@ispras.ru>:
--
keywords: +patch
pull_requests: +4730
stage: -> patch review
___
Python tracker <rep...@bugs.python.org>
<https://bugs.pyt
Change by Alexey Izbyshev <izbys...@ispras.ru>:
--
keywords: +patch
pull_requests: +4731
stage: needs patch -> patch review
___
Python tracker <rep...@bugs.python.org>
<https://bugs.pyt
Alexey Izbyshev <izbys...@ispras.ru> added the comment:
I'm in favor of raising an exception because it'll expose existing code with
incorrect assumptions. I'll check whether it breaks any tests and submit a PR.
--
___
Python tracke
Alexey Izbyshev <izbys...@ispras.ru> added the comment:
Regarding fixing (1), I'm worrying about backward compatibility a bit. Some
people who discovered that behavior might rely on such "move" semantics and
expect that the redirected descriptor is not leaked into the ch
New submission from Alexey Izbyshev <izbys...@ispras.ru>:
Demonstration:
$ cat test.py
import os
import subprocess
import sys
fd = os.dup(sys.stdout.fileno())
subprocess.call([sys.executable, '-c',
'import sys;'
'print("Hello stdout");'
New submission from Alexey Izbyshev <izbys...@ispras.ru>:
Despite some steps made in issue 9860 make patchcheck still doesn't work for
out-of-tree builds because it runs git and hg in the current directory instead
of the source directory (msg169465).
--
messages: 307875
nosy: iz
Change by Alexey Izbyshev <izbys...@ispras.ru>:
--
keywords: +patch
pull_requests: +4663
stage: -> patch review
___
Python tracker <rep...@bugs.python.org>
<https://bugs.pyt
Alexey Izbyshev <izbys...@ispras.ru> added the comment:
Yes, clarifying buffering for text mode in open() would be nice.
@direprobs: just in case you didn't know, you can achieve what you want with
something like the following in pre-3.7:
with open("/dev/null", "wb&qu
New submission from Alexey Izbyshev <izbys...@ispras.ru>:
The fact that "buffering=1" is usable only in text mode is documented for
open(). In binary mode, setting buffering to 1 is silently ignored and
equivalent to using default buffer size. I argue that such behavior is:
Alexey Izbyshev <izbys...@ispras.ru> added the comment:
Yes, your claim is confirmed by the fact that there have been little interest
in this issue since 2011. Still, non-blocking behavior is incorrectly specified
in the docs and is inconsistent (as investigated by Martin). And obscure
Alexey Izbyshev <izbys...@ispras.ru> added the comment:
For added fun: at least one part of the standard library doesn't expect None
returns from read() in the buffering layer.
>>> import os
>>> r, w = os.pipe2(os.O_NONBLOCK)
>>> f = os.fdopen(r, 'r')
>>
Alexey Izbyshev added the comment:
I've encountered this issue too. (FYI, the official 3.6.0 embeddable zip from
https://www.python.org/downloads/windows/ does contain a blank line in its
._pth, so all its users get an invalid entry in sys.path).
The patch is attached. I couldn't fix tests
Alexey Izbyshev added the comment:
Thanks to Steve and everyone for quick and decisive action!
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
New submission from Alexey Izbyshev:
The docs claim: "... the embedded distribution is (almost) fully isolated from
the user’s system, including environment variables, system registry settings,
and installed packages."
Via ProcessMonitor tool I've discovered that python.exe stil
301 - 331 of 331 matches
Mail list logo
