ares_gethostbyname() and exception safety

[htuch]

While investigating a memory leak in Envoy (spotted by https://github.com/google/oss-fuzz), a c-ares consumer, I noticed the following trace:

Direct leak of 8 byte(s) in 1 object(s) allocated from:
--
  | #0 0x4e7a78 in __interceptor___strdup _asan_rtl_
  | #1 0x279fba4 in fake_hostent /builder/home/.cache/bazel/_bazel_root/4e9824db8e7d11820cfa25090ed4ed10/external/envoy_deps_cache_b22e04bff96538ea37e715942da6315c/cares.dep.build/c-ares-cares-1_14_0/ares_gethostbyname.c:290:20
  | #2 0x279fba4 in ares_gethostbyname /builder/home/.cache/bazel/_bazel_root/4e9824db8e7d11820cfa25090ed4ed10/external/envoy_deps_cache_b22e04bff96538ea37e715942da6315c/cares.dep.build/c-ares-cares-1_14_0/ares_gethostbyname.c:98
  | #3 0x8cb8c5 in Envoy::Network::DnsResolverImpl::resolve(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, Envoy::Network::DnsLookupFamily, std::__1::function<void (std::__1::list<std::__1::shared_ptr<Envoy::Network::Address::Instance const>, std::__1::allocator<std::__1::shared_ptr<Envoy::Network::Address::Instance const> > >&&)>) /source/common/network/dns_impl.cc:196:25
  | #4 0x1530264 in Envoy::Upstream::StrictDnsClusterImpl::ResolveTarget::startResolve() /source/common/upstream/upstream_impl.cc:1138:42

what's happening is we're doing a DNS resolution on an IP address, the strdup at

c-ares/ares_gethostbyname.c

Line 290 in ad58527

hostent.h_name = ares_strdup(name);

allocates, and Envoy code is throwing an exception in the callback at

c-ares/ares_gethostbyname.c

Line 293 in ad58527

callback(arg, ARES_ENOMEM, 0, NULL);

. This then prevents the free at

c-ares/ares_gethostbyname.c

Line 304 in ad58527

ares_free((char *)(hostent.h_name));

from happening.

There are two ways to fix this:

1. Make c-ares more robust to exceptions. I'm not sure how broad the issues around c-ares, callbacks and exceptions are, hoping the maintainers of this project can shed some light here.
2. If exceptions can't happen in callbacks, force Envoy to be exception free in any c-ares callback. This is possible but might involve some rearchitecting of how we handle resolution. CC @envoyproxy/maintainers

[daviddrysdale]

I think option 2 is the way to go. c-ares is a C library and so isn't really in a position to do anything about C++ exceptions. As a result, the callbacks it invokes really need to act like C code too (e.g. by having an outer wrapper that consumes all exceptions) -- which is option 2.

[htuch]

Yeah, I think in general this is hard to do, although in this specific case it would be possible to save a pointer to the allocated string somewhere (not on the stack) that ares_destroy() could cleanup (we call this as part of exception handling in Envoy).

Anyway, totally reasonable that c-ares as a C library doesn't want to be in the business of trying to handle C++ exceptions; I have a fix Envoy-side in envoyproxy/envoy#4307, so I will close this out. Thanks.