Opened 3 months ago

Closed 6 weeks ago

#29899 closed defect (fixed)

Descriptor exit_policy can raise TypeError?

Reported by: juga Owned by: atagar
Priority: Medium Milestone:
Component: Core Tor/Stem Version:
Severity: Normal Keywords:
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

In sbws we got this traceback:

  File "/usr/lib/python3/dist-packages/sbws/lib/relaylist.py", line 117, in can_exit_to_port
     if not self.exit_policy:
  File "/usr/lib/python3/dist-packages/stem/exit_policy.py", line 512, in __len__  # noqa
    return len(self._get_rules())
  File "/usr/lib/python3/dist-packages/stem/exit_policy.py", line 464, in _get_rules  # noqa
    for rule in decompressed_rules:
TypeError: 'NoneType' object is not iterable

I'm a bit confused on what triggers that, because looking at stem code, it does not seem that __init__ calls _get_rules, but this seems to happen when just getting the exit_policy attribute in sbws: https://github.com/torproject/sbws/blob/master/sbws/lib/relaylist.py#L92.

In the moment _get_rules is call, this might happen because it is not check that _input_rules is not None: https://github.com/torproject/stem/blob/master/stem/exit_policy.py#L462?

Should also _input_rules be assigned [] instead of None in https://github.com/torproject/stem/blob/master/stem/exit_policy.py#L507?

Child Tickets

Change History (2)

comment:1 Changed 7 weeks ago by atagar

Hi juga, sorry this has gone so long without a reply! Looks to be a concurrency bug. Our get_rules() helper isn't thread safe, and I can see how parallel requests to it could result in that stacktrace.

I'd prefer for our ExitPolicy to remain lock free but I'll need to give this some thought.

comment:2 Changed 6 weeks ago by atagar

Resolution: fixed
Status: newclosed

Hi juga, thought of an elegant fit for this that avoids locking. Feel free to reopen if you need anything else...

https://gitweb.torproject.org/stem.git/commit/?id=87cea95

Note: See TracTickets for help on using tickets.