Fixes: #577
* evconnlistener-do-not-close-client-fd:
listener: cover closing of fd in case evconnlistener_free() called from acceptcb
Revert "Fix potential fd leak in listener_read_cb()"
This reverts commit a695a720cda892c270736d127333d73553842094.
@kgraefe:
"I believe that this commit is just wrong: if lev->cnt is not 1 after
the callback, new_fd will still never be closed in listener_read_cb().
So in that case it is the responsibility of the user's code to close
the file descriptor (which is fine). But why shouldn't it be in the
other case? And how does the user's code know?"
And I agree
'LIBEVENT_INCLUDE_DIRS' is properly initialized in 'LibeventConfig.cmake' as
'LibeventConfig.cmake.in' contains usage of 'LIBEVENT_CMAKE_DIR' and
'EVENT_INSTALL_INCLUDE_DIR' variables but not 'EVENT_CMAKE_DIR' and
'EVENT__INCLUDE_DIRS'.
Related typos are fixed.
Replaces reference in the http.h include header file to evhttp_get_decoded_uri
with evhttp_uridecode. There is no function called evhttp_get_decoded_uri.
This is the second hunk of the first patch
5ff8eb26371c4dc56f384b2de35bea2d87814779 ("Fix crashing http server when
callback do not reply in place")
Fixes: #567
I checked with nginx, and via it's lua bindings it allows body for all
this methods. Also everybody knows that some of web-servers allows body
for GET even though this is not RFC conformant.
Refs: #408
General http callback looks like:
static void http_cb(struct evhttp_request *req, void *arg)
{
evhttp_send_reply(req, HTTP_OK, "Everything is fine", NULL);
}
And they will work fine becuase in this case http will write request
first, and during write preparation it will disable *read callback* (in
evhttp_write_buffer()), but if we don't reply immediately, for example:
static void http_cb(struct evhttp_request *req, void *arg)
{
return;
}
This will leave connection in incorrect state, and if another request
will be written to the same connection libevent will abort with:
[err] ../http.c: illegal connection state 7
Because it thinks that read for now is not possible, since there were no
write.
Fix this by disabling EV_READ entirely. We couldn't just reset callbacks
because this will leave EOF detection, which we don't need, since user
hasn't replied to callback yet.
Reported-by: Cory Fields <cory@coryfields.com>
Since it can arrive after we disabled events in that bufferevent and
reseted fd, hence evhttp_error_cb() could be called after
SSL_RECEIVED_SHUTDOWN.
Closes: #557
Because it is mauvais ton to use binaries instead of normal packages
(like apt-get in debian, pacman in arch, and others).
Plus that link was borken and according to [1] OpenSSL do not ship
binaries officially.
And personally I don't think that this is not obvious that you need
openssl libraries to build libevent with it's support, and BTW you need
headers too (of course).
[1]: https://www.openssl.org/community/binaries.htmlFixes: #562
In function ‘send_a_byte_cb’:
test/regress.c:1853:2: warning: ignoring return value of ‘write’, declared with
attribute warn_unused_result [-Wunused-result]
(void) write(*sockp, "A", 1);
by default, the max buffer size is 16K and histeresis is at 50%, so
a bigger read is needed to unlock writes than you would expect from
other BSD (512 bytes)
this doesn't introduce any regression on FreeBSD 11.1, OpenBSD 6.1, NetBSD 7.1,
macOS 10.12.6 and of course DragonFlyBSD 4.8.1, and most of them show
a max pipe size of 64K, so the read call should drain them all regardless
of how conservative they are on the free pipe space they will require
(usually 512 bytes) before kevent reports the fd as ready for write.
I couldn't find a reference to which bug this code was trying to look for
and it seems to be there from the beginning of git history so it might be
no longer relevant.
Issue: #548
Detected using ThreadSanitizer, resolved by capturing the value
of ev_res in a local variable while the event is locked, then
passing that captured variable to the callback.
TSAN report:
I0728 14:35:09.822118 WARNING: ThreadSanitizer: data race (pid=815501)
I0728 14:35:09.822186 Write of size 2 at 0x7b2c00001bf2 by thread T80 (mutexes: write M1110835549570434736):
I0728 14:35:09.822248 #0 event_active_nolock_ libevent/event.c:2893:14 (0a2b90577e830d775300664df77d0b91+0x1fdab28)
I0728 14:35:09.822316 #1 event_active libevent/event.c:2858:2 (0a2b90577e830d775300664df77d0b91+0x1fdd10e)
I0728 14:35:09.822379 #2 Envoy::Event::TimerImpl::enableTimer(std::chrono::duration<long, std::ratio<1l, 1000l> > const&) envoy/source/common/event/timer_impl.cc:24:5 (0a2b90577e830d775300664df77d0b91+0x459fa0)
...
I0728 14:35:09.824146 Previous read of size 2 at 0x7b2c00001bf2 by main thread:
I0728 14:35:09.824232 #0 event_process_active_single_queue libevent/event.c:1646:33 (0a2b90577e830d775300664df77d0b91+0x1fdf83d)
I0728 14:35:09.824350 #1 event_process_active libevent/event.c (0a2b90577e830d775300664df77d0b91+0x1fd9ad8)
I0728 14:35:09.824445 #2 event_base_loop libevent/event.c:1961 (0a2b90577e830d775300664df77d0b91+0x1fd9ad8)
I0728 14:35:09.824550 #3 Envoy::Event::DispatcherImpl::run(Envoy::Event::Dispatcher::RunType) envoy/source/common/event/dispatcher_impl.cc:166:3 (0a2b90577e830d775300664df77d0b91+0x4576d9)
...
Fixes: #543 (pull-request)
It is a bit confusing to check against the result of EVUTIL_UPCAST(),
because it can return not NULL for NULL pointers, but for even though
with bufferevent we are fine (because bufferevent is the first field in
bufferevent_private), there are no checks for "bufev" in bufferevent's
API, so just remove it to make it generic.
Fixes: #542
Signed-off-by: Ivan Maidanski <i.maidanski@samsung.com>
Signed-off-by: Azat Khuzhin <a3at.mail@gmail.com>
"chain" cannot be NULL here because we have at least one chain (we
handle empty buffer separatelly) and hence loop will be executed at
least once.
Link: 841ecbd961 (commitcomment-23631347)
Signed-off-by: Ivan Maidanski <i.maidanski@samsung.com>
Signed-off-by: Azat Khuzhin <a3at.mail@gmail.com>
Currently it's not clear as to whether "first make it non-pending and
non-active" sentence requires user to take some action (e.g. call event_del(),
which event_free() already does internally) or just describes what this
function does from the developer point of view.
I cannot made it work without this, even though dumpbin shows that that symbol
exists in the event_core.dll, event_extra.dll failed to compile:
==> win: Creating library C:/vagrant/.cmake-vagrant/lib/Debug/event_extra.lib and object C:/vagrant/.cmake-vagrant/lib/Debug/event_extra.exp
==> win: http.obj : error LNK2001: unresolved external symbol _event_debug_logging_mask_ [C:\vagrant\.cmake-vagrant\event_extra_shared.vcxproj]
==> win: C:\vagrant\.cmake-vagrant\bin\Debug\event_extra.dll : fatal error LNK1120: 1 unresolved externals [C:\vagrant\.cmake-vagrant\event_extra_shared.vcxproj]
==> win: Done Building Project "C:\vagrant\.cmake-vagrant\event_extra_shared.vcxproj" (default targets) -- FAILED.
And dumpbin:
sh-4.1$ /cygdrive/c/Program\ Files\ \(x86\)/Microsoft\ Visual\ Studio\ 12.0/VC/bin/amd64/dumpbin.exe /EXPORTS ./bin/Debug/event_core.dll
M
202 C9 00059A3C event_debug_logging_mask_ = _event_debug_logging_mask_
==> win: CMake Warning (dev) at CMakeLists.txt:782 (elseif):
==> win: Policy CMP0054 is not set: Only interpret if() arguments as variables or
==> win: keywords when unquoted. Run "cmake --help-policy CMP0054" for policy
==> win: details. Use the cmake_policy command to set the policy and suppress this
==> win: warning.
==> win:
==> win: Quoted variables like "MSVC" will no longer be dereferenced when the policy
==> win: is set to NEW. Since the policy is not set the OLD behavior will be used.
==> win: This warning is for project developers. Use -Wno-dev to suppress it.
Delete the event from the queue before blocking for the current
event callback termination.
Ensures that no callback is being executed when event_del() returns,
hence making this function a secure mechanism to access data which is
handled in the event callack.
Fixes: #236Fixes: #225
Refs: 6b4b77a
Fixes: del_wait
If reconnecting the via BEV_CTRL_SET_FD, bufferevent_openssl.c expects
OpenSSL to reuse the configuration state in the SSL object but retain
connection state. This corresponds to the SSL_clear API.
The code currently only calls SSL_set_connect_state or
SSL_set_accept_state. Due to a quirk in OpenSSL, doing this causes the
handshake to implicitly SSL_clear the next time it is entered. However,
this, in the intervening time, leaves the SSL object in an odd state as
the connection state has not been dropped yet. This behavior also does
not appear to be documented by OpenSSL.
Instead, call SSL_clear explicitly:
https://www.openssl.org/docs/manmaster/man3/SSL_clear.html
But this is kind of hot-fix, we definitelly need more sane arc4random
compat layer.
Fixes: #488
Introduced-in: 6541168 ("Detect arch4random_addrandom() existence")
