Skip to content
Snippets Groups Projects
New look: Off

run_tests.py fails on Windows

    • Closed Issue created by Trac @tracbot

    When running run_tests.py on Windows, it will complain that "'module' object has no attribute 'sysconf'". The reason it that os.sysconf, which is used out of a try/except clause in stem.util.proc, is undefined on Windows. It should fail gracefully rather than raise an exception. I've fixed it, and my public repo is: https://github.com/beckbaibai/stem

    However, it's not the only bug. The program can't find tor even though I've installed it. It says "Unable to start tor, 'tor' does not exists." I don't know the reason yet.

    Trac:
    Username: reganeet

    To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information

    Child items ...

    • Activity

    • Trac added component::archived/stem owner::atagar priority::medium reporter::reganeet resolution::fixed status::closed type::defect labels

      added component::archived/stem owner::atagar priority::medium reporter::reganeet resolution::fixed status::closed type::defect labels

    • A
      Damian Johnson @atagar ·

      Hi reganeet. Thanks for the patch! I've pushed it to the main repository along with a small fix.

      However, it's not the only bug. The program can't find tor even though I've installed it. It says "Unable to start tor, 'tor' does not exists." I don't know the reason yet.

      This probably isn't a stem bug. If you open cmd and type 'tor' at the prompt then does tor run? Are you sure that tor is in your $PATH?

      Trac:
      Status: new to needs_information

    • Trac
      Trac @tracbot ·
      Author

      I've added tor to my $PATH, and able to run it from CLI, but I still get the same error.

      Trac:
      Username: reganeet

    • A
      Damian Johnson @atagar ·

      Hmm, then I'm not sure what's up. Here's the code that starts the tor process... https://gitweb.torproject.org/stem.git/blob/HEAD:/stem/process.py#l16

      If you run it as... ./run_tests.py --integ --tor C:\path\to\tor

      does it work? If not then the next step is to figure out what about that launch_tor function is failing on Windows.

    • Trac
      Trac @tracbot ·
      Author

      It works. It is caused by file extension ".exe" in windows, so stem.util.system.is_available() cannot find "tor" even if the path to it is contained in $PATH. I've fixed this bug and pushed to my repo.

      Running "./run_tests.py --unit --integ --no-color" produces several failure in unit tests, and integration tests does not work at all.

      Failures in unit tests are caused by two errors. One is "AttributeError: 'module' object has no attribute 'uname'", which is expected since those functions using os.uname() are not designed for windows. Another is in test_expend_path: "AssertionError: '/tmp' != '/tmp\'", which seems to be caused by the different of paths in *nix systems and windows.

      I have no idea why integ tests fail. Here is the log:

      Setting up a test instance... making test directory (F:\Dropbox\tor\stem\test/data)... skipped configuring logger (F:\Dropbox\tor\stem\test/data/log)... Shutting down tor... done Shutting down tor... done TESTING FAILED (0.1 seconds) [UNIT TEST] test_expand_path (test.unit.util.system.TestSystem) ... FAIL [UNIT TEST] test_get_bsd_jail_id (test.unit.util.system.TestSystem) ... ERROR [UNIT TEST] test_get_pid_by_name_lsof (test.unit.util.system.TestSystem) ... ERROR [UNIT TEST] test_get_pid_by_name_pgrep (test.unit.util.system.TestSystem) ... ERROR [UNIT TEST] test_get_pid_by_name_pidof (test.unit.util.system.TestSystem) ... ERROR [UNIT TEST] test_is_running (test.unit.util.system.TestSystem) ... ERROR [UNIT TEST] test_relative_cookie (test.unit.connection.protocolinfo.TestProtocolInfoResponse) ... FAIL

      Trac:
      Username: reganeet

    • A
      Damian Johnson @atagar ·

      Hi reganeet. Thanks for the fix. I'd like to wrap it in an 'is windows' check - what does platform.dist() and sys.platform give for you under Windows?

      >>> import platform
>>> print platform.dist()
('Ubuntu', '11.04', 'natty')

>>> import sys
>>> sys.platform
'linux2'

      One is "AttributeError: 'module' object has no attribute 'uname'", which is expected since those functions using os.uname() are not designed for windows.

      Uggg, why does OS detection need to be such a pita?

      Here is the log

      Please upload the full test log to pastebin then add link to it. Unfortunately this doesn't include the important bits for debugging (the stacktraces).

      Cheers! -Damian

    • Trac
      Trac @tracbot ·
      Author

      Unfortunately, platform.dist() is another Unix-only command. Running is on Windows gives me a tuple of empty strings. sys.platform works though.

      >>> import platform
>>> print platform.dist()
(_, _, '')

>>> import sys
>>> sys.platform
'win32'

      You might want to consider using platform.system(): http://docs.python.org/library/platform.html#platform.system It should return 'Windows' no matter the architecture is x86 or x64.

      I know that log does not help, but Stem did not print anything else about the integ test, and I didn't find an option like --debug or --verbose.

      Trac:
      Username: reganeet

    • A
      Damian Johnson @atagar ·

      Thanks! Pushed an alternative patch that should do the trick... https://gitweb.torproject.org/stem.git/commitdiff/35f31d8c1527e106013ceb293302901dce8f9cf0

      I know that log does not help, but Stem did not print anything else about the integ test

      Actually, I was wondering about the stacktraces from the unit tests.

    • Trac
      Trac @tracbot ·
      Author

      I put it here: http://codeupload.com/5471

      Trac:
      Username: reganeet

    • G
      Sathyanarayanan Gunasekaran @gsathya ·

      Looking at the stacktraces, we should be using os.path.join() which combines the components intelligently based on the operating system instead of hardcoding the paths.

    • G
      Sathyanarayanan Gunasekaran @gsathya ·

      < atagar> gsathya: could you please update the ticket with your osx output for platform.system()? maybe we can use that as this 'what the hell are we running on' check

      >>> import platform
>>> platform.system()
'Darwin'
    • A
      Damian Johnson @atagar ·

      Thanks. It looks like platform.system() == os.uname()[0], at least for Linux and Mac. At some point we should check that this holds true for FreeBSD and OpenBSD but I'd be surprised if it doesn't. Replaced all os.uname() usage so those unit tests should be fine now.

      Looking at the stacktraces, we should be using os.path.join() which combines the components intelligently based on the operating system instead of hardcoding the paths.

      Actually, it is using os.path.join() in expand_path. The trouble is that (a) the test doesn't mock os.path.sep and (b) the expand_path function is unix specific.

      I've fixed 'a' and addressed 'b' by making the function a no-op on Windows. At some point we should make it work on Windows but at the moment nothing vital relies on it and dealing with things like the "C:" prefix will be a minor pita.

      The unit tests should now be working on Windows. The change of expand_path() to being a no-op might make the integ tests come a little closer to working. Stem's default test directory and logging path are unix specific which made that function give a hybrid path...

      F:\Dropbox\tor\stem\test/data/log

      but this should now be left as...

      ./data/log

      Windows understands unix path separators so I think that this is fine but guess we'll see...

    • A
      Damian Johnson @atagar ·

      Known windows compatibility issues from this ticket have been solved so resolving. Feel free to file a new ticket if you run into any more.

      Thanks! -Damian

      Trac:
      Status: needs_information to closed
      Resolution: N/A to fixed

    • Trac closed

      closed

    Please register or sign in to reply