[issue42388] subprocess.check_output(['echo', 'test'], text=True, input=None) fails

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

[issue42606] Support POSIX atomicity guarantee of O_APPEND on Windows

Alexey Izbyshev added the comment: Could anybody provide their thoughts on this RFE? Thanks. -- ___ Python tracker <https://bugs.python.org/issue42606> ___ ___

[issue42606] Support POSIX atomicity guarantee of O_APPEND on Windows

Alexey Izbyshev added the comment: > I don't know what you mean by default access rights. I meant the access rights of the handle created by _wopen(). In my PR I basically assume that _wopen() uses GENERIC_READ/GENERIC_WRITE access rights, but _wopen() doesn't have a contractual obligat

[issue42606] Support POSIX atomicity guarantee of O_APPEND on Windows

Alexey Izbyshev added the comment: > FYI, here are the access rights applicable to files Thanks, I checked that mapping in headers when I was writing _Py_wopen_noraise() as well. But I've found a catch via ProcessHacker: CreateFile() with GENERIC_WRITE (or FILE_GENERIC_WRITE) additiona

[issue42606] Support POSIX atomicity guarantee of O_APPEND on Windows

Alexey Izbyshev added the comment: > It's possible to query the granted access of a kernel handle via > NtQueryObject: ObjectBasicInformation Ah, thanks for the info. But it wouldn't help for option (1) that I had in mind because open() and os.open() currently set only msvcrt-level O_

[issue42969] pthread_exit & PyThread_exit_thread from PyEval_RestoreThread etc. are harmful

Change by Alexey Izbyshev : -- nosy: +izbyshev ___ Python tracker <https://bugs.python.org/issue42969> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue42888] Not installed “libgcc_s.so.1” causes exit crash.

Alexey Izbyshev added the comment: Thank you for testing. I've added a NEWS entry to the PR, so it's ready for review by the core devs. Note that PyThread_exit_thread() can still be called by daemon threads if they try to take the GIL after Py_Finalize(), and also via C APIs like

[issue42888] Not installed “libgcc_s.so.1” causes exit crash.

Change by Alexey Izbyshev : -- keywords: +patch pull_requests: +23063 stage: -> patch review pull_request: https://github.com/python/cpython/pull/24241 ___ Python tracker <https://bugs.python.org/issu

[issue42888] Not installed “libgcc_s.so.1” causes exit crash.

Alexey Izbyshev added the comment: I've made a PR to remove most calls to pthread_exit(). @xxm: could you test it in your environment? -- ___ Python tracker <https://bugs.python.org/issue42

[issue42780] os.set_inheritable() fails for O_PATH file descriptors on Linux

Change by Alexey Izbyshev : -- components: +Library (Lib) nosy: +vstinner versions: -Python 3.6, Python 3.7 ___ Python tracker <https://bugs.python.org/issue42

[issue43113] os.posix_spawn errors with wrong information when shebang points to not-existing file

