Original post:
This post is in response to a posting last December on a Windows
regression fork failure ([Libevent-users] Re: Libevent 2.0.10-stable
is released by Dongsheng Song). I noticed the question was not
answered and I recently experienced the same error myself when
trying to run the Windows regression tests myself.
I checked the return status from the CreateProcess call and found it
was "file not found". This led me to look at the command-line I was
using which was .\regress in a Visual Studio 2008 command prompt
window. Windows could not find the file because it did not have the
.exe extension on the end. The code that builds the command should
be modified to ensure the extension is present.
event_base_free(NULL) means "free the current event base".
Previously, it would assert if there was no 'current' base. Now it
just warns and returns.
Reported by Gilad Benjamini
When searching for a CRLF, it would find an LF, then look for a
preceding CR if not at the start of the buffer. That's fine when
we're starting from the beginning of the buffer, but if we're starting
at (say) byte 100, and we have that byte == LF, we shouldn't check for
a CR at byte 99.
Our evbuffer_strchr() function [which was only used for
search_eol(EOL_LF) could give incorrect results if it found its answer
in the first chunk but didn't start searching from the front of the
chunk.
Also, this patch adds unit tests for evbuffer_search_eol, particularly
in those cases that evbuffer_readln() tests didn't exercise.
Instead of mapping enough bytes for each segment, we were failing to
take into account the slop created by rounding the segment position
down to the nearest page.
Should fix bug 3142394 found by Sebastian Hahn.
This bug would sometimes lead us to looking one bit off the end of
the fdset arrays, and trying to activate a (nonexistent) event if
that bit was set.
Found by Harlann Stenn. Fixes a test failure on OpenSolaris.
Turns out that FreeBSD does _not_ give a ENETUNREACH error when
told to make a TCP socket to 255.255.255.255, but it is quite happy
to do so for 239.10.20.30. So that's what we'll do.
Found by Robert Ransom and Dave Hart.
Previously, evport could only handle up to 8 events per time through
the loop. This would impose an artificially high number of syscalls
on us to retrieve a large number of events.
This code allows the EVLOOP_* flags to work more similarly to how
they do on other platforms (up to 4096 events per syscall). Dispite
dire warning (from 2006), doing this won't impose a big incremental
RAM penalty: if you have 4096 events firing at once, you necessarily
have a proportional number of events pending, and their associated
data structures are already costing a good bit of RAM.
This patch makes the main/many_events_slow_add test pass again.
