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

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#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                 |   Keywords:  bridgedb-parsers
Actual Points:                        |  Parent ID:
       Points:                        |   Reviewer:
      Sponsor:  SponsorM-can          |
--------------------------------------+------------------------------
 The following file:

 {{{
 bridgedb@polyanthum /srv/bridges.torproject.org/from-bifroest
  % cat networkstatus-bridges
 published 2017-08-15 18:58:10
 flag-thresholds stable-uptime=0 stable-mtbf=0 fast-speed=0 guard-
 wfu=0.000% guard-tk=0 guard-bw-inc-exits=0 guard-bw-exc-exits=0 enough-
 mtbf=1 ignoring-advertised-bws=0
 }}}

 causes the bridgedb process to hang. The last log lines output are:

 {{{
 bridgedb@polyanthum ~ % tail -f
 /srv/bridges.torproject.org/log/bridgedb.log
 19:46:33 INFO     L465:Bridges.insert()         BridgeSplitter placing
 bridge $$C44836BF2F42DB5B1AD3CF6085626056593D846A~Shizuokalibelous into
 hashring https (via n=5, pos=0).
 19:46:33 DEBUG    L547:Bridges.insert()         Inserting
 $$C44836BF2F42DB5B1AD3CF6085626056593D846A~Shizuokalibelous into
 hashring...
 19:46:33 DEBUG     L78:geo.getCountryCode()     Looked up country code: NL
 19:46:33 INFO     L465:Bridges.insert()         BridgeSplitter placing
 bridge $$2CC6A05D7F52D7B936ABEE13C782780E4B23B64F~conglutinatoreri into
 hashring email (via n=14, pos=1).
 19:46:33 DEBUG    L547:Bridges.insert()         Inserting
 $$2CC6A05D7F52D7B936ABEE13C782780E4B23B64F~conglutinatoreri into
 hashring...
 19:46:33 INFO     L174:Main.load()              Done inserting 1959
 bridges into hashring.
 19:46:33 DEBUG    L208:persistent.save()        Saving state to:
 '/srv/bridges.torproject.org/run/bridgedb.state'
 19:46:33 INFO      L80:Main.load()              Processing descriptors in
 ../from-bifroest directory...
 19:46:33 INFO      L86:Main.load()              Opening networkstatus
 file: /srv/bridges.torproject.org/from-bifroest/networkstatus-bridges
 19:46:33 INFO     L124:descriptors.parseNetwo() Parsing networkstatus
 file: /srv/bridges.torproject.org/from-bifroest/networkstatus-bridges
 }}}

 Further, and this might be a separate issue, but when BridgeDB hangs in
 this state, the cronjob which calls `bridgedb --reload` launches an
 entirely new process of bridgedb, without killing the old one, since the
 old one is locked while doing blocking IO, and the signal handlers are in
 the async code that it's supposed to come back to. I think there's not
 really any way to fix this, since Stem is doing the IO there, and Stem
 isn't async aware/capable.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/23251>
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