On 1 Jul 2015, at 01:29 , Cory Pruce corypruce@gmail.com wrote:

I've been able to do a make install and am ready to continue setting up the test environment. I see chutney on your github. I'll get that set up when I get home. Do you have any advice for testing Tor? Also, feel free to move this to the mailing list whenever you feel it's appropriate.

Hi Cory,

I'm moving this to tor-dev as it's relevant to other developers.

Chutney

Please use the official chutney repository at git.torproject.org http://git.torproject.org/

My chutney repository a little messy at the moment, and I've merged draft throughput-testing code into my master branch. You're welcome to test the draft code by merging https://github.com/teor2345/chutney/tree/bug14175-bandwidth https://github.com/teor2345/chutney/tree/bug14175-bandwidth The throughput-testing functionality works, but it needs to be tidied up, and have the hard-coded constants turned into command-line options. So it's not ready for release, but it is ready for an early review to check for functionality gaps and bugs.

You might find throughput metrics useful to confirm that any multithreading changes are actually improving performance.

Testing

Once tor is built, you can test it using: # basic tests make test # extended tests make check # benchmarks /src/test/bench # verify tor connectivity using a local test network - requires chutney make test-network # verify that the core functionality of tor works, requires chutney and IPv6 on localhost src/test/test-network.sh --flavour bridges+ipv6+hs # verify that the core functionality of tor works, using chutney, but without IPv6 src/test/test-network.sh --flavour bridges src/test/test-network.sh --flavour hs

There's also various other testing tools: shadow Tor network simulator static analysers, such as coverity and clang-scan dynamic sanitizers: Undefined Behaviour (UBSan), Address (ASAN), … fuzzing (I'm working on some tor-specific harnesses for fuzzing, but they're not ready) and I'm sure there are others which I've missed.

Generally, I'm happy with code once I know it: * compiles with no warnings, * passes the extended unit tests (make check), including any tests written for new functionality, and * passes all the connectivity tests in a comprehensive test network (bridges+ipv6+hs).

For bonus points, you can compile tor using UBSan and ASAN. If you're using clang, you'll find that tor/contrib/clang helps with setting this up. It lists known undefined behaviour in the Tor codebase, so it may be useful if you want to do something similar with gcc. (However, getting sanitizers to work can be incredibly fiddly and a total time-suck, too. So if it's just not working, skip it.)

I'll also occasionally run code through a static analyser, to find subtle bugs which haven't been uncovered using UBSan/ASAN. Again, this isn't something everyone needs to do.

Others may have advice on testing multithreading code in particular.

Tim

Tim Wilson-Brown (teor)

teor2345 at gmail dot com pgp 0xABFED1AC https://gist.github.com/teor2345/d033b8ce0a99adbc89c5

teor at blah dot im OTR D5BE4EC2 255D7585 F3874930 DB130265 7C9EBBC7