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.
This is a partial backport of cb9da0bf and a backport of c9635349.
Because C doesn't like us to declare identifiers starting with an
underscore, Libevent 2.1 has renamed every such identifier. The
only change that affects a public API is that the _EVENT_LOG_*
macros have been renamed to start with EVENT_LOG instead. The old
names are still present, but deprecated.
I'm doing this backport because it represents the deprecation of a
Libevent 2.0 interface, and folks should have the opportunity to
write code that isn't deprecated and works with both 2.0 and 2.1.
When clang 2.9 was around we hoped they'd introduce support for the
normalized=id and override-init warnings by 3.0, but they haven't. We
should only add the version detection back in when clang actually
supports those warnings.
When a nameserver is down, we periodically try sending a "probe"
message to that nameserver to see if it has come back up. If a
nameserver comes up, we cancel any pending probe messages.
Cancelling a probe message while handling the probe's response would
result in a access-after-free or a double-free, so when we notice that
we're about to call a nameserver up because of having received a probe
from it, we need to check whether current response is the response
from the probe.
There was a case where we didn't to that, though: when the resolver
gave us an unusual error response to our request that it resolve
google.com. This is pretty rare, but apparently it can happen with
some weird cacheing nameservers -- the one on the mikrotik router, for
example. Without this patch, we would crash with a NULL pointer
derefernce.
Thanks to Hannes Sowa for finding this issue and helping me track it
down.
