From [1]:
regress_buffer.c:742:3: error: ‘for’ loop initial declarations are only allowed in C99 mode
for (int i = 0; i < 1 << 16; ++i) {
^
regress_buffer.c:742:3: note: use option -std=c99 or -std=gnu99 to compile your code
regress_buffer.c:787:23: error: conflicting types for ‘bufread’
for (int n = toread, bufread = toread;
^
regress_buffer.c:717:51: note: previous definition of ‘bufread’ was here
size_t datalen = strlen(data), toread = datalen, bufread = 0;
^
regress_buffer.c:787:2: error: ‘for’ loop initial declarations are only allowed in C99 mode
for (int n = toread, bufread = toread;
^
[1]: https://travis-ci.org/azat/libevent/jobs/445501665
[ Upstream commit 6ac8e775 ]
[ Fixes: #262 ]
Between start (setting "started_at") and comparing the time when
timeouts triggered with the start (test_timeval_diff_eq), there is too
much various things that can introduce extra delays and eventually could
fail the test on machine with shortage of CPU.
And this is exactly what happend on:
- travis-ci
- #262
Here is a simple reproducer that I came up with for this issue:
docker run --cpus=0.01 -e LD_LIBRARY_PATH=$PWD/lib -e PATH=/usr/bin:/bin:$PWD/bin -v $PWD:$PWD --rm -it debian:testing regress --no-fork --verbose bufferevent/bufferevent_timeout
Under limited CPU (see reproducer) the test almost always has problems
with that "write_timeout_at" exceed default timeval diff tolerance
(test_timeval_diff_eq() has 50 tolerance), i.e.:
FAIL ../test/regress_bufferevent.c:1040: assert(labs(timeval_msec_diff(((&started_at)), ((&res1.write_timeout_at))) - (100)) <= 50): 101 vs 50
But under some setup write timeout can even not triggered, and the
reason for this is that we write to the bufferevent 1024*1024 bytes, and
hence if evbuffer_write_iovec() will has some delay after writev() and
not send more then one vector at a time [1], it is pretty simple to
trigger, i.e.:
FAIL ../test/regress_bufferevent.c:1040: assert(labs(timeval_msec_diff(((&started_at)), ((&res1.write_timeout_at))) - (100)) <= 50): 1540155888478 vs 50
[1]: https://gist.github.com/azat/b72773dfe7549fed865d439e03de05c1
So this patch just send static small payload for all cases (plus a few
more asserts added).
The outcome of this patch is that all regression tests passed on
travis-ci for linux box [2]. While before it fails almost always [3].
Also reproducer with CPU limiting via docker also survive some
iterations (and strictly speaking it should has less CPU then travis-ci
workers I guess).
[2]: https://travis-ci.org/azat/libevent/builds/444391481
[3]: https://travis-ci.org/libevent/libevent/builds/444336505
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.
Written for commit 71e709c7829275a594f767b27468b1b52e8b5bb9.
Fix ipv6 support for http. When URL contain domain, not IP address.
backporting to 2.0: fix conflicts with the name of the main function --
_http_connection_test().
There's a bug in openssl 1.0.1 where TLS1.1 and TLS1.2 can't
renegotiate with themselves. When testing renegotiation with OpenSSL
>=1.0.1 and <1.0.1d, disable those protocols.
Fixes an issue reported on libevent-users in the thread "a dead
looping bug when changing system time backward". Previously, if time
jumped forward 1 hour[*] and we had a one-second periodic timer event,
that event would get invoked 3600 times. That's almost certainly not
what anybody wants.
In a future version of Libevent, we should expose the amount of time
that the callbac kwould have been invoked somehow.
[*] Forward time jumps can happen with nonmonotonic clocks, or with
clocks that jump on suspend/resume. It can also happen from
Libevent's point of view if the user exits from event_base_loop() and
doesn't call it again for a while.
As originally written, the test would only pass if the accept()
callbacks for the evconnlistener were all invoked before the last of
the CONNECTED/ERROR callbacks for the connecting/resolving bufferevent
had its call to event_base_loopexit() complete. But this was only
accidentally true in 2.0, and might not be true at all in 2.1 where
we schedule event_base_once() callbacks more aggressively.
Found by Sebastian Hahn.
