Opened 5 years ago

Closed 5 years ago

#5493 closed defect (fixed)

run_tests.py fails on Windows

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

Description

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.

Child Tickets

Change History (12)

comment:1 Changed 5 years ago by atagar

Status: newneeds_information

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?

comment:2 in reply to:  1 Changed 5 years ago by reganeet

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

comment:3 Changed 5 years ago by 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.

comment:4 Changed 5 years ago by reganeet

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

comment:5 Changed 5 years ago by 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

comment:6 Changed 5 years ago by reganeet

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.

comment:7 Changed 5 years ago by 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.

comment:8 Changed 5 years ago by reganeet

comment:9 Changed 5 years ago by 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.

comment:10 Changed 5 years ago by 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'

comment:11 Changed 5 years ago by 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...

comment:12 Changed 5 years ago by atagar

Resolution: fixed
Status: needs_informationclosed

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

Note: See TracTickets for help on using tickets.