vfork() doesn't share memory on some systems
#443
Comments
kernigh
added a commit
to kernigh/ast
that referenced
this issue
Mar 30, 2018
When spawnvex() calls fork(), it never sets vex->pgrp, so vex->pgrp is always 0. It then called setpgid(pid, 0) on every fork() child. This tried to put every child into a new process group, whether or not we had a SPAWN_pgrp command. In OpenBSD 6.2, if the child's execve() succeeded, then setpgid() failed with EACCES. If the child's execve() failed, then setpgid() succeeded, and the child possibly executed a shell script in the wrong process group. This caused 4 failures in src/tests/signal.sh because the `kill -s INT 0` failed to signal some shell scripts in the wrong process group. The fork() child can execute a shell script since the removal of vfork() in PR att#444 to fix bug att#443. src/tests/signal.sh still has 2 other failures in OpenBSD.
krader1961
pushed a commit
that referenced
this issue
Apr 4, 2018
When spawnvex() calls fork(), it never sets vex->pgrp, so vex->pgrp is always 0. It then called setpgid(pid, 0) on every fork() child. This tried to put every child into a new process group, whether or not we had a SPAWN_pgrp command. In OpenBSD 6.2, if the child's execve() succeeded, then setpgid() failed with EACCES. If the child's execve() failed, then setpgid() succeeded, and the child possibly executed a shell script in the wrong process group. This caused 4 failures in src/tests/signal.sh because the `kill -s INT 0` failed to signal some shell scripts in the wrong process group. The fork() child can execute a shell script since the removal of vfork() in PR #444 to fix bug #443. src/tests/signal.sh still has 2 other failures in OpenBSD.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
User @kernigh brought to our attention that
vfork()on OpenBSD 6.2 does not share the address space between the parent and child process. The old build system has a test thatvfork()implements the legacy behavior. When we converted to the Meson build system and greatly simplified the feature detection code we didn't port those tests and made the incorrect assumption that surely there aren't anyvfork()implementations we care about which don't share the address space.User @kernigh originally proposed reinstating the necessary feature test in PR #432. But after some discussion the consensus appears to be that maintaining support for
vfork()isn't worth the complexity. This issue is to track removal of all support forvfork().The text was updated successfully, but these errors were encountered: