]> granicus.if.org Git - libevent/log
libevent
8 years agoevhttp_have_expect(): fix -Wlogical-not-parentheses
Azat Khuzhin [Fri, 25 Mar 2016 07:21:48 +0000 (10:21 +0300)]
evhttp_have_expect(): fix -Wlogical-not-parentheses

../http.c:589:6: warning: logical not is only applied to the left hand side of this comparison [-Wlogical-not-parentheses]
        if (!req->kind == EVHTTP_REQUEST || !REQ_VERSION_ATLEAST(req, 1, 1))
                        ^          ~~

8 years agoevdns: fix searching empty hostnames
Azat Khuzhin [Thu, 24 Mar 2016 21:33:47 +0000 (00:33 +0300)]
evdns: fix searching empty hostnames

From #332:
  Here follows a bug report by **Guido Vranken** via the _Tor bug bounty program_. Please credit Guido accordingly.

  ## Bug report

  The DNS code of Libevent contains this rather obvious OOB read:

  ```c
  static char *
  search_make_new(const struct search_state *const state, int n, const char *const base_name) {
      const size_t base_len = strlen(base_name);
      const char need_to_append_dot = base_name[base_len - 1] == '.' ? 0 : 1;
  ```

  If the length of ```base_name``` is 0, then line 3125 reads 1 byte before the buffer. This will trigger a crash on ASAN-protected builds.

  To reproduce:

  Build libevent with ASAN:
  ```
  $ CFLAGS='-fomit-frame-pointer -fsanitize=address' ./configure && make -j4
  ```
  Put the attached ```resolv.conf``` and ```poc.c``` in the source directory and then do:

  ```
  $ gcc -fsanitize=address -fomit-frame-pointer poc.c .libs/libevent.a
  $ ./a.out
  =================================================================
  ==22201== ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60060000efdf at pc 0x4429da bp 0x7ffe1ed47300 sp 0x7ffe1ed472f8
  READ of size 1 at 0x60060000efdf thread T0
  ```

P.S. we can add a check earlier, but since this is very uncommon, I didn't add it.

Fixes: #332
8 years agotest/dns: regression for empty hostname
Azat Khuzhin [Thu, 24 Mar 2016 21:21:06 +0000 (00:21 +0300)]
test/dns: regression for empty hostname

Refs: #332

8 years agotest/http: fix SERVER_TIMEOUT tests under win32
Azat Khuzhin [Thu, 24 Mar 2016 17:29:25 +0000 (20:29 +0300)]
test/http: fix SERVER_TIMEOUT tests under win32

Seems that the hack with filling BACKLOG didn't work on win32, and hence we
stuck in write() waiting, not in connect()

And:
$ time regress http/cancel_server_timeout
- on linux: 10secs
- on win32: 2-5secs

I tried to debug this but you can't sniff TCP packages (wireshark/rawpcap) on
localhost in windows xp (according to [RAWPCAP] and my testing).

RAWPCAP: http://www.netresec.com/?page=RawCap

8 years agotest/http: add a helper for creating timedout/failed request
Azat Khuzhin [Thu, 24 Mar 2016 17:26:50 +0000 (20:26 +0300)]
test/http: add a helper for creating timedout/failed request

8 years agotest/http: adopt for C90 (mixed code and declarations)
Azat Khuzhin [Thu, 24 Mar 2016 11:11:10 +0000 (14:11 +0300)]
test/http: adopt for C90 (mixed code and declarations)

8 years agoevdns: avoid double-free in evdns_base_free() for probing requests
Azat Khuzhin [Thu, 24 Mar 2016 09:49:47 +0000 (12:49 +0300)]
evdns: avoid double-free in evdns_base_free() for probing requests

http/cancel_by_host_no_ns:
    OK ../test/regress_http.c:1384: assert(regress_dnsserver(data->base, &portnum, search_table))
    OK ../test/regress_http.c:1387: assert(dns_base)
    OK ../test/regress_http.c:1423: assert(evcon)
         OK ../test/regress_http.c:1444: assert(evhttp_make_request(evcon, req, EVHTTP_REQ_GET, "/delay") != -1): 0 vs -1
         OK ../test/regress_http.c:1455: assert(test_ok == 2): 2 vs 2
         OK ../test/regress_http.c:1480: assert(evhttp_make_request(evcon, req, EVHTTP_REQ_GET, "/test") != -1): 0 vs -1[msg] Nameserver 127.0.0.1:55948 has failed: request timed out.
[msg] All nameservers have failed

    OK ../test/regress_http.c:1274: assert(!req)
         OK ../test/regress_http.c:1505: assert(evhttp_make_request(evcon, req, EVHTTP_REQ_GET, "/test") != -1): 0 vs -1
    OK ../test/regress_http.c:1274: assert(!req)==19199== Invalid read of size 8
==19199==    at 0x4CC285: evdns_cancel_request (evdns.c:2849)
==19199==    by 0x4CEDB2: evdns_nameserver_free (evdns.c:4018)
==19199==    by 0x4CEF5B: evdns_base_free_and_unlock (evdns.c:4052)
==19199==    by 0x4CF13B: evdns_base_free (evdns.c:4088)
==19199==    by 0x4617A3: http_cancel_test (regress_http.c:1518)
==19199==    by 0x490A78: testcase_run_bare_ (tinytest.c:105)
==19199==    by 0x490D5A: testcase_run_one (tinytest.c:252)
==19199==    by 0x491699: tinytest_main (tinytest.c:434)
==19199==    by 0x47E0E0: main (regress_main.c:461)
==19199==  Address 0x61e56d0 is 0 bytes inside a block of size 48 free'd
==19199==    at 0x4C2AE6B: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==19199==    by 0x4AAFFF: event_mm_free_ (event.c:3516)
==19199==    by 0x4C5ADD: request_finished (evdns.c:693)
==19199==    by 0x4CEE95: evdns_base_free_and_unlock (evdns.c:4040)
==19199==    by 0x4CF13B: evdns_base_free (evdns.c:4088)
==19199==    by 0x4617A3: http_cancel_test (regress_http.c:1518)
==19199==    by 0x490A78: testcase_run_bare_ (tinytest.c:105)
==19199==    by 0x490D5A: testcase_run_one (tinytest.c:252)
==19199==    by 0x491699: tinytest_main (tinytest.c:434)
==19199==    by 0x47E0E0: main (regress_main.c:461)
==19199==  Block was alloc'd at
==19199==    at 0x4C2BBD5: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==19199==    by 0x4AAEB2: event_mm_calloc_ (event.c:3459)
==19199==    by 0x4CAAA2: nameserver_send_probe (evdns.c:2327)
==19199==    by 0x4C50FF: nameserver_prod_callback (evdns.c:494)
==19199==    by 0x4A564C: event_process_active_single_queue (event.c:1646)
==19199==    by 0x4A5B95: event_process_active (event.c:1738)
==19199==    by 0x4A6296: event_base_loop (event.c:1961)
==19199==    by 0x4A5C1D: event_base_dispatch (event.c:1772)
==19199==    by 0x46172C: http_cancel_test (regress_http.c:1507)
==19199==    by 0x490A78: testcase_run_bare_ (tinytest.c:105)
==19199==    by 0x490D5A: testcase_run_one (tinytest.c:252)
==19199==    by 0x491699: tinytest_main (tinytest.c:434)
==19199==

