[tor-bugs] #23281 [Core Tor/Stem]: py-stem test failures on FreeBSD

Tor Bug Tracker & Wiki blackhole at torproject.org
Sun Aug 20 19:20:52 UTC 2017


#23281: py-stem test failures on FreeBSD
---------------------------+-----------------------------------
 Reporter:  yurivict271    |          Owner:  atagar
     Type:  defect         |         Status:  needs_information
 Priority:  Medium         |      Milestone:
Component:  Core Tor/Stem  |        Version:
 Severity:  Normal         |     Resolution:
 Keywords:                 |  Actual Points:
Parent ID:                 |         Points:
 Reviewer:                 |        Sponsor:
---------------------------+-----------------------------------

Comment (by atagar):

 Very helpful - thanks yurivict271!

 -----

 {{{
 ======================================================================
 FAIL: test_stats
 ----------------------------------------------------------------------
 Traceback (most recent call last):
   File "/usr/local/lib/python2.7/site-packages/mock/mock.py", line 1305,
 in patched
     return func(*args, **keywargs)
   File "/usr/ports/security/py-
 stem/work/stem-1.5.4/test/unit/util/proc.py", line 138, in test_stats
     self.assertEqual(response, proc.stats(24062, *args))
 AssertionError: Tuples differ: ('0.13',) != ('0.1015625',)

 First differing element 0:
 '0.13'
 '0.1015625'

 - ('0.13',)
 + ('0.1015625',)

 ----------------------------------------------------------------------
 }}}

 Think I see what's up. Proc results take a CLOCK_TICK constant into
 account. It probably differs between our systems. Pushed a fix that should
 get this test to pass...

 https://gitweb.torproject.org/stem.git/commit/?id=3fb2faa

 -----

 {{{
 ======================================================================
 FAIL: test_tail
 ----------------------------------------------------------------------
 Traceback (most recent call last):
   File "/usr/ports/security/py-
 stem/work/stem-1.5.4/test/unit/util/system.py", line 399, in test_tail
     self.assertRaises(IOError, list, system.tail(temp_path))
 AssertionError: IOError not raised

 ----------------------------------------------------------------------

 ======================================================================
 FAIL: test_load_processed_files_permissions
 ----------------------------------------------------------------------
 Traceback (most recent call last):
   File "/usr/ports/security/py-
 stem/work/stem-1.5.4/test/unit/descriptor/reader.py", line 206, in
 test_load_processed_files_permissions
     self.assertRaises(IOError,
 stem.descriptor.reader.load_processed_files, test_listing_path)
 AssertionError: IOError not raised

 ======================================================================
 FAIL: test_skip_listener_read_failure
 ----------------------------------------------------------------------
 Traceback (most recent call last):
   File "/usr/ports/security/py-
 stem/work/stem-1.5.4/test/unit/descriptor/reader.py", line 584, in
 test_skip_listener_read_failure
     self.assertTrue(isinstance(skip_exception,
 stem.descriptor.reader.ReadFailed))
 AssertionError: False is not true

 ----------------------------------------------------------------------
 }}}

 Interesting. This tests are creating files we lack read access on, then
 asserting we cannot read them. We can add a 'if freebsd skip this test'
 but I'm kinda curious - can you not revoke your own read access with
 freebsd? What do you get when you run the following?

 {{{
 % echo "hello world" > /tmp/test_file
 % chmod -r /tmp/test_file
 % python
 Python 2.7.3 (default, Oct 26 2016, 21:04:23)
 [GCC 4.6.3] on linux2
 Type "help", "copyright", "credits" or "license" for more information.
 >>> open('/tmp/test_file', 'rb').read()
 Traceback (most recent call last):
   File "<stdin>", line 1, in <module>
 IOError: [Errno 13] Permission denied: '/tmp/test_file'
 }}}

 -----

 {{{
 ======================================================================
 ERROR: test_parsing_with_example
 ----------------------------------------------------------------------
 Traceback (most recent call last):
   File "/usr/ports/security/py-stem/work/stem-1.5.4/test/unit/manual.py",
 line 157, in test_parsing_with_example
     manual = stem.manual.Manual.from_man(EXAMPLE_MAN_PATH)
   File "/usr/ports/security/py-stem/work/stem-1.5.4/stem/manual.py", line
 378, in from_man
     raise IOError("Unable to run '%s': %s" % (man_cmd, exc))
 IOError: Unable to run 'man --encoding=ascii -P cat /usr/ports/security
 /py-stem/work/stem-1.5.4/test/unit/tor_man_example': man --encoding=ascii
 -P cat /usr/ports/security/py-
 stem/work/stem-1.5.4/test/unit/tor_man_example returned exit status 1

 ======================================================================
 ERROR: test_parsing_with_unknown_options
 ----------------------------------------------------------------------
 Traceback (most recent call last):
   File "/usr/ports/security/py-stem/work/stem-1.5.4/test/unit/manual.py",
 line 180, in test_parsing_with_unknown_options
     manual = stem.manual.Manual.from_man(UNKNOWN_OPTIONS_MAN_PATH)
   File "/usr/ports/security/py-stem/work/stem-1.5.4/stem/manual.py", line
 378, in from_man
     raise IOError("Unable to run '%s': %s" % (man_cmd, exc))
 IOError: Unable to run 'man --encoding=ascii -P cat /usr/ports/security
 /py-stem/work/stem-1.5.4/test/unit/tor_man_with_unknown': man
 --encoding=ascii -P cat /usr/ports/security/py-
 stem/work/stem-1.5.4/test/unit/tor_man_with_unknown returned exit status 1

 ======================================================================
 ERROR: test_saving_manual
 ----------------------------------------------------------------------
 Traceback (most recent call last):
   File "/usr/ports/security/py-stem/work/stem-1.5.4/test/unit/manual.py",
 line 207, in test_saving_manual
     manual = stem.manual.Manual.from_man(EXAMPLE_MAN_PATH)
   File "/usr/ports/security/py-stem/work/stem-1.5.4/stem/manual.py", line
 378, in from_man
     raise IOError("Unable to run '%s': %s" % (man_cmd, exc))
 IOError: Unable to run 'man --encoding=ascii -P cat /usr/ports/security
 /py-stem/work/stem-1.5.4/test/unit/tor_man_example': man --encoding=ascii
 -P cat /usr/ports/security/py-
 stem/work/stem-1.5.4/test/unit/tor_man_example returned exit status 1

 ----------------------------------------------------------------------
 }}}

 I'd like to fix this if we can. What do you get when you run that command?

 {{{
 man --encoding=ascii -P cat /usr/ports/security/py-
 stem/work/stem-1.5.4/test/unit/tor_man_with_unknown
 }}}

 Is there something else we can run to get a man page's content without the
 formatting markup? Here's what I get...

 {{{
 % man --encoding=ascii -P cat test/unit/tor_man_with_unknown
 TOR(1)
 Tor Manual
 TOR(1)



 NAME
        tor - The second-generation onion router

 GENERAL OPTIONS
        BandwidthRate N bytes|KBytes|MBytes|GBytes|KBits|MBits|GBits
            A token bucket limits the average incoming bandwidth usage on
 this node to the specified number of bytes per second, and the average
 outgoing bandwidth usage to that same value. If you want to
            run a relay in the public network, this needs to be at the very
 least 30 KBytes (that is, 30720 bytes). (Default: 1 GByte)


            With this option, and in other options that take arguments in
 bytes, KBytes, and so on, other formats are also supported. Notably,
 "KBytes" can also be written as "kilobytes" or "kb"; "MBytes"
            can be written as "megabytes" or "MB"; "kbits" can be written
 as "kilobits"; and so forth. Tor also accepts "byte" and "bit" in the
 singular. The prefixes "tera" and "T" are also recognized. If
            no units are given, we default to bytes. To avoid confusion, we
 recommend writing "bytes" or "bits" explicitly, since it's easy to forget
 that "B" means bytes, not bits.

 NEW OPTIONS
        SpiffyNewOption transport exec path-to-binary [options]
            Description of this new option.

 Tor
 10/03/2015
 TOR(1)
 }}}

 -----

 {{{
 ======================================================================
 ERROR: test_pids_by_user
 ----------------------------------------------------------------------
 Traceback (most recent call last):
   File "/usr/ports/security/py-
 stem/work/stem-1.5.4/test/integ/util/system.py", line 377, in
 test_pids_by_user
     self.assertTrue(os.getpid() in pids)
 TypeError: argument of type 'NoneType' is not iterable

 ======================================================================
 }}}

 Is there a way with freebsd to get the pids a user is running? This test
 is running 'ps -o pid -u username' and seems that doesn't work. If not
 then not the end of the world - we can note this isn't supported on
 freebsd.

 -----

 {{{
 ======================================================================
 FAIL: test_expand_path
 ----------------------------------------------------------------------
 Traceback (most recent call last):
   File "/usr/ports/security/py-
 stem/work/stem-1.5.4/test/integ/util/system.py", line 563, in
 test_expand_path
     self.assertEqual(home_dir, stem.util.system.expand_path('~%s' %
 username))
 AssertionError: '/root' != '/home/yuri'

 ----------------------------------------------------------------------
 }}}

 Interesting. Does the output of these two commands differ for you?

 {{{
 % python
 Python 2.7.3 (default, Oct 26 2016, 21:04:23)
 [GCC 4.6.3] on linux2
 Type "help", "copyright", "credits" or "license" for more information.
 >>> import os
 >>> os.path.expanduser('~')
 '/home/atagar'
 >>> os.path.expanduser('~%s' % os.environ['USER'])
 '/home/atagar'
 }}}

 -----

 {{{
 ======================================================================
 FAIL: test_hash_password
 ----------------------------------------------------------------------
 Traceback (most recent call last):
   File "/usr/ports/security/py-
 stem/work/stem-1.5.4/test/integ/process.py", line 104, in
 test_hash_password
     self.assertTrue(re.match('^16:[0-9A-F]{58}\n$', output))
 AssertionError: None is not true

 ----------------------------------------------------------------------
 }}}

 Interesting. What do you get from the following? Note that 'my_password'
 here can be anything - just interested in the format of the output.

 {{{
 tor --hush --hash-password my_password
 16:FF773344208EE8F4600696F285936B0EA81B6F6598204A061B631F68E2
 }}}

 -----

 {{{
 ======================================================================
 ERROR: test_hidden_services_conf
 ----------------------------------------------------------------------
 Traceback (most recent call last):
   File "/usr/ports/security/py-stem/work/stem-1.5.4/test/runner.py", line
 127, in wrapped
     return func(self, *args, **kwargs)
   File "/usr/ports/security/py-
 stem/work/stem-1.5.4/test/integ/control/controller.py", line 549, in
 test_hidden_services_conf
     controller.set_hidden_service_conf(initialconf)
   File "/usr/ports/security/py-stem/work/stem-1.5.4/stem/control.py", line
 2582, in set_hidden_service_conf
     self.set_options(hidden_service_options)
   File "/usr/ports/security/py-stem/work/stem-1.5.4/stem/control.py", line
 2419, in set_options
     raise stem.InvalidRequest(response.code, response.message)
 InvalidRequest: Unacceptable option value: Failed to configure rendezvous
 options. See logs for details.

 ----------------------------------------------------------------------
 }}}

 Interesting. Maybe port 8020, 8021, 8030, 8031, or 8032 are already in
 use? Odd ports to have a conflict with but possible I suppose. If you
 don't think that's it mind attaching the output of the following?

 {{{
 % run_tests.py --integ --log TRACE --verbose --test
 test.integ.control.controller
 }}}

 -----

 {{{
 STATIC CHECKS
 460     * /usr/ports/security/py-
 stem/work/stem-1.5.4/stem/descriptor/remote.py
 461       line 445  - E722 do not use bare except'             | except:
 462       line 1013 - E722 do not use bare except'             | except:
 }}}

 These look ok. Pycodestyle added some new assertions since our last
 release. If you test against the git version these should be suppressed.

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


More information about the tor-bugs mailing list