[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-bugs] #23251 [Obfuscation/BridgeDB]: Parsing a networkstatus-bridges with flags only causes BridgeDB to hang

#23251: Parsing a networkstatus-bridges with flags only causes BridgeDB to hang
----------------------------------+------------------------------
 Reporter:  isis                  |          Owner:  isis
     Type:  defect                |         Status:  new
 Priority:  Medium                |      Milestone:
Component:  Obfuscation/BridgeDB  |        Version:
 Severity:  Major                 |     Resolution:
 Keywords:  bridgedb-parsers      |  Actual Points:
Parent ID:                        |         Points:
 Reviewer:                        |        Sponsor:  SponsorM-can
----------------------------------+------------------------------

Comment (by isis):

 Replying to [comment:1 atagar]:
 > Hi Isis. Added a quick test to see if that line's problematic for Stem.
 Seems to be just fine...
 >
 > https://gitweb.torproject.org/stem.git/commit/?id=30990ab
 >

 Right, that should be fine for Stem. Also, BridgeDB's parsers actually
 skip the flags/headers entirely and tell Stem to start reading after them,
 so it wouldn't be a Stem issue anyway. :)

 > As for Stem not being 'async aware' I'm not sure what you mean or why
 that's relevant. You're just using Stem as a descriptor parser. That has
 nothing to do with its controller functionality.

 Oh, I mean that BridgeDB is Twisted python, so it's main loop is
 asynchronous. But while BridgeDB is doing it's
 `bridgedb.parse.descriptors.*` functions (which call Stem) the handling of
 the file isn't done in the way that Twisted is happy with because it's
 blocking (see the `FileWriter(proto.Protocol)` class in the
 `bridgedb.git/scripts/get-tor-exits` script for an exmaple of how Twisted
 wants IO to be done). So because this IO is all blocking, and because of
 the hang bug, it never returns to BridgeDB's main loop, which is where the
 handlers for the SIGUSR1 and SIGHUPs signals are, which are required to
 restart BridgeDB when it receives new descriptors from the BridgeAuth.

 To be clear, none of this is a bug in Stem. It's all BridgeDB.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/23251#comment:2>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online

_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs