kc3-lang/libevent
Branch :
Log
| Author | Commit | Date | CI | Message |
|---|---|---|---|---|
 |
a487706e | 2016-08-07 23:14:01 | test: fix building with --disable-thread-support under win32 | |
|
38716c65 | 2016-08-07 23:07:44 | cmake: do not use stderr for notifications/version-info For all except "STATUS" message() will write to stderr, and this also includes case when you does not have <mode> at all. Plus for every message in stderr powershell generates exception and make appveyor fails. Fixes: https://ci.appveyor.com/project/azat/libevent/build/2.1.5.85/job/i10k7m0t80330mtr | |
|
18108574 | 2016-08-07 21:30:04 | appveyor: ignore failure of mingw-get Since according to doc [1], appveyour will fail the build on every powershell's exception: "PowerShell script is considered successful if it finishes without exception." [1]: https://www.appveyor.com/docs/build-configuration#powershell | |
|
ac90133c | 2016-08-07 20:52:41 | appveyor: drop shallow_clone, since we use tags for detecting version in cmake | |
|
bb09535b | 2016-08-07 22:19:39 | autoconf: fix --disable-thread-support build under win32 Fixes: https://ci.appveyor.com/project/azat/libevent/build/job/gvud4tcqsd5bnarl Fixes: https://ci.appveyor.com/project/azat/libevent/build/2.1.6.80/job/5frnb1c3n4quxxqy Fixes: https://ci.appveyor.com/project/azat/libevent/build/2.1.6.80/job/3wdahbrew7setmoa | |
|
8f950155 | 2016-06-19 14:15:41 | appveyor: support cmake & autotools using build matrix (like travis-ci has) This will allow us to avoid possible compilation regressions, and also some failures in different environments (for example because of different sizeof(size_t)). For example we can avoid next issues: - #361 - #314 - #311 (And I'm pretty sure that this is not complete list) And of course it reduce job for maintainers. But it also have one downside, appveyor doesn't have such concurrency like travis-ci, so it can take a while to finish the whole build, but we can resolve this later, or reduce build matrix to only one for autotools and one for cmake. Fixes: #364 | |
|
8a2c6c77 | 2016-08-08 18:15:41 | Ignore `make dist` generated files | |
 |
df6f99e5 | 2016-07-08 09:43:39 | Check for Mac OS X 10.4 kqueue bug properly EV_ERROR is a bit in struct kevent::flags. Other bits may be set too. Actually we have osx builds on travis-ci, but it uses osx 10.9.5, and we don't have warnings there, since I guess that there is no OR'ing with previous flag in case of error, while in 10.12 there is OR. Fixes: #377 Fixes: #376 Link: https://crbug.com/626534 Link: https://travis-ci.org/libevent/libevent/jobs/141033429 | |
|
8892f4cb | 2016-07-07 13:15:41 | buffer: don't mix code and declarations | |
 |
666db91a | 2016-06-29 15:11:50 | Fix memory leak in signal-test.c | |
 |
30316177 | 2016-06-28 10:37:24 | [#372] check for errno.h | |
|
e7abef1c | 2016-06-26 11:15:58 | Merge pull request #367 from neerajbadlani/master Update gitignore file to ignore cscope gen'ed files | |
|
70040c09 | 2016-06-26 01:57:45 | buffer: Merge branch '340-dig-v2' All details in this two patches (it's titles), and shortlog is below. * 340-dig-v2: buffer: fix overflow check in evbuffer_expand_singlechain() test/buffer: cover evbuffer_expand() for overflow | |
|
a3f4ccd1 | 2016-06-21 19:49:57 | buffer: fix overflow check in evbuffer_expand_singlechain() Refs: #306 Fixes: #340 Fixes: 20d6d4458bee5d88bda1511c225c25b2d3198d6c | |
|
48dab7aa | 2016-06-22 15:48:51 | test/buffer: cover evbuffer_expand() for overflow Refs: #306 Refs: #340 | |
|
17cc6362 | 2016-06-24 18:07:39 | [Issue #313] set method to ASCII "NULL" if evhttp_method() returns NULL | |
 |
0aaa4fbe | 2016-06-22 21:15:53 | Update gitignore file to ignore cscope gen'ed files | |
|
a69e4fad | 2016-06-19 13:24:18 | buffer: Merge branch 'evbuffer-empty-chains-fixes-v4' This fixes bug with empty-chains and evbuffer_add_buffer()/evbuffer_remove_buffer(). * evbuffer-empty-chains-fixes-v4: buffer: evbuffer_add_buffer(): clean empty chains from destination buffer test/buffer: evbuffer_add_buffer() with empty chains test/buffer: evbuffer_remove_buffer() with empty chains (prepend) test/buffer: evbuffer_remove_buffer() with empty chains (evbuffer_add_buffer()) Reported-by: Eduardo Panisset <eduardo@anchorfree.com> | |
|
9b294082 | 2016-06-19 13:21:15 | bufferevent_filter: Merge branch 'be-filter-data-stuck' Fixes data stuck in filters with active watermarks. * be-filter-data-stuck: test/be_filter: creating test case for data stuck with active watermarks be_filter: avoid data stuck under active watermarks | |
 |
766194b3 | 2016-06-19 02:09:50 | test/be_filter: creating test case for data stuck with active watermarks v2: fix whitespaces s/int/size_t/ use tt_int_op() s/malloc/calloc (to avoid possible false-positive) | |
|
b627ad88 | 2016-06-17 10:46:32 | be_filter: avoid data stuck under active watermarks Suppose we have bufferevent filter attached to bufferevent socket. Read high watermark for bufferevent filter is configured to 4096 bytes. Socket receives 4343 bytes. Due to watermark, 4096 bytes are transferred from socket input buffer to filter input buffer and 247 bytes are left in bufferevent socket. Suppose that no more data is received through socket. At this point 247 bytes will sit forever in input buffer of bufferevent socket. The patch attached solves this issue registering read callback to filter's input buffer if it reaches its read high water mark and data was left in corresponding underlying's input buffer. This read callback calls filter process input function as soon as filter input buffer falls below its read high watermark and there still is data left in underlying input buffer. Callback is deregistered as soon as filter input buffer falls below its read high watermark. | |
 |
28518896 | 2016-05-21 21:05:11 | Fix bufferevent_pair to properly set BEV_EVENT_{READING,WRITING} on flush. Here's some fun. From `bufferevent.h`: ``` #define BEV_EVENT_READING 0x01 /**< error encountered while reading */ #define BEV_EVENT_WRITING 0x02 /**< error encountered while writing */ ``` And from `event.h`: ``` /** Wait for a socket or FD to become readable */ #define EV_READ 0x02 /** Wait for a socket or FD to become writeable */ #define EV_WRITE 0x04 ``` Library users have to be very careful to get this right; it turns out, the library itself got this wrong in the `bufferevent_pair` code. It appears that in most of the code, only `BEV_EVENT_FINISHED` will indicate whether it's read or write; on error or timeout, it appears that "both" is assumed and not set in the callback. I read through all the other places where `BEV_EVENT_FINISHED` is passed to an event callback; it appears that the pair code is the only spot that got it wrong. azat: add TT_FORK to avoid breaking clean env, and rebase commit message (copied from #359) Fixes: #359 | |
|
26fd9321 | 2016-06-07 18:31:48 | buffer: evbuffer_add_buffer(): clean empty chains from destination buffer @EMPanisset reported a problem (#358) with evbuffer_remove_buffer(), but actually I think that the problem is in evbuffer_add_buffer() which introduces this empty chain, all other callers (except evbuffer_prepend_buffer(), but it doesn't have this problem though) should be safe. And FWIW the only API that allows empty chains is evbuffer_add_reference(), and we can add check there to avoid such issues, but for now I leaved this without fixing, since I think that evbuffer_add_reference() with empty chains can be used as a barrier (but this can be tricky). Fixes: regress evbuffer/remove_buffer_with_empty2 v2: introduce/fixes evbuffer/add_buffer_with_empty | |
|
a272bc42 | 2016-06-17 15:54:53 | test/buffer: evbuffer_add_buffer() with empty chains Reported-by: @EMPanisset Link: https://github.com/libevent/libevent/issues/358#issuecomment-225345697 | |
|
f0cfa146 | 2016-06-08 13:41:30 | test/buffer: evbuffer_remove_buffer() with empty chains (prepend) Using: - evbuffer_add() - evbuffer_prepend_buffer() - evbuffer_add_reference() - evbuffer_remove_buffer() | |
|
2880ce6a | 2016-06-07 14:56:32 | test/buffer: evbuffer_remove_buffer() with empty chains (evbuffer_add_buffer()) Using: - evbuffer_add() - evbuffer_add_buffer() -- the one that has problem - evbuffer_add_reference() -- the only one that allows empty chains to be added - evbuffer_remove_buffer() | |
|
2a4bf294 | 2016-06-17 16:14:02 | test/http: avoid using conditionals with omitted operands (fixes VS2015) But we need to add VS2015 build on appveyor. Fixes: #361 Reported-by: @nntrab | |
|
aabf1c2d | 2016-06-17 16:07:15 | test/http: don't mix declarations and code (fixes -Wdeclaration-after-statement) | |
|
c08d90ba | 2016-06-17 15:54:31 | test/buffer: fix leak in test_evbuffer_prepend() | |
|
e7d1e392 | 2016-06-17 15:43:26 | test/buffer: avoid errors with --no-fork (reinitialize static vars) | |
 |
b5ca3656 | 2016-05-30 16:53:41 | For non GCC/clang on OSX the -Wno-deprecated-declarations may not be valid Closes: nmathewson/Libevent#129 | |
|
41e54464 | 2016-05-12 00:40:25 | Merge branch 'travis-ci-os-matrix-v2' This increases libevent coverage to: - os:osx - cmake -DEVENT__DISABLE_MM_REPLACEMENT=ON - cmake -DEVENT__ENABLE_VERBOSE_DEBUG=ON - configure --disable-openssl - configure --disable-thread-support - configure --disable-malloc-replacement - fix travis-ci builds under automake >1.11 Possible failures after this patch set (not always, IOW in some builds this issues aren't real issues): - some failures but mostly because of timing issues, must be fixed separately. - https://travis-ci.org/azat/libevent/jobs/129430229 # on brew update - https://travis-ci.org/azat/libevent/jobs/129430221 # some locking issues * travis-ci-os-matrix-v2: automake: define serial-tests only if automake have this option test/automake: don't use paralell test harness (since automake 1.12) travis-ci/osx: relink gcc/g++ instead of clang travis-ci: enable multi-os mode (osx, linux) travis-ci: increase matrix (--disable-foo) travis-ci: adjust alignment Fixes: #356 Travis-CI: https://travis-ci.org/azat/libevent/builds/129430181 | |
|
61179dec | 2016-05-11 16:02:02 | automake: define serial-tests only if automake have this option P.S. I did try a lot of other ways, but seems that this is the only one that will work. Fixes: automake 1.11 Travis-CI: https://travis-ci.org/azat/libevent/jobs/129398265 | |
|
44d755e0 | 2016-05-11 10:18:25 | test/automake: don't use paralell test harness (since automake 1.12) Starting from automake 1.2 there is parallel test harness, that redirects all output to some log, which serial-test doesn't do. So in case of new runner we can get no output for 10 minutes, for example on my desktop: $ time make verify VERBOSE=1 PASS: test/test-script.sh ============================================================================ Testsuite summary for libevent 2.1.5-beta ============================================================================ # TOTAL: 1 # PASS: 1 # SKIP: 0 # XFAIL: 0 # FAIL: 0 # XPASS: 0 # ERROR: 0 ============================================================================ real 25m31.735s user 0m13.753s sys 0m7.648s And this means that this will fail on travis-ci, since it has timeout for 10 minutes. Sure we can use `travis wait 60` instead, but I think that it is better to fix this by writing result to output, instead of hacking around, so let's use serial-tests instead of parallel always. And now it works on travis-ci under linux because it has automake 1.11 while osx has at least 1.12. Links: https://docs.travis-ci.com/user/common-build-problems/ https://www.gnu.org/software/automake/manual/html_node/Serial-Test-Harness.html#Serial-Test-Harness https://www.gnu.org/software/automake/manual/html_node/Parallel-Test-Harness.html CI: https://travis-ci.org/azat/libevent/jobs/129171497 # ok on linux https://travis-ci.org/azat/libevent/jobs/129171532 # no output for 10 min on osx | |
|
481481d3 | 2016-05-10 10:25:05 | travis-ci/osx: relink gcc/g++ instead of clang Since by default osx replaces /usr/bin/gcc with it's apple clang, while we have gcc in our build matrix, so use real gcc. | |
|
79917e48 | 2016-05-09 18:14:31 | travis-ci: enable multi-os mode (osx, linux) - use addons.apt.packages instead of `apt-get install` - add `brew update`/`brew install ...` Link: https://docs.travis-ci.com/user/installing-dependencies/ Link: https://docs.travis-ci.com/user/multi-os/ | |
|
59649f74 | 2016-05-09 18:48:56 | travis-ci: increase matrix (--disable-foo) Use --disable-foo from https://github.com/libevent/libevent/wiki/ReleaseChecklist | |
|
c8be3395 | 2016-05-09 18:54:41 | travis-ci: adjust alignment | |
|
38e0f4a5 | 2016-05-02 15:21:50 | be_openssl: clear all pending errors before SSL_*() calls Refs: #350 Reported-by: @CapSel | |
|
ce389933 | 2016-04-21 02:16:21 | Ignore all pkgconfig generated stuff In the referenced commit new *.pc added, and I think it is better to ignore them all. Refs: b8d7c6211a965c19c7c5de414135ff13b5fa2476 ("libevent_core and libevent_extra also deserve a pkgconfig file") | |
|
e77ff418 | 2016-04-21 01:47:29 | test/buffer: cover n_add_for_cb when evbuffer_prepend() need to allocate buffer Regression-for: 0abd0393eaf029e1ead8a09b479ea6830f7152ee ("Fix n_add_for_cb in evbuffer_prepend() in case of new buffer required") | |
|
bd19a28a | 2016-04-21 02:11:26 | test/tinytest_macros: add new one tt_nstr_op() | |
|
0abd0393 | 2016-04-21 01:58:58 | Fix n_add_for_cb in evbuffer_prepend() in case of new buffer required Signed-off-by: @luoming1224 Fixes: #349 | |
 |
b8d7c621 | 2016-04-20 07:31:25 | libevent_core and libevent_extra also deserve a pkgconfig file | |
|
d5e634a8 | 2016-04-18 13:39:54 | Merge branch 'be-filter-outputcb-disable-during-execution' * be-filter-outputcb-disable-during-execution: test/bufferevent: check that output_filter disabled during processing output be_filter: actually disable output_filter during processing output | |
|
ae288125 | 2016-04-18 12:50:24 | test/bufferevent: check that output_filter disabled during processing output Regression-for: c031215d532c97f1d82efd672ecd622d31d3342d ("be_filter: actually disable output_filter during processing output") | |
 |
c031215d | 2016-02-28 16:49:15 | be_filter: actually disable output_filter during processing output IOW: Make the code do what the comment says it should do. | |
|
2a71b332 | 2016-03-31 20:45:47 | listener: unlock lev on error in listener_read_cb() Without this patch: $ regress --no-fork +listener/error_unlock listener/error_unlock: [warn] Error from accept() call: Too many open files [err] ../evthread.c:220: Assertion lock->count == 0 failed in ../evthread.c Aborted (core dumped) Fixes: #341 Fixes: listener/error_unlock | |
|
7d856516 | 2016-03-31 20:50:12 | test/listener: regression for missing unlock in listener_read_cb() P.S. it triggers even without pthread, but this makes checks more strict. Refs: #341 | |
|
b59ef3bd | 2016-03-29 19:20:30 | Merge remote-tracking branch 'origin/pr/339' * origin/pr/339: evbuffer_add: Use last_with_datap if set, not last. test/regress: add tests for evbuffer_add() breakage on empty last chain Fixes: #335 | |
 |
a8769ef1 | 2016-03-26 20:11:43 | evbuffer_add: Use last_with_datap if set, not last. evbuffer_add() would always put data in the last chain, even if there was available space in a previous chain, and in doing so it also failed to update last_with_datap, causing subsequent calls to other functions that do look at last_with_datap to add data in the middle of the evbuffer instead of at the end. Fixes the evbuffer_add() part of issue #335, and the evbuffer/add2 and evbuffer/add3 tests, and also prevents wasting space available in the chain pointed to by last_with_datap. | |
|
d5ee7391 | 2016-03-26 14:14:44 | test/regress: add tests for evbuffer_add() breakage on empty last chain The evbuffer/add* tests currenly break on 2.0.21, 2.0.22 and 2.1 HEAD due to issue #335. The evbuffer/reference2 test breaks on 2.0.21 and 2.0.22 due to commit b18c04dd not being applied. | |
|
bddad71e | 2016-03-25 11:22:43 | test/http: fix running some tests sequential (with --no-fork) After this patch $ regress --no-fork +http/.. Passed without failures. | |
|
cbc3209d | 2016-03-25 11:04:51 | test/http: localize evhttp server structure | |
|
24b52149 | 2016-03-25 10:21:48 | 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)) ^ ~~ | |
|
ec65c420 | 2016-03-25 00:33:47 | 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 | |
|
d7348bab | 2016-03-25 00:21:06 | test/dns: regression for empty hostname Refs: #332 | |
|
d49a6587 | 2016-03-24 20:29:25 | 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 | |
|
376f1073 | 2016-03-24 20:26:50 | test/http: add a helper for creating timedout/failed request | |
|
d02a2858 | 2016-03-24 14:11:10 | test/http: adopt for C90 (mixed code and declarations) | |
|
4db15e09 | 2016-03-24 12:49:47 | 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== | |
|
5830e331 | 2016-03-24 14:05:28 | 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 | |
|
7a4b4729 | 2016-03-24 13:38:05 | 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 | |
|
0c343afe | 2016-03-24 10:27:24 | test/http: cover NS timed out during request cancellations separatelly | |
|
f0e13411 | 2016-03-22 23:36:19 | 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. | |
|
4a53c54b | 2016-03-22 19:29:50 | 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. | |
|
86dfd2ce | 2016-03-21 17:09:17 | 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 | |
|
8cbe65d5 | 2016-03-21 17:08:34 | evdns: export cancel via callbacks in util (like async lib core/extra issues) | |
|
334340da | 2016-03-12 18:50:41 | 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 | |
|
dbff101b | 2016-03-21 16:55:59 | be_sock: evutil_getaddrinfo_async_() always return 0 | |
|
927ab33f | 2016-03-13 13:05:25 | 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. | |
|
351207f4 | 2016-03-22 23:10:19 | regress_clean_dnsserver(): reset global port vars This will fix some test chains with --no-fork. | |
|
d4054928 | 2016-03-11 20:17:51 | http: make fallback for EVHTTP_CON_READ_ON_WRITE_ERROR more cleaner | |
|
2ff164ab | 2016-03-11 19:58:05 | 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 | |
|
3b581693 | 2016-03-11 20:06:11 | 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) | |
|
7c899995 | 2016-03-11 19:52:32 | 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 | |
|
f15cbd52 | 2016-03-11 20:59:36 | 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" | |
|
8f18a626 | 2016-03-11 20:40:52 | 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") | |
|
0b46b39e | 2016-03-11 13:08:28 | 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 | |
|
5c2b4c19 | 2016-03-11 19:25:11 | test/http: separate coverage for EVHTTP_CON_READ_ON_WRITE_ERROR | |
|
31d81163 | 2016-03-11 14:23:03 | test/http: cover "Expect: 100-continue" client-server interaction | |
|
ed469abb | 2016-03-11 16:18:48 | test/http: *lingering tests shouldn't have "Expect: 100-continue" | |
|
255525dd | 2016-03-11 13:55:41 | 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). | |
|
2185e639 | 2016-03-11 14:02:13 | 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 | |
|
04fc82f7 | 2016-03-11 01:27:52 | test: use EVUTIL_SHUT_WR | |
|
0f2de104 | 2016-03-10 23:51:15 | Ignore verify_tests.bat (win32 version) | |
|
31667659 | 2016-03-10 18:40:34 | 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 | |
|
87f7238f | 2016-03-10 01:50:12 | 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 | |
|
c46ead5d | 2016-03-10 01:07:54 | cmake: require at least 3.1 for target_sources() | |
|
36588e16 | 2016-03-10 00:33:04 | 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 | |
|
f29f59e8 | 2016-03-10 00:25:09 | 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*. | |
|
060e5a2d | 2016-03-09 18:55:20 | 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 | |
|
e122ca1e | 2016-02-15 03:21:39 | test: http/lingering_close: cover EVHTTP_SERVER_LINGERING_CLOSE | |
|
f41e1b01 | 2016-02-15 03:13:02 | test: http/non_lingering_close: cover ~EVHTTP_SERVER_LINGERING_CLOSE | |
|
addf2b90 | 2016-02-15 03:46:20 | test: http/*: update expected HTTP codes for body exceeds `max_body_size` | |
|
ac448a74 | 2016-02-15 03:26:40 | 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 | |
|
d38a7239 | 2016-02-15 02:41:19 | test: http/data_length_constrains: set EVHTTP_CON_READ_ON_WRITE_ERROR | |
|
9fde5189 | 2016-02-15 00:12:54 | 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 | |
|
680742e1 | 2016-02-10 14:43:18 | 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 | |
|
0792e1e7 | 2016-02-10 12:37:30 | 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 |