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

Марк Коренберг added the comment: I have studied assembler output of _posixsubprocess.o compilation. Yes, everything seems safe. So, I'm closing the bug. -- resolution: -> works for me stage: test needed -> resolved status: open -> closed ___

[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 to touch

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

Марк Коренберг added the comment: So, finally: 1. Regarding vfork() and stack - everything is nice. No bugs because libc has nasty hacks for stack restoration. 2. Having the ability to turn off vfork using environment variables is NICE. At least, one can easily compare the performance. 3.

[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 > Description" in that vfork(2)

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

Gregory P. Smith added the comment: Thanks! I agree with you that this is probably not an actual problem on Linux. _I did look at the various glibc architecture vfork.s implementations: Cute tricks used on some where they need to avoid a stack modifying traditional return from vfork()._

[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 can't be

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

Gregory P. Smith added the comment: Our current assumptions around the use of vfork() are very much glibc specific. Another useful reference for reasoning, comments, and history is https://github.com/golang/go/blob/master/src/syscall/exec_linux.go#L146 `forkAndExecInChild1` --

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

Change by Gregory P. Smith : -- keywords: +3.10regression ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

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

Gregory P. Smith added the comment: Immediate action item: Add a way for people to disable vfork at runtime by setting a flag in the subprocess module, just in case. This can be backported to 3.10 - It'd provide an escape hatch for anyone without a need to rebuild Python to disable use of

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

Gregory P. Smith added the comment: Can you provide a reproducable way to demonstrate evidence of a problem in CPython's use of the Linux libc vfork() implementation? A test case that causes a CPython parent or child process on Linux when built with HAVE_VFORK failing to function properly