Bug 684889 - Using 'getgrent_r' call yields "ldap_result: Assertion `ld != ((void *)0)' failed."
Summary: Using 'getgrent_r' call yields "ldap_result: Assertion `ld != ((void *)0)' fa...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: nss_ldap
Version: 5.6
Hardware: i386
OS: Linux
urgent
urgent
Target Milestone: rc
: ---
Assignee: Nalin Dahyabhai
QA Contact: Ondrej Moriš
URL:
Whiteboard:
: 713340 (view as bug list)
Depends On:
Blocks: 703831
TreeView+ depends on / blocked
 
Reported: 2011-03-14 17:51 UTC by Ricky Nelson
Modified: 2018-11-14 17:30 UTC (History)
7 users (show)

Fixed In Version: nss_ldap-253-41.el5
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-07-21 08:08:37 UTC
Target Upstream Version:


Attachments (Terms of Use)
Core file which includes the stack trace in description (6.00 MB, application/x-gzip)
2011-03-14 17:53 UTC, Ricky Nelson
no flags Details
Source code of test program (5.05 KB, text/plain)
2011-03-14 17:54 UTC, Ricky Nelson
no flags Details
execuatable build on top of that source code (20.00 KB, application/x-tar)
2011-03-14 17:55 UTC, Ricky Nelson
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2011:1030 0 normal SHIPPED_LIVE nss_ldap bug fix update 2011-07-20 15:44:10 UTC

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


Note You need to log in before you can comment on or make changes to this bug.