History log of /bionic/libc/netbsd/resolv/res_init.c
Revision Date Author Comments
b23f193dcc0fa74b5be1978f85cc1c6811493c86 21-May-2012 Geremy Condra <gcondra@google.com> Ensure that the port number and TXID are properly randomized.

This fix reads from /dev/urandom to get the required entropy.

Bug: 6535492
Change-Id: Ibc2fec3f71a67607b608ad9b767b0b6504993c1d
b6cd6816d2145682aecb64a676bd3df32185a0e2 17-Mar-2011 David 'Digit' Turner <digit@google.com> libc: Fix leak in the DNS thread-specific state.

NOTE: This is a back-port from the internal HC branch.

This patch fixes a leak that occurs when creating a new
thread-specific DNS resolver state object.

Essentially, each thread that calls gethostbyname() or getaddrinfo()
at least once will leak a small memory block. Another leak happens
anytime these functions are called after a change of the network
settings.

The leak is insignificant and hard to notice on typical programs.
However, netd tends to create one new thread for each DNS request
it processes, and quickly grows in size after a > 20 hours.

The same problem is seen in other system processes that tend to
create one thread per request too.

The leak occured becasue res_ninit() was called twice when creating
a new thread-specific DNS resolver state in _res_get_thread().

This function could not properly reset an existing thread and was
leaking a memory block.

The patch does two things:

- First, it fixes res_ninit() to prevent any leakage when resetting
the state of a given res_state instance.

- Second, it modifies the _res_get_thread() implementation to
make it more explicit, and avoid calling res_ninit() twice
in a row on first-time creation.

Fix for Bug 4089945, and Bug 4090857

Change-Id: Icde1d4d1dfb9383efdbf38d0658ba915be77942e
4661fda2e5339c39ceb3aefd184eb8be3d0ca835 17-Mar-2011 David 'Digit' Turner <digit@google.com> libc: Fix leak in the DNS thread-specific state.

This patch fixes a leak that occurs when creating a new
thread-specific DNS resolver state object.

Essentially, each thread that calls gethostbyname() or getaddrinfo()
at least once will leak a small memory block. Another leak happens
anytime these functions are called after a change of the network
settings.

The leak is insignificant and hard to notice on typical programs.
However, netd tends to create one new thread for each DNS request
it processes, and quickly grows in size after a > 20 hours.

The same problem is seen in other system processes that tend to
create one thread per request too.

The leak occured becasue res_ninit() was called twice when creating
a new thread-specific DNS resolver state in _res_get_thread().

This function could not properly reset an existing thread and was
leaking a memory block.

The patch does two things:

- First, it fixes res_ninit() to prevent any leakage when resetting
the state of a given res_state instance.

- Second, it modifies the _res_get_thread() implementation to
make it more explicit, and avoid calling res_ninit() twice
in a row on first-time creation.

Fix for Bug 4089945, and Bug 4090857

Change-Id: Ie4831a8dbe82be8f07fce5ddd1d36bf95994f836
7cc5666d94615d9249163dc7ac0f58c2614497ce 14-Oct-2010 Jim Huang <jserv@0xlab.org> resolv: make internal symbols static/hidden

Change-Id: I988b83613e6252c0cc961555e81c10f856a38b37
d378c68d74cb4fdac450650fe816c9d649c8edaf 09-Mar-2010 David 'Digit' Turner <digit@google.com> Fix spurious DNS lookups in the C library.

The problem was that the 'defdname' field of res_state structure
was not properly initialized in __res_vinit(). This field is used
to store the default domain name, which is normally build from
calling gethostname() (see line 549 of res_init.c).

Unfortunately, in the typical Android case, gethostname() returns
an error (the hostname is configured) and a random stack string is
used later to build the DNS search list (see lines 556+ in res_init.c)

For the sake of illustration, let's say the search list is set to
a random value like 'xWLK'.

The end result is that when trying to result an unknown domain name
(e.g. 'www.ptn'), the query fails then the resolver tries to make a
new query with the DNS search list path(s) appended (e.g. 'www.ptn.xWLK').

The patch simply initializes 'defdname' to an empty string to avoid
this when the net.dns.search system property is not set.

Also contains whitespace/formatting fixes
aeae1f5b6c6cf22c2854e07f11555591c5430607 09-Apr-2009 Chung-yih Wang <cywang@google.com> Add the domain search list for VPN connection.
The current solution is to read the net.dns.search property,
and expand the list during the resolve initialization. In the
future, we could implement search list per process.

Update: refine the code accordingly.

Update: remove unnecessary code.

Update: remove the unused variable.
1dc9e472e19acfe6dc7f41e429236e7eef7ceda1 04-Mar-2009 The Android Open Source Project <initial-contribution@android.com> auto import from //depot/cupcake/@135843
1767f908af327fa388b1c66883760ad851267013 04-Mar-2009 The Android Open Source Project <initial-contribution@android.com> auto import from //depot/cupcake/@135843
a27d2baa0c1a2ec70f47ea9199b1dd6762c8a349 21-Oct-2008 The Android Open Source Project <initial-contribution@android.com> Initial Contribution