Hide Forgot
Description of problem: After upgrading from RHEL 5.5 to RHEL 5.6, unable to run test program attached without an ldap assertion failed error. It seems that this is possibly due to a structure (__session.ls_conn) within nss_ldap not being truly reentrant. Version-Release number of selected component (if applicable): nss_ldap-253-37.el5.i386 How reproducible: Compile and run the test program provided. It errors out with an ldap assertion failed. This is only when 'getgrent_r' is used to query the ldap server for group info. If this is taken out of the program, there is no ldap assertion error. Steps to Reproduce: 1. Compile and run the test program provided 2. 3. Actual results: There is an ldap assertion error: ldap_result: Assertion `ld != ((void *)0)' failed. Expected results: No error should occur. Additional info: This program does not error out under RHEL 5.5. It errors out under RHEL 5.6. Also attached is a core where if you look at the stack trace, it looks as though the ldap structure '__session.ls_conn' is null which causes the error to occur. Here's the stack trace: #0 0x004ba402 in __kernel_vsyscall () No symbol table info available. #1 0x00220df0 in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 resultvar = <value optimized out> pid = 3461108 selftid = 14013 #2 0x00222701 in abort () at abort.c:88 act = {__sigaction_handler = {sa_handler = 0x4d5f434c, sa_sigaction = 0x4d5f434c}, sa_mask = { __val = {3461108, 3465536, 165581152, 2526058144, 2506679, 165581152, 165581252, 2526058392, 3461108, 106, 165581152, 2526058348, 2458253, 165583488, 165583488, 105, 165581152, 0, 105, 4222451712, 165583488, 2494470, 165583488, 165583488, 165583593, 165583788, 165583488, 165583788, 0, 0, 0, 0}}, sa_flags = 0, sa_restorer = 0x34e140 <main_arena>} sigs = {__val = {32, 0 <repeats 31 times>}} #3 0x0021a26b in __assert_fail (assertion=0xcc79a7 "ld != ((void *)0)", file=0xcc7af0 "../../../libraries/libldap/result.c", line=113, function=0xcc7ad7 "ldap_result") at assert.c:78 buf = 0x9de7810 "x\232\336\tp\341\064" errstr = "Unexpected error.\n" #4 0x00a83109 in ldap_result () from /lib/libnss_ldap.so.2 No symbol table info available. #5 0x00a742f0 in do_result (ctx=0x9dd5368, all=0) at ldap-nss.c:2485 rc = 52 stat = 1750 tv = {tv_sec = 60, tv_usec = 0} tvp = 0x96909900 #6 0x00a7453a in do_parse (ctx=0x9dd5368, result=0x9690f304, buffer=0x9690e300 "577", buflen=4096, errnop=0x9690fb5c, parser=0xa778f0 <_nss_ldap_parse_gr>) at ldap-nss.c:2872 resultStat = <value optimized out> parseStat = 1750 #7 0x00a75a73 in _nss_ldap_getent_ex (args=0x0, ctx=0xd660f8, result=0x9690f304, buffer=0x9690e300 "577", buflen=4096, errnop=0x9690fb5c, filterprot=0xd6d8c0 "(&(objectClass=posixGroup))", sel=LM_GROUP, user_attrs=0x0, parser=0xa778f0 <_nss_ldap_parse_gr>) at ldap-nss.c:3445 stat = NSS_STATUS_SUCCESS #8 0x00a76434 in _nss_ldap_getent (ctx=0xd660f8, result=0x9690f304, buffer=0x9690e300 "577", buflen=4096, errnop=0x9690fb5c, filterprot=0xd6d8c0 "(&(objectClass=posixGroup))", sel=LM_GROUP, parser=0xa778f0 <_nss_ldap_parse_gr>) at ldap-nss.c:3389 status = <value optimized out> #9 0x00a76e50 in _nss_ldap_getgrent_r (result=0x9690f304, buffer=0x9690e300 "577", buflen=6, errnop=0x36bd) at ldap-grp.c:1265 No locals. #10 0x002dc08e in __nss_getent_r (getent_func_name=0x31f125 "getgrent_r", setent_func_name=0x31f130 "setgrent", lookup_fct=0x2dcc80 <__nss_group_lookup2>, nip=0x34e94c, startp=0x34e954, last_nip=0x34e950, stayopen_tmp=0x0, res=0, resbuf=0x9690f304, buffer=0x9690e300 "577", buflen=4096, result=0x9690f300, h_errnop=0x0) at getnssent_r.c:164 fct = {f = 0xa76df0 <_nss_ldap_getgrent_r>, ptr = 0xa76df0} no_more = <value optimized out> status = 3467604 #11 0x0028783d in __getgrent_r (resbuf=0x9690f304, buffer=0x9690e300 "577", buflen=4096, result=0x9690f300) at ../nss/getXXent_r.c:162 status = <value optimized out> save = 14013 #12 0x08048a6b in Login (szUsr=0xbfd1d7d4 "gssvc") at testgetpw_r.c:107 pwd = {pw_name = 0x9c58b30 "gssvc", pw_passwd = 0x9c58b36 "x", pw_uid = 500, pw_gid = 500, pw_gecos = 0x9c58b40 "", pw_dir = 0x9c58b41 "/home/gssvc", pw_shell = 0x9c58b4d "/bin/bash"} result = 0x9690f374 buf1 = {st_dev = 0, __pad1 = 0, st_ino = 0, st_mode = 0, st_nlink = 0, st_uid = 0, st_gid = 0, st_rdev = 0, __pad2 = 0, st_size = 0, st_blksize = 0, st_blocks = 0, st_atim = {tv_sec = 0, tv_nsec = 0}, st_mtim = {tv_sec = 0, tv_nsec = 0}, st_ctim = {tv_sec = 0, tv_nsec = 0}, __unused4 = 0, __unused5 = 0} buf = 0x9c58b30 "gssvc" bufsize = 1024 szyes = "" s = 0 szPwd = 0x8048d2f "harvest" szusr = 0xbfd1d7d4 "gssvc" m_lUid = 500 m_lGid = 500 i = 1 grp = {gr_name = 0x9690e304 "gpolo", gr_passwd = 0x9690e30a "*", gr_gid = 577, gr_mem = 0x9690e30c} groupInfo = 0x0 grpp = 0x9690f304 userNameCursor = 0 grpBuf = "577\000gpolo\000*\000\000\000\000\000\000\000\000\000mon\000\b㐖\r㐖\021㐖\000\000\000\000ith\000smwilse\000mspradley\000chushour\000jmulhern\000lmalec\000jxwhitney\000\000\000\000\025㐖\035㐖$㐖,㐖4㐖>㐖G㐖P㐖W㐖", '\000' <repeats 3959 times>"\377, " j = 0 grpid = 0 grpi = 0 m_lSuppGids = 0 m_suppGids = {0 <repeats 4096 times>} #13 0x003c1832 in start_thread (arg=0x9690fb90) at pthread_create.c:301 __res = <value optimized out> __ignore1 = <value optimized out> __ignore2 = <value optimized out> pd = 0x9690fb90 now = <value optimized out> unwind_buf = {cancel_jmp_buf = {{jmp_buf = {4005876, 0, 4001536, -1768885064, 266744414, -1723148735}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = { prev = 0x0, cleanup = 0x0, canceltype = 0}}} not_first_call = 0 robust = <value optimized out> #14 0x002ca0ae in clone () from /lib/libc.so.6 ======== From frame #4 (right before the assertion failed) ldap_result: int ldap_result( LDAP *ld, int msgid, int all, struct timeval *timeout, LDAPMessage **result ) { LDAPMessage *lm; int rc; assert( ld != NULL ); <-------------- HERE assert( result != NULL ); Debug( LDAP_DEBUG_TRACE, "ldap_result ld %p msgid %d\n", (void *)ld, msgid, 0 ); And that gets called from here: 2485 rc = 2486 ldap_result (__session.ls_conn, ctx->ec_msgid, all, tvp, 2487 &ctx->ec_res); Is the __session.ls_conn structure actually reentrant? There's not any locking around access to it.
Created attachment 484264 [details] Core file which includes the stack trace in description
Created attachment 484265 [details] Source code of test program
Created attachment 484267 [details] execuatable build on top of that source code
*** Bug 713340 has been marked as a duplicate of this bug. ***
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2011-1030.html