Red Hat Bugzilla – Bug 441429
gethostid fails when linked against libbind
Last modified: 2013-04-30 19:39:35 EDT
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:
Created attachment 301589 [details] bash shell script to reproduce fault
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.
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
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.
(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)
(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.
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.