8 years agoMerge branch 'bufev-cancellations-v5'
Azat Khuzhin [Thu, 24 Mar 2016 11:05:28 +0000 (14:05 +0300)]
Merge branch 'bufev-cancellations-v5'

This patch set fixes bufferevent via http request cancellations (connect() and
dns-request), it survives tests and cancel.. with --no-fork, so this must be ok
(though I have one patch for dns layer pending).
But I'm not sure about cancel.. unit tests on win32, will fix disable them
later if they will differs (plus maybe we must make them skip-by-default?).

Fixes: #333
* bufev-cancellations-v5:
  http: set fd to -1 unconditioally, to avoid leaking of DNS requests
  test/http: cover NS timed out during request cancellations separatelly
  http: avoid leaking of fd in evhttp_connection_free()
  http: get fd from be layer during connection reset
  be_sock: cancel in-progress dns requests
  evdns: export cancel via callbacks in util (like async lib core/extra issues)
  test/http: request cancellation with resolving/{conn,write}-timeouts in progress

8 years agohttp: set fd to -1 unconditioally, to avoid leaking of DNS requests
Azat Khuzhin [Thu, 24 Mar 2016 10:38:05 +0000 (13:38 +0300)]
http: set fd to -1 unconditioally, to avoid leaking of DNS requests

Otherwise:
http/cancel_by_host_ns_timeout_inactive_server: [msg] Nameserver 127.0.0.1:37035 has failed: request timed out.
[msg] All nameservers have failed
OK
1 tests ok.  (0 skipped)
==26211==
==26211== FILE DESCRIPTORS: 3 open at exit.
==26211== Open file descriptor 2: /dev/pts/47
==26211==    <inherited from parent>
==26211==
==26211== Open file descriptor 1: /dev/pts/47
==26211==    <inherited from parent>
==26211==
==26211== Open file descriptor 0: /dev/pts/47
==26211==    <inherited from parent>
==26211==
==26211==
==26211== HEAP SUMMARY:
==26211==     in use at exit: 1,112 bytes in 5 blocks
==26211==   total heap usage: 149 allocs, 144 frees, 18,826 bytes allocated
==26211==
==26211== 40 bytes in 1 blocks are indirectly lost in loss record 1 of 5
==26211==    at 0x4C2BBD5: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==26211==    by 0x4AAEB2: event_mm_calloc_ (event.c:3459)
==26211==    by 0x498F5B: evbuffer_add_cb (buffer.c:3309)
==26211==    by 0x4A0EF5: bufferevent_socket_new (bufferevent_sock.c:366)
==26211==    by 0x4BFADF: evhttp_connection_base_bufferevent_new (http.c:2375)
==26211==    by 0x4BFC8F: evhttp_connection_base_new (http.c:2427)
==26211==    by 0x460DAA: http_cancel_test (regress_http.c:1417)
==26211==    by 0x490A78: testcase_run_bare_ (tinytest.c:105)
==26211==    by 0x490D5A: testcase_run_one (tinytest.c:252)
==26211==    by 0x491699: tinytest_main (tinytest.c:434)
==26211==    by 0x47E0E0: main (regress_main.c:461)
==26211==
==26211== 136 bytes in 1 blocks are indirectly lost in loss record 2 of 5
==26211==    at 0x4C2BBD5: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==26211==    by 0x4AAEB2: event_mm_calloc_ (event.c:3459)
==26211==    by 0x491FF0: evbuffer_new (buffer.c:365)
==26211==    by 0x49A1BE: bufferevent_init_common_ (bufferevent.c:300)
==26211==    by 0x4A0E44: bufferevent_socket_new (bufferevent_sock.c:353)
==26211==    by 0x4BFADF: evhttp_connection_base_bufferevent_new (http.c:2375)
==26211==    by 0x4BFC8F: evhttp_connection_base_new (http.c:2427)
==26211==    by 0x460DAA: http_cancel_test (regress_http.c:1417)
==26211==    by 0x490A78: testcase_run_bare_ (tinytest.c:105)
==26211==    by 0x490D5A: testcase_run_one (tinytest.c:252)
==26211==    by 0x491699: tinytest_main (tinytest.c:434)
==26211==    by 0x47E0E0: main (regress_main.c:461)
==26211==
==26211== 136 bytes in 1 blocks are indirectly lost in loss record 3 of 5
==26211==    at 0x4C2BBD5: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==26211==    by 0x4AAEB2: event_mm_calloc_ (event.c:3459)
==26211==    by 0x491FF0: evbuffer_new (buffer.c:365)
==26211==    by 0x49A1FB: bufferevent_init_common_ (bufferevent.c:305)
==26211==    by 0x4A0E44: bufferevent_socket_new (bufferevent_sock.c:353)
==26211==    by 0x4BFADF: evhttp_connection_base_bufferevent_new (http.c:2375)
==26211==    by 0x4BFC8F: evhttp_connection_base_new (http.c:2427)
==26211==    by 0x460DAA: http_cancel_test (regress_http.c:1417)
==26211==    by 0x490A78: testcase_run_bare_ (tinytest.c:105)
==26211==    by 0x490D5A: testcase_run_one (tinytest.c:252)
==26211==    by 0x491699: tinytest_main (tinytest.c:434)
==26211==    by 0x47E0E0: main (regress_main.c:461)
==26211==
==26211== 536 bytes in 1 blocks are indirectly lost in loss record 4 of 5
==26211==    at 0x4C2BBD5: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==26211==    by 0x4AAEB2: event_mm_calloc_ (event.c:3459)
==26211==    by 0x4A0E15: bufferevent_socket_new (bufferevent_sock.c:350)
==26211==    by 0x4BFADF: evhttp_connection_base_bufferevent_new (http.c:2375)
==26211==    by 0x4BFC8F: evhttp_connection_base_new (http.c:2427)
==26211==    by 0x460DAA: http_cancel_test (regress_http.c:1417)
==26211==    by 0x490A78: testcase_run_bare_ (tinytest.c:105)
==26211==    by 0x490D5A: testcase_run_one (tinytest.c:252)
==26211==    by 0x491699: tinytest_main (tinytest.c:434)
==26211==    by 0x47E0E0: main (regress_main.c:461)
==26211==
==26211== 1,112 (264 direct, 848 indirect) bytes in 1 blocks are definitely lost in loss record 5 of 5
==26211==    at 0x4C2BBD5: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==26211==    by 0x4AAEB2: event_mm_calloc_ (event.c:3459)
==26211==    by 0x4D0564: evdns_getaddrinfo (evdns.c:4685)
==26211==    by 0x4B13BA: evutil_getaddrinfo_async_ (evutil.c:1575)
==26211==    by 0x4A139E: bufferevent_socket_connect_hostname (bufferevent_sock.c:524)
==26211==    by 0x4C02DB: evhttp_connection_connect_ (http.c:2588)
==26211==    by 0x4C04DD: evhttp_make_request (http.c:2643)
==26211==    by 0x4615FF: http_cancel_test (regress_http.c:1504)
==26211==    by 0x490A78: testcase_run_bare_ (tinytest.c:105)
==26211==    by 0x490D5A: testcase_run_one (tinytest.c:252)
==26211==    by 0x491699: tinytest_main (tinytest.c:434)
==26211==    by 0x47E0E0: main (regress_main.c:461)
==26211==
==26211== LEAK SUMMARY:
==26211==    definitely lost: 264 bytes in 1 blocks
==26211==    indirectly lost: 848 bytes in 4 blocks
==26211==      possibly lost: 0 bytes in 0 blocks
==26211==    still reachable: 0 bytes in 0 blocks
==26211==         suppressed: 0 bytes in 0 blocks

