[tor-dev] Discussions

[teor]

> On 1 Jul 2015, at 01:29 , Cory Pruce <corypruce at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20150701/79daf4d2/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20150701/79daf4d2/attachment.sig>