Azat Khuzhin [Fri, 11 Mar 2016 16:58:05 +0000 (19:58 +0300)]
http: fix EVHTTP_CON_READ_ON_WRITE_ERROR when it doesn't supported by OS
For example win32 doesn't accept such things (maybe via overloaded IO, I'm not
sure), also I looked into curl and seems that the behaviour is the same (IOW
like with EVHTTP_CON_READ_ON_WRITE_ERROR on linux/win32).
Fixes: https://ci.appveyor.com/project/nmathewson/libevent/build/2.1.5.216#L499 (win32) Fixes: 680742e1665b85487f10c0ef3df021e3b8e98634 ("http: read server response
even after server closed the connection")
v2: v0 was just removing that flag, i.e. make it deprecated and set_flags() will return -1
This patch set fixes and covers http client and "Expect: 100-continue"
functionality (plus increase coverage under some related options, to avoid
further regressions).
* http-client-fix-expect-100-continue-v6:
http: fix leaking of response_code_line
http: fix "Expect: 100-continue" client side
test/http: separate coverage for EVHTTP_CON_READ_ON_WRITE_ERROR
test/http: cover "Expect: 100-continue" client-server interaction
test/http: *lingering tests shouldn't have "Expect: 100-continue"
Azat Khuzhin [Fri, 11 Mar 2016 17:40:52 +0000 (20:40 +0300)]
http: fix leaking of response_code_line
Since now evhttp_parse_response_line() can be called twice because after
"HTTP/1.1 100 Continue" we can have "HTTP/1.1 200"
==29162== 9 bytes in 1 blocks are definitely lost in loss record 1 of 1
==29162== at 0x4C29C0F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==29162== by 0x5CBF0A9: strdup (in /lib/x86_64-linux-gnu/libc-2.21.so)
==29162== by 0x4AA3AC: event_mm_strdup_ (event.c:3493)
==29162== by 0x4BD843: evhttp_parse_response_line (http.c:1680)
==29162== by 0x4BE333: evhttp_parse_firstline_ (http.c:2013)
==29162== by 0x4BEA4F: evhttp_read_firstline (http.c:2243)
==29162== by 0x4BC5F8: evhttp_read_cb (http.c:1136)
==29162== by 0x4993F1: bufferevent_run_readcb_ (bufferevent.c:233)
==29162== by 0x49FBC0: bufferevent_trigger_nolock_ (bufferevent-internal.h:392)
==29162== by 0x49FF10: bufferevent_readcb (bufferevent_sock.c:208)
==29162== by 0x4A474A: event_persist_closure (event.c:1580)
==29162== by 0x4A49F5: event_process_active_single_queue (event.c:1639)
Azat Khuzhin [Fri, 11 Mar 2016 10:08:28 +0000 (13:08 +0300)]
http: fix "Expect: 100-continue" client side
Instead of sending data always at the beginning of the request wait until the
server will respond with "HTTP/1.1 100 Continue".
Before this patch server do send "HTTP/1.1 100 Continue" but client always send
post data even without waiting server response.
P.S. this patch also touches some not 100% related tab-align issues.
Azat Khuzhin [Fri, 11 Mar 2016 10:55:41 +0000 (13:55 +0300)]
be_sock: unfreeze buffers on fd changing
Only bufferevent_sock have evbuffer_freeze()/evbuffer_unfreeze() & ctrl ops, so
we don't need to fix other bufferevents (be_pair doesn't have ctrl op).
Found during draining buffers in http layer, and hence 501-not-implemented
error in regress http/.. (with some custom hacking).
Azat Khuzhin [Wed, 9 Mar 2016 21:33:04 +0000 (00:33 +0300)]
cmake: fix adding of compiler flags, and now it will
- add_compiler_flags() must accept array IOW just ARGN will be enoough
- add_compiler_flags() called with variable name instead of it's value
P.S. and fix some alignments issues
P.P.S. more cmake issues expected since now CFLAGS actually works
P.P.P.S. some issues with cmake cache is possible, so just reset it
Azat Khuzhin [Wed, 9 Mar 2016 21:25:09 +0000 (00:25 +0300)]
Replace -Wswitch-enum with -Wswitch, and add it into cmake rules too
According to https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html:
-Wswitch-enum
Warn whenever a switch statement has an index of enumerated type and lacks a
case for one or more of the named codes of that enumeration. case labels
outside the enumeration range also provoke warnings when this option is used.
The only difference between -Wswitch and this option is that this option
gives a warning about an omitted enumeration code even if there is a *default
label*.
Azat Khuzhin [Wed, 9 Mar 2016 15:55:20 +0000 (18:55 +0300)]
Merge branch 'more-graceful-http-v10'/lingering close
In short: now `evhttp_set_max_body_size()` is browser-friendly.
This patch set implements lingering close (something like nginx have), this
will make web-server more graceful for currently existing web browsers, so:
- without EVHTTP_CON_LINGERING_CLOSE/EVHTTP_SERVER_LINGERING_CLOSE
before: it will read min(max_body_size, Content-Length)
- with EVHTTP_CON_LINGERING_CLOSE/EVHTTP_SERVER_LINGERING_CLOSE:
it will read max(max_body_size, Content-Length), and web browsers will show
"413 Request Entity Too Large".
Also it fixes a bug on client-side with non-lingering close web-servers
(EVHTTP_CON_READ_ON_WRITE_ERROR), found during implementing web-server
lingering close.
* more-graceful-http-v10:
test: http/lingering_close: cover EVHTTP_SERVER_LINGERING_CLOSE
test: http/non_lingering_close: cover ~EVHTTP_SERVER_LINGERING_CLOSE
test: http/*: update expected HTTP codes for body exceeds `max_body_size`
http: take EVHTTP_CON_LINGERING_CLOSE into account for "Expect: 100-Continue"
test: http/data_length_constrains: set EVHTTP_CON_READ_ON_WRITE_ERROR
http: lingering close (like nginx have) for entity-too-large
http: read server response even after server closed the connection
test: increase buffer size for http/data_length_constraints to trigger EPIPE
Azat Khuzhin [Mon, 15 Feb 2016 00:26:40 +0000 (03:26 +0300)]
http: take EVHTTP_CON_LINGERING_CLOSE into account for "Expect: 100-Continue"
Also since after this patch code became more generic, we now respond with
HTTP_ENTITYTOOLARGE even without "Expect: 100-Continue", which is correct by
RFC.
Azat Khuzhin [Sun, 14 Feb 2016 21:12:54 +0000 (00:12 +0300)]
http: lingering close (like nginx have) for entity-too-large
By lingering close I mean something what nginx have for this name, by this term
I mean that we need to read all the body even if it's size greater then
`max_body_size`, otherwise browsers on win32 (including chrome) failed read the
http status - entity-too-large (while on linux chrome for instance are good),
and also this includes badly written http clients.
Refs: #321
v2: do this only under EVHTTP_SERVER_LINGERING_CLOSE
Azat Khuzhin [Wed, 10 Feb 2016 11:43:18 +0000 (14:43 +0300)]
http: read server response even after server closed the connection
Otherwise if we will try to write more data than server can accept
(see `evhttp_set_max_body_size()` for libevent server) we will get `EPIPE` and
will not try to read server's response which must contain 400 error for now
(which is not strictly correct though, it must 413).
```
$ strace regress --no-fork http/data_length_constraints
...
connect(10, {sa_family=AF_INET, sin_port=htons(43988), sin_addr=inet_addr("127.0.0.1")}, 16) = -1 EINPROGRESS (Operation now in progress)
...
writev(10, [{"POST / HTTP/1.1\r\nHost: somehost\r"..., 60}, {"aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"..., 16324}], 2) = 16384
epoll_wait(5, [{EPOLLOUT, {u32=10, u64=10}}, {EPOLLIN, {u32=11, u64=11}}], 32, 50000) = 2
writev(10, [{"aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"..., 16384}], 1) = 16384
ioctl(11, FIONREAD, [32768]) = 0
readv(11, [{"POST / HTTP/1.1\r\nHost: somehost\r"..., 4096}], 1) = 4096
epoll_ctl(5, EPOLL_CTL_DEL, 11, 0x7fff09d41e50) = 0
epoll_ctl(5, EPOLL_CTL_ADD, 11, {EPOLLOUT, {u32=11, u64=11}}) = 0
epoll_wait(5, [{EPOLLOUT, {u32=10, u64=10}}, {EPOLLOUT, {u32=11, u64=11}}], 32, 50000) = 2
writev(10, [{"aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"..., 16384}], 1) = 16384
writev(11, [{"HTTP/1.1 400 Bad Request\r\nConten"..., 129}, {"<HTML><HEAD>\n<TITLE>400 Bad Requ"..., 94}], 2) = 223
epoll_ctl(5, EPOLL_CTL_DEL, 11, 0x7fff09d42080) = 0
shutdown(11, SHUT_WR) = 0
close(11) = 0
epoll_wait(5, [{EPOLLOUT|EPOLLERR|EPOLLHUP, {u32=10, u64=10}}], 32, 50000) = 1
writev(10, [{"aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"..., 16384}], 1) = -1 EPIPE (Broken pipe)
--- SIGPIPE {si_signo=SIGPIPE, si_code=SI_USER, si_pid=13954, si_uid=1000} ---
epoll_ctl(5, EPOLL_CTL_DEL, 10, 0x7fff09d42010) = 0
shutdown(10, SHUT_WR) = -1 ENOTCONN (Transport endpoint is not connected)
close(10) = 0
write(1, "\n FAIL ../test/regress_http.c:3"..., 37
```
Careful reader can ask why it send error even when it didn't read
`evcon->max_body_size`, and the answer will be checks for `evcon->max_body_size
against `Content-Length` header, which contains ~8MB (-2 bytes).
And also if we will not drain the output buffer than we will send buffer that
we didn't send in previous request and instead of sending method via
`evhttp_make_header()`.
Fixes: http/data_length_constraints
Refs: #321
v2: do this only under EVHTTP_CON_READ_ON_WRITE_ERROR flag
Azat Khuzhin [Sun, 14 Feb 2016 23:59:40 +0000 (02:59 +0300)]
http: fix conflicts EVHTTP_CON_AUTOFREE and EVHTTP_CON_REUSE_CONNECTED_ADDR
And we can't make them continuous, since the latest is a public API, and
otherwise we will break binary compatibility.
Also extra check for EVHTTP_CON_PUBLIC_FLAGS_END, in case somebody forgot about
this (implementer I mean).
Azat Khuzhin [Mon, 1 Feb 2016 14:32:09 +0000 (17:32 +0300)]
evdns: name_parse(): fix remote stack overread
@asn-the-goblin-slayer:
"the name_parse() function in libevent's DNS code is vulnerable to a buffer overread.
971 if (cp != name_out) {
972 if (cp + 1 >= end) return -1;
973 *cp++ = '.';
974 }
975 if (cp + label_len >= end) return -1;
976 memcpy(cp, packet + j, label_len);
977 cp += label_len;
978 j += label_len;
No check is made against length before the memcpy occurs.
This was found through the Tor bug bounty program and the discovery should be credited to 'Guido Vranken'."
Reproducer for gdb (https://gist.github.com/azat/e4fcf540e9b89ab86d02):
set $PROT_NONE=0x0
set $PROT_READ=0x1
set $PROT_WRITE=0x2
set $MAP_ANONYMOUS=0x20
set $MAP_SHARED=0x01
set $MAP_FIXED=0x10
set $MAP_32BIT=0x40
start
set $length=202
# overread
set $length=2
# allocate with mmap to have a seg fault on page boundary
set $l=(1<<20)*2
p mmap(0, $l, $PROT_READ|$PROT_WRITE, $MAP_ANONYMOUS|$MAP_SHARED|$MAP_32BIT, -1, 0)
set $packet=(char *)$1+$l-$length
# hack the packet
set $packet[0]=63
set $packet[1]='/'
p malloc(sizeof(int))
set $idx=(int *)$2
set $idx[0]=0
set $name_out_len=202
p malloc($name_out_len)
set $name_out=$3
# have WRITE only mapping to fail on read
set $end=$1+$l
p (void *)mmap($end, 1<<12, $PROT_NONE, $MAP_ANONYMOUS|$MAP_SHARED|$MAP_FIXED|$MAP_32BIT, -1, 0)
set $m=$4
p name_parse($packet, $length, $idx, $name_out, $name_out_len)
x/2s (char *)$name_out
Azat Khuzhin [Sat, 30 Jan 2016 21:57:16 +0000 (00:57 +0300)]
evutil_parse_sockaddr_port(): fix buffer overflow
@asn-the-goblin-slayer:
"Length between '[' and ']' is cast to signed 32 bit integer on line 1815. Is
the length is more than 2<<31 (INT_MAX), len will hold a negative value.
Consequently, it will pass the check at line 1816. Segfault happens at line
1819.
Generate a resolv.conf with generate-resolv.conf, then compile and run
poc.c. See entry-functions.txt for functions in tor that might be
vulnerable.
Please credit 'Guido Vranken' for this discovery through the Tor bug bounty
program."
Reproducer for gdb (https://gist.github.com/azat/be2b0d5e9417ba0dfe2c):
start
p (1ULL<<31)+1ULL
# $1 = 2147483649
p malloc(sizeof(struct sockaddr))
# $2 = (void *) 0x646010
p malloc(sizeof(int))
# $3 = (void *) 0x646030
p malloc($1)
# $4 = (void *) 0x7fff76a2a010
p memset($4, 1, $1)
# $5 = 1990369296
p (char *)$4
# $6 = 0x7fff76a2a010 '\001' <repeats 200 times>...
set $6[0]='['
set $6[$1]=']'
p evutil_parse_sockaddr_port($4, $2, $3)
# $7 = -1
Azat Khuzhin [Thu, 7 Jan 2016 14:51:40 +0000 (17:51 +0300)]
cmake: Fix detection of ssize_t/SSIZE_T
Since ssize_it is POSIX, windows/VS also have this but with BaseTsd.h, plus the
logic prefers "ssize_t" (lower) instead of "SSIZE_T" (upper) when the latest
only available -- fix this too.
Azat Khuzhin [Sat, 2 Jan 2016 21:23:22 +0000 (00:23 +0300)]
test/regress: cover event_del() waiting mechanism
Since we have some issues (see refs) for changing waiting order in event_del()
I wrote this simple test, so maybe this test can explain something or at least
cover what we have before and show it will be broken.
P.S. we really need avoid such stuff like lets-test-with-sleep/usleep.
Azat Khuzhin [Sun, 27 Dec 2015 13:49:42 +0000 (16:49 +0300)]
Merge branch 'event_reinit-for-signals-v3'
* event_reinit-for-signals-v3:
test/regress: cover existing signal callbacks and fork() + event_reinit()
test/regress: cover signals after fork() + event_reinit()
test/regress: main/fork: rewrite assertions by just removing event in callback
event_reinit: make signals works after fork() without evsig_add()
event_reinit: always re-init signal's socketpair
Azat Khuzhin [Sat, 26 Dec 2015 23:31:03 +0000 (02:31 +0300)]
test/regress: main/fork: rewrite assertions by just removing event in callback
Instead of assigning some variable value (got_child), and schedule exit from
loop from that callback, just remove event for that signal, and event loop will
exit automatically when there will be no events.
event_reinit: make signals works after fork() without evsig_add()
event_reinit() removes the event, but only evsig_add puts it back. So any
signals set up before event_reinit will be ignored until another signal is
added.
Before this patch event_reinit() only closes the signal socketpair fds and
recreates them if signals have been added, but this is wrong, since socketpair
fds created on backend init, and if we will not re-create them bad things in
child/parent signal handling will happens (and indeed this is what happens for
non-reinit backends like select).
billsegall [Thu, 17 Dec 2015 11:27:37 +0000 (21:27 +1000)]
Provide a mechanism for building the library on Windows with different compiler flags. Add a batch file that builds it for the M[DT][d] options and performs a hunt and gather of the different output libraries.
billsegall [Wed, 16 Dec 2015 01:17:36 +0000 (11:17 +1000)]
The Windows socket type is defined as SOCKET.
Under the hood it's an unsigned rather than a signed type and whilst C
compilers are largely happy with this C++ compilers tend to be fussy
about class function signatures which makes C++ usage of libevent
problematic.
Azat Khuzhin [Mon, 23 Nov 2015 10:52:31 +0000 (13:52 +0300)]
be_sock: bufferevent_socket_connect_hostname(): make it thread-safe
If you use bufferevent_socket_connect_hostname() to resolve, then ipv4 answer
can be returned before ipv6 scheduled and if you will destroy bufferevent after
ipv4 answer will come (in a separate thread of course) then ipv6 will trigger
UAF:
$ a.out
=================================================================
==29733==ERROR: AddressSanitizer: heap-use-after-free on address 0x60200000ef50 at pc 0x0000004b7aef bp 0x7fffffffd940 sp 0x7fffffffd0f8
READ of size 2 at 0x60200000ef50 thread T0
#0 0x4b7aee in __interceptor_index (/src/oss/libevent/libevent-github/.invest/217-evhttp-threaded/a.out+0x4b7aee)
#1 0x5060eb in string_num_dots /src/oss/libevent/libevent-github/.cmake-debug/../evdns.c:2739
#2 0x5078df in search_request_new /src/oss/libevent/libevent-github/.cmake-debug/../evdns.c:3214
#3 0x506afd in evdns_base_resolve_ipv6 /src/oss/libevent/libevent-github/.cmake-debug/../evdns.c:2935
#4 0x50aa94 in evdns_getaddrinfo /src/oss/libevent/libevent-github/.cmake-debug/../evdns.c:4719
#5 0x51de4f in evutil_getaddrinfo_async_ /src/oss/libevent/libevent-github/.cmake-debug/../evutil.c:1567
#6 0x4fe023 in bufferevent_socket_connect_hostname /src/oss/libevent/libevent-github/.cmake-debug/../bufferevent_sock.c:519
#7 0x524f54 in evhttp_connection_connect_ /src/oss/libevent/libevent-github/.cmake-debug/../http.c:2493
#8 0x525156 in evhttp_make_request /src/oss/libevent/libevent-github/.cmake-debug/../http.c:2548
#9 0x52d373 in main (/src/oss/libevent/libevent-github/.invest/217-evhttp-threaded/a.out+0x52d373)
#10 0x7ffff6849b44 in __libc_start_main /tmp/buildd/glibc-2.19/csu/libc-start.c:287
#11 0x445806 in _start (/src/oss/libevent/libevent-github/.invest/217-evhttp-threaded/a.out+0x445806)
0x60200000ef50 is located 0 bytes inside of 15-byte region [0x60200000ef50,0x60200000ef5f)
freed by thread T1 here:
#0 0x4cc4f2 in __interceptor_free (/src/oss/libevent/libevent-github/.invest/217-evhttp-threaded/a.out+0x4cc4f2)
#1 0x5141c1 in event_mm_free_ /src/oss/libevent/libevent-github/.cmake-debug/../event.c:3512
#2 0x522402 in evhttp_connection_free /src/oss/libevent/libevent-github/.cmake-debug/../http.c:1206
#3 0x52cc5f in connection_closer (/src/oss/libevent/libevent-github/.invest/217-evhttp-threaded/a.out+0x52cc5f)
#4 0x50e80e in event_process_active_single_queue /src/oss/libevent/libevent-github/.cmake-debug/../event.c:1642
#5 0x50ed57 in event_process_active /src/oss/libevent/libevent-github/.cmake-debug/../event.c:1734
#6 0x50f458 in event_base_loop /src/oss/libevent/libevent-github/.cmake-debug/../event.c:1957
#7 0x50eddf in event_base_dispatch /src/oss/libevent/libevent-github/.cmake-debug/../event.c:1768
#8 0x52d075 in event_dispatch_thread (/src/oss/libevent/libevent-github/.invest/217-evhttp-threaded/a.out+0x52d075)
#9 0x7ffff74fc0a3 in start_thread /tmp/buildd/glibc-2.19/nptl/pthread_create.c:309
Azat Khuzhin [Wed, 25 Nov 2015 14:47:42 +0000 (17:47 +0300)]
autotools: fix getservbyname() detection
The mentioned commit adds this check under-the-else of the previous condition
between getaddrinfo()/gethostbyname_r(), so this check is triggered only when
we don't have getaddrinfo() which is wrong, fix this by move it upper.
Fixes [CI] since it uses getservbyname() and it failed with autotools only
(cmake detection is ok).
CI: https://travis-ci.org/libevent/libevent/builds/93125954 Fixes: af08a94085e49e6942835b4c6b50a774536d5b5b ("Check for getservbyname even
if not on win32.")
Azat Khuzhin [Wed, 25 Nov 2015 10:09:15 +0000 (13:09 +0300)]
Merge branch 'evdns-fail-requests-v6'
This patchset fixes some issues wit evdns_base_free(..., fail_requests=1), and
there are two cases: with callback wrapper for evdns_getaddrinfo() and not,
both fixed by this patches, and adds regression tests for this.
* evdns-fail-requests-v6:
evdns: evdns_base_free(): fix UAF of evdns_base with @fail_requests
test/dns: cover evdns_getaddrinfo() and evdns_base_free() with @fail_requests
evdns: evdns_base_free(): free requests before namservers
test/dns: cover @fail_requests for evdns_base_free()
test/dns: more graceful coverage of @fail_requests
Azat Khuzhin [Mon, 23 Nov 2015 12:05:19 +0000 (15:05 +0300)]
evdns: evdns_base_free(): fix UAF of evdns_base with @fail_requests
If you call evdns_base_free() with @fail_requests == 1, then it will defer
callback with DNS_ERR_SHUTDOWN, but that callback (internal) uses
data->evdns_base, but we already freed that evdns base, so we can't do
this, fix this by checking @result to DNS_ERR_SHUTDOWN.
Azat Khuzhin [Mon, 23 Nov 2015 12:36:30 +0000 (15:36 +0300)]
evdns: evdns_base_free(): free requests before namservers
Otherwise we will trigger next UAF:
$ valgrind --vgdb-error=1 regress --no-fork +dns/client_fail_requests
==24733== Memcheck, a memory error detector
==24733== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==24733== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==24733== Command: regress --no-fork +dns/client_fail_requests
==24733==
==24733==
==24733== TO DEBUG THIS PROCESS USING GDB: start GDB like this
==24733== /path/to/gdb regress
==24733== and then give GDB the following command
==24733== target remote | /usr/lib/valgrind/../../bin/vgdb --pid=24733
==24733== --pid is optional if only one valgrind process is running
==24733==
dns/client_fail_requests: ==24733== Invalid read of size 4
==24733== at 0x4C3352: request_finished (evdns.c:662)
==24733== by 0x4CC8B7: evdns_base_free_and_unlock (evdns.c:4048)
==24733== by 0x4CCAFD: evdns_base_free (evdns.c:4088)
==24733== by 0x458E95: dns_client_fail_requests_test (regress_dns.c:2039)
==24733== by 0x48EA5D: testcase_run_bare_ (tinytest.c:105)
==24733== by 0x48ED3F: testcase_run_one (tinytest.c:252)
==24733== by 0x48F67E: tinytest_main (tinytest.c:434)
==24733== by 0x47C0DA: main (regress_main.c:461)
==24733== Address 0x61e6f70 is 448 bytes inside a block of size 456 free'd
==24733== at 0x4C29EAB: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==24733== by 0x4A8F4D: event_mm_free_ (event.c:3512)
==24733== by 0x4CC7A1: evdns_nameserver_free (evdns.c:4021)
==24733== by 0x4CC7DC: evdns_base_free_and_unlock (evdns.c:4037)
==24733== by 0x4CCAFD: evdns_base_free (evdns.c:4088)
==24733== by 0x458E95: dns_client_fail_requests_test (regress_dns.c:2039)
==24733== by 0x48EA5D: testcase_run_bare_ (tinytest.c:105)
==24733== by 0x48ED3F: testcase_run_one (tinytest.c:252)
==24733== by 0x48F67E: tinytest_main (tinytest.c:434)
==24733== by 0x47C0DA: main (regress_main.c:461)
==24733== Block was alloc'd at
==24733== at 0x4C28C4F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==24733== by 0x4A8D5A: event_mm_malloc_ (event.c:3437)
==24733== by 0x4C8B96: evdns_nameserver_add_impl_ (evdns.c:2505)
==24733== by 0x4C916D: evdns_base_nameserver_ip_add (evdns.c:2629)
==24733== by 0x458DA3: dns_client_fail_requests_test (regress_dns.c:2031)
==24733== by 0x48EA5D: testcase_run_bare_ (tinytest.c:105)
==24733== by 0x48ED3F: testcase_run_one (tinytest.c:252)
==24733== by 0x48F67E: tinytest_main (tinytest.c:434)
==24733== by 0x47C0DA: main (regress_main.c:461)
==24733==
==24733== (action on error) vgdb me ...
Azat Khuzhin [Mon, 23 Nov 2015 12:14:32 +0000 (15:14 +0300)]
test/dns: more graceful coverage of @fail_requests
In case when evdns_base_free() called with @fail_requests, we can potentially
have leaks, but we can avoid them if we will run event loop once again to
trigger defer cbs, so let's do this, instead of magical decrements (and also
this will give an example how to avoid leaks for evdns).
This covers SSL_ERROR_WANT_READ/SSL_ERROR_WANT_WRITE error codes from ssl,
under which we must block read/write to avoid busy looping, and hence extra CPU
usage.
This test introduces custom BIO that will count read/write and validates
counters, with patches for be_openssl that drops handling
SSL/SSL_ERROR_WANT_READ there are more then 43K reads, so 100 is pretty ok.
Azat Khuzhin [Fri, 13 Nov 2015 13:00:39 +0000 (16:00 +0300)]
be_openssl: don't call do_write() directly from outbuf_cb
Otherwise we can trigger incorrect callback, the simplest way to trigger this
is using http regression tests -- https_chunk_out, since all it do is:
evhttp_send_reply_end()
evbuffer_add()
do_write()
evhttp_write_buffer()
evcon->cb = cb
And indeed this is what happens:
(gdb) bt
#0 do_write (bev_ssl=0x738a90, atmost=16384) at bufferevent_openssl.c:717
#1 0x00000000004b69f7 in consider_writing (bev_ssl=0x738a90) at bufferevent_openssl.c:875
#2 0x00000000004b7386 in be_openssl_outbuf_cb (buf=0x7387b0, cbinfo=0x7fffffffd590, arg=0x738a90) at bufferevent_openssl.c:1147
#3 0x0000000000490100 in evbuffer_run_callbacks (buffer=0x7387b0, running_deferred=0) at buffer.c:508
#4 0x00000000004901e5 in evbuffer_invoke_callbacks_ (buffer=0x7387b0) at buffer.c:529
#5 0x0000000000493a30 in evbuffer_add (buf=0x7387b0, data_in=0x4ecfb2, datlen=5) at buffer.c:1803
#6 0x00000000004be2e3 in evhttp_send_reply_end (req=0x7371a0) at http.c:2794
#7 0x000000000045c407 in http_chunked_trickle_cb (fd=-1, events=1, arg=0x75aaf0) at regress_http.c:402
...
(gdb) p bev.writecb
$4 = (bufferevent_data_cb) 0x4ba17e <evhttp_write_cb>
$5 = (void *) 0x7379b0
(gdb) p (struct evhttp_connection *)bev.cbarg
$6 = (struct evhttp_connection *) 0x7379b0
(gdb) p $6->cb
$7 = (void (*)(struct evhttp_connection *, void *)) 0x0
Azat Khuzhin [Tue, 10 Nov 2015 17:26:50 +0000 (20:26 +0300)]
Add missing <string.h> for openssl_hostname_validation module
Now it included by openssl, but nfter
openssl/openssl@master-post-reformat-1494-g6329b60 it will print warning
(apparently they dropped <string.h> from the generic headers).
Azat Khuzhin [Thu, 5 Nov 2015 14:56:07 +0000 (17:56 +0300)]
be_openssl: use bufferevent_enable() instead of bufferevent_add_event_()
By using bufferevent_enable() there will be no event for READ *or* WRITE if
they are not enabled before, and this patch reduces difference for
be_sock_enable/be_openssl_enable (handshake)
Azat Khuzhin [Thu, 5 Nov 2015 14:40:25 +0000 (17:40 +0300)]
be_openssl: don't add events during bev creation (like be_sock)
Using the following examples you can get changes between be_openssl and
be_sock:
$ function diff_addr()
{
eval diff -u $(printf "<(strip_addr %s) " "$@")
}
$ function strip_addr()
{
sed 's/0x[a-zA-Z0-9]*/0xFFFF/g' "$@"
}
$ EVENT_DEBUG_LOGGING_ALL= regress --verbose --no-fork +http/https_connection_retry 2> /tmp/https-retry.log >&2
$ EVENT_DEBUG_LOGGING_ALL= regress --verbose --no-fork +http/connection_retry 2> /tmp/http-retry.log >&2
$ diff_addr /tmp/http-retry.log /tmp/https-retry.log
Azat Khuzhin [Fri, 6 Nov 2015 06:45:55 +0000 (09:45 +0300)]
Merge branch 'https-coverage-v6'
This patchset adds some basic tests to cover some https cases:
$ regress +http/https_..
http/https_basic: [forking] OK
http/https_simple: [forking] OK
http/https_simple_dirty: [forking] OK
http/https_incomplete: [forking] OK
http/https_incomplete_timeout: [forking] OK
http/https_connection_retry: [forking] OK
http/https_connection_retry_conn_address: [forking] OK
7 tests ok. (0 skipped)
But there are some leaks in http regression tests (like init_ssl() and others),
must be fixed by using custom setup routine.
* https-coverage-v6:
test/http: allow dirty shutdown for ssl to fix https_incomplete
test/http: https basic
test/http: incomplete{,_timeout} for https
test/http: add simplest test for http/https/https_dirty_shutdown
test/http: https: retry coverage
test/http: https server support (plus some helpers)
test/http: more sanity checks
test/ssl: export getkey()/getcert()/get_ssl_ctx()/init_ssl() for https