This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug libc/17977] New: gethostbyname_r hangs forever


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]