This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: How to test a patch in resolv/?
- From: Stan Shebs <stanshebs at google dot com>
- To: Florian Weimer <fweimer at redhat dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>
- Date: Tue, 6 Oct 2015 14:37:15 -0500
- Subject: Re: How to test a patch in resolv/?
- Authentication-results: sourceware.org; auth=none
- References: <CA+5-Q5KH4NS8V8GPX0YeQwq59UHWSn7eimmbZ=47jhJae5oqLA at mail dot gmail dot com> <56141DBB dot 7010902 at redhat dot com>
On Tue, Oct 6, 2015 at 2:15 PM, Florian Weimer <fweimer@redhat.com> wrote:
> On 10/06/2015 08:38 PM, Stan Shebs wrote:
>> Last week at Google, getaddrinfo() blew up in an attention-getting way,
>> apparently due to an innocuous internal server change triggering BZ 16754
>> (the library version we're using derives from 2.19).
>
> I think that's not the right bug number.
Oh right, I meant 16574 (Memory leak in _nss_dns_gethostbyname4_r with
big DNS answer).
>> So while there is a patch for this bug, and it even applies cleanly to our
>> version, I'm wondering how to write a test that demonstrates it's an actual
>> fix, without depending on masses of internal Google configuration. It seems
>> like one ought to be able to build a little mock DNS server, but I don't see
>> that anyone has done that to date, and maybe there is some better way
>> to do a unit test.
>
> You can use static linking to poke at library internals reliably, if
> that helps.
>
> It used to be possible to override the configured name servers by
> directly writing to the _res structure. This would make it possible to
> redirect DNS queries to a custom test server (either in another thread
> or process). I don't know if current libresolv versions still support that.
An interesting idea, I'll check it out.