8 years agotest/http: cover NS timed out during request cancellations separatelly
Azat Khuzhin [Thu, 24 Mar 2016 07:27:24 +0000 (10:27 +0300)]
test/http: cover NS timed out during request cancellations separatelly

8 years agohttp: avoid leaking of fd in evhttp_connection_free()
Azat Khuzhin [Tue, 22 Mar 2016 20:36:19 +0000 (23:36 +0300)]
http: avoid leaking of fd in evhttp_connection_free()

Since we do close fd there if we don't have BEV_OPT_CLOSE_ON_FREE, and
evcon->fd can be incorrect (non -1), so just get it from the underlying
bufferevent to fix this.

And after this patch the following tests report 0 instead of 2307 fd leaks:
$ valgrind --leak-check=full --show-reachable=yes --track-fds=yes --error-exitcode=1 regress --no-fork http/cancel..
==11299== FILE DESCRIPTORS: 3 open at exit.

And this is stdin/stderr/stdout.

8 years agohttp: get fd from be layer during connection reset
Azat Khuzhin [Tue, 22 Mar 2016 16:29:50 +0000 (19:29 +0300)]
http: get fd from be layer during connection reset

Since it can be non -1, and we must close it, otherwise we will have problems.

And after this patch the following tests report fd 2307 instead of 2309 fd leaks:
$ valgrind --leak-check=full --show-reachable=yes --track-fds=yes --error-exitcode=1 regress --no-fork http/cancel..
==10853== FILE DESCRIPTORS: 2307 open at exit.

8 years agobe_sock: cancel in-progress dns requests
Azat Khuzhin [Mon, 21 Mar 2016 14:09:17 +0000 (17:09 +0300)]
be_sock: cancel in-progress dns requests

Before this patch we didn't have such functionality and this can cause some
issues when we are cancelling HTTP request while after this we will get a
response/timeout from the NS and in this case error_cb will be called and can
damage newly started HTTP request.
We could also have problems with connect, but we don't have them since we
closes the fd in HTTP layer.

This is not so good that this is done in be_sock, but it is internal, so we can
change without pain. Plus I don't like that callback-via-evutil, but since we
have event_extra we need do like that.

And after this patch the following tests doesn't report leaks:
$ valgrind --leak-check=full --show-reachable=yes --track-fds=yes --error-exitcode=1 regress --no-fork http/cancel..
...
==10469== FILE DESCRIPTORS: 2309 open at exit.
...
==10469== HEAP SUMMARY:
==10469==     in use at exit: 0 bytes in 0 blocks
==10469==   total heap usage: 33,846 allocs, 33,846 frees, 4,617,651 bytes allocated
==10469==
==10469== All heap blocks were freed -- no leaks are possible

v2: do under lock
v3: reset dns request
v4: ignore EVUTIL_EAI_CANCEL in regular callback

8 years agoevdns: export cancel via callbacks in util (like async lib core/extra issues)
Azat Khuzhin [Mon, 21 Mar 2016 14:08:34 +0000 (17:08 +0300)]
evdns: export cancel via callbacks in util (like async lib core/extra issues)

8 years agotest/http: request cancellation with resolving/{conn,write}-timeouts in progress
Azat Khuzhin [Sat, 12 Mar 2016 15:50:41 +0000 (18:50 +0300)]
test/http: request cancellation with resolving/{conn,write}-timeouts in progress

This patch adds 8 new tests:
- http/cancel
- http/cancel_by_host
- http/cancel_by_host_no_ns
- http/cancel_by_host_inactive_server
- http/cancel_inactive_server
- http/cancel_by_host_no_ns_inactive_server
- http/cancel_by_host_server_timeout
- http/cancel_server_timeout
- http/cancel_by_host_no_ns_server_timeout

This patches not 100% for http layer, but more for be_sock, but it was simpler
to add them here, plus it also shows some bugs with fd leaking in http layer.

