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
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
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.
In case when evdns_base_free() called with @fail_requests, we can potentially
have leaks, but we can avoid them if we will run event loop once again to
trigger defer cbs, so let's do this, instead of magical decrements (and also
this will give an example how to avoid leaks for evdns).
This covers SSL_ERROR_WANT_READ/SSL_ERROR_WANT_WRITE error codes from ssl,
under which we must block read/write to avoid busy looping, and hence extra CPU
usage.
This test introduces custom BIO that will count read/write and validates
counters, with patches for be_openssl that drops handling
SSL/SSL_ERROR_WANT_READ there are more then 43K reads, so 100 is pretty ok.
Fixes:
../test/regress_bufferevent.c: In function ‘test_bufferevent_socket_filter_inactive’:
../test/regress_bufferevent.c:1180:1: warning: label ‘end’ defined but not used [-Wunused-label]
end:
Right now this will fail with the next assertion:
$ regress --no-fork --verbose bufferevent/bufferevent_socket_filter_inactive
bufferevent/bufferevent_socket_filter_inactive: [err] ../event.c:862: Assertion TAILQ_EMPTY(&base->activequeues[i]) failed in event_base_free_
Aborted
../test/regress_buffer.c:201:12: warning: logical not is only applied to the left hand side of this comparison [-Wlogical-not-parentheses]
tt_assert(!memcmp((char*)EVBUFFER_DATA(evb), "1/hello", 7) != 0);
After this test had been fixed for freebsd the debug build was broken because
we can't call evthread_set_lock_callbacks() when something already initialized,
and we can't call event_base_free() (in kqueue case) when it is initialized,
because of "held_by", but this only playing role during freeing lock profiler
so reset lock callbacks there before and this will fix both.
Fixes: 79f9ace4ae8a259a5cf1b4ff3869078b60ff16a1 ("test: fix
bufferevent/bufferevent_pair_release_lock for freebsd")
P.S. after this patch 'make verify' finishes without errors on freebsd.
On FreeBSD with kqueue there is a call to evthread_debug_lock_mark_unlocked()
during event_base_free(), that will fail with an assert because of unmatched
"held_by", fix this by reseting lock callbacks to NULL before
event_base_free().
Trace:
bufferevent/bufferevent_pair_release_lock: [warn] Trying to disable lock functions after they have been set up will probaby not work.
[warn] Trying to disable lock functions after they have been set up will probaby not work.
FAIL libevent/test/regress_bufferevent.c:259: lock: lock error[err] libevent/evthread.c:277: Assertion lock->held_by == me failed in evthread_debug_lock_mark_unlocked
[New Thread 802006400 (LWP 100070/regress)]
Program received signal SIGABRT, Aborted.
[Switching to Thread 802006400 (LWP 100070/regress)]
0x000000080167d6ca in thr_kill () from /lib/libc.so.7
(gdb) bt
#0 0x000000080167d6ca in thr_kill () from /lib/libc.so.7
#1 0x0000000801752149 in abort () from /lib/libc.so.7
#2 0x00000000004dff44 in event_exit (errcode=-559030611) at libevent/log.c:105
#3 0x00000000004e053c in event_errx (eval=-559030611, fmt=0x5182cc "%s:%d: Assertion %s failed in %s") at libevent/log.c:162
#4 0x00000000004d9954 in evthread_debug_lock_mark_unlocked (mode=0, lock=0x802017060) at libevent/evthread.c:277
#5 0x00000000004d909a in debug_lock_unlock (mode=0, lock_=0x802017060) at libevent/evthread.c:290
#6 0x00000000004e132c in evsig_dealloc_ (base=0x80201e300) at libevent/signal.c:434
#7 0x00000000004e36c1 in kq_dealloc (base=0x80201e300) at libevent/kqueue.c:435
#8 0x00000000004c9a44 in event_base_free_ (base=0x80201e300, run_finalizers=1) at libevent/event.c:855
#9 0x00000000004c931a in event_base_free (base=0x0) at libevent/event.c:887
#10 0x0000000000452657 in lock_unlock_free_thread_cbs () at libevent/test/regress_bufferevent.c:279
#11 0x0000000000452621 in free_lock_unlock_profiler (data=0x8020170a0) at libevent/test/regress_bufferevent.c:317
#12 0x000000000044bc8f in test_bufferevent_pair_release_lock (arg=0x8020170a0) at libevent/test/regress_bufferevent.c:334
#13 0x00000000004b2288 in testcase_run_bare_ (testcase=0x737660) at libevent/test/tinytest.c:105
#14 0x00000000004b1e72 in testcase_run_one (group=0x738c90, testcase=0x737660) at libevent/test/tinytest.c:252
#15 0x00000000004b2930 in tinytest_main (c=3, v=0x7fffffffead0, groups=0x738c20) at libevent/test/tinytest.c:434
#16 0x00000000004982fe in main (argc=3, argv=0x7fffffffead0) at libevent/test/regress_main.c:459
(gdb) f 4
#4 0x00000000004d9954 in evthread_debug_lock_mark_unlocked (mode=0, lock=0x802017060) at libevent/evthread.c:277
277 EVUTIL_ASSERT(lock->held_by == me);
Current language: auto; currently minimal
(gdb) p lock
$1 = (struct debug_lock *) 0x802017060
(gdb) p lock->held_by
$2 = 0
(gdb) p me
$3 = 34393318400
It must enter the event loop regardless BEV_OPT_DEFER_CALLBACKS, to avoid
potential errors with subsequent connect(), you will find more info in #43,
since this is a regression for it.
This is the regression for evhttp_write_buffer() where we reset readcb to avoid
illegal state:
http/write_during_read: [err] evhttp_read_cb: illegal connection state 7
If you will comment that this test will fail.
Before this patch you will see next error:
$ EVENT_DEBUG_MODE= regress --no-fork bufferevent/bufferevent_pair_release_lock
bufferevent/bufferevent_pair_release_lock: [err] evthread initialization must be called BEFORE anything else!
In this case client can't connect to server, and this bring to the front some
bugs with assigning on already added events (because of ```fd_is_set``` stuff),
for more info see #258, since this is the reproducible for it.
