Bug 684889

Summary: Using 'getgrent_r' call yields "ldap_result: Assertion `ld != ((void *)0)' failed."
Product: Red Hat Enterprise Linux 5 Reporter: Ricky Nelson <rnelson>
Component: nss_ldapAssignee: Nalin Dahyabhai <nalin>
Status: CLOSED ERRATA QA Contact: Ondrej Moriš <omoris>
Severity: urgent Docs Contact:
Priority: urgent    
Version: 5.6CC: cww, dpal, jn, jplans, omoris, prc, rfreire
Target Milestone: rcKeywords: ZStream
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: nss_ldap-253-41.el5 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-07-21 08:08:37 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On:    
Bug Blocks: 703831    
Attachments:
Description Flags
Core file which includes the stack trace in description
none
Source code of test program
none
execuatable build on top of that source code none

Description Ricky Nelson 2011-03-14 17:51:43 UTC
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.

Comment 1 Ricky Nelson 2011-03-14 17:53:05 UTC
Created attachment 484264 [details]
Core file which includes the stack trace in description

Comment 2 Ricky Nelson 2011-03-14 17:54:41 UTC
Created attachment 484265 [details]
Source code of test program

Comment 3 Ricky Nelson 2011-03-14 17:55:45 UTC
Created attachment 484267 [details]
execuatable build on top of that source code

Comment 15 Nalin Dahyabhai 2011-07-01 15:23:38 UTC
*** Bug 713340 has been marked as a duplicate of this bug. ***

Comment 16 errata-xmlrpc 2011-07-21 08:08:37 UTC
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