Alexey Izbyshev added the comment: > IMO the fix is simple: only create OSError from the errno, never pass a > filename. This will remove a normally helpful piece of the error message in exchange to being marginally less confusing in a rare case of non-existing interpreter (the

[issue42606] Support POSIX atomicity guarantee of O_APPEND on Windows

Alexey Izbyshev added the comment: > I think truncation via TRUNCATE_EXISTING (O_TRUNC, with O_WRONLY or O_RDWR) > or overwriting with CREATE_ALWAYS (O_CREAT | O_TRUNC) is at least tolerable > because the caller doesn't care about the existing data. Yes, I had a thought that

[issue43069] Python fails to read a script whose path is `/dev/fd/X`

Alexey Izbyshev added the comment: I would suggest to start digging from the following piece of code in `maybe_pyc_file()` (Python/pythonrun.c): int ispyc = 0; if (ftell(fp) == 0) { if (fread(buf, 1, 2, fp) == 2 && ((unsigned int)buf[1]<

[issue43113] os.posix_spawn errors with wrong information when shebang points to not-existing file

Alexey Izbyshev added the comment: > Ideally, the error would say: > FileNotFoundError: ./demo: /usr/bin/hugo: bad interpreter: No such file or > directory The kernel simply returns ENOENT on an attempt to execve() a file with non-existing hash-bang interpreter. The sa

[issue43113] os.posix_spawn errors with wrong information when shebang points to not-existing file

Alexey Izbyshev added the comment: > FileNotFoundError: [Errno 2] No such file or directory: Either './demo' or > the interpreter of './demo' not found. This doesn't sound good to me because a very probable and a very improbable reasons are combined together without any distinction. A

[issue43113] os.posix_spawn errors with wrong information when shebang points to not-existing file

Alexey Izbyshev added the comment: How do you propose to approach documentation of such behavior? The underlying cause is the ambiguity of ENOENT error code from execve() returned by the kernel, so it applies to all places where Python can call execve(), including os.posixspawn(), os.execve

[issue43113] os.posix_spawn errors with wrong information when shebang points to not-existing file

Alexey Izbyshev added the comment: I generally agree, but getting a good, short error message seems to be the hard part here. I previously complained[1] about the following proposal by @hroncok: FileNotFoundError: [Errno 2] No such file or directory: Either './demo' or the interpreter

[issue32592] Drop support of Windows Vista and Windows 7

Alexey Izbyshev added the comment: As far as I understand, commit [1] explicitly prevents CPython from running on Windows 7, and it's included into 3.9. So it seems to be too late to complain, despite that, according to Wikipedia, more than 15% of all Windows PCs are still running Windows 7

[issue32592] Drop support of Windows Vista and Windows 7

Alexey Izbyshev added the comment: > If we had a dedicated maintainer who was supporting Win7 and making releases > for it, then we (i.e. they) could support it. But then, there's nothing to > stop someone doing that already, and even to stop them charging money for it > if they

[issue32592] Drop support of Windows Vista and Windows 7

Alexey Izbyshev added the comment: > If Win8-only calls are not used, then presumably it should still build and > run on Windows 7, presumably with the flag flipped back to Win7. And if there > are Win8-only calls used and the flag is set to Win7+, I assume that the MSVC &

[issue43308] subprocess.Popen leaks file descriptors opened for DEVNULL or PIPE stdin/stdout/stderr arguments

Change by Alexey Izbyshev : -- nosy: +gregory.p.smith ___ Python tracker <https://bugs.python.org/issue43308> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue42738] subprocess: don't close all file descriptors by default (close_fds=False)

Alexey Izbyshev added the comment: > As a concrete example, we have a (non-Python) build system and task runner > that orchestrates many tasks to run in parallel. Some of those tasks end up > invoking Python scripts that use subprocess.run() to run other programs. Our >

[issue44656] Dangerous mismatch between MAXPATHLEN and MAX_PATH on Windows

New submission from Alexey Izbyshev : In PC/getpathp.c CPython uses buffers with length MAXPATHLEN+1, which is 257 on Windows[1]. On Windows 7, where PathCch* functions are not available, CPython <= 3.8 fallbacks to PathCombineW()/PathCanonicalizeW()[2]. Those functions ass

[issue47260] os.closerange() can be no-op in a seccomp sandbox

Change by Alexey Izbyshev : -- keywords: +patch pull_requests: +30443 stage: -> patch review pull_request: https://github.com/python/cpython/pull/32418 ___ Python tracker <https://bugs.python.org/issu

[issue47260] os.closerange() can be no-op in a seccomp sandbox

Alexey Izbyshev added the comment: > It's been years now and that hasn't happened, even with more recent flag > additions. I think it's safe to say it won't, and such a fallback upon error > won't put us back into a bogus pre-close_range situation where we're > needlessly close(

[issue47260] os.closerange() can be no-op in a seccomp sandbox

Change by Alexey Izbyshev : -- keywords: +patch stage: -> patch review ___ Python tracker <https://bugs.python.org/issue47260> ___ ___ Python-bugs-list mai

[issue47245] potential undefined behavior with subprocess using vfork() on Linux

Alexey Izbyshev added the comment: In short: both this bug report and [1] are invalid. The reason why doing syscall(SYS_vfork) is illegal is explained by Florian Weimer in [2]: >The syscall function in glibc does not protect the on-stack return address >against overwriting, so it

[issue35823] Use vfork() in subprocess on Linux

Alexey Izbyshev added the comment: The preceding comment is wrong, see discussion in #47245 and https://bugzilla.kernel.org/show_bug.cgi?id=215813#c14 for explanation of why that bug report is irrelevant for CPython. -- ___ Python tracker <ht

[issue47245] potential undefined behavior with subprocess using vfork() on Linux?

Alexey Izbyshev added the comment: > As for glibc specifics, I'm mostly thinking of the calls we do in the child. > According to the "Standard Description (POSIX.1)" calls to anything other > than `_exit()` or `exec*()` are not allowed. But the longer "Linux > D

[issue47245] potential undefined behavior with subprocess using vfork() on Linux?

Alexey Izbyshev added the comment: > 3. We have to fix error-path in order not to change heap state (contents and > allocations), possibly do not touch locks. During vfork() child execution - > the only parent THREAD (not the process) is blocked. For example, it's not > allowed

[issue47260] os.closerange() can be no-op in a seccomp sandbox

New submission from Alexey Izbyshev : After #40422 _Py_closerange() assumes that close_range() closes all file descriptors even if it returns an error (other than ENOSYS): if (close_range(first, last, 0) == 0 || errno != ENOSYS) { /* Any errors encountered while closing file

<    1   2   3   4