PortForwardingHelper stdout/stderr log forwarding seems fragile
While working on a fix for a regression I caused in legacy/trac#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 calllog_from_pipe()
once immediately after spawning the process. From my quick observation the call tolog_form_pipe()
almost always result in aEAGAIN
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()
andlog_from_pipe()
to handleSPAWN_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.