Right now we have next picture (we can also play with timeouts/attempts for
evdns to make tests fail, IOW to track the failures even without valgrind):
$ valgrind --leak-check=full --show-reachable=yes --track-fds=yes --error-exitcode=1 regress --no-fork http/cancel..
http/cancel: OK
http/cancel_by_host: OK
http/cancel_by_host_no_ns: [msg] Nameserver 127.0.0.1:42489 has failed: request timed out.
[msg] All nameservers have failed
OK
http/cancel_by_host_inactive_server: OK
http/cancel_inactive_server: OK
http/cancel_by_host_no_ns_inactive_server: [msg] Nameserver 127.0.0.1:51370 has failed: request timed out.
[msg] All nameservers have failed
OK
http/cancel_by_host_server_timeout: OK
http/cancel_server_timeout: OK
http/cancel_by_host_no_ns_server_timeout: [msg] Nameserver 127.0.0.1:45054 has failed: request timed out.
[msg] All nameservers have failed
OK
9 tests ok.  (0 skipped)
==3202==
==3202== FILE DESCRIPTORS: 2309 open at exit.
...
==8403== HEAP SUMMARY:
==8403==     in use at exit: 1,104 bytes in 5 blocks
==8403==   total heap usage: 10,916 allocs, 10,911 frees, 1,458,818 bytes allocated
==8403==
==8403== 40 bytes in 1 blocks are indirectly lost in loss record 1 of 5
==8403==    at 0x4C2BBD5: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==8403==    by 0x4AAD2D: event_mm_calloc_ (event.c:3459)
==8403==    by 0x498E48: evbuffer_add_cb (buffer.c:3309)
==8403==    by 0x4A0DE2: bufferevent_socket_new (bufferevent_sock.c:366)
==8403==    by 0x4BF8BA: evhttp_connection_base_bufferevent_new (http.c:2369)
==8403==    by 0x4BFA6A: evhttp_connection_base_new (http.c:2421)
==8403==    by 0x460CFC: http_cancel_test (regress_http.c:1413)
==8403==    by 0x490965: testcase_run_bare_ (tinytest.c:105)
==8403==    by 0x490C47: testcase_run_one (tinytest.c:252)
==8403==    by 0x491586: tinytest_main (tinytest.c:434)
==8403==    by 0x47DFCD: main (regress_main.c:461)
==8403==
==8403== 136 bytes in 1 blocks are indirectly lost in loss record 2 of 5
==8403==    at 0x4C2BBD5: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==8403==    by 0x4AAD2D: event_mm_calloc_ (event.c:3459)
==8403==    by 0x491EDD: evbuffer_new (buffer.c:365)
==8403==    by 0x49A0AB: bufferevent_init_common_ (bufferevent.c:300)
==8403==    by 0x4A0D31: bufferevent_socket_new (bufferevent_sock.c:353)
==8403==    by 0x4BF8BA: evhttp_connection_base_bufferevent_new (http.c:2369)
==8403==    by 0x4BFA6A: evhttp_connection_base_new (http.c:2421)
==8403==    by 0x460CFC: http_cancel_test (regress_http.c:1413)
==8403==    by 0x490965: testcase_run_bare_ (tinytest.c:105)
==8403==    by 0x490C47: testcase_run_one (tinytest.c:252)
==8403==    by 0x491586: tinytest_main (tinytest.c:434)
==8403==    by 0x47DFCD: main (regress_main.c:461)
==8403==
==8403== 136 bytes in 1 blocks are indirectly lost in loss record 3 of 5
==8403==    at 0x4C2BBD5: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==8403==    by 0x4AAD2D: event_mm_calloc_ (event.c:3459)
==8403==    by 0x491EDD: evbuffer_new (buffer.c:365)
==8403==    by 0x49A0E8: bufferevent_init_common_ (bufferevent.c:305)
==8403==    by 0x4A0D31: bufferevent_socket_new (bufferevent_sock.c:353)
==8403==    by 0x4BF8BA: evhttp_connection_base_bufferevent_new (http.c:2369)
==8403==    by 0x4BFA6A: evhttp_connection_base_new (http.c:2421)
==8403==    by 0x460CFC: http_cancel_test (regress_http.c:1413)
==8403==    by 0x490965: testcase_run_bare_ (tinytest.c:105)
==8403==    by 0x490C47: testcase_run_one (tinytest.c:252)
==8403==    by 0x491586: tinytest_main (tinytest.c:434)
==8403==    by 0x47DFCD: main (regress_main.c:461)
==8403==
==8403== 528 bytes in 1 blocks are indirectly lost in loss record 4 of 5
==8403==    at 0x4C2BBD5: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==8403==    by 0x4AAD2D: event_mm_calloc_ (event.c:3459)
==8403==    by 0x4A0D02: bufferevent_socket_new (bufferevent_sock.c:350)
==8403==    by 0x4BF8BA: evhttp_connection_base_bufferevent_new (http.c:2369)
==8403==    by 0x4BFA6A: evhttp_connection_base_new (http.c:2421)
==8403==    by 0x460CFC: http_cancel_test (regress_http.c:1413)
==8403==    by 0x490965: testcase_run_bare_ (tinytest.c:105)
==8403==    by 0x490C47: testcase_run_one (tinytest.c:252)
==8403==    by 0x491586: tinytest_main (tinytest.c:434)
==8403==    by 0x47DFCD: main (regress_main.c:461)
==8403==
==8403== 1,104 (264 direct, 840 indirect) bytes in 1 blocks are definitely lost in loss record 5 of 5
==8403==    at 0x4C2BBD5: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==8403==    by 0x4AAD2D: event_mm_calloc_ (event.c:3459)
==8403==    by 0x4D0326: evdns_getaddrinfo (evdns.c:4682)
==8403==    by 0x4B1213: evutil_getaddrinfo_async_ (evutil.c:1568)
==8403==    by 0x4A1255: bufferevent_socket_connect_hostname (bufferevent_sock.c:517)
==8403==    by 0x4C00B6: evhttp_connection_connect_ (http.c:2582)
==8403==    by 0x4C02B8: evhttp_make_request (http.c:2637)
==8403==    by 0x4614EC: http_cancel_test (regress_http.c:1496)
==8403==    by 0x490965: testcase_run_bare_ (tinytest.c:105)
==8403==    by 0x490C47: testcase_run_one (tinytest.c:252)
==8403==    by 0x491586: tinytest_main (tinytest.c:434)
==8403==    by 0x47DFCD: main (regress_main.c:461)
==8403==
==8403== LEAK SUMMARY:
==8403==    definitely lost: 264 bytes in 1 blocks
==8403==    indirectly lost: 840 bytes in 4 blocks
==8403==      possibly lost: 0 bytes in 0 blocks
==8403==    still reachable: 0 bytes in 0 blocks
==8403==         suppressed: 0 bytes in 0 blocks

8 years agobe_sock: evutil_getaddrinfo_async_() always return 0
Azat Khuzhin [Mon, 21 Mar 2016 13:55:59 +0000 (16:55 +0300)]
be_sock: evutil_getaddrinfo_async_() always return 0

8 years agotest/http: exit from the loop in the errorcb to wait cancellation
Azat Khuzhin [Sun, 13 Mar 2016 10:05:25 +0000 (13:05 +0300)]
test/http: exit from the loop in the errorcb to wait cancellation

This will make cancellation tests more graceful, that said that error_cb can
not be called sometimes if you will break the loop in cancel.

Plus drop that define for function generations, since function body changed,
and it is not generic anymore, plus that macro didn't used by anyone else.

8 years agoregress_clean_dnsserver(): reset global port vars
Azat Khuzhin [Tue, 22 Mar 2016 20:10:19 +0000 (23:10 +0300)]
regress_clean_dnsserver(): reset global port vars

This will fix some test chains with --no-fork.

