Age | Commit message (Collapse) | Author |
|
(patch by Bernd Schmidt <bernds_cb1 at t-online.de>)
|
|
__dns_lookup(). This avoids segmentation faults when more than 1024
file descriptors are used by an application.
|
|
MontaVista noticed that when their kernels were configured to trap on unaligned
access gethostbyname_r could mysteriously crash. I tracked this down to an
unaligned buffer being passed to gethostbyname_r from some other part of uClibc
(afraid I don't remember where from any more). We have to pad the beginning of
the buffer to a pointer alignment before we store pointers in it.
|
|
IPv6 entries in /etc/hosts. Previous only the first of these host would work,
as uClibc would read the /etc/hosts file from top to bottom, failing if the
first hit did not match the IP type.
Now uClibc will continue reading, even if the first correct entry name, but wrong IP
type fails. Thus, allowing a second correct entry name with correct IP type
will result in a name resolve.
Signed-off-by: Hans-Christian Egtvedt <hcegtvedt@atmel.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
I have successfully made gethostbyname_r(), res_init(), and gethostid() fully
reentrant. In addition, I have added a NULL check to inet_aton(). This is
where SEG FAULTs were coming from when gethostbyname_r() was called.
|
|
|
|
|
|
Hi Erik,
Thanks for all your great work. I found a set of bugs in
resolv.c . Basically, there is code that looks like:
BIGLOCK;
__nameserversXX=__nameservers;
__nameserverXX=__nameserver;
BIGUNLOCK;
i = __dns_lookup(dname, type, __nameserversXX, __nameserverXX, &packet, &a);
which is a problem because the declarations are
int __nameservers;
char * __nameserver[MAX_SERVERS];
int __searchdomains;
char * __searchdomain[MAX_SEARCH];
so you can see that __nameserver is a pointer. Copying the
pointer to __nameserverXX doesn't protect the global variable
space. I have attached a patch and the new file. I hope you
will incorporate these bug fixes. I spent quite a bit of time
tracking them down.
Many thanks,
Ron
|
|
gethostbyname2_r tries to resolve an ipv6 address from /etc/hosts using
get_hosts_byname_r, but with AF_INET instead of the supplied address family.
This returns ipv4 addresses marked as ipv6 ones. Fix from nbd.
|
|
|
|
things, and avoid potential deadlocks caused when a thread holding a uClibc
internal lock get canceled and terminates without releasing the lock. This
change also provides a single place, bits/uClibc_mutex.h, for thread libraries
to modify to change all instances of internal locking.
|
|
otherwise we get messed up alias memory and this simple test case will
segfault:
python -c 'import socket; print socket.gethostbyaddr("80.68.88.204")[2];'
see bug report in blackfin tracker for more info:
http://blackfin.uclinux.org/tracker/index.php?func=detail&aid=1503&group_id=17&atid=141
|
|
defined, gettimeofday has other prototype and tm_gmtoff/tm_zone do not exist
|
|
|
|
most of global data relocations are back
|
|
|
|
|
|
gone from libc. The remaining are left as exercise for others ;-)
|
|
|
|
|
|
missing headers, other jump relocs removed
|
|
|
|
was indeed a badly chosen name
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
x_internal, do not use cascading aliases
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
addr.c also as int. Rename mylock/LOCK/UNLOCK in resolv.c to allow IMA compiling
|
|
by 'nslookup www.yahoo.com' and 'nslookup mail.hotmail.com', and thus we
currently return ERANGE when trying to lookup some of the most popular hosts on
the planet. Whether these sites deserve to be popular is a question I'll leave
for someone else to worry about.
This change makes certain we have enough static buffer space to handle about 21
IPv4 IP address replies per DNS query. Far more than enough to handle common
cases such as www.yahoo.com and mail.hotmail.com.
|
|
This fix, based on this patch
http://bugs.uclibc.org/view.php?id=104
makes it so uClibc fills out round robin dns lists for
applications such as nslookup:
Before:
$ nslookup google.com
Server: mace.codepoet.org
Address: 10.10.10.1
Name: google.com
Address: 216.239.39.99
After:
$ nslookup google.com
Server: mace.codepoet.org
Address: 10.10.10.1
Name: google.com
Addresses: 216.239.57.99, 216.239.37.99, 216.239.39.99
|
|
|
|
|
|
|