PortForwardingHelper stdout/stderr log forwarding seems fragile

While working on a fix for a regression I caused in #21757 (moved) I noticed that we had code in our utility module that could be affected by the same regression as I was trying to fix.

I've tried to list some of my observations while studying this code:

  • We use non-blocking I/O for stdout and stderr in the spawned tor-fw-helper child process, but we only call log_from_pipe() once immediately after spawning the process. From my quick observation the call to log_form_pipe() almost always result in a EAGAIN and we then return without processing any lines at all since we never actually try to read again.
  • We have duplicated code in handle_fw_helper_line() and log_from_pipe() to handle SPAWN_ERROR_MESSAGE error messages during child creation with a comment related to the first observation.

I tried to test this with a simple dummy PortForwardingHelper script which outputs a set of lines on stdout and stderr, sleeps for a while, then continues to write some more content before it exits and only a subset of these lines are actually forwarded to tor's logging subsystem.

The application seems to work correctly and contact my router, so this issue is purely related to the forwarding of stdout and stderr from the helper process.

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information