8 years agohttp: make fallback for EVHTTP_CON_READ_ON_WRITE_ERROR more cleaner
Azat Khuzhin [Fri, 11 Mar 2016 17:17:51 +0000 (20:17 +0300)]
http: make fallback for EVHTTP_CON_READ_ON_WRITE_ERROR more cleaner

8 years agohttp: fix EVHTTP_CON_READ_ON_WRITE_ERROR when it doesn't supported by OS
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

8 years agotest/http: read_on_write_error: fix it for win32
Azat Khuzhin [Fri, 11 Mar 2016 17:06:11 +0000 (20:06 +0300)]
test/http: read_on_write_error: fix it for win32

Fixes: https://ci.appveyor.com/project/nmathewson/libevent/build/2.1.5.216#L499 (win32)
8 years agohttp: do not do function calls under EVUTIL_ASSERT() to fix NDEBUG builds
Azat Khuzhin [Fri, 11 Mar 2016 16:52:32 +0000 (19:52 +0300)]
http: do not do function calls under EVUTIL_ASSERT() to fix NDEBUG builds

Fixes: 2185e639210f072f37e9d19aff7dba382db84529 ("http: assert's that
evbuffer_drain() success on connection reset")
Fixes: http/data_length_constraints
  FAIL ../test/regress_http.c:3775: assert(evhttp_request_get_response_code(req) == HTTP_ENTITYTOOLARGE): 501 vs 413

8 years agoMerge branch 'http-client-fix-expect-100-continue-v6'
Azat Khuzhin [Fri, 11 Mar 2016 17:59:36 +0000 (20:59 +0300)]
Merge branch 'http-client-fix-expect-100-continue-v6'

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"

8 years agohttp: fix leaking of response_code_line
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)

Fixes: 0b46b39e95ad77951176f09782138305ba34edf3 ("http: fix "Expect:
100-continue" client side")

8 years agohttp: fix "Expect: 100-continue" client side
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.

Covered-by: http/data_length_constraints
Covered-by: http/read_on_write_error
8 years agotest/http: separate coverage for EVHTTP_CON_READ_ON_WRITE_ERROR
Azat Khuzhin [Fri, 11 Mar 2016 16:25:11 +0000 (19:25 +0300)]
test/http: separate coverage for EVHTTP_CON_READ_ON_WRITE_ERROR

8 years agotest/http: cover "Expect: 100-continue" client-server interaction
Azat Khuzhin [Fri, 11 Mar 2016 11:23:03 +0000 (14:23 +0300)]
test/http: cover "Expect: 100-continue" client-server interaction

8 years agotest/http: *lingering tests shouldn't have "Expect: 100-continue"
Azat Khuzhin [Fri, 11 Mar 2016 13:18:48 +0000 (16:18 +0300)]
test/http: *lingering tests shouldn't have "Expect: 100-continue"

8 years agobe_sock: unfreeze buffers on fd changing
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).

8 years agohttp: assert's that evbuffer_drain() success on connection reset
Azat Khuzhin [Fri, 11 Mar 2016 11:02:13 +0000 (14:02 +0300)]
http: assert's that evbuffer_drain() success on connection reset

Since otherwise we can have nasty bugs with part of previous *request* in
current *request* and hence some parsing errors.

And now we have failures:
  http/non_lingering_close: [forking] [err] ../http.c:1326: Assertion !evbuffer_drain(tmp, -1) failed in ../http.c

8 years agotest: use EVUTIL_SHUT_WR
Azat Khuzhin [Thu, 10 Mar 2016 22:27:52 +0000 (01:27 +0300)]
test: use EVUTIL_SHUT_WR

8 years agoIgnore verify_tests.bat (win32 version)
Azat Khuzhin [Thu, 10 Mar 2016 20:51:15 +0000 (23:51 +0300)]
Ignore verify_tests.bat (win32 version)

8 years agotest/http: avoid huge stack allocations to fix win32 builds
Azat Khuzhin [Thu, 10 Mar 2016 15:40:34 +0000 (18:40 +0300)]
test/http: avoid huge stack allocations to fix win32 builds

Since according to [DOC] default stack size is 1MB, so let's use dynamic
allocations instead of changing defaults.

DOC: https://msdn.microsoft.com/en-us/library/8cxs58a6.aspx
Not-fixes: http/data_length_constraints
Fixes: http/lingering_close
Fixes: http/non_lingering_close
Fixes: https://ci.appveyor.com/project/nmathewson/libevent/build/2.1.5.213
8 years agocmake: require 3.1 only for win32 to make it work under ubunty precise
Azat Khuzhin [Wed, 9 Mar 2016 22:50:12 +0000 (01:50 +0300)]
cmake: require 3.1 only for win32 to make it work under ubunty precise

Also I [TRIED] wily but ubuntu can't upgrade transparently.

TRIED: https://travis-ci.org/azat/libevent/jobs/114924723
Fixes: https://travis-ci.org/libevent/libevent/jobs/114917275
8 years agocmake: require at least 3.1 for target_sources()
Azat Khuzhin [Wed, 9 Mar 2016 22:07:54 +0000 (01:07 +0300)]
cmake: require at least 3.1 for target_sources()

8 years agocmake: fix adding of compiler flags, and now it will
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

8 years agoReplace -Wswitch-enum with -Wswitch, and add it into cmake rules too
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*.

8 years agoMerge branch 'more-graceful-http-v10'/lingering close
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

Fixes: #321
Covered-by: http/non_lingering_close
Covered-by: http/lingering_close
8 years agotest: http/lingering_close: cover EVHTTP_SERVER_LINGERING_CLOSE
Azat Khuzhin [Mon, 15 Feb 2016 00:21:39 +0000 (03:21 +0300)]
test: http/lingering_close: cover EVHTTP_SERVER_LINGERING_CLOSE

8 years agotest: http/non_lingering_close: cover ~EVHTTP_SERVER_LINGERING_CLOSE
Azat Khuzhin [Mon, 15 Feb 2016 00:13:02 +0000 (03:13 +0300)]
test: http/non_lingering_close: cover ~EVHTTP_SERVER_LINGERING_CLOSE

