Nick Mathewson [Fri, 8 Oct 2010 17:05:13 +0000 (13:05 -0400)]
New evhttp_uri(encode|decode) functions to handle + and NUL characters right
The old evhttp_decode_uri() function would act as tough it was doing
an (illegal, undefined) decode operation on a whole URL at once, and
treat + characters following a ? as different from + characters
preceding one. But that's not useful: If you are decoding a URI
before splitting off query parameters, you are begging to fail as soon
as somebody gives you a value with an encoded & in it.
The new evhttp_uridecode() function takes an argument that says
whether to decode + signs. Both uridecode and uriencode also now
support encoding or decoding to strings with internal 0-valued
characters.
Nick Mathewson [Fri, 8 Oct 2010 16:57:11 +0000 (12:57 -0400)]
evhttp_encode_uri encodes all reserved characters, including !$'()*+,/:=@
Perviously, some characters not listed as "unreserved" by RFC 3986
(notably "!$'()*+,/:=@") were not encoded by evhttp_encode_uri. This
made trouble, especially when encoding path components (where @ and /
are bad news) and parameters (where + should get encoded so it doesn't
later decode into a space).
Nick Mathewson [Wed, 6 Oct 2010 15:48:52 +0000 (11:48 -0400)]
Let evhttp_parse_query return -1 on failure
We already detected certain malformed queries, but we responded by
aborting the query-parsing process half-way through without telling
the user. Now, if query-parsing fails, no headers are returned, and
evhttp_parse_query returns -1.
Nick Mathewson [Fri, 1 Oct 2010 03:15:47 +0000 (23:15 -0400)]
Fix a spurious-call bug on epoll.c
We were trying to check whether any events had really been
notified on an fd before calling evmap_io_active on it, but instead
we were checking for an event pointer, which was always true.
In practice, this patch shouldn't change much, since epoll_wait
shouldn't return an event unless there is actually an event going
on.
Spotted by an anonymous bug reporter on Sourceforge. Closes bug 3078425.
Nick Mathewson [Fri, 24 Sep 2010 02:45:55 +0000 (22:45 -0400)]
Fix all warnings in the main codebase flagged by -Wsigned-compare
Remember, the code
int is_less_than(int a, unsigned b) {
return a < b;
}
is buggy, since the C integer promotion rules basically turn it into
int is_less_than(int a, unsigned b) {
return ((unsigned)a) < b;
}
and we really want something closer to
int is_less_than(int a, unsigned b) {
return a < 0 || ((unsigned)a) < b;
}
.
Nick Mathewson [Wed, 15 Sep 2010 05:40:02 +0000 (01:40 -0400)]
Make default signal backend fully threadsafe
Jason Toffaletti discovered with helgrind that our signal handler was
messing with evsig_base, which can be set from lots of places in the
code. Ordinarly, we'd just stick a lock on it, except that it is
illegal (and genuinely error-prone) to call pthread_mutex_acquire()
from inside a signal handler.
The solution is to only store the fd we write to in a static variable,
write the signal number to the fd, and put evsig_cb in charge of
activating signal events.
I have no idea how we'll cope if we want to enable this to handle
siginfo (where available) in the future.
Nick Mathewson [Wed, 15 Sep 2010 05:08:39 +0000 (01:08 -0400)]
Warn when using the error-prone EV_SIGNAL interface in an error-prone way. Also, fix a couple of race conditions in signal.c
When using the signal.c signal backend, Libevent currently only allows
one event_base to actually receive signals at a time. (This has been
the behavior since at least 1.4 and probably much earlier.) Now, we
detect and warn if you're likely to be racing about which signal goes
to which thread.
We also add a lock to control modifications of the evsig_base field,
to avoid race conditions like those found by Jason Toffaletti.
Nick Mathewson [Wed, 8 Sep 2010 17:22:55 +0000 (13:22 -0400)]
Minimize calls to base_notify implementation functions, thereby avoiding needless syscalls
The trick here is that if we already told the base to wake up, and it
hasn't woken up yet, we don't need to tell it to wake up again. This
should help lots with inherently multithreaded code like IOCP.
Only process up to MAX_DEFERRED deferred_cbs at a time.
If threads queue callbacks while event_process_deferred_callbacks is
running, the loop may spin long enough to significantly skew timers.
A unit test stressing this behavior is also in this commit.
- Increment reference count of bufferevents before initiating overlapped
operations to prevent the destructor from being called while operations
are pending. The only portable way of canceling overlapped ops is to
close the socket.
- Translate error codes to WSA* codes.
- Better handling of errors.
- Add an interface to add and del "virtual" events. Because IOCP
bufferevents don't register any events with the base, the event loop
has no way of knowing they exist. This causes the loop to terminate
prematurely. event_base_{add,del}_virtual increment/decrement base's
event count so the loop runs while there are any enabled IOCP
bufferevents.
- Prevent evbuffer_{add,prepend}_buffer from moving read-pinned chains.
- Fix evbuffer_drain to handle read-pinned chains better.
- Raise the limit on WSABUFs from two to MAX_WSABUFS for overlapped reads.
Nick Mathewson [Thu, 2 Sep 2010 15:10:50 +0000 (11:10 -0400)]
Use the _func() replacements for open, fstat, etc in evutil.c on win32
Remember that in a fit of ANSI C compliance, Microsoft decided to
screw portability by renaming basically all the functions in unistd.h to
get prefixed with an understore.
For some reason, mingw didn't seem to mind, but at least some people's
compilers did: see bug 3044490.
Nick Mathewson [Thu, 2 Sep 2010 16:06:58 +0000 (12:06 -0400)]
Declare signal handler function as "__cdecl" on Windows.
I swear, they must have half a dozen different calling conventions.
(goes to check)
Holy crud. They actually do. There's __cdecl, __stdcall, __fastcall,
"thiscall", "naked" and the obsolete "__pascal", "__fortran", and
"__syscall". And don't forget WINAPI and __far.
Anyways, this should fix 3044488 if I got it right.
Nick Mathewson [Thu, 2 Sep 2010 15:36:44 +0000 (11:36 -0400)]
Move evkeyvalq into a separate header for evhttp_parse_query users
The evhttp_parse_query API is a bit misdesigned; all the other
evkeyvalq stuff is abstract and lets you get away with having a header
stub, but evhttp_parse_query seems to require that you instantiate an
empty evkeyvalq of your own.
Nick Mathewson [Wed, 1 Sep 2010 20:36:30 +0000 (16:36 -0400)]
Close th_notify_fds and open a new pair on reinit
After a fork, you want subthreads to wake up the event_base in the
child process, not to have the child process and the main process
fight over who wakes up whom.
Related to a problem found by Nicholas Marriott while debugging 3048812.
Nick Mathewson [Mon, 30 Aug 2010 15:35:06 +0000 (11:35 -0400)]
Fix a bug in our win32 condition implementation
The do ... while loop in our wait code could spin while waiting
because the event object wasn't reset until there were no longer any
events waiting to be woken up. We also want to reset the event object
if the count of events to wake up reaches zero.
Nick Mathewson [Tue, 17 Aug 2010 17:26:03 +0000 (13:26 -0400)]
Correctly detect failure to delete bufferevent read-timeout event
Gilad Benjamini noted that we check the error code for deleting a
write-timeout event twice, and the read timeout not at all. This
shouldn't be a bit problem, since it's really hard for a delete to
fail on a timeout-only event, but it's worth fixing.
Nick Mathewson [Tue, 17 Aug 2010 17:18:18 +0000 (13:18 -0400)]
Use conditions instead of current_event_lock to fix a deadlock.
Avi Bab correctly noted as bug 3044479 the fact that any thread
blocking on current_event_lock will do so while holding
th_base_lock, making it impossible for the currently running event's
callback to call any other functions that require th_base_lock.
This patch switches the current_event_lock code to instead use a
condition variable that we wait on if we're trying to mess with
a currently-executing event, and that we signal when we're done
executing a callback if anybody is waiting on it.
Nick Mathewson [Tue, 17 Aug 2010 17:15:34 +0000 (13:15 -0400)]
Add a condition variable backend, with implementations for pthreads and win32
The interface from the user's POV is similar to the locking
implementation: either provide a structure full of function
pointers, or just call evthread_use_*_threads() and everything will
be okay.
The internal interface is meant to vaguely resemble pthread_cond_*,
which Windows people will better recognize as *ConditionVariable*.
Gilad Benjamini [Fri, 13 Aug 2010 21:08:59 +0000 (17:08 -0400)]
Clean up syntax on TAILQ_ENTRY() usage
Though the C standards allow it, it's apparently possible to get MSVC
upset by saying "struct { int field; } (declarator);" instead of
"struct {int field; } declarator;", so let's just not do that.
Nick Mathewson [Fri, 13 Aug 2010 15:41:37 +0000 (11:41 -0400)]
Make include/event2/event-config.h not included in source dist
As a generated file, it shouldn't get included in our source
distribution. Apparently there is an automake incant for this:
nobase_ even stacks with nodist_ .
Nick Mathewson [Fri, 13 Aug 2010 15:34:39 +0000 (11:34 -0400)]
Change include order in Makefile.nmake
If there is an event-config.h in include/event2 (either because we
screwed up packaging like in 2.0.6-rc or because we previously tried
building with mingw and we didn't make distclean in the middle), we
want MSVC to find the one one in WIN32-Code/include/event2 first.
Nick Mathewson [Mon, 9 Aug 2010 16:08:40 +0000 (12:08 -0400)]
Fix a nasty dangling-event bug when using rate-limiting groups
When we freed a bufferevent that was in a rate-limiting group and
blocked on IO, the process of freeing it caused it to get removed
from the group. But removing the bufferevent from the group made
its limits get removed, which could make it get un-suspended and in
turn cause its events to get re-added. Since we would then
immediately _free_ the events, this would result in dangling
pointers.
Nick Mathewson [Fri, 6 Aug 2010 20:36:23 +0000 (16:36 -0400)]
Fix unit tests with -DUSE_DEBUG enabled
If you were to enable USE_DEBUG and slog through all 700+ MB of
debugging output, you'd find that one of the unit tests failed,
since it tested the debug logging code, but the string it expected
and the string it logged differed by a tab vs 2 spaces.