Bug 441429 - gethostid fails when linked against libbind
Summary: gethostid fails when linked against libbind
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: bind
Version: 5.1
Hardware: x86_64
OS: Linux
low
medium
Target Milestone: rc
: ---
Assignee: Adam Tkac
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-04-08 01:54 UTC by Anthony Harris
Modified: 2013-04-30 23:39 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-03-30 11:48:25 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
bash shell script to reproduce fault (785 bytes, text/plain)
2008-04-08 01:54 UTC, Anthony Harris
no flags Details

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.


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