8 years agotest: http/*: update expected HTTP codes for body exceeds `max_body_size`
Azat Khuzhin [Mon, 15 Feb 2016 00:46:20 +0000 (03:46 +0300)]
test: http/*: update expected HTTP codes for body exceeds `max_body_size`

8 years agohttp: take EVHTTP_CON_LINGERING_CLOSE into account for "Expect: 100-Continue"
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.

Refs: #321
v2: remove EVHTTP_CON_ABOUT_TO_CLOSE

8 years agotest: http/data_length_constrains: set EVHTTP_CON_READ_ON_WRITE_ERROR
Azat Khuzhin [Sun, 14 Feb 2016 23:41:19 +0000 (02:41 +0300)]
test: http/data_length_constrains: set EVHTTP_CON_READ_ON_WRITE_ERROR

8 years agohttp: lingering close (like nginx have) for entity-too-large
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

8 years agohttp: read server response even after server closed the connection
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

8 years agotest: increase buffer size for http/data_length_constraints to trigger EPIPE
Azat Khuzhin [Wed, 10 Feb 2016 09:37:30 +0000 (12:37 +0300)]
test: increase buffer size for http/data_length_constraints to trigger EPIPE

With greater buffer it can't be written with one writev(2), and hence we can
trigger more tricky cases, like calling writecb/readcb more then once.

Refs: #321

8 years agosample/hello-world: exAmple, not eXMple
kirillDanshin [Fri, 4 Mar 2016 16:18:18 +0000 (19:18 +0300)]
sample/hello-world: exAmple, not eXMple

Fixes: #334
8 years agohttp: fix conflicts EVHTTP_CON_AUTOFREE and EVHTTP_CON_REUSE_CONNECTED_ADDR
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).

Refs: #182

8 years agohttp: coding style issue
Azat Khuzhin [Mon, 15 Feb 2016 00:53:25 +0000 (03:53 +0300)]
http: coding style issue

8 years agoutil: fix "%zu" format on TDM-gcc/MinGW-w64
Azat Khuzhin [Wed, 24 Feb 2016 11:10:21 +0000 (14:10 +0300)]
util: fix "%zu" format on TDM-gcc/MinGW-w64

From: @gvanem
Fixes: #326
8 years agotest/tinytest_demo: include <windows.h> for win32 to fix tdm-gcc
Azat Khuzhin [Wed, 24 Feb 2016 11:02:37 +0000 (14:02 +0300)]
test/tinytest_demo: include <windows.h> for win32 to fix tdm-gcc

From: @gvanem
Fixes: #325
8 years agotest/regress_ssl: Fix compile problems for win32
Trond Norbye [Mon, 15 Feb 2016 17:01:36 +0000 (18:01 +0100)]
test/regress_ssl: Fix compile problems for win32

Windows doesn't have unistd.h, but have the required
functionality in io.h.

azat: use ev_ssize_t instead of ssize_t

8 years agoevdns: name_parse(): fix remote stack overread
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

Before this patch:
$ gdb -ex 'source gdb' dns-example
$1 = 1073741824
$2 = (void *) 0x633010
$3 = (void *) 0x633030
$4 = (void *) 0x40200000

Program received signal SIGSEGV, Segmentation fault.
__memcpy_sse2_unaligned () at memcpy-sse2-unaligned.S:33

After this patch:
$ gdb -ex 'source gdb' dns-example
$1 = 1073741824
$2 = (void *) 0x633010
$3 = (void *) 0x633030
$4 = (void *) 0x40200000
$5 = -1
0x633030:       "/"
0x633032:       ""
(gdb) p $m
$6 = (void *) 0x40200000
(gdb) p $1
$7 = 1073741824
(gdb) p/x $1
$8 = 0x40000000
(gdb) quit

P.S. plus drop one condition duplicate.

Fixes: #317
8 years agoevutil_parse_sockaddr_port(): fix buffer overflow
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

Before:
  $ gdb bin/http-connect < gdb
  (gdb) $1 = 2147483649
  (gdb) (gdb) $2 = (void *) 0x646010
  (gdb) (gdb) $3 = (void *) 0x646030
  (gdb) (gdb) $4 = (void *) 0x7fff76a2a010
  (gdb) (gdb) $5 = 1990369296
  (gdb) (gdb) $6 = 0x7fff76a2a010 '\001' <repeats 200 times>...
  (gdb) (gdb) (gdb) (gdb)
  Program received signal SIGSEGV, Segmentation fault.
  __memcpy_sse2_unaligned () at memcpy-sse2-unaligned.S:36

After:
  $ gdb bin/http-connect < gdb
  (gdb) $1 = 2147483649
  (gdb) (gdb) $2 = (void *) 0x646010
  (gdb) (gdb) $3 = (void *) 0x646030
  (gdb) (gdb) $4 = (void *) 0x7fff76a2a010
  (gdb) (gdb) $5 = 1990369296
  (gdb) (gdb) $6 = 0x7fff76a2a010 '\001' <repeats 200 times>...
  (gdb) (gdb) (gdb) (gdb) $7 = -1
  (gdb) (gdb) quit

Fixes: #318
8 years agocmake: don't define EVENT__NEED_DLLIMPORT always (fixes VS2013 static build)
Azat Khuzhin [Mon, 11 Jan 2016 22:37:34 +0000 (01:37 +0300)]
cmake: don't define EVENT__NEED_DLLIMPORT always (fixes VS2013 static build)

Otherwise that #ifdef in visibility.h is useless, and __declspec(dllimport)
will be always on.

Fixes: #314
Fixes: 4545fa9b6866df47ce2f908631a84477a94d5f49 ("Add option to build shared
library")

8 years agoAdd missing return statement to del_wait_thread so libevent can build.
Nick Mathewson [Fri, 22 Jan 2016 16:16:05 +0000 (11:16 -0500)]
Add missing return statement to del_wait_thread so libevent can build.

8 years agohttp-connect: make it win32 compilable
Azat Khuzhin [Mon, 11 Jan 2016 23:03:12 +0000 (02:03 +0300)]
http-connect: make it win32 compilable

Fixes: commit 1d34498ea31134bd7a8fcadcb95910b30a479e19 ("sample: add HTTP
CONNECT tunnelling example using libevent http layer")

8 years agocmake: fix building dns-example under win32 (missing getopt)
Azat Khuzhin [Mon, 11 Jan 2016 22:57:07 +0000 (01:57 +0300)]
cmake: fix building dns-example under win32 (missing getopt)

8 years agovisibility: align it to make it more readable
Azat Khuzhin [Mon, 11 Jan 2016 22:35:46 +0000 (01:35 +0300)]
visibility: align it to make it more readable

8 years agocmake: Fix detection of ssize_t/SSIZE_T
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.

Refs: #311

8 years agotest/regress: cover event_del() waiting mechanism
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.

Refs: #225
Refs: #226
Refs: #236

9 years agoIgnore more configure stuff (configure.lineno)
Azat Khuzhin [Sun, 27 Dec 2015 13:50:33 +0000 (16:50 +0300)]
Ignore more configure stuff (configure.lineno)

Link: https://lists.gnu.org/archive/html/autoconf/2004-01/msg00043.html
9 years agoMerge branch 'event_reinit-for-signals-v3'
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

Fixes #307

9 years agotest/regress: cover existing signal callbacks and fork() + event_reinit()
Azat Khuzhin [Sat, 26 Dec 2015 23:48:40 +0000 (02:48 +0300)]
test/regress: cover existing signal callbacks and fork() + event_reinit()

Regression-for: 88640aa ("event_reinit: make signals works after fork() without
evsig_add()")

9 years agotest/regress: cover signals after fork() + event_reinit()
Azat Khuzhin [Sun, 27 Dec 2015 06:26:54 +0000 (09:26 +0300)]
test/regress: cover signals after fork() + event_reinit()

Regression-for: ad0c237 ("event_reinit: always re-init signal's socketpair")

9 years agotest/regress: main/fork: rewrite assertions by just removing event in callback
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.

9 years agoevent_reinit: make signals works after fork() without evsig_add()
Nicholas Marriott [Sat, 26 Dec 2015 23:15:03 +0000 (02:15 +0300)]
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.

Fixes: #307
9 years agoevent_reinit: always re-init signal's socketpair
Nicholas Marriott [Sat, 26 Dec 2015 22:43:37 +0000 (01:43 +0300)]
event_reinit: always re-init signal's socketpair

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).

Fixes: #307
9 years agoUpdate README.md
Mark Ellzey [Wed, 23 Dec 2015 10:42:48 +0000 (02:42 -0800)]
Update README.md

9 years agoFixed issue with cmake version generation
Mark Ellzey [Tue, 22 Dec 2015 01:43:00 +0000 (17:43 -0800)]
Fixed issue with cmake version generation

9 years agoMerge pull request #125 from libevent/master
Mark Ellzey [Mon, 21 Dec 2015 23:33:50 +0000 (15:33 -0800)]
Merge pull request #125 from libevent/master

update upstream

9 years agoMerge pull request #305 from libevent/cmake_updates
Mark Ellzey [Mon, 21 Dec 2015 12:42:54 +0000 (04:42 -0800)]
Merge pull request #305 from libevent/cmake_updates

CMake updates that fix things I thought I fixed.

9 years agoCmake is now officially working.
Mark Ellzey [Mon, 21 Dec 2015 12:36:24 +0000 (04:36 -0800)]
Cmake is now officially working.

Though I am currently breaking out things that seem to be repetitive, and a
cooler version macro and changelog updater.

More to come.

9 years agoMore cmake updates, lot's of missing definitions
Mark Ellzey [Mon, 21 Dec 2015 05:44:04 +0000 (21:44 -0800)]
More cmake updates, lot's of missing definitions

9 years agoMerge pull request #300 from ellzey/cmake_updates
Mark Ellzey [Sun, 20 Dec 2015 10:17:25 +0000 (02:17 -0800)]
Merge pull request #300 from ellzey/cmake_updates

Cmake updates

9 years agoCMake syntax fixes fo .in files
Mark Ellzey [Sun, 20 Dec 2015 09:56:25 +0000 (01:56 -0800)]
CMake syntax fixes fo .in files

9 years agoMerge pull request #299 from libevent/revert-297-master
Mark Ellzey [Sun, 20 Dec 2015 09:09:36 +0000 (01:09 -0800)]
Merge pull request #299 from libevent/revert-297-master

Revert "The Windows socket type is defined as SOCKET."

9 years agoRevert "The Windows socket type is defined as SOCKET."
Mark Ellzey [Sun, 20 Dec 2015 08:57:50 +0000 (00:57 -0800)]
Revert "The Windows socket type is defined as SOCKET."

9 years agoCMAKE CMAKE CMAKE CLEANUPS
Mark Ellzey [Sun, 20 Dec 2015 08:43:46 +0000 (00:43 -0800)]
CMAKE CMAKE CMAKE CLEANUPS

It's almost useful.

9 years agoLot's of cmake updates
Mark Ellzey [Sat, 19 Dec 2015 09:47:49 +0000 (01:47 -0800)]
Lot's of cmake updates

This is still not done, cmake here was a horrid mess, but we're
getting our act together now.

9 years agoMerge pull request #297 from billsegall/master
Mark Ellzey [Fri, 18 Dec 2015 20:17:04 +0000 (12:17 -0800)]
Merge pull request #297 from billsegall/master

The Windows socket type is defined as SOCKET.

9 years agoProvide a mechanism for building the library on Windows with different compiler flags...
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.

9 years agoThe Windows socket type is defined as SOCKET.
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.

9 years agoMerge pull request #296 from lzmths/master
Mark Ellzey [Mon, 14 Dec 2015 20:31:08 +0000 (12:31 -0800)]
Merge pull request #296 from lzmths/master

Refactoring conditional directives that break parts of statements.

9 years agoMerge pull request #289 from mc-server/UnicodeErrMsgFix
Mark Ellzey [Mon, 14 Dec 2015 20:20:59 +0000 (12:20 -0800)]
Merge pull request #289 from mc-server/UnicodeErrMsgFix

Fixed Unicode issue in error messages.

9 years agoRefactoring conditional directives that break parts of statements.
lzmths [Mon, 14 Dec 2015 14:04:00 +0000 (11:04 -0300)]
Refactoring conditional directives that break parts of statements.

9 years agoFixed Unicode issue in error messages.
Mattes D [Fri, 9 Oct 2015 17:41:30 +0000 (19:41 +0200)]
Fixed Unicode issue in error messages.

9 years agobe_sock: bufferevent_socket_connect_hostname(): make it thread-safe
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

Fixes: #217
Closes: #222
Closes: #219
Gist: https://gist.github.com/azat/92cbb34232ac02d7972b (from #217 but thread-safe)

9 years agoautotools: fix getservbyname() detection
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.")

9 years agotest/dns: check exit code of evdns_getaddrinfo()
Azat Khuzhin [Wed, 25 Nov 2015 14:29:42 +0000 (17:29 +0300)]
test/dns: check exit code of evdns_getaddrinfo()

By some reason all autotools builds failed:
CI: https://travis-ci.org/libevent/libevent/builds/93125954

9 years agoMerge branch 'evdns-fail-requests-v6'
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

9 years agoevdns: evdns_base_free(): fix UAF of evdns_base with @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.

Fixes: regress dns/client_fail_requests_getaddrinfo
Fixes: #269
9 years agotest/dns: cover evdns_getaddrinfo() and evdns_base_free() with @fail_requests
Azat Khuzhin [Mon, 23 Nov 2015 12:52:10 +0000 (15:52 +0300)]
test/dns: cover evdns_getaddrinfo() and evdns_base_free() with @fail_requests

9 years agoevdns: evdns_base_free(): free requests before namservers
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 ...

Fixes: regress dns/client_fail_requests
Fixes: #269
9 years agotest/dns: cover @fail_requests for evdns_base_free()
Azat Khuzhin [Mon, 23 Nov 2015 12:28:40 +0000 (15:28 +0300)]
test/dns: cover @fail_requests for evdns_base_free()

9 years agotest/dns: more graceful coverage of @fail_requests
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).

9 years agosample/https-client: allow to change path to ca-certificates
Azat Khuzhin [Mon, 23 Nov 2015 22:35:25 +0000 (01:35 +0300)]
sample/https-client: allow to change path to ca-certificates

And default to one that linux have, for freebsd you will need:
$ https-client -url https://google.com -crt /usr/local/share/certs/ca-root-nss.crt

9 years agosample/https-client: check for ERR_remove_thread_state() existence
Azat Khuzhin [Mon, 23 Nov 2015 15:44:03 +0000 (18:44 +0300)]
sample/https-client: check for ERR_remove_thread_state() existence

Fixes: freebsd 9.2 build
9 years agohttp: avoid epoll_ctl() on already closed fd (triggers by http/chunk_out)
Azat Khuzhin [Thu, 19 Nov 2015 22:37:46 +0000 (01:37 +0300)]
http: avoid epoll_ctl() on already closed fd (triggers by http/chunk_out)

Before:
$ strace -eepoll_ctl,close regress --verbose --no-fork +http/chunk_out
close(3)                                = 0
close(3)                                = 0
close(3)                                = 0
close(3)                                = 0
close(3)                                = 0
close(3)                                = 0
close(3)                                = 0
close(3)                                = 0
http/chunk_out: epoll_ctl(5, EPOLL_CTL_ADD, 8, {EPOLLIN, {u32=8, u64=8}}) = 0
close(10)                               = 0
close(9)                                = 0
epoll_ctl(5, EPOLL_CTL_ADD, 9, {EPOLLIN, {u32=9, u64=9}}) = 0
epoll_ctl(5, EPOLL_CTL_ADD, 10, {EPOLLOUT, {u32=10, u64=10}}) = 0
epoll_ctl(5, EPOLL_CTL_ADD, 11, {EPOLLIN, {u32=11, u64=11}}) = 0
epoll_ctl(5, EPOLL_CTL_DEL, 10, 7ffffb10b870) = 0
epoll_ctl(5, EPOLL_CTL_ADD, 10, {EPOLLIN, {u32=10, u64=10}}) = 0
close(12)                               = 0
epoll_ctl(5, EPOLL_CTL_MOD, 11, {EPOLLIN|EPOLLOUT, {u32=11, u64=11}}) = 0
epoll_ctl(5, EPOLL_CTL_MOD, 11, {EPOLLIN, {u32=11, u64=11}}) = 0
close(11)                               = 0
epoll_ctl(5, EPOLL_CTL_DEL, 11, 7ffffb10b770) = -1 EBADF (Bad file descriptor)
...

And trace for latest:
close(11)                               = 0
 > regress(evutil_closesocket+0x15) [0xadac4]
 > regress(evhttp_connection_free+0x19d) [0xbada2]
 > regress(evhttp_send_done+0x14d) [0xbde43]
 > regress(evhttp_write_cb+0x4a) [0xba1a1]
 > regress(bufferevent_run_writecb_+0xa2) [0x97bba]
 > regress(bufferevent_trigger_nolock_+0xb1) [0x9e330]
 > regress(bufferevent_writecb+0x2a3) [0x9e91a]
 > regress(event_persist_closure+0x2bb) [0xa2e09]
 > regress(event_process_active_single_queue+0x2a8) [0xa30b4]
 > regress(event_process_active+0x13f) [0xa3696]
 > regress(event_base_loop+0x2ab) [0xa3d97]
 > regress(event_base_dispatch+0x1d) [0xa371e]
 > regress(http_chunk_out_test_impl+0x132) [0x74940]
epoll_ctl(5, EPOLL_CTL_DEL, 11, 7fff09439fe0) = -1 EBADF (Bad file descriptor)
 > regress(epoll_ctl+0x36) [0xb49a3]
 > regress(epoll_apply_one_change+0x14e) [0xb4cd4]
 > regress(epoll_nochangelist_del+0x87) [0xb51e4]
 > regress(evmap_io_del_+0x247) [0xaab04]
 > regress(event_del_nolock_+0x2f7) [0xa6aa8]
 > regress(event_callback_cancel_nolock_+0x6e) [0xa747e]
 > regress(event_callback_finalize_many_+0xeb) [0xa4dd6]
 > regress(bufferevent_decref_and_unlock_+0x21d) [0x98da7]
 > regress(bufferevent_writecb+0x312) [0x9e989]
 > regress(event_persist_closure+0x2bb) [0xa2e09]
 > regress(event_process_active_single_queue+0x2a8) [0xa30b4]
 > regress(event_process_active+0x13f) [0xa3696]
 > regress(event_base_loop+0x2ab) [0xa3d97]
 > regress(event_base_dispatch+0x1d) [0xa371e]
 > regress(http_chunk_out_test_impl+0x132) [0x74940]
 ...

9 years agohttp: install timeout for read too during connect for ssl
Azat Khuzhin [Sun, 15 Nov 2015 21:55:30 +0000 (00:55 +0300)]
http: install timeout for read too during connect for ssl

Since during ssl handshake we can read too, and if something nasty will happens
during this handshake (because of too many events in the loop of something like
this) we can wait forever since there is no read timeout:
  (gdb) p *$2.task.connection.bufev
  $11 = {
    ...
    be_ops = 0x7f78c2864b00 <bufferevent_ops_openssl>,
    ev_read = {
      ...
      ev_ = {
        ev_io = {
          ...
          ev_timeout = { tv_sec = 0, tv_usec = 0 }
        },
        ev_signal = { ... }
      },
      ev_events = 82, ev_res = 2,
      ev_timeout = { tv_sec = 10889976, tv_usec = 418753 }
    },
    ev_write = {
      ...
      ev_ = {
        ev_io = {
          ...
          ev_timeout = { tv_sec = 20, tv_usec = 0 }
        },
        ev_signal = { ... }
      },
      ev_events = 84, ev_res = 4,
      ev_timeout = { tv_sec = 10889977, tv_usec = 598753 }
    },
    ...
    errorcb = 0x7f78c287de70 <evhttp_connection_cb>,
    ...
    timeout_read = { tv_sec = 0, tv_usec = 0 },
    timeout_write = { tv_sec = 20, tv_usec = 0 },
    enabled = 4
  }
  (gdb) bt
  #0  0x00007f78c17c3633 in __epoll_wait_nocancel () at syscall-template.S:81
  #1  0x00007f78c2aaf508 in epoll_dispatch (base=0x18f76d0, tv=<optimized out>) at epoll.c:463
  ...

Found-with: massive crawling
Tested-with: massive crawling