Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
For bugs related to Red Hat Enterprise Linux 5 product line. The current stable release is 5.10. For Red Hat Enterprise Linux 6 and above, please visit Red Hat JIRA https://issues.redhat.com/secure/CreateIssue!default.jspa?pid=12332745 to report new issues.

Bug 441429

Summary: gethostid fails when linked against libbind
Product: Red Hat Enterprise Linux 5 Reporter: Anthony Harris <anthony>
Component: bindAssignee: Adam Tkac <atkac>
Status: CLOSED WONTFIX QA Contact:
Severity: medium Docs Contact:
Priority: low    
Version: 5.1CC: ovasik, sghosh, sputhenp
Target Milestone: rc   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-03-30 11:48:25 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
bash shell script to reproduce fault none

Description Anthony Harris 2008-04-08 01:54:37 UTC 
Description of problem:

Linking against libbind (provided by bind-libbind-devel) causes a segmentation 
fault during a call to gethostid on 64-bit RHEL5.

The same program not linked against libbind runs successfully.

On 32-bit RHEL5, both versions run successfully.


Version-Release number of selected component (if applicable):
bind-libbind-devel-9.3.3-10.el5
gcc-4.1.2-14.el5
glibc-2.5-18.el5_1.1

How reproducible:
consistent when nscd stopped
consistent when nscd hasn't cached requested object
difficult to reproduce if nscd has cached requested object


Steps to Reproduce:

1. run attached script; passes on 32-bit arch, segfault on 64-bit arch
  
Actual results:

bind-libbind-devel-9.3.3-10.el5
gcc-4.1.2-14.el5
this will work
gcc -o /tmp/test-nolibbind /tmp/test.cpp
/tmp/test-nolibbind
Host ID is [503998053]
this will segfault on 64bit but work on 32
gcc -o /tmp/test-libbind /tmp/test.cpp
/tmp/test-libbind
./runtest.sh: line 39: 22323 Segmentation fault      /tmp/test-libbind


Expected results:

bind-libbind-devel-9.3.3-10.el5
gcc-4.1.2-14.el5
this will work
gcc -o /tmp/test-nolibbind /tmp/test.cpp
/tmp/test-nolibbind
Host ID is [503999077]
this will segfault on 64bit but work on 32
gcc -o /tmp/test-libbind /tmp/test.cpp
/tmp/test-libbind
Host ID is [503999077]


Additional info:
Comment 1 Anthony Harris 2008-04-08 01:54:37 UTC 
Created attachment 301589 [details]
bash shell script to reproduce fault
Comment 2 Jakub Jelinek 2008-04-10 11:32:25 UTC 
That's not surprising when libbind overrides many glibc symbols, a lot of them
incompatibly.  NSS modules glibc loads (gethostid queries hostname) then bind to
incompatible symbols.
Either libbind needs to use some bind specific prefix for all symbols it exports
(and tweak headers to redirect its symbols), or it simply must not be used in
any program that ever uses NSS.
Comment 3 Anthony Harris 2008-04-11 01:03:30 UTC 
Will you be following this bug up either internally or with ISC?
Also, is there any workaround you can propose?
The software must use libbind (dynamic DNS updates) and also must use nss 
(hostname resolution for database connection).

Regards,
Anthony
Comment 4 Adam Tkac 2008-04-14 09:36:42 UTC 
This is pretty bad problem. I think ISC and glibc upstreams have to negotiate
who will use that symbols and who not. I guess there is big flamewar ahead and
ISC will never modify their libbind because as far as I know glibc's libresolv
is modified ISC's libbind. Also I'm not sure about fix for rhel. It is
impossible modify library symbols because it breaks ABI compatibility. I think
best way how solve this is link software statically against libbind.a and
dynamically against other libraries.
Comment 5 Chris Wright 2008-04-14 10:29:09 UTC 
(In reply to comment #4)
> This is pretty bad problem. I think ISC and glibc upstreams have to negotiate
> who will use that symbols and who not. I guess there is big flamewar ahead and
> ISC will never modify their libbind because as far as I know glibc's libresolv
> is modified ISC's libbind. Also I'm not sure about fix for rhel. It is
> impossible modify library symbols because it breaks ABI compatibility. I think
> best way how solve this is link software statically against libbind.a and
> dynamically against other libraries.

But surely this problem is actually just a problem with the 64bit build, 
perhapse an incorrect compile flag in the rpm or something, or some other 
subtle bug. The 32bit version of the packages work fine (ie RHEL5 32bit x86 the 
same code works no problems, why is their no symbol errors their?, it is only 
the 64bit x86_64 version that doesnt)
Comment 6 Lubomir Kundrak 2008-04-21 10:49:30 UTC 
(In reply to comment #4)
> I think
> best way how solve this is link software statically against libbind.a and
> dynamically against other libraries.

That is not an option. There were security problems with libbind already in
past, and in case we would link anything statically if could cause us big trouble.
Comment 9 Adam Tkac 2010-03-30 11:48:25 UTC 
This issue will be never fixed.

Main problem is that glibc's libresolv and ISC's libbind libraries define same symbols. None of those libraries can be changed because of their long tradition and ABI stability. You cannot expect predictable behaviour when executable is linked against two libraries with same symbols. I recommend you to change your program to use only one of them (even if that means you will have to copy & paste parts of libbind library). Or you might try to use dlopen/dlsym/dlclose to get needed functions from libbind library, in my opinion it will work.