Bug 122730 - Problem with reentrant getservbyname_r() calls in threaded programs
Problem with reentrant getservbyname_r() calls in threaded programs
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: glibc (Show other bugs)
3.0
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-05-07 11:24 EDT by Nils Philippsen
Modified: 2007-11-30 17:07 EST (History)
2 users (show)

See Also:
Fixed In Version: 2.3.2-95.27
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-09-25 17:28:02 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Test program (4.30 KB, text/plain)
2004-05-07 11:27 EDT, Nils Philippsen
no flags Details
Different test program which shows the problem on FC2 as well (10.00 KB, application/octet-stream)
2004-07-29 05:23 EDT, Nils Philippsen
no flags Details

  None (edit)
Description Nils Philippsen 2004-05-07 11:24:15 EDT
Description of problem:

Threaded program crashes with multiple concurrent getservbyname_r()
calls on NIS boxes.

Version-Release number of selected component (if applicable):

glibc-2.3.2-95.6

How reproducible:

Easy

Steps to Reproduce:
1. Build test program (will attach shortly)
2. Execute test program
  
Actual results:

Program crashes

Expected results:

Threads each call getservbyname_r() consecutively for a number of
times, then after 30 seconds the program exits.

Additional info:

I could only reproduce this on RHEL3 when bound to a NIS domain,
RHEL2.1 and FC2 don't show this behaviour.
Comment 1 Nils Philippsen 2004-05-07 11:27:17 EDT
Created attachment 100080 [details]
Test program

Test program, compile with:

gcc -o main main.c -lpthread

run with:

./main

The program opens a number of threads which each consecutively call
getservbyname_r() for a nonexisting service "gurus" (just an example) a number
of times (200 in the attached test program).
Comment 2 Jakub Jelinek 2004-05-07 17:06:36 EDT
Are you able to reproduce this with glibc-2.3.2-95.20
(U2 glibc)?
There have been a bunch of fixes in exactly this part of the NIS
client code.
Comment 3 Nils Philippsen 2004-05-10 10:31:46 EDT
Yes, I got the SIGSEGV with 2.3.2-95.20 as well.
Comment 4 Jakub Jelinek 2004-05-25 09:03:34 EDT
http://sources.redhat.com/ml/libc-hacker/2004-05/msg00038.html
Wonder why you haven't seen it on FC2, wasn't it UP and a bit of sheer
luck?
Comment 5 Nils Philippsen 2004-07-29 05:23:34 EDT
Created attachment 102278 [details]
Different test program which shows the problem on FC2 as well

Another test program which shows the problem on FC2 as well, courtesy of
Fabrizio Muscarella, refined by me. Simply untar and make. Builds
nis_tst_getservbyname_r and nis_tst_getaddrinfo which use getservbyname_r() or
getaddrinfo() respectively.
Comment 6 Jakub Jelinek 2004-07-29 14:14:15 EDT
Can you reproduce it with glibc-2.3.3-31 or later though (rawhide/FC3t1)?
Comment 7 Ulrich Drepper 2004-08-26 02:38:01 EDT
Ping!?  I cannot reproduce any problem with glibc-2.3.3-45.i686.

The program prints
Oops... (Servname not supported for ai_socktype)
Comment 8 Nils Philippsen 2004-08-26 02:55:31 EDT
Oops indeed, will check when I have access to an FC3 box later in the day.
Comment 9 Fabrizio Muscarella 2004-08-26 04:30:35 EDT
Hi,

the output 'Oops...' is printed only by the second test program if you
compile it without USE_GETSERVBYNAME_R (bacause i forgot to check the
return value of getservbyname_r , mmmmm ;-( ). In this case will be
interesting to known if getservbyname_r is working too. 
Comment 10 Ulrich Drepper 2004-09-25 17:28:02 EDT
I see no failures with a current glibc version in neither versions of
the program in the second patch.  I mark the bug as fixed.  If you
still see failures, please reopen with appropriate instructions to
reproduce.

Note You need to log in before you can comment on or make changes to this bug.