This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug libc/17977] New: gethostbyname_r hangs forever
- From: "eric.newton at gmail dot com" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Fri, 13 Feb 2015 20:51:55 +0000
- Subject: [Bug libc/17977] New: gethostbyname_r hangs forever
- Auto-submitted: auto-generated
https://sourceware.org/bugzilla/show_bug.cgi?id=17977
Bug ID: 17977
Summary: gethostbyname_r hangs forever
Product: glibc
Version: unspecified
Status: NEW
Severity: normal
Priority: P2
Component: libc
Assignee: unassigned at sourceware dot org
Reporter: eric.newton at gmail dot com
CC: drepper.fsp at gmail dot com
Created attachment 8126
--> https://sourceware.org/bugzilla/attachment.cgi?id=8126&action=edit
proposed patch for the bug
A large (java) multi-threaded server process was found to be hanging on calls
to gethostbyname_r.
It was further determined that it only hung when /etc/hosts.conf contained
"reorder on".
Inspecting the source for _res_hconf_reorder_addrs, it is straightforward to
see the bug.
Assume there are 3 threads executing the function at the same time. All see
num_ifs is -1 at line 407, and attempt to get the lock on line 422.
One thread gets the lock at line 422, initializes the static data structure,
and unlocks the lock.
The next thread gets the lock. It double-checks the value of num_ifs at line
425. Seeing that it is now >0, it skips the initialization.
But this thread does not unlock the lock.
The last thread hangs on the lock forever.
--
You are receiving this mail because:
You are on the CC list for the bug.