If an evdns_getaddrinfo timeout happens while pending_cb is set, and
a callback is about to run, but we get a call to
evdns_getaddrinfo_gotresolve before it finishes.
Github issue #60. Thanks to Greg Hazel for patch and patience.
If we ran out of memory in evhttp_uriencode when allocating the
output buffer, we would neglect to call evbuffer_free() on our
temporary buffer. Now we always free the temporary buffer.
Fixes sourceforge issue 3539887. Thanks to Andrew Cox for reporting
this one.
(Tweaked by nickm: Fix up the arcr4andom_buf OSX hack so that the
fallback case isn't compiled into the code when we have
arc4random_buf() and we are not on OSX. Also add a comment
explaining what's up.)
Otherwise, requests initially sent to a failing nameserver would
stay there indefinitely, even if other nameservers would work.
Fix for sourceforge bug 3518439
the function do_read() will call SSL_read(), and if successful, will
call _bufferevent_run_readcb() before returning to consider_reading().
consider_reading() will then check SSL_pending() to make sure all
pending data has also been read. If it does not, do_read() is called
again.
The issue with this is the possibility that the function that is
executed by _bufferevent_run_readcb() called
bufferevent_disable(ssl_bev, EV_READ) before the second do_read(); In
this case, the users read callback is executed a second time. This is
potentially bad for applications that expect the bufferevent to stay
disabled until further notice. (this is why running openssl bufferevents
without DEFER_CALLBACKS has always been troublesome).
This approach should make the creation of the file more atomic, to
fix a bug reported by Dinh.
This patch has one change from Zack's original version: it avoids
$<, since Dave Hart tells me he thinks that's not so portable.
(commit message by nickm)
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.
