#26360: Transport plugins deadlock if they write too much to stderr
------------------------------+--------------------
     Reporter:  dcf           |      Owner:  (none)
         Type:  defect        |     Status:  new
     Priority:  Medium        |  Milestone:
    Component:  Core Tor/Tor  |    Version:
     Severity:  Normal        |   Keywords:  pt
Actual Points:                |  Parent ID:
       Points:                |   Reviewer:
      Sponsor:                |
------------------------------+--------------------
 
[https://gitweb.torproject.org/tor.git/tree/src/or/transports.c?id=bc951e83aac770d123118bf485d14490c2539048#n516
 launch_managed_proxy], via
 
[https://gitweb.torproject.org/tor.git/tree/src/common/util.c?id=bc951e83aac770d123118bf485d14490c2539048#n4232
 tor_spawn_background], opens a pipe from the child process's stderr, but
 never reads from the pipe. If the child process writes too much to its
 stderr, eventually an OS buffer fills up and the child process hangs. This
 manifests in the tor log as "No running bridges."

 Seems like this has always been a problem, but it only showed up recently
 with Snowflake, which by default logs to stderr and is more chatty than
 past transports have been. See #25600. The problem went away when
 instructing snowflake-client to log to a file instead of to stderr.

 Ccing ahf as suggested by arma.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/26360>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Reply via email to