Change by Alexey Izbyshev :
--
pull_requests: +21885
pull_request: https://github.com/python/cpython/pull/22970
___
Python tracker
<https://bugs.python.org/issue42
Alexey Izbyshev added the comment:
I've submitted both PRs.
Regarding PR 22970:
* I made it a draft since we'd probably want to fix the leak first, but then it
will have to be rebased.
* It fixes a bug with _enable_gc(): if it failed after fork(), we'd raise
OSError instea
Change by Alexey Izbyshev :
--
keywords: +patch
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue42146>
___
___
Python-bugs-list mai
Change by Alexey Izbyshev :
--
type: behavior -> resource usage
___
Python tracker
<https://bugs.python.org/issue42146>
___
___
Python-bugs-list mai
Alexey Izbyshev added the comment:
Thanks for merging! I've rebased PR 22970.
--
___
Python tracker
<https://bugs.python.org/issue42146>
___
___
Pytho
Change by Alexey Izbyshev :
Added file: https://bugs.python.org/file49531/test.py
___
Python tracker
<https://bugs.python.org/issue42097>
___
___
Python-bugs-list mailin
Alexey Izbyshev added the comment:
(Restored test.py attachment)
The issue happens due to an incorrect usage of `multiprocessing.Pool`.
```
# Set up multiprocessing pool, initialising logging in each subprocess
with multiprocessing.Pool(initializer=process_setup,
initargs=(get_queue
Alexey Izbyshev added the comment:
By the way, I don't see a direct relation between `test.py` (which doesn't use
`subprocess` directly) and your comment describing `subprocess` usage with
threads. So if you think that the bug in `test.py` is unrelated to the problem
you face, fe
Alexey Izbyshev added the comment:
It seems that allowing `input=None` to mean "redirect stdin to a pipe and send
an empty string there" in `subprocess.check_output` was an accident(?), and
this behavior is inconsistent with `subprocess.run` and `communicate`, where
`input=None` ha
Alexey Izbyshev added the comment:
> (probably can't even limit that to the case when `text` is used, since it was
> added in 3.7)
Well, actually, we can, since we probably don't need to preserve compatibility
with the AttributeError currently caused by `text=True`
Change by Alexey Izbyshev :
--
nosy: +rhettinger
versions: -Python 3.6, Python 3.7
___
Python tracker
<https://bugs.python.org/issue42457>
___
___
Python-bug
New submission from Alexey Luchko :
$ make
...
gcc -shared -Wl,--enable-auto-image-base
build/temp.cygwin-1.7.11-i686-2.7/Python-2.7.3rc2/Modules/_io/bufferedio.o
build/temp.cygwin-1.7.11-i686-2.7/Python-2.7.3rc2/Modules/_io/bytesio.o
build/temp.cygwin-1.7.11-i686-2.7/Python-2.7.3rc2/Modules
Alexey Luchko added the comment:
The error got building Python 2.7.2 & 2.7.3rc2
--
___
Python tracker
<http://bugs.python.org/issue14437>
___
___
Python
New submission from Alexey Luchko :
$ CFLAGS=-I/usr/include/ncursesw/ CPPFLAGS=-I/usr/include/ncursesw/ ./configure
$ make
...
building '_curses' extension
gcc -fno-strict-aliasing -I/usr/include/ncursesw/ -DNDEBUG -g -fwrapv -O3 -Wall
-Wstrict-prototypes -I. -IInclude -I./Incl
Alexey Luchko added the comment:
Checked solution by David Robinow
http://mail.python.org/pipermail/python-list/2012-March/1290038.html
It works. Diff follows: """
--- Modules/_io/_iomodule.h.orig2012-03-16 03:26:36.0 +0200
+++ Modules/_io/_iomodule.h 2
Alexey Luchko added the comment:
It's cygwin's issue. Cygwin's python 2.6 has a patch for it.
Just in case:
--- origsrc/Python-2.6.5/Include/py_curses.h2009-09-06 16:23:05.0
-0500
+++ src/Python-2.6.5/Include/py_curses.h2010-04-14 15:21:23.008971400
-0500
Alexey Luchko added the comment:
Final 2.7.3 didn't get the fix.
Checked http://python.org/ftp/python/2.7.3/Python-2.7.3.tar.xz
--
___
Python tracker
<http://bugs.python.org/is
Alexey Kostyrin added the comment:
Can not reproduce - warning is displayed with PYTHONASYNCIODEBUG=1
Python version:
Python 3.8.0b1+ (heads/3.8:3f7629d93c, Jun 10 2019, 13:46:55)
[Clang 10.0.0 (clang-1000.10.44.4)] on darwin
--
nosy: +def_bk
Alexey Izbyshev added the comment:
This is because of a leak of 'wstr' at
https://github.com/python/cpython/blob/1005c84535191a72ebb7587d8c5636a065b7ed79/Objects/unicodeobject.c#L3476
.
There is another leak and usage of uninitialized 'str' because the following
&quo
Alexey Izbyshev added the comment:
The added test exposed a leak in unicode_encode_locale(). See msg330534.
--
___
Python tracker
<https://bugs.python.org/issue34
Alexey Izbyshev added the comment:
Correction: the fall-through in "else if (res == -3)" clause doesn't cause a
memory leak, but still results in usage of uninitialized 'str'.
--
___
Python tracker
<https:
Alexey Izbyshev added the comment:
See #28108 and https://sourceware.org/bugzilla/show_bug.cgi?id=23859 (for
msg276123).
--
nosy: +izbyshev
___
Python tracker
<https://bugs.python.org/issue35
Alexey Izbyshev added the comment:
If I understood PR 10919 correctly, sysconfig.get_config_var('userbase') can
now return unexpanded paths containing '~'. Is it intended despite the previous
discussion starting with msg135047?
--
Alexey Izbyshev added the comment:
> I prefer to stick to the initial bug report which hasn't been fixed in 8 years
I'm interested in fixing this bug too since it bit me in SCons and I had to use
a local patch for it. I welcome the upstream fix and don't object to
Alexey Izbyshev added the comment:
> Would it make sense to backport this fix in 3.6 and 3.7?
I'd like to see it there, given that this bug surfaced in many use cases not
involving any modern features or systemd at all.
--
___
Python
Alexey Izbyshev added the comment:
You might try to check the list of DLLs loaded into the stuck python process
and find third-party ones (e.g., antivirus). If there are any, disable the
third-party software and try again.
--
nosy: +izbyshev
Alexey Izbyshev added the comment:
How is it possible to use faulthandler if the interpreter hasn't even started
yet?
--
___
Python tracker
<https://bugs.python.org/is
Alexey Izbyshev added the comment:
argparse.SUPPRESS is an opaque value to be used by argparse clients. It could
be anything, it just happens to be a string. So the code doesn't compare
strings but checks whether a supplied object *is* the opaque value. I do not
see any problem with
Change by Alexey Izbyshev :
--
nosy: +gregory.p.smith, izbyshev
___
Python tracker
<https://bugs.python.org/issue35537>
___
___
Python-bugs-list mailin
Alexey Izbyshev added the comment:
Serhiy, PyOS_* functions are called only if preexec_fn != None. But it will
never be possible to implement support for preexec_fn (and some other
subprocess features, e.g. close_fds) if processes are run via posix_spawn, so I
don't see why anything s
Alexey Izbyshev added the comment:
Victor and Joannah, thanks for working on adding vfork() support to subprocess.
Regarding speedups in the real world, I can share a personal anecdote. Back at
the time when AOSP was built with make (I think it was AOSP 5) I've observed
~2x slowdow
Alexey Izbyshev added the comment:
> I'm open to experiment to use vfork() in _posixsubprocess
Are you going to do experiments? If not, I can try to do some in early January.
> Using vfork() can cause new issues: that's why there is a
> POSIX_SPAWN_USE_VFORK flag
Alexey Izbyshev added the comment:
> * cwd
posix_spawn_file_actions_addchdir_np() is scheduled for glibc 2.29 [1] and
exists in Solaris [2] (though its suffix indicates that it's "non-portable" --
not in POSIX). POSIX also has a bug for this [7].
>
Alexey Izbyshev added the comment:
The resolution of this [1] glibc bug report effectively says that the use of
global variables tzname, timezone and daylight is not supported by glibc unless
a POSIX-style TZ setting is used (which is probably never in real world).
[1] https
Change by Alexey Izbyshev :
--
nosy: +izbyshev
___
Python tracker
<https://bugs.python.org/issue35674>
___
___
Python-bugs-list mailing list
Unsubscribe:
Alexey Izbyshev added the comment:
> * On FreeBSD, if setting posix_spawn() "attributes" or execute posix_spawn()
> "file actions" fails, posix_spawn() succeed but the child process exits
> immediately with exit code 127 without trying to call execv(). If
Alexey Izbyshev added the comment:
> Until muscl decides to provide an "#ifdef __MUSL__"-like or any way that it's
> musl, I propose to not support musl: don't use os.posix_spawn() but
> _posixsubprocess.
FYI, I'm researching how to use vfork(), focusing
Alexey Izbyshev added the comment:
> Hi,
> As a disclaimer, I'm a FreeBSD developer interested in making sure we're
> doing the right thing here. =)
> May I ask what the above assessment is based on, and specifically what we
> need to address?
Hello, Kyle! That
Alexey Izbyshev added the comment:
> One of the issue that I have with using posix_spawn() is that the *exact*
> behavior of subprocess is not properly defined by test_subprocess. Should we
> more more tests, or document that the exact behavior is "an implementation
> de
Alexey Izbyshev added the comment:
Would it make sense to use os.confstr('CS_PATH') instead of a hardcoded path,
or is identical behavior on all POSIX platforms preferred to that?
--
nosy: +izbyshev
___
Python tracker
<https://bu
Alexey Izbyshev added the comment:
Thank you for the answers, Kyle!
> I'll be preparing a patch for our posix_spawn's signal handling.
Great!
> My mistake in my setuid assessment was pointed out to me- it doesn't seem
> like a highly likely attack vector, but it
Alexey Izbyshev added the comment:
> It should be compared to the current code. Currently, _posixsubprocess uses a
> loop calling execv(). I don't think that calling posix_spawn() in a loop
> until one doesn't fail is more inefficient.
> The worst case would be
Alexey Izbyshev added the comment:
Thanks for the info on CS_PATH, Victor. IMHO it'd make sense to use the
libc-provided default PATH at least in shutil.which() since its intent is to
emulate "which" from the default shell.
--
___
Alexey Izbyshev added the comment:
>> * pass_fds: there is not API to mark a fd as inheritable (clear O_CLOEXEC
>> flag)
> POSIX has a bug for this [5]. It's marked fixed, but the current POSIX docs
> doesn't reflect the changes. The idea is to make
> p
Alexey Izbyshev added the comment:
Another problem with posix_spawn() on glibc: it doesn't report errors to the
parent process when run under QEMU user-space emulation and Windows Subsystem
for Linux. This is because starting with commit [1] (glibc 2.25) posix_spawn()
relies on ad
New submission from Alexey Izbyshev :
This issue is to propose a (complementary) alternative to the usage of
posix_spawn() in subprocess (see bpo-35537).
As mentioned by Victor Stinner in msg332236, posix_spawn() has the potential of
being faster and safer than fork()/exec() approach
Change by Alexey Izbyshev :
--
keywords: +patch, patch, patch
pull_requests: +11484, 11485, 11486
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issu
Change by Alexey Izbyshev :
--
keywords: +patch
pull_requests: +11484
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue35823>
___
_
Change by Alexey Izbyshev :
--
keywords: +patch, patch
pull_requests: +11484, 11485
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issu
Alexey Izbyshev added the comment:
> Is sys.platform equal to 'linux' on WSL? Sorry, I don't know WSL. If it's
> equal, is it possible to explicitly exclude WSL in the subprocess test,
> _use_posix_spawn()?
I don't have immediate access to WSL righ
Alexey Izbyshev added the comment:
> W.r.t. closing all file descriptors > 2: posix_spawn_file_actions_addclose
> can do this when using posix_spawn. That would have a performance cost, you'd
> basically have to resort to closing all possible file descriptors and cannot
Alexey Izbyshev added the comment:
I've checked subprocess.Popen() error reporting in QEMU user-mode and WSL and
confirm that it works both with my patch (vfork/exec) and the traditional
fork/exec, but doesn't work with glibc's posix_spawn.
The first command below u
Alexey Izbyshev added the comment:
Thank you for the review and your thoughts, Gregory.
> With this in place we may want to make the _use_posix_spawn() logic in
> subprocess.py stricter? That could be its own followup PR.
Yes, I think we can always use vfork() on Linux unless we fin
Alexey Izbyshev added the comment:
I've been struggling with fixing spurious -Wclobbered GCC warnings. Originally,
I've got the following:
/scratch2/izbyshev/cpython/Modules/_posixsubprocess.c: In function
‘subprocess_fork_exec’:
/scratch2/izbyshev/cpython/Modules/_posixsubproces
New submission from Alexey Izbyshev :
Victor Stinner pointed out that on x86 Gentoo Installed with X 3.x buildbot,
there is a compiler warning:
Python/pystate.c:1483:18: warning: cast to pointer from integer of
different size [-Wint-to-pointer-cast]
(https://buildbot.python.org/all
Change by Alexey Izbyshev :
--
keywords: +patch
pull_requests: +11852
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue35972>
___
_
Alexey Izbyshev added the comment:
"long long" is mandated to be at least 64-bit by C99 (5.2.4.2.1 Sizes of
integer types). If it were 32-bit, no warnings would have been issued.
--
___
Python tracker
<https://bugs.python.o
Alexey Izbyshev added the comment:
I'll look into it later today. An obvious guess is that my test simply exposed
an existing leak because the exception code path wasn't tested before AFAIK,
but I need to check it.
--
assignee: -
Change by Alexey Izbyshev :
--
keywords: +patch
pull_requests: +11876
stage: test needed -> patch review
___
Python tracker
<https://bugs.python.org/issu
Alexey Izbyshev added the comment:
Thank you for your introduction about _xxsubinterpreters, Eric.
This particular leak is easy: it's right in _channel_send(). I've submitted a
PR.
I've also done a quick scan of neighboring code, and it seems there are other
lea
Alexey Izbyshev added the comment:
I don't know what you mean by "in-line" pre-processing output, but you can use
-E option to get the normal preprocessor output. Line directives will tell you
where those functions come from on a system where there is no compilation error.
Change by Alexey Izbyshev :
--
nosy: +izbyshev
___
Python tracker
<https://bugs.python.org/issue36046>
___
___
Python-bugs-list mailing list
Unsubscribe:
Alexey Izbyshev added the comment:
> Interesting. Because both errors/conditions are mapped to
> ERROR_INVALID_HANDLE we need the creation time. I can work on a patch for
> that.
I don't understand why any patch for CPython is needed at all. Using invalid
handles is a serio
Change by Alexey Izbyshev :
--
assignee: -> gregory.p.smith
___
Python tracker
<https://bugs.python.org/issue36046>
___
___
Python-bugs-list mailing list
Un
Alexey Izbyshev added the comment:
Patrick, could you provide more background that would explain your choice of
setreuid/setregid functions and the desired handling of supplementary groups?
I'm not a security expert, so I may not have sufficient expertise to judge on
that, but may
New submission from Alexey Trenikhin:
#include
int main(){
PyUnicode_Decode("abcdef", 4, "utf_8", "ignore");
return 0;
}
crashes on linux and Windows (but works fine with encoding "utf-8" )
--
components: Unicode
files: test.c
Alexey Popravka added the comment:
Hi guys! Any update on this?
I've just hit this issue.
Cancelled futures in _waiters is not a problem (any more).
There is still a problem when release() wakes up next waiter
but task waiting for it gets cancelled and so all the rest waiters
are in pe
Alexey Popravka added the comment:
Also there is the same problem with asyncio.Condition wait() / notify() couple
as it repeats the same Lock.acquire()/release() logic
--
___
Python tracker
<http://bugs.python.org/issue27
Alexey Izbyshev added the comment:
> 1) This is intentional, this is for dropping privileges before running some
> (possibly untrusted) command, we do not want to leave a path for the
> subprocess to gain root back. If there is a subprocess that needs root for
> some operatio
Change by Alexey Izbyshev :
--
nosy: +izbyshev
___
Python tracker
<https://bugs.python.org/issue31904>
___
___
Python-bugs-list mailing list
Unsubscribe:
Alexey Muranov added the comment:
IMO "overriding" a method with itself should not change the behaviour. So it
seems to me that the following is a bug:
class C:
def __init__(self, m):
print(m)
class D:
@staticmethod
Alexey Muranov added the comment:
Here is a use case for writable bases:
https://stackoverflow.com/q/56007866
class Stateful:
"""
Abstract base class for "stateful" classes.
Subclasses must implement InitState mixin.
"""
New submission from Alexey Muranov :
I expect that overriding methods with themselves like in the following example
should not change the behaviour of the class:
class C:
a = 1
def __init__(self, b):
self.b = b
def f(self, x):
return x
Alexey Muranov added the comment:
The issue is the following: i expect overriding a method with itself to not
change behaviour of the class. I do not see how my understanding of `__new__`
or its point could be relevant.
Do we agree that overriding a method with itself should not change
Alexey Muranov added the comment:
Incidentally, the documentation gives the following signature of __new__:
object.__new__(cls[, ...])
which suggests a variable number of arguments.
--
___
Python tracker
<https://bugs.python.org/issue36
Alexey Muranov added the comment:
I've noticed some faults in my code examples: `super(__class__, __class__)`
instead of a more appropriate `super(__class__, cls)`, forgotten `return`
before `super(__class__, self).foo(*args, **kwarg)`, maybe there are more. I
cannot edit previous com
Alexey Muranov added the comment:
There were problems with the use case for mutable bases that i posted (see
#36827). Here is an updated version:
https://gist.github.com/alexeymuranov/04e2807eb5679ac7e36da4454a58fa7e
--
___
Python tracker
Alexey Muranov added the comment:
Here is an example of code where i got surprised by the current behaviour and
had to apply some (ugly) workaround:
https://gist.github.com/alexeymuranov/04e2807eb5679ac7e36da4454a58fa7e
--
___
Python tracker
Alexey Muranov added the comment:
I see that I am not the only one who got bitten by this unexpected behaviour
(though the others might have not realised it). There is a question ["Creating
a singleton in Python"][1] on StackOverflow which was posted in 2011 and by now
has the to
New submission from Alexey Baldin :
_ssl.c has thread-usafe code in implementation of read, write and other
methods. E.g. 'write' method:
2099PySSL_BEGIN_ALLOW_THREADS
2100len = SSL_write(self->ssl, b->buf, (int)b->len);
2101_PySSL_UPDATE_ERRNO_IF(
Alexey Baldin added the comment:
I'd gather errno and win error into local variables (or struct) just after SSL
call and then pass them to PySSL_SetError.
--
___
Python tracker
<https://bugs.python.org/is
Alexey Izbyshev added the comment:
Any feedback on the updated PR?
--
___
Python tracker
<https://bugs.python.org/issue32236>
___
___
Python-bugs-list mailin
Alexey Izbyshev added the comment:
Any objections to the PR?
--
nosy: +belopolsky, eric.araujo
___
Python tracker
<https://bugs.python.org/issue32256>
___
___
New submission from Alexey Izbyshev :
_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 version is al
Change by Alexey Izbyshev :
--
keywords: +patch
pull_requests: +5382
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue32777>
___
___
Py
Alexey Izbyshev 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_exec() by e.g. specify
New submission from Alexey Izbyshev :
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 order of
destination descriptors. It
Change by Alexey Izbyshev :
--
keywords: +patch
pull_requests: +5482
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue32844>
___
___
Py
Alexey Izbyshev 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
<https://bugs.pyt
New submission from Alexey Izbyshev :
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 intended to
Change by Alexey Izbyshev :
--
keywords: +patch
pull_requests: +5497
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue32859>
___
___
Py
New submission from Alexey Izbyshev :
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 descriptors)
1.2) dup3() i
Change by Alexey Izbyshev :
--
keywords: +patch
pull_requests: +5503
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue32862>
___
___
Py
Alexey Izbyshev added the comment:
ktrace shows that dup(0) succeeded but fstat(0) failed. The symptom is the same
as in #30225. Could you check whether any of the following quick tests produces
the same error?
python3 -c 'import os, subprocess, sys; r, w = os.pipe(); os.cl
Alexey Izbyshev added the comment:
>Also, it has to skip this check if the FD is flagged as a pipe, because a pipe
>is likely opened in synchronous mode and blocked on a read in the parent, in
>which case calling GetFileType would deadlock.
Does an FD get flagged as a pipe b
Alexey Izbyshev added the comment:
@eryksun: Thank you for the note! I've commented on #32865. This adds even more
inconsistency to this corner case.
--
___
Python tracker
<https://bugs.python.org/is
New submission from Alexey Izbyshev :
MultiByteToWideChar expects the destination buffer size to be given in wide
characters, not bytes.
This is currently not a real issue since _Py_fopen_obj is only used internally
with mode being a short constant string in all call sites I've
Change by Alexey Izbyshev :
--
keywords: +patch
pull_requests: +5517
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue32869>
___
___
Py
Change by Alexey Izbyshev :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Alexey Izbyshev added the comment:
Thank you for checking. If this issue happens even when Python is run manually
from an ordinary shell, fixing it in the same way as in #30225 is probably not
what you want because while the error message will be gone the corresponding
std stream will be
101 - 200 of 470 matches
Mail list logo
