[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
The WindowsBufferProblems
- To: <or-dev@xxxxxxxxxxxxx>
- Subject: The WindowsBufferProblems
- From: "Ge van Geldorp" <ge@xxxxxx>
- Date: Wed, 14 Jun 2006 17:19:23 +0200
- Delivered-to: archiver@seul.org
- Delivered-to: or-dev-outgoing@seul.org
- Delivered-to: or-dev@seul.org
- Delivery-date: Wed, 14 Jun 2006 11:19:42 -0400
- Reply-to: or-dev@xxxxxxxxxxxxx
- Sender: owner-or-dev@xxxxxxxxxxxxx
- Thread-index: AcaPxeqs7qkqkIW2Ro++SOE30ffnrQ==
After reading the pleas for help on the Tor website on the "WSAENOBUFS"
problem
(http://wiki.noreply.org/noreply/TheOnionRouter/WindowsBufferProblems and
http://bugs.noreply.org/flyspray/index.php?do=details&id=98) I decided to
dig a bit into it. Unfortunately, after two weeks of trying, I still haven't
been able to reproduce the problem.
I have tried with both clean installs of XP Professional SP2 and XP Home SP2
(no registry tweaks or other "fancy" stuff) and Tor 0.1.1.20. Since
indications are that the problem is related to nonpaged pool exhaustion and
the amount of nonpaged pool is related to the amount of RAM installed, I
tried with low RAM amounts (96Mb and 128Mb, resulting in maximum nonpaged
pool sizes of 38Mb and 50Mb resp.). Tor would run happily for days.
The Wiki says "Running a Tor server on a vanilla XP install does not
(easily) trigger the problem. But it can be consistently reproduced if you
also run TCP/IP intensive applications such as P2P clients (BitTorrent,
eDonkey, eMule, etc).". Well, not for me. I had a BitTorrent client with
about 250 peers running alongside Tor. This config didn't even come close to
exhausting the nonpaged pool (around 11Mb of the maximum of 38Mb used). Tor
performed flawlessly.
So, I wrote a test program that just eats up nonpaged pool by building TCP
connections to itself over the loopback interface and on each connection
writing some stuff without ever reading it from the other end (causing it to
be buffered in nonpaged pool). When running the test program to eat (almost)
all nonpaged pool I start to see failures when running Tor (WSAENOBUFS
errors on write, WSAECONNRESET on read, using "info" loglevel). However, Tor
handled these failures gracefully, closing the affected circuits. I didn't
have to reboot to fix. I also didn't see the "do_main_loop(): select failed:
No buffer space available [WSAENOBUFS ] [10055]" (or rather it's modern
equivalent, "libevent call with ... failed: [WSAENOBUFS] [10055]") message a
single time.
So by now I'm starting to wonder if this problem still exists? Has anyone
recently seen a WSAENOBUFS problem which needed a reboot to fix? Even
better, anyone who can consistently reproduce it?
GvG