Reputation: 1397
I have a situation when I try to launch a process (Chrome originally) with posix_spawn
on MacOS. This code should work on Linux as well, but I haven't tested yet.
I want to create pipes for descriptors 1 (STDOUT), 2 (STDERR) and also 3 (write) and 4 (read).
It doesn't work with Chrome, and I'm trying to test this case with a simple code:
#!/usr/bin/env python3
import os
import sys
import time
import fcntl
print("fcntl 3:", fcntl.fcntl(3, fcntl.F_GETFD))
print("fcntl 4:", fcntl.fcntl(4, fcntl.F_GETFD))
fd4 = os.fdopen(4, 'wb')
while True:
print('Cycle')
time.sleep(2)
while chunk := os.read(3, 1024):
print('REQ:', chunk.decode('utf8', errors='backslashreplace'), file=sys.stderr)
fd4.write(b'FOO')
I'm trying to check if descriptors are reachable. Descriptor 3 is ready for reading, and data can be read from it.
But descriptor 4 is not accessible, an attempt to open it or test with fcntl leads to an error "OSError: [Errno 9] Bad file descriptor". And Chrome fails on the same try.
Here is the C++ code (simplified a little) with posix_spawn
that leads to this situation:
#include "pipes.h"
#include <cerrno>
#include <cstring>
#include <spawn.h>
#include <stdio.h>
#include <sys/poll.h>
#include <sys/wait.h>
extern "C" char** environ;
constexpr int CDP_WRITE_FILENO = 3;
constexpr int CDP_READ_FILENO = 4;
void RunBrowser(const char* exePath, const std::vector<const char*>& launchArgs) {
posix_spawn_file_actions_t childFdActions{};
posix_spawn_file_actions_init(&childFdActions);
DEFER(&childFdActions) {
posix_spawn_file_actions_destroy(&childFdActions);
};
int stdoutPipe[2];
int stderrPipe[2];
int cdpWritePipe[2];
int cdpReadPipe[2];
if (pipe(stdoutPipe) || pipe(stderrPipe) || pipe(cdpWritePipe) || pipe(cdpReadPipe)) {
throw TBrowserError() << "Could not create a pipe: " << std::strerror(errno);
}
posix_spawn_file_actions_addclose(&childFdActions, stdoutPipe[0]);
posix_spawn_file_actions_addclose(&childFdActions, stderrPipe[0]);
posix_spawn_file_actions_addclose(&childFdActions, cdpWritePipe[1]);
posix_spawn_file_actions_addclose(&childFdActions, cdpReadPipe[0]);
posix_spawn_file_actions_adddup2(&childFdActions, stdoutPipe[1], STDOUT_FILENO);
posix_spawn_file_actions_adddup2(&childFdActions, stderrPipe[1], STDERR_FILENO);
posix_spawn_file_actions_adddup2(&childFdActions, cdpWritePipe[0], CDP_WRITE_FILENO);
posix_spawn_file_actions_adddup2(&childFdActions, cdpReadPipe[1], CDP_READ_FILENO);
posix_spawn_file_actions_addclose(&childFdActions, stdoutPipe[1]);
posix_spawn_file_actions_addclose(&childFdActions, stderrPipe[1]);
posix_spawn_file_actions_addclose(&childFdActions, cdpWritePipe[0]);
posix_spawn_file_actions_addclose(&childFdActions, cdpReadPipe[1]);
pid_t childPid{};
if (const int ret = posix_spawn(&childPid, exePath,
&childFdActions, nullptr,
const_cast<char* const*>(launchArgs.data()),
environ)) {
throw TBrowserError() << "Failed to spawn a process: " << std::strerror(ret);
}
close(stdoutPipe[1]);
close(stderrPipe[1]);
close(cdpWritePipe[0]);
close(cdpReadPipe[1]);
int status;
do {
const int ret = waitpid(childPid, &status, WUNTRACED | WCONTINUED);
if (ret == -1) {
kill(childPid, SIGKILL);
throw TBrowserError() << "waitpid error: -1";
}
if (WIFEXITED(status)) {
const auto retCode = WEXITSTATUS(status);
if (retCode == 0) {
break;
}
throw TBrowserError() << std::format("Browser process failed with exit code {}", retCode);
}
if (WIFSIGNALED(status)) {
throw TBrowserError() << "Browser process killed by signal " << WTERMSIG(status);
}
if (WIFSTOPPED(status)) {
std::cerr << "Browser process stopped by signal " << WSTOPSIG(status) << std::endl;
}
if (WIFCONTINUED(status)) {
std::cerr << "Browser process is continued" << std::endl;
}
} while (WIFEXITED(status) || WIFSIGNALED(status));
}
Upvotes: 3
Views: 96
Reputation: 13582
This is just a speculation:
First, pipe(stdoutPipe)
occupies file descriptors 3 and 4 in the parent process. (The other pipe()
calls occupy later file descriptors, but this is not relevant.)
Then in the client:
p_s_f_a_addclose(&childFdActions, stdoutPipe[0]);
closes descriptor 3.p_s_f_a_adddup2(&childFdActions, cdpWritePipe[0], CDP_WRITE_FILENO);
makes descriptor 3 usable.p_s_f_a_adddup2(&childFdActions, cdpReadPipe[1], CDP_READ_FILENO);
makes descriptor 4 usable.p_s_f_a_addclose(&childFdActions, stdoutPipe[1]);
closes descriptor 4.The last action makes the file descriptor unusable in the client.
As a solution, you can do the adddup2
calls first, and then add all the addclose
calls, but only if they do not close one of the file descriptors 0 to 4.
Upvotes: 2