Hide Forgot
Description of problem:When a program creates multi threads to invoke getpwuid_r, getpwuid_r causes the program core dump when the program is running in a for loop for a couple of minutes. Version-Release number of selected component (if applicable): libc.so.6 How reproducible: Steps to Reproduce: 1.Compile attached program 2.run following script: while true do ./testgetpwuid > output 2>&1 if [ $? -gt 0 ] ; then break; fi done 3.After a couple of minutes, program testgetpwuid core dump and the core stack trace is following: #0 0x00aa858a in __nscd_get_map_ref () from /lib/tls/libc.so.6 #1 0x00aa6854 in nscd_getpw_r () from /lib/tls/libc.so.6 #2 0x00aa6ba7 in __nscd_getpwuid_r () from /lib/tls/libc.so.6 #3 0x00a3967a in getpwuid_r@@GLIBC_2.1.2 () from /lib/tls/libc.so.6 #4 0x08048a50 in testgetpwuid_r () #5 0x00be7341 in start_thread () from /lib/tls/libpthread.so.0 #6 0x00a776fe in clone () from /lib/tls/libc.so.6 Actual results: Expected results: Additional info:
Created attachment 148157 [details] Test program
You haven't said which exact glibc version you are using or whether the user data is provided by /etc/passwd, NIS, NIS+, LDAP or some other services. There have been several fixes in the nscd client code since RHEL4.4, can you please try: http://people.redhat.com/jakub/glibc/2.3.4-2.36.1/ if you have an older glibc than that?
Yes, the user data ia provided by /etc/passwd, NIS,... The test program can be run succesfully for a few times. The glibc version which we are using is glibc- 2.3.4-2.13.
2.3.4-2.13 is 18 month old, there have been really many bugfixes even in this area since then.
Hi Jakub, I have upgraded the glibc to the version that you have suggested. The problem appears resolved. Thanks! Which release patch we should notify our customer to use in order to solve this problem. What is your recomentation? Thanks!
Try RHEL4 U4 glibc (glibc-2.3.4-2.25), if that works, try also RHEL4 U3 glibc (glibc-2.3.4-2.19).
Hi Jakub, I just got chance to try RHEL4 U4 glibc (glibc-2.3.4-2.25) on my system, it appears that the problem still exists.
Then this will be fixed in RHEL4.5.
a fix for this issue should have been issued in rhel-4.5 (2.3.4-2.36) -> RESOLVED:CURRENTRELEASE