Description of problem: Firefox will crash when calling gethostbyname. Version-Release number of selected component (if applicable): Fedora 10 How reproducible: Every Time Steps to Reproduce: 1. You have to setup a network which has nis running on it. 2. You have to assign a hostname to your web server which you have so that the name will resolve both via nis and dns. (i.e. have it in your yp server /etc/hosts file and registered with whom ever you bought the hostname from) 3. Have a web server running on this host 4. Then surf to the host and watch firefox crash. There is a work around. In nsswitch.conf, reverse the order of nis and dns for the host lookup as in hosts: files dns nis Then gethostbyname will look in dns first, find it there, and not ask for it from the nis server (aka ypserver). If it asks for it form the nis server, crashola! Actual results: Expected results: Firefox should not crash Additional info: There is clearly something odd, and the firefox crashing is the worst of it. But in general, hostname lookups are very slow. About 20% of the time, firefox will come back with a "lookup failed, check your dns" error messages with a retry button right under it. Clicking on the retry button will then get me to the web page. Something is funky with nis....
Here's another example, ssh bombed on me. One thing to note, the yp server is running rhel5. [root@basement00 ~]# rpm -qa | grep -i ypserv ypserv-2.19-3 what follows is the output of my ssh command.... [adler@office01 ~]$ ssh ssh-box *** glibc detected *** ssh: munmap_chunk(): invalid pointer: 0x00007fbee821ba8e *** ======= Backtrace: ========= /lib64/libc.so.6[0x1a86e98] /lib64/libnss_nis.so.2(_nss_nis_gethostbyname4_r+0x1b6)[0x302c836] /lib64/libc.so.6[0x1adc4d6] /lib64/libc.so.6(getaddrinfo+0x1cd)[0x1ade19d] ssh[0x7fbee7eae957] ssh(main+0xefd)[0x7fbee7ea4d5d] /lib64/libc.so.6(__libc_start_main+0xe6)[0x1a2d546] ssh[0x7fbee7ea3819] ======= Memory map: ======== 00110000-00130000 r-xp 00000000 09:00 12210554 /lib64/ld-2.9.so 0032f000-00330000 r--p 0001f000 09:00 12210554 /lib64/ld-2.9.so 00330000-00331000 rw-p 00020000 09:00 12210554 /lib64/ld-2.9.so 00331000-00471000 r-xp 00000000 09:00 12210729 /lib64/libcrypto.so.0.9.8g 00471000-00670000 ---p 00140000 09:00 12210729 /lib64/libcrypto.so.0.9.8g 00670000-00691000 rw-p 0013f000 09:00 12210729 /lib64/libcrypto.so.0.9.8g 00691000-00694000 rw-p 00691000 00:00 0 00694000-00696000 r-xp 00000000 09:00 12210588 /lib64/libutil-2.9.so 00696000-00895000 ---p 00002000 09:00 12210588 /lib64/libutil-2.9.so 00895000-00896000 r--p 00001000 09:00 12210588 /lib64/libutil-2.9.so 00896000-00897000 rw-p 00002000 09:00 12210588 /lib64/libutil-2.9.so 00897000-008ac000 r-xp 00000000 09:00 12210574 /lib64/libz.so.1.2.3 008ac000-00aab000 ---p 00015000 09:00 12210574 /lib64/libz.so.1.2.3 00aab000-00aac000 rw-p 00014000 09:00 12210574 /lib64/libz.so.1.2.3 00aac000-00ac2000 r-xp 00000000 09:00 12210558 /lib64/libnsl-2.9.so 00ac2000-00cc2000 ---p 00016000 09:00 12210558 /lib64/libnsl-2.9.so 00cc2000-00cc3000 r--p 00016000 09:00 12210558 /lib64/libnsl-2.9.so 00cc3000-00cc4000 rw-p 00017000 09:00 12210558 /lib64/libnsl-2.9.so 00cc4000-00cc6000 rw-p 00cc4000 00:00 0 00cc6000-00ccf000 r-xp 00000000 09:00 12210725 /lib64/libcrypt-2.9.so 00ccf000-00ece000 ---p 00009000 09:00 12210725 /lib64/libcrypt-2.9.so 00ece000-00ecf000 r--p 00008000 09:00 12210725 /lib64/libcrypt-2.9.so 00ecf000-00ed0000 rw-p 00009000 09:00 12210725 /lib64/libcrypt-2.9.so 00ed0000-00efe000 rw-p 00ed0000 00:00 0 00efe000-00f12000 r-xp 00000000 09:00 12210564 /lib64/libresolv-2.9.so 00f12000-01112000 ---p 00014000 09:00 12210564 /lib64/libresolv-2.9.so 01112000-01113000 r--p 00014000 09:00 12210564 /lib64/libresolv-2.9.so 01113000-01114000 rw-p 00015000 09:00 12210564 /lib64/libresolv-2.9.so 01114000-01116000 rw-p 01114000 00:00 0 01116000-01144000 r-xp 00000000 09:00 2426757 /usr/lib64/libgssapi_krb5.so.2.2 01144000-01343000 ---p 0002e000 09:00 2426757 /usr/lib64/libgssapi_krb5.so.2.2 01343000-01345000 rw-p 0002d000 09:00 2426757 /usr/lib64/libgssapi_krb5.so.2.2 01345000-013e3000 r-xp 00000000 09:00 2426756 /usr/lib64/libkrb5.so.3.3 013e3000-015e3000 ---p 0009e000 09:00 2426756 /usr/lib64/libkrb5.so.3.3 015e3000-015e7000 rw-p 0009e000 09:00 2426756 /usr/lib64/libkrb5.so.3.3 015e7000-0160b000 r-xp 00000000 09:00 2426755 /usr/lib64/libk5crypto.so.3.1 0160b000-0180a000 ---p 00024000 09:00 2426755 /usr/lib64/libk5crypto.so.3.1 0180a000-0180c000 rw-p 00023000 09:00 2426755 /usr/lib64/libk5crypto.so.3.1 0180c000-0180f000 r-xp 00000000 09:00 12210702 /lib64/libcom_err.so.2.1 0180f000-01a0e000 ---p 00003000 09:00 12210702 /lib64/libcom_err.so.2.1 01a0e000-01a0f000 rw-p 000020Aborted [adler@office01 ~]$ ssh ssh-box
I've done some more investigation on this problem and have found out the following. If I have multiple aliases in my /etc/hosts file on the yp master, then the gethostbyname causes application to bomb. In otherwords the following entry causes the client application to bomb /etc/hosts entry on yp(nis) master.... 123.123.123.123 some.ip.name.com ipname1 ipname2 the following command will bomb on the client (my workstation running fedora 10) ssh ipname1 if I change the some.ip.name.com entry in /etc/hosts on the yp master to this 123.123.123.123 some.ip.name.com ipname1 then the command executed on the client (again, my workstation running fedora 10) ssh ipname1 works fine.... The nis server is running redhat 5.2.
I see that this bug has been assigned. The recent release of glibc 2.9-3 did not fix this. Also, my system is an x86_64. Good luck!
2.9-3 should fix this. I cannot reproduce any problem with this version and I've fixed for 2.9-3 bugs in the NIS host alias handling. You should make sure you really test the right version and don't have any old code in use. If the problem persists you'll have to install the debuginfo package and show a complete backtrace and show the setup you use.
This message is a reminder that Fedora 10 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 10. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '10'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 10's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 10 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 10 changed to end-of-life (EOL) status on 2009-12-17. Fedora 10 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.