Previously, we'd issue an HTTP/1.1 400 Bad Request" response on every
connection close, event if sever sent response already.
This patch changes the behavior, so we only issue the response on
close when the connection state is not DISCONNECTED, and so we set
the state to DISCONNECTED when the connection closes.
Includes a regression test; fixes sourceforge bug 2909909.
It turns out that kqueue_dealloc wasn't calling evsig_dealloc()
(because it doesn't use the main signal handler logic) so the sh_old
array was leaking.
This patch also introduces a fix in evsig_dealloc() where we set
the sh_old array to NULL when we free it, so that main/fork can pass.
William's original commit message:
Valgrind complains on startup because kq_init passes to kevent only
a partially initialized structure. The code doesn't expect kevent
to look at .fflags, .udata, or .data, I suppose, because it merely
tickles the kernel looking for an error response. But perhaps
that's unwarranted chuminess (notwithstanding that it's checking
for an OS X bug), and needless noise nonetheless.
This is necessary because it is not actually possible to use
evbuffer_readline() safely: it will treat "A\r\n" as 'A' EOL if it
reads it all at once, and as 'A' EOL EOL if there is a delay between
reading the \r and the \n.
Nicholas Marriott's comments on this patch:
Gilles is too busy so I've had a go at this, please see the diff
below. Rather than try to backport directly from 2.0 where the
evbuffer code is quite different, I've backported the _readln
function from when it was initially added in buffer.c r550. I can't
see any relevant bug fixes after this point so the function is
pretty much just copied in directly from that revision.
We were saying calloc(N,N*sizeof(struct event_list*)) when we should have
been saying calloc(N,sizeof(struct event_list*)). This wasted N*(N-1) words
of memory, where N was the number of priorities. This wouldn't be a big deal
for any sane number of priorities, but it's a bug nonetheless.
svn:r1526
On some systems (notably HPUX), there is already a
/usr/include/sys/_time.h, which our sys/_time.h shadows. Found and
diagnosed by Kathryn Hogg.
This is a quick fix for 1.4 only; for 2.0, I want to eliminate
compat/sys/_time.h entirely, and have util-internal subsume it.
svn:r1493
New backends like poll and kqueue and so on add fds to the queue in
the order that they are triggered. But the select backend currently
activates low-numbered fds first, whereas the poll and win32 backends
currently favor whatever fds have been on for the longest. This is no
good for fairness.
svn:r1327
Generally speaking, it way better to event_assign() an event when you
allocate it than to assign it before every time you event_add it: if
it is already event_add()ed, the assign will mess it up so that it
doesn't _look_ added, and event_add() will insert a second copy.
Later, event_del() will only delete the second copy. Eventually, the
event_base will have a dangling pointer to freed memory. Ouch!
svn:r1308
Some win32 systems (mostly those using Kaspersky, it would seem)
prevent us from faking socketpair(). This makes our signal
notification code just not work. Our response since 1.4 has been to
assert. For users who would rather work without signals than not work
at all, this has been a regression from 1.3e.
This patch makes adding signal events fail in this case; there's no
reason to kill the whole process.
svn:r1304
This is based on patch 2790759 from Kevin Springborn. His comments on
sourceforge:
Problem:
The failure case is as follows: Event is added using epoll_add (a
direct pointer is stored in the user_data section), epoll_recalc is
called and the fds array is moved (invalidating the user_data
pointer stored in epoll). epoll_dispatch is called for the added
event and accesses evepoll based on the invalid pointer (set before
the fds array was relocated).
Solution:
Dispatch has access to the epollop structure, so given the fd we can
find the corresponding evepoll struct. Use data.fd instead of
data.ptr and store the fd corresponding to the event. This way when
epoll_recalc moves the fds array (and updates the fds array pointer
in epollop), the evepoll calculation in dispatch still finds the
valid evepoll struct.
svn:r1282
