- openldap-bugs - openldap.org

Re: (ITS#5572) Append global ACL to new backends
by hyc＠symas.com 20 Jun '08

20 Jun '08

rein(a)OpenLDAP.org wrote: > The global ACLs are not added to newly created backends, i.e a server restart > must be done before they are included. The patch at the end should fix this. OK > to commit Howard? My preference here would be to rip out everything that appends the global ACLs and instead change the access_allowed checker to reference the global ACLs directly when needed. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#5572) Append global ACL to new backends
by rein＠OpenLDAP.org 20 Jun '08

20 Jun '08

Full_Name: Rein Tollevik Version: CVS head OS: linux and solaris URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.93.160.250) Submitted by: rein The global ACLs are not added to newly created backends, i.e a server restart must be done before they are included. The patch at the end should fix this. OK to commit Howard? Rein Tollevik Basefarm AS diff -u -r1.335 bconfig.c --- servers/slapd/bconfig.c 16 Jun 2008 12:45:30 -0000 1.335 +++ servers/slapd/bconfig.c 20 Jun 2008 16:51:03 -0000 @@ -4351,6 +4355,9 @@ /* Newly added databases and overlays need to be started up */ if ( CONFIG_ONLINE_ADD( ca )) { if ( colst[0]->co_type == Cft_Database ) { + /* append global access controls */ + acl_append( &ca->be->be_acl, frontendDB->be_acl, -1 ); + rc = backend_startup_one( ca->be, &ca->reply ); } else if ( colst[0]->co_type == Cft_Overlay ) {

1 0

(ITS#5571) Don't renumber the config database
by rein＠OpenLDAP.org 20 Jun '08

20 Jun '08

Full_Name: Rein Tollevik Version: CVS head OS: linux and solaris URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.93.160.250) Submitted by: rein Dynamically adding databases that requires renumbering of the existing olcDatabase values could also renumber the config database. But the code expects that to always be index 0, and slapd fails to start again. The "prod" server from test053-syncprov-glue shows a case where this would happen. The patch at the end prevents config_renumber_one() from renumbering the config database. Howard, is this OK? Rein Tollevik Basefarm AS diff -u -r1.335 bconfig.c --- servers/slapd/bconfig.c 16 Jun 2008 12:45:30 -0000 1.335 +++ servers/slapd/bconfig.c 20 Jun 2008 14:39:41 -0000 @@ -3762,6 +3762,10 @@ char ibuf[32], *ptr1, *ptr2 = NULL; int rc = 0; + if ( !strncmp( e->e_nname.bv_val, "olcDatabase={0}config,", + STRLENOF("olcDatabase={0}config,") )) + return 0; + rc = config_rename_attr( rs, e, &rdn, &a ); if ( rc ) return rc;

1 0

(ITS#5570) Error while using MirrorMode Replication
by shravan.rathore＠polaris.co.in 20 Jun '08

20 Jun '08

Full_Name: Shravan R Version: 2.3.39 OS: Linux 2.4.9 URL: Submission from: (NULL) (202.168.89.5) Hi, I am trying the MirrorMode Replication using syncrepl on 2 Linux machines. I followed the below configuration, but found an error. # Global section serverID 1 # database section # syncrepl directives syncrepl rid=001 provider=ldap://ldap-ridr1.example.com bindmethod=simple binddn="cn=mirrormode,dc=example,dc=com" credentials=mirrormode searchbase="dc=example,dc=com" schemachecking=on type=refreshAndPersist retry="60 +" syncrepl rid=002 provider=ldap://ldap-rid2.example.com bindmethod=simple binddn="cn=mirrormode,dc=example,dc=com" credentials=mirrormode searchbase="dc=example,dc=com" schemachecking=on type=refreshAndPersist retry="60 +" mirrormode on The error is as follows: Config: ** successfully added syncrepl "ldap://ldap-ridr1.example.com" line 105 (syncrepl ***) /usr/local/etc/openldap/slapd.conf: line 105: syncrepl: database already shadowed. /usr/local/etc/openldap/slapd.conf: line 105: <syncrepl> handler exited with 1! This error occurs when it reads the 2nd occurance of syncrepl at retry="60 +" Please let me know, what went wrong in the configuration resulting in this error. Also, there is a warning for serverID, while reading the config file. Is this fine? reading config file /usr/local/etc/openldap/slapd.conf line 2 (serverID 1) /usr/local/etc/openldap/slapd.conf: line 2: unknown directive <serverID> outside backend info and database definitions (ignored). Thanks... Shravan R

1 0

(ITS#5569) smbk5pwd breaks ppolicy-mandated password changes
by bgmilne＠staff.telkomsa.net 20 Jun '08

20 Jun '08

Full_Name: Buchan Milne Version: 2.3.41 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (196.207.32.38) When both the smbk5pwd and ppolicy overlays are loaded, and an entry is in a state that requires a password change (I tested with 'pwdReset: TRUE' on the entry), the entry cannot change its password via an LDAP password change extended operation: $ ldapsearch -H ldapi:// -LLL -x "(uid=bgmilne)" pwdReset pwdPolicySubEntry dn: uid=bgmilne,ou=People,dc=ranger,dc=dnsalias,dc=com pwdPolicySubentry: cn=default,ou=Password Policies,dc=ranger,dc=dnsalias,dc=co m pwdReset: TRUE $ ldapsearch -H ldapi:// -LLL -x -s base -b 'cn=default,ou=Password Policies,dc=ranger,dc=dnsalias,dc=com' @pwdPolicy dn: cn=default,ou=Password Policies,dc=ranger,dc=dnsalias,dc=com objectClass: pwdPolicy objectClass: namedObject pwdAttribute: userPassword pwdLockout: TRUE pwdMustChange: TRUE $ ldappasswd -H ldapi:// -x -D uid=bgmilne,ou=People,dc=ranger,dc=dnsalias,dc=com -W -S New password: Re-enter new password: Enter LDAP Password: Result: Insufficient access (50) Additional info: Operations are restricted to bind/unbind/abandon/StartTLS/modify password The relevant parts of the slapd.conf follow: [...] include /usr/share/openldap/schema/ppolicy.schema include /etc/openldap/schema/local.schema pidfile /var/run/ldap/slapd.pid argsfile /var/run/ldap/slapd.args modulepath /usr/lib64/openldap moduleload back_monitor.la moduleload syncprov.la moduleload ppolicy.la moduleload auditlog.la moduleload smbk5pwd.so moduleload allop.so moduleload rwm.la moduleload back_relay.la TLSCertificateFile /etc/ssl/openldap/ldap.pem TLSCertificateKeyFile /etc/ssl/openldap/ldap.pem TLSCACertificateFile /etc/ssl/openldap/ldap.pem localSSF 56 loglevel 256 access to dn.exact="" by * read access to dn.exact="cn=Subschema" by * read overlay allop database bdb suffix "dc=ranger,dc=dnsalias,dc=com" directory /var/lib/ldap rootdn "cn=manager,dc=ranger,dc=dnsalias,dc=com" checkpoint 256 5 cachesize 1000 idlcachesize 3000 index objectClass eq index uidNumber,gidNumber,memberuid,member eq index uid eq,subinitial index cn,mail,surname,givenname eq,subinitial index sambaSID eq,sub index sambaDomainName,displayName,sambaGroupType eq index sambaSIDList eq index krb5PrincipalName eq index uniqueMember pres,eq index zoneName,relativeDomainName eq index sudouser eq,sub index entryCSN,entryUUID eq index dhcpHWAddress,dhcpClassData eq authz-regexp "gidNumber=0\\\+uidNumber=0,cn=peercred,cn=external,cn=auth" "uid=Account Admin,ou=System Accounts,dc=ranger,dc=dnsalias,dc=com" sasl-regexp uid=(.*),cn=ranger.dnsalias.com,cn=gssapi,cn=auth ldap:///dc=ranger,dc=dnsalias,dc=com??sub?(krb5PrincipalName=$1@RANGER.DNSALIAS.COM) authz-regexp "" "" include /etc/openldap/mandriva-dit-access.conf overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 overlay ppolicy ppolicy_default "cn=default,ou=Password Policies,dc=ranger,dc=dnsalias,dc=com" overlay smbk5pwd overlay auditlog auditlog /var/lib/ldap/audit.log database monitor access to dn.subtree="cn=Monitor" by group.exact="cn=LDAP Monitors,ou=System Groups,dc=ranger,dc=dnsalias,dc=com" read by group.exact="cn=LDAP Admins,ou=System Groups,dc=ranger,dc=dnsalias,dc=com" read by * none database config rootdn cn=config rootpw xxxxx Commenting out the 'overlay smbk5pwd' results in the user being able to change their password (with identical input to the previous case): $ ldappasswd -H ldapi:// -x -D uid=bgmilne,ou=People,dc=ranger,dc=dnsalias,dc=com -W -S New password: Re-enter new password: Enter LDAP Password: Result: Success (0) Changing the order the modules are stacked in does not seem to make a difference. I could find no other reason why the password change was not being allowed, except that smbk5pwd is interfering. I have not run this same test case on 2.4.x yet, but I remember having problems trying to change passwords on 2.4.10 with a very similar configuration, so I think it exists in 2.4.10 as well.

1 0

Re: (ITS#5565) slapd crashes due to SIGPIPE
by jwm＠horde.net 19 Jun '08

19 Jun '08

On Tue, Jun 17, 2008 at 03:44:39PM -0700, Howard Chu wrote: > > We had been running 2.3.41 plus the fix for ITS 5469, but upgraded to > > RE23 as of about a week ago to make sure a fix wasn't already present. > > Below is a representative backtrace. > > This trace is not indicative of a crash. You have to tell gdb not to stop > when SIGPIPE is received in order to get an accurate view of the program > behavior: "handle SIGPIPE nostop" Ach, I didn't consider that gdb would be stopping on these signals on its own. New backtrace is below. BTW, how does one retitle a Jitterbug bug? I didn't see a way to authenticate to the web interface; does Jitterbug accept e-mail commands to manipulate bugs? 759 int connection_state_closing( Connection *c ) 760 { 761 /* c_mutex must be locked by caller */ 762 763 int state; 764 assert( c != NULL ); 765 assert( c->c_struct_state == SLAP_C_USED ); 766 767 state = c->c_conn_state; 768 769 assert( state != SLAP_C_INVALID ); 770 771 return state == SLAP_C_CLOSING; 772 } GNU gdb 6.4.90-debian Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i486-linux-gnu"...Using host libthread_db library "/lib/tls/libthread_db.so.1". [Thread debugging using libthread_db enabled] [New Thread -1212729120 (LWP 22601)] Failed to read a valid object file image from memory. 0xb7c44aa2 in pread64 () from /lib/tls/libc.so.6 [New Thread -1538888784 (LWP 22625)] [Thread -1538888784 (LWP 22625) exited] [New Thread -1538888784 (LWP 22626)] [Thread -1538888784 (LWP 22626) exited] [New Thread -1538888784 (LWP 22627)] [New Thread -1875645520 (LWP 22628)] [New Thread -1879839824 (LWP 22629)] [New Thread -1884034128 (LWP 22630)] [New Thread -1924138064 (LWP 22631)] [New Thread -1937777744 (LWP 22632)] [New Thread -1953502288 (LWP 22633)] [New Thread -1957696592 (LWP 22634)] [New Thread -1963996240 (LWP 22635)] [New Thread -1969243216 (LWP 22636)] [New Thread -1974490192 (LWP 22637)] [New Thread -1979737168 (LWP 22638)] [New Thread -1993376848 (LWP 22639)] [New Thread -2053129296 (LWP 22640)] Program received signal SIGABRT, Aborted. [Switching to Thread -1963996240 (LWP 22635)] 0xb7bb1947 in raise () from /lib/tls/libc.so.6 Thread 17 (Thread -2053129296 (LWP 22640)): #0 0xb7cc2c01 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0 No symbol table info available. #1 0xb7f2e754 in ldap_pvt_thread_cond_wait (cond=0x814d374, mutex=0x814d35c) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/libraries/libldap_r/thr_posix.c:299 No locals. #2 0xb7f2e033 in ldap_int_thread_pool_wrapper (xpool=0x814d358) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/libraries/libldap_r/tpool.c:466 ctx = (ldap_int_thread_ctx_t *) 0x0 ltc_key = {{ltk_key = 0x80b73c0, ltk_data = 0x87ad2080, ltk_free = 0x80b6f10 <slap_sl_mem_destroy>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 31 times>} tid = 2241838000 i = 655 hash = <value optimized out> #3 0xb7cc00bd in start_thread () from /lib/tls/libpthread.so.0 No symbol table info available. #4 0xb7c5501e in clone () from /lib/tls/libc.so.6 No symbol table info available. Thread 16 (Thread -1993376848 (LWP 22639)): #0 0xb7cc2c01 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0 No symbol table info available. #1 0xb7f2e754 in ldap_pvt_thread_cond_wait (cond=0x814d374, mutex=0x814d35c) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/libraries/libldap_r/thr_posix.c:299 No locals. #2 0xb7f2e033 in ldap_int_thread_pool_wrapper (xpool=0x814d358) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/libraries/libldap_r/tpool.c:466 ctx = (ldap_int_thread_ctx_t *) 0x0 ltc_key = {{ltk_key = 0x80b73c0, ltk_data = 0x85395e0, ltk_free = 0x80b6f10 <slap_sl_mem_destroy>}, {ltk_key = 0x8218160, ltk_data = 0xba, ltk_free = 0xb79ee2e0 <bdb_locker_id_free>}, {ltk_key = 0xb79e1800, ltk_data = 0x871ff008, ltk_free = 0xb79e18d0 <search_stack_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 29 times>} tid = 2301590448 i = 483 hash = <value optimized out> #3 0xb7cc00bd in start_thread () from /lib/tls/libpthread.so.0 No symbol table info available. #4 0xb7c5501e in clone () from /lib/tls/libc.so.6 No symbol table info available. Thread 15 (Thread -1979737168 (LWP 22638)): #0 0xb7cc2c01 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0 No symbol table info available. #1 0xb7f2e754 in ldap_pvt_thread_cond_wait (cond=0x814d374, mutex=0x814d35c) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/libraries/libldap_r/thr_posix.c:299 No locals. #2 0xb7f2e033 in ldap_int_thread_pool_wrapper (xpool=0x814d358) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/libraries/libldap_r/tpool.c:466 ctx = (ldap_int_thread_ctx_t *) 0x0 ltc_key = {{ltk_key = 0x80b73c0, ltk_data = 0x8661808, ltk_free = 0x80b6f10 <slap_sl_mem_destroy>}, {ltk_key = 0x8218160, ltk_data = 0xb8, ltk_free = 0xb79ee2e0 <bdb_locker_id_free>}, {ltk_key = 0xb79e1800, ltk_data = 0x892f8008, ltk_free = 0xb79e18d0 <search_stack_free>}, {ltk_key = 0x8217638, ltk_data = 0x38, ltk_free = 0xb79ee2e0 <bdb_locker_id_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 28 times>} tid = 2315230128 i = 723 hash = <value optimized out> #3 0xb7cc00bd in start_thread () from /lib/tls/libpthread.so.0 No symbol table info available. #4 0xb7c5501e in clone () from /lib/tls/libc.so.6 No symbol table info available. Thread 14 (Thread -1974490192 (LWP 22637)): #0 0xb7cc2c01 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0 No symbol table info available. #1 0xb7f2e754 in ldap_pvt_thread_cond_wait (cond=0x814d374, mutex=0x814d35c) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/libraries/libldap_r/thr_posix.c:299 No locals. #2 0xb7f2e033 in ldap_int_thread_pool_wrapper (xpool=0x814d358) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/libraries/libldap_r/tpool.c:466 ctx = (ldap_int_thread_ctx_t *) 0x0 ltc_key = {{ltk_key = 0x80b73c0, ltk_data = 0x8614d58, ltk_free = 0x80b6f10 <slap_sl_mem_destroy>}, {ltk_key = 0x8218160, ltk_data = 0xb9, ltk_free = 0xb79ee2e0 <bdb_locker_id_free>}, {ltk_key = 0xb79e1800, ltk_data = 0x87df5008, ltk_free = 0xb79e18d0 <search_stack_free>}, {ltk_key = 0x8217638, ltk_data = 0x37, ltk_free = 0xb79ee2e0 <bdb_locker_id_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 28 times>} tid = 2320477104 i = 564 hash = <value optimized out> #3 0xb7cc00bd in start_thread () from /lib/tls/libpthread.so.0 No symbol table info available. #4 0xb7c5501e in clone () from /lib/tls/libc.so.6 No symbol table info available. Thread 13 (Thread -1969243216 (LWP 22636)): #0 0xb7cc2c01 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0 No symbol table info available. #1 0xb7f2e754 in ldap_pvt_thread_cond_wait (cond=0x814d374, mutex=0x814d35c) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/libraries/libldap_r/thr_posix.c:299 No locals. #2 0xb7f2e033 in ldap_int_thread_pool_wrapper (xpool=0x814d358) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/libraries/libldap_r/tpool.c:466 ctx = (ldap_int_thread_ctx_t *) 0x0 ltc_key = {{ltk_key = 0x80b73c0, ltk_data = 0x823dc58, ltk_free = 0x80b6f10 <slap_sl_mem_destroy>}, {ltk_key = 0x8217638, ltk_data = 0x36, ltk_free = 0xb79ee2e0 <bdb_locker_id_free>}, {ltk_key = 0xb79e1800, ltk_data = 0x859fc008, ltk_free = 0xb79e18d0 <search_stack_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 29 times>} tid = 2325724080 i = 660 hash = <value optimized out> #3 0xb7cc00bd in start_thread () from /lib/tls/libpthread.so.0 No symbol table info available. #4 0xb7c5501e in clone () from /lib/tls/libc.so.6 No symbol table info available. Thread 12 (Thread -1963996240 (LWP 22635)): #0 0xb7bb1947 in raise () from /lib/tls/libc.so.6 No symbol table info available. #1 0xb7bb30c9 in abort () from /lib/tls/libc.so.6 No symbol table info available. #2 0xb7bab05f in __assert_fail () from /lib/tls/libc.so.6 No symbol table info available. #3 0x0806bba2 in connection_state_closing (c=0x90342f48) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/servers/slapd/connection.c:765 state = <value optimized out> __PRETTY_FUNCTION__ = "connection_state_closing" #4 0x0807bc34 in send_ldap_ber (conn=0x90342f48, ber=0x8aefbdac) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/servers/slapd/result.c:162 err = 6 sd = 135491153 bytes = <value optimized out> #5 0x0807dd19 in slap_send_search_entry (op=0x8aefbf20, rs=0x8aefc1cc) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/servers/slapd/result.c:1137 a_flags = 0x1 <Address 0x1 out of bounds> berbuf = {buffer = "\002\000\001\000\000\000\000\000ÿÿÿÿ\000\000\000\000\000\000\000\000$Ñ\237\212\232Ñ\237\212Rá\237\212\000\000\000\000\000\000\000\000\210À\"\b\000\000\000\000\210À\"\b\000\000\000\000Ì\rò·\030\000\000\000Ì\rò·\000\000\000\000xÂï\212\030Ÿï\212ÜÀñ·\r\000\000\000\210À\"\b\000\000\000\000ÔÉñ·\f\000\000\000xÂï\2128Ÿï\212ðÅñ·\fÀ\237\212hŸï\212\f\000\000\000tŸï\212\001\000\000\000 ¿ï\212ÈŸï\212\231t\f\bhŸï\212\f\000\000\000\001\000\000\000xÂï\212\210À\"\blŸï\212hŸï\212\206µñ·\001\000\000\000\000\000\000\000csn=,rid=001"..., ialign = 65538, lalign = 65538, falign = 9.18382988e-41, dalign = 3.2380074297143616e-319, palign = 0x10002 <Address 0x10002 out of bounds>} ber = (BerElement *) 0x8aefbdac a = (Attribute *) 0x6 i = 1 j = <value optimized out> rc = <value optimized out> edn = 0x94abb97 "reqStart=20080604231418.000048Z,cn=log" userattrs = 1 acl_state = {as_recorded = 0, as_vd_acl = 0x0, as_vi_acl = 0x0, as_vd_acl_mask = 0, as_vd_acl_matches = {{rm_so = 0, rm_eo = 0} <repeats 100 times>}, as_vd_acl_count = 0, as_vd_access = 0x0, as_vd_access_count = 0, as_result = 0, as_vd_ad = 0x0} attrsonly = 0 ad_entry = (AttributeDescription *) 0x814ad90 e_flags = (char **) 0x0 #6 0xb79c3eaa in syncprov_qtask (ctx=0x8aefc2c8, arg=0x856d058) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/servers/slapd/overlays/syncprov.c:798 so = (syncops *) 0x856d088 on = (slap_overinst *) 0x819da60 opbuf = {buffer = "ð¿ï\212c\000\000\000i¥YH\000\000\000\000ÌÀï\212\006\000\000\000\201D\207\006\000\000\000\210D\207\002\000\000\000\000\000\000\000ÿÿÿÿÿÿÿÿ\\Ø\031\b\000\000\000\000\204C\207ž\201¬\207.\000\000\000\217D\207", '\0' <repeats 12 times>, "\001", '\0' <repeats 39 times>, "LÀï\212\200", '\0' <repeats 11 times>, "\025\000\000\000kD\207\025\000\000\000kD\207", '\0' <repeats 48 times>, "\001\000\000\000&\000\000\000H/4\220\002\000\000\000\003\000\000\000\000\000\000\000ÈÂï\212\210À\"\bP»\023\bconn=38 op=1", '\0' <repeats 171 times>, ialign = -1963999248, lalign = -1963999248, falign = -2.30870617e-32, dalign = 2.1122923453963239e-312, palign = 0x8aefbff0 "\001"} op = (Operation *) 0x8aefbf20 be = {bd_info = 0x819d960, be_ctrls = "\000\001\001\001\000\000\001\000\001\000\001\001\001\000\001", '\0' <repeats 17 times>, "\001", be_flags = 256, be_restrictops = 0, be_requires = 0, be_ssf_set = {sss_ssf = 0, sss_transport = 0, sss_tls = 0, sss_sasl = 0, sss_update_ssf = 0, sss_update_transport = 0, sss_update_tls = 0, sss_update_sasl = 0, sss_simple_bind = 0}, be_suffix = 0x819d728, be_nsuffix = 0x819d740, be_schemadn = {bv_len = 0, bv_val = 0x0}, be_schemandn = {bv_len = 0, bv_val = 0x0}, be_rootdn = {bv_len = 14, bv_val = 0x819d5e0 "cn=root,cn=log"}, be_rootndn = {bv_len = 14, bv_val = 0x819d7c8 "cn=root,cn=log"}, be_rootpw = {bv_len = 0, bv_val = 0x0}, be_max_deref_depth = 15, be_def_limit = {lms_t_soft = 3600, lms_t_hard = 0, lms_s_soft = 500, lms_s_hard = 0, lms_s_unchecked = -1, lms_s_pr = 0, lms_s_pr_hide = 0, lms_s_pr_total = 0}, be_limits = 0x819d7b8, be_acl = 0x818c9e8, be_dfltaccess = ACL_READ, be_replica = 0x0, be_replogfile = 0x0, be_update_ndn = {bv_len = 0, bv_val = 0x0}, be_update_refs = 0x0, be_pending_csn_list = 0x8217320, be_pcl_mutex = {__m_reserved = 0, __m_count = 0, __m_owner = 0x0, __m_kind = 0, __m_lock = {__status = 0, __spinlock = 0}}, be_pcl_mutexp = 0x819d440, be_syncinfo = 0x0, be_pb = 0x0, be_cf_ocs = 0xb79f5660, be_private = 0x819d478, be_next = {stqe_next = 0x819dc98}} rc = <value optimized out> #7 0xb7f2deff in ldap_int_thread_pool_wrapper (xpool=0x814d358) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/libraries/libldap_r/tpool.c:478 ctx = (ldap_int_thread_ctx_t *) 0x8d66c548 ltc_key = {{ltk_key = 0x80b73c0, ltk_data = 0x822c088, ltk_free = 0x80b6f10 <slap_sl_mem_destroy>}, {ltk_key = 0x8218160, ltk_data = 0xbb, ltk_free = 0xb79ee2e0 <bdb_locker_id_free>}, {ltk_key = 0xb79e1800, ltk_data = 0x861fd008, ltk_free = 0xb79e18d0 <search_stack_free>}, {ltk_key = 0x8217638, ltk_data = 0x3a, ltk_free = 0xb79ee2e0 <bdb_locker_id_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 28 times>} tid = 2330971056 i = 756 hash = <value optimized out> #8 0xb7cc00bd in start_thread () from /lib/tls/libpthread.so.0 No symbol table info available. #9 0xb7c5501e in clone () from /lib/tls/libc.so.6 No symbol table info available. Thread 11 (Thread -1957696592 (LWP 22634)): #0 0xb7cc2c01 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0 No symbol table info available. #1 0xb7f2e754 in ldap_pvt_thread_cond_wait (cond=0x814d374, mutex=0x814d35c) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/libraries/libldap_r/thr_posix.c:299 No locals. #2 0xb7f2e033 in ldap_int_thread_pool_wrapper (xpool=0x814d358) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/libraries/libldap_r/tpool.c:466 ctx = (ldap_int_thread_ctx_t *) 0x0 ltc_key = {{ltk_key = 0x80b73c0, ltk_data = 0x8d01068, ltk_free = 0x80b6f10 <slap_sl_mem_destroy>}, {ltk_key = 0x8218160, ltk_data = 0xb1, ltk_free = 0xb79ee2e0 <bdb_locker_id_free>}, {ltk_key = 0xb79e1800, ltk_data = 0x869fe008, ltk_free = 0xb79e18d0 <search_stack_free>}, {ltk_key = 0x8217638, ltk_data = 0x3b, ltk_free = 0xb79ee2e0 <bdb_locker_id_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 28 times>} tid = 2337270704 i = 629 hash = <value optimized out> #3 0xb7cc00bd in start_thread () from /lib/tls/libpthread.so.0 No symbol table info available. #4 0xb7c5501e in clone () from /lib/tls/libc.so.6 No symbol table info available. Thread 10 (Thread -1953502288 (LWP 22633)): #0 0xb7cc2c01 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0 No symbol table info available. #1 0xb7f2e754 in ldap_pvt_thread_cond_wait (cond=0x814d374, mutex=0x814d35c) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/libraries/libldap_r/thr_posix.c:299 No locals. #2 0xb7f2e033 in ldap_int_thread_pool_wrapper (xpool=0x814d358) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/libraries/libldap_r/tpool.c:466 ctx = (ldap_int_thread_ctx_t *) 0x0 ltc_key = {{ltk_key = 0x80b73c0, ltk_data = 0x84c92f0, ltk_free = 0x80b6f10 <slap_sl_mem_destroy>}, {ltk_key = 0x8217638, ltk_data = 0x35, ltk_free = 0xb79ee2e0 <bdb_locker_id_free>}, {ltk_key = 0x8218160, ltk_data = 0xb2, ltk_free = 0xb79ee2e0 <bdb_locker_id_free>}, {ltk_key = 0xb79e1800, ltk_data = 0x885f6008, ltk_free = 0xb79e18d0 <search_stack_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 28 times>} tid = 2341465008 i = 693 hash = <value optimized out> #3 0xb7cc00bd in start_thread () from /lib/tls/libpthread.so.0 No symbol table info available. #4 0xb7c5501e in clone () from /lib/tls/libc.so.6 No symbol table info available. Thread 9 (Thread -1937777744 (LWP 22632)): #0 0xb7c44af6 in pread64 () from /lib/tls/libc.so.6 No symbol table info available. #1 0xb7ad6968 in __os_io_4002 () from /usr/lib/libdb-4.2.so No symbol table info available. #2 0xb7acd60e in __memp_pgread_4002 () from /usr/lib/libdb-4.2.so No symbol table info available. #3 0xb7ace67c in __memp_fget_4002 () from /usr/lib/libdb-4.2.so No symbol table info available. #4 0xb7a453f9 in __bam_search_4002 () from /usr/lib/libdb-4.2.so No symbol table info available. #5 0xb7a390b3 in __bam_c_init_4002 () from /usr/lib/libdb-4.2.so No symbol table info available. #6 0xb7a3a101 in __bam_c_init_4002 () from /usr/lib/libdb-4.2.so No symbol table info available. #7 0xb7a96aee in __db_c_get_4002 () from /usr/lib/libdb-4.2.so No symbol table info available. #8 0xb7a9e456 in __db_c_get_pp_4002 () from /usr/lib/libdb-4.2.so No symbol table info available. #9 0xb79e9675 in bdb_dn2id (op=0x822bed8, dn=0x8c73bcd8, ei=0x8c73bccc, locker=176, lock=0x8c73bd08) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/servers/slapd/back-bdb/dn2id.c:315 bdb = (struct bdb_info *) 0x82190a0 db = (DB *) 0x82190a0 cursor = (DBC *) 0x1000 rc = 0 key = {data = 0x87aeb4b8, size = 74, ulen = 0, dlen = 0, doff = 0, flags = 0} data = {data = 0x8c73bc84, size = 0, ulen = 4, dlen = 0, doff = 0, flags = 32} nid = 2275410448 #10 0xb79ef40d in bdb_cache_find_ndn (op=0x822bed8, locker=176, ndn=0x87aebb8c, res=0x8c7fbfd0) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/servers/slapd/back-bdb/cache.c:341 lock = {off = 281144, ndx = 474, gen = 2469, mode = DB_LOCK_READ} bdb = (struct bdb_info *) 0x819dda0 ei = {bei_parent = 0x822fb00, bei_id = 2422655544, bei_lockpad = 7703, bei_state = -18484, bei_nrdn = {bv_len = 72, bv_val = 0x87aeb5ad "uid=rascal92,dc=example,dc=net,ou=example,ou=services,o=example"}, bei_e = 0x615, bei_kids = 0x0, bei_kids_mutex = {__m_reserved = 0, __m_count = 0, __m_owner = 0x4, __m_kind = -1938572012, __m_lock = {__status = 4, __spinlock = 0}}, bei_lrunext = 0x0, bei_lruprev = 0x0} eip = (EntryInfo *) 0x822fb00 ei2 = (EntryInfo *) 0x0 rc = -1938572068 ptr = <value optimized out> #11 0xb79ef8c6 in bdb_cache_find_id (op=0x822bed8, tid=0x0, id=2197, eip=0x8c7fbfd0, islocked=0, locker=176, lock=0x8c7fbf28) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/servers/slapd/back-bdb/cache.c:716 bdb = (struct bdb_info *) 0x819dda0 ep = (Entry *) 0x87aebb80 rc = 0 load = <value optimized out> ei = {bei_parent = 0x0, bei_id = 2197, bei_lockpad = 0, bei_state = 0, bei_nrdn = {bv_len = 0, bv_val = 0x0}, bei_e = 0x0, bei_kids = 0x0, bei_kids_mutex = {__m_reserved = 0, __m_count = 0, __m_owner = 0x0, __m_kind = 0, __m_lock = {__status = 0, __spinlock = 0}}, bei_lrunext = 0x0, bei_lruprev = 0x0} #12 0xb79e346c in bdb_search (op=0x822bed8, rs=0x8c7fd244) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/servers/slapd/back-bdb/search.c:696 scopeok = 1 bdb = (struct bdb_info *) 0x819dda0 id = 2197 cursor = 2197 candidates = {4294967295, 1, 1315154, 0 <repeats 131069 times>} scopes = {0 <repeats 65115 times>, 1874813323, 2357182692, 134914208, 2357182692, 2357180440, 134914251, 2351943732, 135654592, 0, 0, 0, 135655256, 2357180472, 135122385, 2357182692, 135655240, 0, 2357182692, 2357182804, 2357182808, 1941922187, 2357182772, 134914208, 2357182772, 2357180520, 134914251, 2349882130, 135556176, 0, 134906653, 2357180628, 135556496, 2357180552, 135122385, 2357182772, 135556480, 0, 2357182772, 2357187160, 2357182856, 2357180584, 134911775, 135557712, 2357182772, 134914208, 0, 2357187160, 2357182856, 2357182808, 134906653, 2357180708, 0, 1032, 0, 0, 0, 0, 0, 2349882130, 0, 0, 2349882141, 0, 0, 0, 0, 2351943928, 2357187060, 2357182888, 134906325, 0 <repeats 59 times>, 3082729587, 0, 0, 3082672430, 135227836, 135227836, 0, 3083562996, 135227833, 3, 2357182504, 3082571759, 2357182540, 135227833, 3, 0, 0, 0, 2357182356, 3082570669, 0, 0, 2357182464, 0 <repeats 12 times>, 2357182688, 0, 0, 0, 0, 0, 0, 0, 0, 0, 4294967295, 15, 135227836, 135227831, 2357182356, 0, 11, 0 <repeats 12 times>, 3086073092, 0, 0, 0, 1931476992, 11, 0 <repeats 29 times>, 135227832, 0, 0, 4294967295, 0, 0, 0, 2357182832, 0 <repeats 31 times>, 3083607575, 0, 0, 0, 2372321648, 0, 3086334744, 135916992, 135916868, 2357181512, 3086334744, 135916992, 135916868, 104, 3080484372, 100...} e = (Entry *) 0x87aeae98 base = {e_id = 1, e_name = {bv_len = 593113649, bv_val = 0x30303030 <Address 0x30303030 out of bounds>}, e_nname = {bv_len = 10, bv_val = 0x8d672a58 "o=example"}, e_attrs = 0x30303030, e_ocflags = 0, e_bv = {bv_len = 3086072815, bv_val = 0x0}, e_private = 0x822e6f0} e_root = {e_id = 0, e_name = {bv_len = 0, bv_val = 0x0}, e_nname = {bv_len = 0, bv_val = 0x0}, e_attrs = 0x0, e_ocflags = 0, e_bv = {bv_len = 0, bv_val = 0x0}, e_private = 0x0} matched = (Entry *) 0x0 ei = (EntryInfo *) 0x0 ei_root = {bei_parent = 0x0, bei_id = 0, bei_lockpad = 0, bei_state = 0, bei_nrdn = {bv_len = 0, bv_val = 0x0}, bei_e = 0x0, bei_kids = 0x0, bei_kids_mutex = {__m_reserved = 0, __m_count = 0, __m_owner = 0x0, __m_kind = 0, __m_lock = {__status = 0, __spinlock = 0}}, bei_lrunext = 0x0, bei_lruprev = 0x0} realbase = {bv_len = 10, bv_val = 0x8d672a58 "o=example"} manageDSAit = 2 tentries = 1315154 lastid = 4294967295 locker = 176 lock = {off = 0, ndx = 180, gen = 2466, mode = DB_LOCK_READ} ltid = (DB_TXN *) 0x0 #13 0x080c57e0 in overlay_op_walk (op=0x822bed8, rs=0x8c7fd244, which=op_search, oi=0x819eb18, on=0x819eee8) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/servers/slapd/backover.c:650 sc_next = <value optimized out> rc = 32768 #14 0x080c5bde in over_op_func (op=0x822bed8, rs=0x8c7fd244, which=op_search) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/servers/slapd/backover.c:702 oi = (slap_overinfo *) 0x819eb18 on = (slap_overinst *) 0x819eee8 be = (BackendDB *) 0x819dc98 db = {bd_info = 0xb79f59c0, be_ctrls = "\000\001\001\001\000\000\001\000\001\000\001\001\001\000\001", '\0' <repeats 17 times>, "\001", be_flags = 256, be_restrictops = 0, be_requires = 0, be_ssf_set = {sss_ssf = 0, sss_transport = 0, sss_tls = 0, sss_sasl = 0, sss_update_ssf = 0, sss_update_transport = 0, sss_update_tls = 0, sss_update_sasl = 0, sss_simple_bind = 0}, be_suffix = 0x819e028, be_nsuffix = 0x819e040, be_schemadn = {bv_len = 0, bv_val = 0x0}, be_schemandn = {bv_len = 0, bv_val = 0x0}, be_rootdn = {bv_len = 18, bv_val = 0x819e1a8 "cn=root,o=example"}, be_rootndn = {bv_len = 18, bv_val = 0x819e300 "cn=root,o=example"}, be_rootpw = {bv_len = 20, bv_val = 0x819e078 "{crypt}bo3zUPoqIZwko"}, be_max_deref_depth = 15, be_def_limit = {lms_t_soft = 3600, lms_t_hard = 0, lms_s_soft = 500, lms_s_hard = 0, lms_s_unchecked = -1, lms_s_pr = 0, lms_s_pr_hide = 0, lms_s_pr_total = 0}, be_limits = 0x819d940, be_acl = 0x818c9e8, be_dfltaccess = ACL_READ, be_replica = 0x8198cb0, be_replogfile = 0x819b958 "/var/lib/ldap/replog", be_update_ndn = {bv_len = 0, bv_val = 0x0}, be_update_refs = 0x0, be_pending_csn_list = 0x8225cd0, be_pcl_mutex = {__m_reserved = 0, __m_count = 0, __m_owner = 0x0, __m_kind = 0, __m_lock = {__status = 0, __spinlock = 0}}, be_pcl_mutexp = 0x819dd68, be_syncinfo = 0x0, be_pb = 0x0, be_cf_ocs = 0xb79f5660, be_private = 0x819dda0, be_next = {stqe_next = 0x0}} cb = {sc_next = 0x0, sc_response = 0x80c5550 <over_back_response>, sc_cleanup = 0, sc_private = 0x819eb18} rc = 4096 __PRETTY_FUNCTION__ = "over_op_func" #15 0x0806f852 in fe_op_search (op=0x822bed8, rs=0x8c7fd244) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/servers/slapd/search.c:355 entry = (Entry *) 0x11 bd = (BackendDB *) 0x813f120 #16 0x0807015b in do_search (op=0x822bed8, rs=0x8c7fd244) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/servers/slapd/search.c:217 base = {bv_len = 10, bv_val = 0x8c105af7 "o=example"} siz = 2 i = 0 #17 0x0806d5cb in connection_operation (ctx=0x8c7fd2c8, arg_v=0x822bed8) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/servers/slapd/connection.c:1133 curelm = <value optimized out> rc = <value optimized out> rs = {sr_type = REP_SEARCH, sr_tag = 0, sr_msgid = 0, sr_err = 0, sr_matched = 0x0, sr_text = 0x0, sr_ref = 0x0, sr_ctrls = 0x0, sr_un = {sru_sasl = {r_sasldata = 0x0}, sru_extended = {r_rspoid = 0x0, r_rspdata = 0x0}, sru_search = {r_entry = 0x0, r_attr_flags = 0, r_operational_attrs = 0x0, r_attrs = 0x8c2fd0e4, r_nentries = 1727, r_v2ref = 0x0}}, sr_flags = 0} tag = 99 opidx = SLAP_OP_SEARCH conn = (Connection *) 0x90342538 memctx = (void *) 0x8d66c170 memctx_null = (void *) 0x0 __PRETTY_FUNCTION__ = "connection_operation" #18 0xb7f2deff in ldap_int_thread_pool_wrapper (xpool=0x814d358) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/libraries/libldap_r/tpool.c:478 ctx = (ldap_int_thread_ctx_t *) 0x8229140 ltc_key = {{ltk_key = 0x80b73c0, ltk_data = 0x8d66c170, ltk_free = 0x80b6f10 <slap_sl_mem_destroy>}, {ltk_key = 0x8218160, ltk_data = 0xb0, ltk_free = 0xb79ee2e0 <bdb_locker_id_free>}, {ltk_key = 0xb79e1800, ltk_data = 0x8b8ff008, ltk_free = 0xb79e18d0 <search_stack_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 29 times>} tid = 2357189552 i = 662 hash = <value optimized out> #19 0xb7cc00bd in start_thread () from /lib/tls/libpthread.so.0 No symbol table info available. #20 0xb7c5501e in clone () from /lib/tls/libc.so.6 No symbol table info available. Thread 8 (Thread -1924138064 (LWP 22631)): #0 0xb7cc2c01 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0 No symbol table info available. #1 0xb7f2e754 in ldap_pvt_thread_cond_wait (cond=0x814d374, mutex=0x814d35c) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/libraries/libldap_r/thr_posix.c:299 No locals. #2 0xb7f2e033 in ldap_int_thread_pool_wrapper (xpool=0x814d358) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/libraries/libldap_r/tpool.c:466 ctx = (ldap_int_thread_ctx_t *) 0x0 ltc_key = {{ltk_key = 0x80b73c0, ltk_data = 0x822c610, ltk_free = 0x80b6f10 <slap_sl_mem_destroy>}, {ltk_key = 0x8218160, ltk_data = 0xaf, ltk_free = 0xb79ee2e0 <bdb_locker_id_free>}, {ltk_key = 0xb79e1800, ltk_data = 0x8c7fe008, ltk_free = 0xb79e18d0 <search_stack_free>}, {ltk_key = 0x8217638, ltk_data = 0x34, ltk_free = 0xb79ee2e0 <bdb_locker_id_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 28 times>} tid = 2370829232 i = 647 hash = <value optimized out> #3 0xb7cc00bd in start_thread () from /lib/tls/libpthread.so.0 No symbol table info available. #4 0xb7c5501e in clone () from /lib/tls/libc.so.6 No symbol table info available. Thread 7 (Thread -1884034128 (LWP 22630)): #0 0xb7cc2c01 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0 No symbol table info available. #1 0xb7f2e754 in ldap_pvt_thread_cond_wait (cond=0x814d374, mutex=0x814d35c) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/libraries/libldap_r/thr_posix.c:299 No locals. #2 0xb7f2e033 in ldap_int_thread_pool_wrapper (xpool=0x814d358) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/libraries/libldap_r/tpool.c:466 ctx = (ldap_int_thread_ctx_t *) 0x0 ltc_key = {{ltk_key = 0x80b73c0, ltk_data = 0x822c688, ltk_free = 0x80b6f10 <slap_sl_mem_destroy>}, {ltk_key = 0x8217638, ltk_data = 0x24, ltk_free = 0xb79ee2e0 <bdb_locker_id_free>}, {ltk_key = 0x8218160, ltk_data = 0x95, ltk_free = 0xb79ee2e0 <bdb_locker_id_free>}, {ltk_key = 0xb79e1800, ltk_data = 0x8e43a008, ltk_free = 0xb79e18d0 <search_stack_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 28 times>} tid = 2410933168 i = 733 hash = <value optimized out> #3 0xb7cc00bd in start_thread () from /lib/tls/libpthread.so.0 No symbol table info available. #4 0xb7c5501e in clone () from /lib/tls/libc.so.6 No symbol table info available. Thread 6 (Thread -1879839824 (LWP 22629)): #0 0xb7ad1183 in __memp_fput_4002 () from /usr/lib/libdb-4.2.so No symbol table info available. #1 0xb7a96622 in __db_c_close_4002 () from /usr/lib/libdb-4.2.so No symbol table info available. #2 0xb7a96bed in __db_c_get_4002 () from /usr/lib/libdb-4.2.so No symbol table info available. #3 0xb7a9e456 in __db_c_get_pp_4002 () from /usr/lib/libdb-4.2.so No symbol table info available. #4 0xb79ec080 in bdb_idl_delete_key (be=0x8ff3dd4c, db=0x8224f00, tid=0x87aec278, key=0x8ff3db74, id=1928417) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/servers/slapd/back-bdb/idl.c:930 rc = 0 data = {data = 0x8ff3db14, size = 4, ulen = 4, dlen = 0, doff = 0, flags = 32} cursor = (DBC *) 0x8225350 lo = <value optimized out> hi = <value optimized out> tmp = <value optimized out> nid = <value optimized out> nlo = 0 nhi = 38 err = <value optimized out> __PRETTY_FUNCTION__ = "bdb_idl_delete_key" #5 0xb79e9e58 in bdb_dn2id_delete (op=0x8ff3de98, txn=0x87aec278, eip=0x8225920, e=0x8ac1578) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/servers/slapd/back-bdb/dn2id.c:232 bdb = (struct bdb_info *) 0x819d478 db = (DB *) 0x8224f00 buf = 0x87aec2f8 "@reqStart=20080604231418.000072Z%cn=log" key = {data = 0x87aec318, size = 8, ulen = 8, dlen = 0, doff = 0, flags = 32} lock = {off = 280640, ndx = 599, gen = 9135, mode = DB_LOCK_WRITE} pdn = {bv_len = 6, bv_val = 0xb7614e90 ""} ptr = {bv_len = 6, bv_val = 0x87aec319 "cn=log"} rc = 0 #6 0xb79dc1d8 in bdb_delete (op=0x8ff3de98, rs=0x8ff3e1f4) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/servers/slapd/back-bdb/delete.c:356 bdb = (struct bdb_info *) 0x819d478 matched = <value optimized out> pdn = {bv_len = 6, bv_val = 0x8c00ff8 "cn=log"} e = (Entry *) 0x8ac1578 p = (Entry *) 0x8d66c840 ei = (EntryInfo *) 0x8c00f10 eip = (EntryInfo *) 0x8225920 manageDSAit = 0 children = (AttributeDescription *) 0x814af20 entry = (AttributeDescription *) 0x814ad90 ltid = (DB_TXN *) 0x87aec1f8 lt2 = (DB_TXN *) 0x87aec278 opinfo = {boi_bdb = 0x8ff3dd4c, boi_txn = 0x87aec1f8, boi_err = 0, boi_locker = 2147493923, boi_acl_cache = 0, boi_locks = 0x0} eid = 3083568320 locker = 2147493923 lock = {off = 281000, ndx = 136, gen = 10245, mode = DB_LOCK_READ} plock = {off = 282296, ndx = 386, gen = 9049, mode = DB_LOCK_READ} num_retries = 0 rc = <value optimized out> preread_ctrl = (LDAPControl **) 0x0 ctrls = {0x0, 0x8bfffb4, 0x0, 0x8ac1578, 0xb79c7614, 0x8bfffa8} num_ctrls = 0 parent_is_glue = <value optimized out> parent_is_leaf = -1879843768 #7 0x080c57e0 in overlay_op_walk (op=0x8ff3de98, rs=0x8ff3e1f4, which=op_delete, oi=0x819d960, on=0x819da60) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/servers/slapd/backover.c:650 sc_next = <value optimized out> rc = 32768 #8 0x080c5bde in over_op_func (op=0x8ff3de98, rs=0x8ff3e1f4, which=op_delete) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/servers/slapd/backover.c:702 oi = (slap_overinfo *) 0x819d960 on = (slap_overinst *) 0x819da60 be = (BackendDB *) 0x819d370 db = {bd_info = 0xb79f59c0, be_ctrls = "\000\001\001\001\000\000\001\000\001\000\001\001\001\000\001", '\0' <repeats 17 times>, "\001", be_flags = 256, be_restrictops = 0, be_requires = 0, be_ssf_set = {sss_ssf = 0, sss_transport = 0, sss_tls = 0, sss_sasl = 0, sss_update_ssf = 0, sss_update_transport = 0, sss_update_tls = 0, sss_update_sasl = 0, sss_simple_bind = 0}, be_suffix = 0x819d728, be_nsuffix = 0x819d740, be_schemadn = {bv_len = 0, bv_val = 0x0}, be_schemandn = {bv_len = 0, bv_val = 0x0}, be_rootdn = {bv_len = 14, bv_val = 0x819d5e0 "cn=root,cn=log"}, be_rootndn = {bv_len = 14, bv_val = 0x819d7c8 "cn=root,cn=log"}, be_rootpw = {bv_len = 0, bv_val = 0x0}, be_max_deref_depth = 15, be_def_limit = {lms_t_soft = 3600, lms_t_hard = 0, lms_s_soft = 500, lms_s_hard = 0, lms_s_unchecked = -1, lms_s_pr = 0, lms_s_pr_hide = 0, lms_s_pr_total = 0}, be_limits = 0x819d7b8, be_acl = 0x818c9e8, be_dfltaccess = ACL_READ, be_replica = 0x0, be_replogfile = 0x0, be_update_ndn = {bv_len = 0, bv_val = 0x0}, be_update_refs = 0x0, be_pending_csn_list = 0x8217320, be_pcl_mutex = {__m_reserved = 0, __m_count = 0, __m_owner = 0x0, __m_kind = 0, __m_lock = {__status = 0, __spinlock = 0}}, be_pcl_mutexp = 0x819d440, be_syncinfo = 0x0, be_pb = 0x0, be_cf_ocs = 0xb79f5660, be_private = 0x819d478, be_next = {stqe_next = 0x819dc98}} cb = {sc_next = 0xb79cf660, sc_response = 0x80c5550 <over_back_response>, sc_cleanup = 0, sc_private = 0x819d960} rc = 804813 __PRETTY_FUNCTION__ = "over_op_func" #9 0xb79cad20 in accesslog_purge (ctx=0x8ff3e2c8, arg=0x819e768) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/servers/slapd/overlays/accesslog.c:589 i = 5081 li = <value optimized out> conn = {c_struct_state = 0, c_conn_state = 0, c_conn_idx = 0, c_close_reason = 0x0, c_mutex = {__m_reserved = 0, __m_count = 0, __m_owner = 0x0, __m_kind = 0, __m_lock = {__status = 0, __spinlock = 0}}, c_sb = 0x0, c_starttime = 0, c_activitytime = 0, c_connid = 4294967295, c_peer_domain = {bv_len = 0, bv_val = 0x80f4ac8 ""}, c_peer_name = {bv_len = 0, bv_val = 0x80f4ac8 ""}, c_listener = 0x80f5d60, c_sasl_bind_in_progress = 0, c_sasl_bind_mech = {bv_len = 0, bv_val = 0x0}, c_sasl_dn = {bv_len = 0, bv_val = 0x0}, c_sasl_authz_dn = {bv_len = 0, bv_val = 0x0}, c_authz_backend = 0x0, c_authz_cookie = 0x0, c_authz = {sai_method = 0, sai_mech = {bv_len = 0, bv_val = 0x0}, sai_dn = {bv_len = 0, bv_val = 0x0}, sai_ndn = {bv_len = 0, bv_val = 0x0}, sai_ssf = 0, sai_transport_ssf = 0, sai_tls_ssf = 0, sai_sasl_ssf = 0}, c_protocol = 0, c_ops = {stqh_first = 0x0, stqh_last = 0x0}, c_pending_ops = {stqh_first = 0x0, stqh_last = 0x0}, c_write_mutex = {__m_reserved = 0, __m_count = 0, __m_owner = 0x0, __m_kind = 0, __m_lock = {__status = 0, __spinlock = 0}}, c_write_cv = {__c_lock = {__status = 0, __spinlock = 0}, __c_waiting = 0x0, __padding = '\0' <repeats 27 times>, __align = 0}, c_currentber = 0x0, c_writewaiter = 0, c_is_tls = 0, c_needs_tls_accept = 0, c_sasl_layers = 0, c_sasl_done = 0, c_sasl_authctx = 0x0, c_sasl_sockctx = 0x0, c_sasl_extra = 0x0, c_sasl_bindop = 0x0, c_pagedresults_state = {ps_be = 0x0, ps_size = 0, ps_cookie = 0, ps_count = 0}, c_n_ops_received = 0, c_n_ops_executing = 0, c_n_ops_pending = 0, c_n_ops_completed = 0, c_n_get = 0, c_n_read = 0, c_n_write = 0, c_pb = 0x0, c_extensions = 0x0, c_clientfunc = 0, c_clientarg = 0x0, c_send_ldap_result = 0x807ef50 <slap_send_ldap_result>, c_send_search_entry = 0x807c600 <slap_send_search_entry>, c_send_search_reference = 0x807bd00 <slap_send_search_reference>, c_send_ldap_extended = 0, c_send_ldap_intermediate = 0} opbuf = {buffer = "hßó\217J\000\000\000M¥YH\002\000\000\000LÝó\217&\000\000\000š\017À\b&\000\000\000Ø\017À\b\001\000\000\000\000\000\000\000ÿÿÿÿÿÿÿÿ\000\000\000\000\001\000\000\000 ž\023\b|âó\217\033\000\000\000\fàc\217", '\0' <repeats 52 times>, "Äßó\217", '\0' <repeats 12 times>, "\016\000\000\000àÕ\031\b\016\000\000\000È×\031\b", '\0' <repeats 24 times>, "\220`[\b\000\000\000\000 \000\000\000Žáó\217\204Üó\217\000\000\000\000\000\000\000\000ÿÿÿÿDàó\217", '\0' <repeats 12 times>, "Èâó\217ð\221\"\bP»\023\bconn=-1 op=0", '\0' <repeats 171 times>, ialign = -1879842968, lalign = -1879842968, falign = -2.4047703e-29, dalign = 1.5822091849233038e-312, palign = 0x8ff3df68 ""} op = (Operation *) 0x8ff3de98 rs = {sr_type = REP_RESULT, sr_tag = 107, sr_msgid = 0, sr_err = -30990, sr_matched = 0x0, sr_text = 0x0, sr_ref = 0x0, sr_ctrls = 0x0, sr_un = {sru_sasl = {r_sasldata = 0x0}, sru_extended = {r_rspoid = 0x0, r_rspdata = 0x0}, sru_search = {r_entry = 0x0, r_attr_flags = 0, r_operational_attrs = 0x0, r_attrs = 0x813b8a0, r_nentries = 0, r_v2ref = 0x0}}, sr_flags = 0} cb = {sc_next = 0x0, sc_response = 0xb79cad70 <log_old_lookup>, sc_cleanup = 0, sc_private = 0x8ff3e230} f = {f_choice = 166, f_un = {f_un_result = -1879842192, f_un_dn = 0x8ff3e270, f_un_desc = 0x8ff3e270, f_un_ava = 0x8ff3e270, f_un_ssa = 0x8ff3e270, f_un_mra = 0x8ff3e270, f_un_complex = 0x8ff3e270}, f_next = 0x0} ava = {aa_desc = 0x8187280, aa_value = {bv_len = 15, bv_val = 0x8ff3e24a "20080605001613Z"}} pd = {slots = 23200, used = 23194, dn = 0x8dabd008, ndn = 0x8dc0b008, csn = {bv_len = 32, bv_val = 0x8ff3e1b4 "20080604225659Z#000009#00#000000"}} timebuf = "20080605001613Z\000\024\bô\237Ì·" csnbuf = "20080604225659Z#000009#00#000000", '\0' <repeats 31 times> old = 1212624973 #10 0xb7f2deff in ldap_int_thread_pool_wrapper (xpool=0x814d358) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/libraries/libldap_r/tpool.c:478 ctx = (ldap_int_thread_ctx_t *) 0x822eb68 ltc_key = {{ltk_key = 0x80b73c0, ltk_data = 0x82291f0, ltk_free = 0x80b6f10 <slap_sl_mem_destroy>}, {ltk_key = 0x8217638, ltk_data = 0x1c, ltk_free = 0xb79ee2e0 <bdb_locker_id_free>}, {ltk_key = 0xb79e1800, ltk_data = 0x8ee3d008, ltk_free = 0xb79e18d0 <search_stack_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 29 times>} tid = 2415127472 i = 797 hash = <value optimized out> #11 0xb7cc00bd in start_thread () from /lib/tls/libpthread.so.0 No symbol table info available. #12 0xb7c5501e in clone () from /lib/tls/libc.so.6 No symbol table info available. Thread 5 (Thread -1875645520 (LWP 22628)): #0 0xb7cc2c01 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0 No symbol table info available. #1 0xb7f2e754 in ldap_pvt_thread_cond_wait (cond=0x90342bc0, mutex=0x90342b08) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/libraries/libldap_r/thr_posix.c:299 No locals. #2 0x0807bc24 in send_ldap_ber (conn=0x90342af8, ber=0x9027cc8c) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/servers/slapd/result.c:198 err = 11 sd = 41 bytes = <value optimized out> #3 0x0807dd19 in slap_send_search_entry (op=0x8d67bac8, rs=0x9033e244) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/servers/slapd/result.c:1137 a_flags = 0x1 <Address 0x1 out of bounds> berbuf = {buffer = "\002\000\001\000\000\000\000\000ÿÿÿÿ\000\000\000\000\000\000\000\000ðÕ\207(Û\207ÛÞ\207\000\000\000\000\036×\207žÀ\"\b(Í'\220ÖÒ\b\bÈºg\215`É«\207šm\024\b\000\000\000\000\004\000\000\000\000\000\000\000\030Í'\220¡î\236·<Þ\031\b(Ï3\220øÌ'\220\030»õ·\bß\031\b\000\000\000\000Pl\024\b]æò·\210É«\207šm\024\b(Í'\220©]\a\bšm\024\bšm\024\b\177\023\000\000\234R\237·\234R\237·šm\024\bšÍ'\220<°\b\b\210É«\207šm\024\bšm\024\b\000\000\000\000\004", '\0' <repeats 11 times>, "\037\004¬·`\201!\b\\"..., ialign = 65538, lalign = 65538, falign = 9.18382988e-41, dalign = 3.2380074297143616e-319, palign = 0x10002 <Address 0x10002 out of bounds>} ber = (BerElement *) 0x9027cc8c a = (Attribute *) 0x8 i = 1 j = <value optimized out> rc = <value optimized out> edn = 0x87abc3e8 "uid=mwe,dc=example,dc=net,ou=example,ou=services,o=example" userattrs = 1 acl_state = {as_recorded = 3, as_vd_acl = 0x0, as_vi_acl = 0x0, as_vd_acl_mask = 0, as_vd_acl_matches = {{rm_so = 0, rm_eo = 0} <repeats 100 times>}, as_vd_acl_count = 0, as_vd_access = 0x0, as_vd_access_count = 0, as_result = 1, as_vd_ad = 0x8147818} attrsonly = 0 ad_entry = (AttributeDescription *) 0x814ad90 e_flags = (char **) 0x0 #4 0xb79e3c47 in bdb_search (op=0x8d67bac8, rs=0x9033e244) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/servers/slapd/back-bdb/search.c:879 tmp = <value optimized out> bdb = (struct bdb_info *) 0x819dda0 id = 2099 cursor = 2099 candidates = {4294967295, 1, 1315154, 1315154, 0 <repeats 131068 times>} scopes = {0 <repeats 64741 times>, 3082729587, 0, 0, 0, 3083490390, 3083490390, 0, 3083562996, 2, 2419312800, 2419311216, 3082683477, 2419312800, 3083490388, 3082729587, 3083490388, 2, 3082672430, 2419312624, 2419312624, 0, 3083562996, 135313010, 0, 2419312772, 3082571759, 2419312800, 135313010, 0, 0, 0, 0, 2419312624, 3082570669, 0, 0, 2419312732, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 2, 0, 2419312948, 0, 0, 0, 0, 0, 0, 0, 0, 0, 4294967295, 8, 135313010, 135313006, 2419312624, 0, 11, 0, 0, 0, 10, 2419312623, 0, 0, 0, 0, 0, 0, 0, 0, 0, 2, 0, 1680867328, 0 <repeats 30 times>, 135313009, 0, 0, 1, 0, 3, 0, 2419313020, 0 <repeats 96 times>, 136495288, 0, 2396246676, 2419312040, 3083621274, 83, 3086082427, 39, 2396246676, 83, 3086093772, 0, 3086093772, 2419312232, 3086078746, 2349882424, 2396246676, 83, 0, 3086093772, 136495288, 2419312104, 3086076372, 4060, 136495288, 0, 0, 3086093772, 0, 2419312152, 3086070827, 0, 4060, 136495288, 0, 2419312488, 1, 2419312184, 3086071233, 2419312488, 1, 2419312200, 3086071174, 2396246677, 2419312250, 1, 3086093772, 24, 2419312488, 2419312248, 3086093772, 81, 2419312488, 2419312264, 3086061034, 2419312488, 2419312250, 1, 3086093772, 2396246676, 2349882344, 2419312280, 3086079738, 2349882448, 2396246676, 83, 3086093772, 1, 3086093772, 2419312344, 3086093772, 83, 2419312488, 2419312328, 3086070385, 2349882344, 2396246676, 83, 3086334744...} e = (Entry *) 0x1 base = {e_id = 1, e_name = {bv_len = 593113649, bv_val = 0x30303030 <Address 0x30303030 out of bounds>}, e_nname = {bv_len = 10, bv_val = 0x85ea478 "o=example"}, e_attrs = 0x30303030, e_ocflags = 0, e_bv = {bv_len = 3086072815, bv_val = 0x8db8b960 "reqStart=20080605001018.000049Z,cn=log"}, e_private = 0x822e6f0} e_root = {e_id = 0, e_name = {bv_len = 0, bv_val = 0x0}, e_nname = {bv_len = 0, bv_val = 0x0}, e_attrs = 0x0, e_ocflags = 0, e_bv = {bv_len = 0, bv_val = 0x0}, e_private = 0x0} matched = (Entry *) 0x0 ei = (EntryInfo *) 0x87ab7f18 ei_root = {bei_parent = 0x0, bei_id = 0, bei_lockpad = 0, bei_state = 0, bei_nrdn = {bv_len = 0, bv_val = 0x0}, bei_e = 0x0, bei_kids = 0x0, bei_kids_mutex = {__m_reserved = 0, __m_count = 0, __m_owner = 0x0, __m_kind = 0, __m_lock = {__status = 0, __spinlock = 0}}, bei_lrunext = 0x0, bei_lruprev = 0x0} realbase = {bv_len = 10, bv_val = 0x85ea478 "o=example"} manageDSAit = 2 tentries = 1315154 lastid = 4294967295 locker = 148 lock = {off = 280856, ndx = 965, gen = 4488, mode = DB_LOCK_READ} ltid = (DB_TXN *) 0x0 #5 0x080c57e0 in overlay_op_walk (op=0x8d67bac8, rs=0x9033e244, which=op_search, oi=0x819eb18, on=0x819eee8) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/servers/slapd/backover.c:650 sc_next = <value optimized out> rc = 32768 #6 0x080c5bde in over_op_func (op=0x8d67bac8, rs=0x9033e244, which=op_search) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/servers/slapd/backover.c:702 oi = (slap_overinfo *) 0x819eb18 on = (slap_overinst *) 0x819eee8 be = (BackendDB *) 0x819dc98 db = {bd_info = 0xb79f59c0, be_ctrls = "\000\001\001\001\000\000\001\000\001\000\001\001\001\000\001", '\0' <repeats 17 times>, "\001", be_flags = 256, be_restrictops = 0, be_requires = 0, be_ssf_set = {sss_ssf = 0, sss_transport = 0, sss_tls = 0, sss_sasl = 0, sss_update_ssf = 0, sss_update_transport = 0, sss_update_tls = 0, sss_update_sasl = 0, sss_simple_bind = 0}, be_suffix = 0x819e028, be_nsuffix = 0x819e040, be_schemadn = {bv_len = 0, bv_val = 0x0}, be_schemandn = {bv_len = 0, bv_val = 0x0}, be_rootdn = {bv_len = 18, bv_val = 0x819e1a8 "cn=root,o=example"}, be_rootndn = {bv_len = 18, bv_val = 0x819e300 "cn=root,o=example"}, be_rootpw = {bv_len = 20, bv_val = 0x819e078 "{crypt}bo3zUPoqIZwko"}, be_max_deref_depth = 15, be_def_limit = {lms_t_soft = 3600, lms_t_hard = 0, lms_s_soft = 500, lms_s_hard = 0, lms_s_unchecked = -1, lms_s_pr = 0, lms_s_pr_hide = 0, lms_s_pr_total = 0}, be_limits = 0x819d940, be_acl = 0x818c9e8, be_dfltaccess = ACL_READ, be_replica = 0x8198cb0, be_replogfile = 0x819b958 "/var/lib/ldap/replog", be_update_ndn = {bv_len = 0, bv_val = 0x0}, be_update_refs = 0x0, be_pending_csn_list = 0x8225cd0, be_pcl_mutex = {__m_reserved = 0, __m_count = 0, __m_owner = 0x0, __m_kind = 0, __m_lock = {__status = 0, __spinlock = 0}}, be_pcl_mutexp = 0x819dd68, be_syncinfo = 0x0, be_pb = 0x0, be_cf_ocs = 0xb79f5660, be_private = 0x819dda0, be_next = {stqe_next = 0x0}} cb = {sc_next = 0x0, sc_response = 0x80c5550 <over_back_response>, sc_cleanup = 0, sc_private = 0x819eb18} rc = -4 __PRETTY_FUNCTION__ = "over_op_func" #7 0x0806f852 in fe_op_search (op=0x8d67bac8, rs=0x9033e244) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/servers/slapd/search.c:355 entry = (Entry *) 0x11 bd = (BackendDB *) 0x813f120 #8 0x0807015b in do_search (op=0x8d67bac8, rs=0x9033e244) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/servers/slapd/search.c:217 base = {bv_len = 10, bv_val = 0x8d6827f7 "o=example"} siz = 2 i = 0 #9 0x0806d5cb in connection_operation (ctx=0x9033e2c8, arg_v=0x8d67bac8) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/servers/slapd/connection.c:1133 curelm = <value optimized out> rc = <value optimized out> rs = {sr_type = REP_SEARCH, sr_tag = 0, sr_msgid = 0, sr_err = 0, sr_matched = 0x0, sr_text = 0x0, sr_ref = 0x0, sr_ctrls = 0x8ee3bfe4, sr_un = {sru_sasl = {r_sasldata = 0x87abc960}, sru_extended = {r_rspoid = 0x87abc960 "3\b", r_rspdata = 0x22}, sru_search = {r_entry = 0x87abc960, r_attr_flags = 34, r_operational_attrs = 0x87ab3f88, r_attrs = 0x8ed3c0e4, r_nentries = 1646, r_v2ref = 0x0}}, sr_flags = 0} tag = 99 opidx = SLAP_OP_SEARCH conn = (Connection *) 0x90342af8 memctx = (void *) 0x822c0b8 memctx_null = (void *) 0x0 __PRETTY_FUNCTION__ = "connection_operation" #10 0xb7f2deff in ldap_int_thread_pool_wrapper (xpool=0x814d358) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/libraries/libldap_r/tpool.c:478 ctx = (ldap_int_thread_ctx_t *) 0x8db8b990 ltc_key = {{ltk_key = 0x80b73c0, ltk_data = 0x822c0b8, ltk_free = 0x80b6f10 <slap_sl_mem_destroy>}, {ltk_key = 0x8218160, ltk_data = 0x94, ltk_free = 0xb79ee2e0 <bdb_locker_id_free>}, {ltk_key = 0x8217638, ltk_data = 0x25, ltk_free = 0xb79ee2e0 <bdb_locker_id_free>}, {ltk_key = 0xb79e1800, ltk_data = 0x8dc39008, ltk_free = 0xb79e18d0 <search_stack_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 28 times>} tid = 2419321776 i = 606 hash = <value optimized out> #11 0xb7cc00bd in start_thread () from /lib/tls/libpthread.so.0 No symbol table info available. #12 0xb7c5501e in clone () from /lib/tls/libc.so.6 No symbol table info available. Thread 4 (Thread -1538888784 (LWP 22627)): #0 0xb7c55679 in epoll_wait () from /lib/tls/libc.so.6 No symbol table info available. #1 0x0806a0df in slapd_daemon_task (ptr=0x0) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/servers/slapd/daemon.c:2174 active = <value optimized out> l = 4 last_idle_check = 0 ebadf = 0 #2 0xb7cc00bd in start_thread () from /lib/tls/libpthread.so.0 No symbol table info available. #3 0xb7c5501e in clone () from /lib/tls/libc.so.6 No symbol table info available. Thread 1 (Thread -1212729120 (LWP 22601)): #0 0xb7cc1183 in pthread_join () from /lib/tls/libpthread.so.0 No symbol table info available. #1 0xb7f2e894 in ldap_pvt_thread_join (thread=2756078512, thread_return=0x0) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/libraries/libldap_r/thr_posix.c:193 No locals. #2 0x08067b06 in slapd_daemon () at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/servers/slapd/daemon.c:2579 listener_tid = 2756078512 rc = 0 #3 0x0805a309 in main (argc=9, argv=0xbfddf794) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/servers/slapd/main.c:859 save_errno = <value optimized out> fp = <value optimized out> i = 9 no_detach = 0 rc = 1 urls = 0x8140008 "ldap:/// ldaps:///" username = 0x8140030 "gidNumber" groupname = 0x8140020 "\202®Ê·°[\233·" sandbox = 0x0 syslogUser = 160 configfile = 0x8140040 "/etc/ldap/slapd.conf.master" configdir = 0x0 serverName = <value optimized out> scp = <value optimized out> scp_entry = <value optimized out> debug_unknowns = (char **) 0x0 syslog_unknowns = (char **) 0x0 l = <value optimized out> slapd_pid_file_unlink = 1 slapd_args_file_unlink = 1 __PRETTY_FUNCTION__ = "main" #0 0xb7bb1947 in raise () from /lib/tls/libc.so.6 Quitting: Can't detach LWP 22630: No such process -- John Morrissey _o /\ ---- __o jwm(a)horde.net _-< \_ / \ ---- < \, www.horde.net/ __(_)/_(_)________/ \_______(_) /_(_)__

1 0

Re: (ITS#5568) Multiple Suffix not working in 2.3.39 Release.
by h.b.furuseth＠usit.uio.no 19 Jun '08

19 Jun '08

quanah(a)zimbra.com writes: > Multiple suffixes are indeed supported, but your configuration is > completely invalid. Why so? Looks to me like a doc bug at best - the doc should say that _some_ backends support multiple suffixes, and for others one can use multiple databases instead. Though the latter may indeed be what the poster needed. BDB does support multiple suffixes #if defined(BDB_MULTIPLE_SUFFIXES), but it's undocumented except for a FAQ entry which doesn't look right: http://www.openldap.org/faq/data/cache/342.html I don't see how subordinates can be a substitute for multiple suffixes in a single database, since such suffixes should presumably not be subordinates of each other. -- Hallvard

1 0

Re: (ITS#5568) Multiple Suffix not working in 2.3.39 Release.
by quanah＠zimbra.com 19 Jun '08

19 Jun '08

--On Thursday, June 19, 2008 10:37 AM +0000 shravan.rathore(a)polaris.co.in wrote: > I went through threads on multiple suffix and it say, it will be > supported from 2.3 version. Software usage questions should be directed to openldap-software(a)openldap.org Multiple suffixes are indeed supported, but your configuration is completely invalid. I highly advise writing the above mentioned list to get help with configuring openldap. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#5568) Multiple Suffix not working in 2.3.39 Release.
by shravan.rathore＠polaris.co.in 19 Jun '08

19 Jun '08

Full_Name: Shravan R Version: 2.3.39 OS: Linux 2.4.9 URL: Submission from: (NULL) (202.168.89.5) I have an existing slapd configuration running fine with BDB 4.5.2. But when i add another suffix(ou=users is part of existing dc=armor) to this configuration, slapd starts, processes bdb details and stops on finding more than 1 suffix as shown in the debug log. slapd.conf details: database bdb suffix "dc=armor,dc=com" suffix "ou=users" rootdn "cn=root,dc=armor,dc=com" rootpw secret directory /root/Server2/local/var/openldap-data The Debug Log: backend_startup_one: starting "dc=armor,dc=com" bdb_db_open: dc=armor,dc=com bdb_db_open: only one suffix allowed backend_startup_one: bi_db_open failed! (-1) slapd shutdown: initiated ====> bdb_cache_release_all slapd destroy: freeing system resources. slapd stopped. connections_destroy: nothing to destroy. I went through threads on multiple suffix and it say, it will be supported from 2.3 version.

1 0

Re: (ITS#5520) infinite recursion in syncrepl overlay
by hyc＠symas.com 18 Jun '08

18 Jun '08

jeff(a)jeffrodriguez.com wrote: > Full_Name: Jeff Rodriguez > Version: 2.3.30 > OS: Debian etch > URL: ftp://ftp.openldap.org/incoming/jeff-rodriguez-080520.tgz > Submission from: (NULL) (208.48.140.97) > > > syncprov seems to be causing a segfault when importing kerberos entries. > > slapd.conf, LDIFs, heimdal kerberos schema, and logs included. These are live > files I was used to generate the segfault. It's also reproducible with the conf > and ldif files customized to the environment. Commenting out syncprov and > related lines in the conf eliminates the segfault. > > 1. stop slapd > 2. wipe out current database > 3. slapadd schema.ldif and chown the database to openldap user and group > 4. start slapd with: /usr/sbin/slapd -g openldap -u openldap -d 1 -h "ldap:/// > ldapi:///" > 5. add ldif entries live: ldapadd -H ldapi:///var/run/ldapi -D > cn=admin,o=example -w CHANGE_THIS_PASSWORD -f bugged.ldif > 6. segfault > > uname -a: > Linux ds1.phx2 2.6.18-6-xen-amd64 #1 SMP Sun Feb 10 18:02:52 UTC 2008 x86_64 > GNU/Linux Your slapd.conf is incorrect. Please re-read the slapo-syncprov(5) manpage; syncprov must be instantiated over a specific database. You have it configured in the global section, not on a specific database. This ITS will be closed. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5561) SEGV using TLS/SASL
by hyc＠symas.com 18 Jun '08

18 Jun '08

Lea Anthony wrote: > The version I have does not have debugging info, however I was able to get hold of this backtrace: > > > #0 0xb7b5bb05 in free () from /lib/libc.so.6 > #1 0xb7ac566e in _sasldb_getdata () from /usr/lib/sasl2/libsasldb.so.2 > #2 0xb7ac33d7 in sasldb_auxprop_lookup () from /usr/lib/sasl2/libsasldb.so.2 > #3 0xb7e2df6e in _sasl_auxprop_lookup () from /usr/lib/libsasl2.so.2 > #4 0xb7e2f6b4 in _sasl_canon_user () from /usr/lib/libsasl2.so.2 > #5 0xb7ac8425 in login_server_mech_step () from /usr/lib/sasl2/liblogin.so.2 > #6 0xb7e38567 in sasl_server_step () from /usr/lib/libsasl2.so.2 > #7 0x080a5c08 in ?? () > #8 0x08213c10 in ?? () > #9 0x082289fd in ?? () > #10 0x00000000 in ?? () > > Looks like the bug is in libsasl2 ? It seems so. > ----- Original Message ----- > From: "Howard Chu"<hyc(a)symas.com> > To: "lea anthony"<lea.anthony(a)meirion-dwyfor.ac.uk> > Cc: openldap-its(a)openldap.org > Sent: Tuesday, June 17, 2008 9:22:43 PM (GMT) Europe/London > Subject: Re: (ITS#5561) SEGV using TLS/SASL > > lea.anthony(a)meirion-dwyfor.ac.uk wrote: >> Full_Name: Lea Anthony >> Version: 2.3.40 >> OS: Arch Linux >> URL: http://pastebin.com/f6b680f22 >> Submission from: (NULL) (194.82.229.100) >> >> >> I have TLS setup as follows: >> >> TLSCertificateFile /etc/openldap/certs/cert.pem >> TLSCertificateKeyFile /etc/openldap/certs/key.pem >> TLSCipherSuite HIGH:MEDIUM:+TLSv1:+SSLv2:+SSLv3 >> >> The server starts fine and doing "ldapsearch -x -ZZ" will do an anonymous bind >> fine. >> >> However, doing "ldapsearch -ZZ" will cause a segfault on the server. The >> pastebin URL contains the post SSL negotiation debug lines from "slapd -d -1". > > I'm unable to reproduce this crash. Please provide a stack trace. > > http://www.openldap.org/faq/data/cache/59.html > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5567) v2.4.10 + gnutls: unable to get TLS client DN, works with openssl
by hyc＠symas.com 18 Jun '08

18 Jun '08

dev-zero(a)gentoo.org wrote: > Full_Name: Tiziano Müller > Version: 2.4.10 > OS: Gentoo Linux 2008.0 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (212.126.163.234) > > > I've generated certificates for the server and a client using my own CA. > The following works: > * client checks server certificate > * server checks client certificate > > Nevertheless the following keeped appearing in the log: > 2008-06-18T13:49:13.135510+02:00 localhost slapd[1771]: connection_read(14): > unable to get TLS client DN, error=-4 id=1 > > And I was therefore not able to use SASL/EXTERNAL. > > When I rebuilt OpenLDAP with OpenSSL instead of GnuTLS it suddenly worked (while > not changing anything else). > > The certificates have been generated using OpenSSL (even though this shouldn't > matter). Works fine for me. Most likely your GnuTLS is broken. See ITS#5515. This ITS will be closed. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5566) ACL Documentation Update
by ando＠sys-net.it 18 Jun '08

18 Jun '08

fkhan(a)emergen.biz wrote: > Full_Name: Faraz Khan > Version: 2.4.7 > OS: Linux Debian Etch > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (202.133.78.60) > > > Documentation update: OpenLdap 2.4 allows the use of the ADD and Zap ACLs (in > addition to write) to finely control whether an ADD or a Zap is allowed. Write = > Add + Zap > > This is not documented anywhere- was told to me by Pierangelo Masarati Now it's documented in the man page in HEAD, see <http://www.openldap.org/devel/cvsweb.cgi/doc/man/man5/slapd.access.5> for details. Please check. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: ando(a)sys-net.it -----------------------------------

1 0

(ITS#5567) v2.4.10 + gnutls: unable to get TLS client DN, works with openssl
by dev-zero＠gentoo.org 18 Jun '08

18 Jun '08

Full_Name: Tiziano Müller Version: 2.4.10 OS: Gentoo Linux 2008.0 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (212.126.163.234) I've generated certificates for the server and a client using my own CA. The following works: * client checks server certificate * server checks client certificate Nevertheless the following keeped appearing in the log: 2008-06-18T13:49:13.135510+02:00 localhost slapd[1771]: connection_read(14): unable to get TLS client DN, error=-4 id=1 And I was therefore not able to use SASL/EXTERNAL. When I rebuilt OpenLDAP with OpenSSL instead of GnuTLS it suddenly worked (while not changing anything else). The certificates have been generated using OpenSSL (even though this shouldn't matter).

1 0

(ITS#5566) ACL Documentation Update
by fkhan＠emergen.biz 18 Jun '08

18 Jun '08

Full_Name: Faraz Khan Version: 2.4.7 OS: Linux Debian Etch URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (202.133.78.60) Documentation update: OpenLdap 2.4 allows the use of the ADD and Zap ACLs (in addition to write) to finely control whether an ADD or a Zap is allowed. Write = Add + Zap This is not documented anywhere- was told to me by Pierangelo Masarati

1 0

Re: (ITS#5565) slapd crashes due to SIGPIPE
by hyc＠symas.com 18 Jun '08

18 Jun '08

jwm(a)horde.net wrote: > Full_Name: John Morrissey > Version: RE23-20080612 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (2001:4830:120d:0:21f:5bff:fee9:da92) > > > The fix for ITS 5469 stopped the assertion failures that caused slapd to crash, > but slapd continues to crash every few days due to receipt of SIGPIPEs. That is not possible; slapd explicitly ignores SIGPIPE. > We had > been running 2.3.41 plus the fix for ITS 5469, but upgraded to RE23 as of about > a week ago to make sure a fix wasn't already present. Below is a representative > backtrace. This trace is not indicative of a crash. You have to tell gdb not to stop when SIGPIPE is received in order to get an accurate view of the program behavior: "handle SIGPIPE nostop" -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#5565) slapd crashes due to SIGPIPE
by jwm＠horde.net 18 Jun '08

18 Jun '08

Full_Name: John Morrissey Version: RE23-20080612 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2001:4830:120d:0:21f:5bff:fee9:da92) The fix for ITS 5469 stopped the assertion failures that caused slapd to crash, but slapd continues to crash every few days due to receipt of SIGPIPEs. We had been running 2.3.41 plus the fix for ITS 5469, but upgraded to RE23 as of about a week ago to make sure a fix wasn't already present. Below is a representative backtrace. GNU gdb 6.4.90-debian Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i486-linux-gnu"...Using host libthread_db library "/lib/tls/libthread_db.so.1". [Thread debugging using libthread_db enabled] [New Thread -1212389152 (LWP 16459)] [New Thread -1883694160 (LWP 16466)] [New Thread -1879499856 (LWP 16465)] [New Thread -1875305552 (LWP 16464)] [New Thread -1538548816 (LWP 16463)] Failed to read a valid object file image from memory. 0xb7d14183 in pthread_join () from /lib/tls/libpthread.so.0 [New Thread -1917846608 (LWP 16495)] [New Thread -1931486288 (LWP 16496)] [New Thread -1935680592 (LWP 16497)] [New Thread -1939874896 (LWP 16498)] [New Thread -1944069200 (LWP 16499)] [New Thread -1948263504 (LWP 16500)] [New Thread -1952457808 (LWP 16501)] [New Thread -1956652112 (LWP 16502)] [New Thread -1960846416 (LWP 16503)] [New Thread -1965040720 (LWP 16504)] [New Thread -2121270352 (LWP 16587)] [New Thread 2132802480 (LWP 16724)] [New Thread 2079325104 (LWP 17194)] [New Thread 2032139184 (LWP 17346)] [New Thread 2027944880 (LWP 17347)] [New Thread 2023750576 (LWP 17348)] Program received signal SIGPIPE, Broken pipe. [Switching to Thread -2121270352 (LWP 16587)] 0xb7d18391 in __write_nocancel () from /lib/tls/libpthread.so.0 Thread 21 (Thread 2023750576 (LWP 17348)): #0 0xb7d15c01 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0 No symbol table info available. #1 0xb7f81754 in ldap_pvt_thread_cond_wait (cond=0x814d374, mutex=0x814d35c) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/libraries/libldap_r/thr_posix.c:299 No locals. #2 0xb7f81033 in ldap_int_thread_pool_wrapper (xpool=0x814d358) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/libraries/libldap_r/tpool.c:466 ctx = (ldap_int_thread_ctx_t *) 0x0 ltc_key = {{ltk_key = 0x80b73c0, ltk_data = 0x90bee38, ltk_free = 0x80b6f10 <slap_sl_mem_destroy>}, {ltk_key = 0x8217b18, ltk_data = 0x46, ltk_free = 0xb7a412e0 <bdb_locker_id_free>}, {ltk_key = 0x821d048, ltk_data = 0xca, ltk_free = 0xb7a412e0 <bdb_locker_id_free>}, {ltk_key = 0xb7a34800, ltk_data = 0x77cfe008, ltk_free = 0xb7a348d0 <search_stack_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 28 times>} tid = 2023750576 i = 706 hash = <value optimized out> #3 0xb7d130bd in start_thread () from /lib/tls/libpthread.so.0 No symbol table info available. #4 0xb7ca801e in clone () from /lib/tls/libc.so.6 No symbol table info available. Thread 20 (Thread 2027944880 (LWP 17347)): #0 0xb7d15c01 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0 No symbol table info available. #1 0xb7f81754 in ldap_pvt_thread_cond_wait (cond=0x814d374, mutex=0x814d35c) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/libraries/libldap_r/thr_posix.c:299 No locals. #2 0xb7f81033 in ldap_int_thread_pool_wrapper (xpool=0x814d358) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/libraries/libldap_r/tpool.c:466 ctx = (ldap_int_thread_ctx_t *) 0x0 ltc_key = {{ltk_key = 0x80b73c0, ltk_data = 0x9579580, ltk_free = 0x80b6f10 <slap_sl_mem_destroy>}, {ltk_key = 0x8217b18, ltk_data = 0x45, ltk_free = 0xb7a412e0 <bdb_locker_id_free>}, {ltk_key = 0x821d048, ltk_data = 0xc9, ltk_free = 0xb7a412e0 <bdb_locker_id_free>}, {ltk_key = 0xb7a34800, ltk_data = 0x76bfb008, ltk_free = 0xb7a348d0 <search_stack_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 28 times>} tid = 2027944880 i = 770 hash = <value optimized out> #3 0xb7d130bd in start_thread () from /lib/tls/libpthread.so.0 No symbol table info available. #4 0xb7ca801e in clone () from /lib/tls/libc.so.6 No symbol table info available. Thread 19 (Thread 2032139184 (LWP 17346)): #0 0xb7d15c01 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0 No symbol table info available. #1 0xb7f81754 in ldap_pvt_thread_cond_wait (cond=0x814d374, mutex=0x814d35c) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/libraries/libldap_r/thr_posix.c:299 No locals. #2 0xb7f81033 in ldap_int_thread_pool_wrapper (xpool=0x814d358) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/libraries/libldap_r/tpool.c:466 ctx = (ldap_int_thread_ctx_t *) 0x0 ltc_key = {{ltk_key = 0x80b73c0, ltk_data = 0x9447908, ltk_free = 0x80b6f10 <slap_sl_mem_destroy>}, {ltk_key = 0x821d048, ltk_data = 0xcb, ltk_free = 0xb7a412e0 <bdb_locker_id_free>}, {ltk_key = 0xb7a34800, ltk_data = 0x773fc008, ltk_free = 0xb7a348d0 <search_stack_free>}, {ltk_key = 0x8217b18, ltk_data = 0x48, ltk_free = 0xb7a412e0 <bdb_locker_id_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 28 times>} tid = 2032139184 i = 579 hash = <value optimized out> #3 0xb7d130bd in start_thread () from /lib/tls/libpthread.so.0 No symbol table info available. #4 0xb7ca801e in clone () from /lib/tls/libc.so.6 No symbol table info available. Thread 18 (Thread 2079325104 (LWP 17194)): #0 0xb7d15c01 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0 No symbol table info available. #1 0xb7f81754 in ldap_pvt_thread_cond_wait (cond=0x814d374, mutex=0x814d35c) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/libraries/libldap_r/thr_posix.c:299 No locals. #2 0xb7f81033 in ldap_int_thread_pool_wrapper (xpool=0x814d358) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/libraries/libldap_r/tpool.c:466 ctx = (ldap_int_thread_ctx_t *) 0x0 ltc_key = {{ltk_key = 0x80b73c0, ltk_data = 0x96a2e18, ltk_free = 0x80b6f10 <slap_sl_mem_destroy>}, {ltk_key = 0x8217b18, ltk_data = 0x43, ltk_free = 0xb7a412e0 <bdb_locker_id_free>}, {ltk_key = 0x821d048, ltk_data = 0xc3, ltk_free = 0xb7a412e0 <bdb_locker_id_free>}, {ltk_key = 0xb7a34800, ltk_data = 0x7b1fe008, ltk_free = 0xb7a348d0 <search_stack_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 28 times>} tid = 2079325104 i = 789 hash = <value optimized out> #3 0xb7d130bd in start_thread () from /lib/tls/libpthread.so.0 No symbol table info available. #4 0xb7ca801e in clone () from /lib/tls/libc.so.6 No symbol table info available. Thread 17 (Thread 2132802480 (LWP 16724)): #0 0xb7d15c01 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0 No symbol table info available. #1 0xb7f81754 in ldap_pvt_thread_cond_wait (cond=0x814d374, mutex=0x814d35c) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/libraries/libldap_r/thr_posix.c:299 No locals. #2 0xb7f81033 in ldap_int_thread_pool_wrapper (xpool=0x814d358) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/libraries/libldap_r/tpool.c:466 ctx = (ldap_int_thread_ctx_t *) 0x0 ltc_key = {{ltk_key = 0x80b73c0, ltk_data = 0x9a85110, ltk_free = 0x80b6f10 <slap_sl_mem_destroy>}, {ltk_key = 0x8217b18, ltk_data = 0x3f, ltk_free = 0xb7a412e0 <bdb_locker_id_free>}, {ltk_key = 0x821d048, ltk_data = 0xb9, ltk_free = 0xb7a412e0 <bdb_locker_id_free>}, {ltk_key = 0xb7a34800, ltk_data = 0x7e4fe008, ltk_free = 0xb7a348d0 <search_stack_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 28 times>} tid = 2132802480 i = 585 hash = <value optimized out> #3 0xb7d130bd in start_thread () from /lib/tls/libpthread.so.0 No symbol table info available. #4 0xb7ca801e in clone () from /lib/tls/libc.so.6 No symbol table info available. Thread 16 (Thread -2121270352 (LWP 16587)): #0 0xb7d18391 in __write_nocancel () from /lib/tls/libpthread.so.0 No symbol table info available. #1 0xb7f7117b in sb_stream_write (sbiod=0x752a7210, buf=0x7cd5c0f0, len=991) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/libraries/liblber/sockbuf.c:521 __PRETTY_FUNCTION__ = "sb_stream_write" #2 0xb7f7031a in sb_debug_write (sbiod=0x81a1a700, buf=0x7cd5c0f0, len=991) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/libraries/liblber/sockbuf.c:820 ret = <value optimized out> ebuf = "®◊\203\201\024\004∑\001\000\000\000»◊\203\201¡Â∑\214\203\201\001\000\000\000ÿ◊\203\201¡Â∑Ù\237∑\020\000∞\215∞\220E\177ÿ◊\203\201\214\203\201\002\000\000\000¯◊\203\201\206Â∑Ù\237∑\020\000∞\215\000|\006v¯◊\203\201\" ∑\020\000∞\215\000|\006vÃ=∑ﬂ\003\000\000\214\203\201\030ÿ\203\201\032Û∑\000|\006v&ÿ\203\201\002\000\000" #3 0xb7f706fa in ber_int_sb_write (sb=0x805e85c8, buf=0x7cd5c0f0, len=991) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/libraries/liblber/sockbuf.c:431 ret = 2094383344 __PRETTY_FUNCTION__ = "ber_int_sb_write" #4 0xb7f6e271 in ber_flush (sb=0x805e85c8, ber=0x8183dc8c, freeit=0) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/libraries/liblber/io.c:232 towrite = 991 rc = <value optimized out> __PRETTY_FUNCTION__ = "ber_flush" #5 0x0807bc50 in send_ldap_ber (conn=0x90395258, ber=0x8183dc8c) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/servers/slapd/result.c:169 err = <value optimized out> sd = 135491153 bytes = <value optimized out> #6 0x0807dd19 in slap_send_search_entry (op=0x8249e30, rs=0x818ff244) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/servers/slapd/result.c:1137 a_flags = 0x1 <Address 0x1 out of bounds> berbuf = {buffer = "\002\000\001\000\000\000\000\000ˇˇˇˇ\000\000\000\000\000\000\000\000¿||\203∆|\000\000\000\000¿|`\004$\b(\203\201÷\b\b0\236$\b@ÍÎ\177®m\024\b\000\000\000\000\004\000\000\000\000\000\000\000\030\203\201Ê\037§∑Tﬁ\031\b\f\203\201\f\203\201\030Î˙∑\bﬂ\031\b\000\000\000\000Pl\024\bÿ\031\bhÍÎ\177®m\024\b(\203\201©]\a\b®m\024\b®m\024\b\177\023\000\000\234\202§∑\234\202§∑®m\024\b®\203\201<∞\b\bhÍÎ\177®m\024\b®m\024\b\000\000\000\000\004", '\0' <repeats 11 times>, "|ÍÎ\177|ÍÎ\177@"..., ialign = 65538, lalign = 65538, falign = 9.18382988e-41, dalign = 3.2380074297143616e-319, palign = 0x10002 <Address 0x10002 out of bounds>} ber = (BerElement *) 0x8183dc8c a = (Attribute *) 0x8 i = 1 j = <value optimized out> rc = <value optimized out> edn = 0x7bf73fe9 "uid=frro,dc=example,dc=net,ou=example,ou=services,o=example" userattrs = 1 acl_state = {as_recorded = 3, as_vd_acl = 0x0, as_vi_acl = 0x0, as_vd_acl_mask = 0, as_vd_acl_matches = {{rm_so = 0, rm_eo = 0} <repeats 100 times>}, as_vd_acl_count = 0, as_vd_access = 0x0, as_vd_access_count = 0, as_result = 1, as_vd_ad = 0x8147818} attrsonly = 0 ad_entry = (AttributeDescription *) 0x814ad90 e_flags = (char **) 0x0 #7 0xb7a36c47 in bdb_search (op=0x8249e30, rs=0x818ff244) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/servers/slapd/back-bdb/search.c:879 tmp = <value optimized out> bdb = (struct bdb_info *) 0x819dda0 id = 22974 cursor = 22974 candidates = {4294967295, 1, 1313262, 1313262, 129256, 148982, 223840, 230794, 237887, 289589, 317961, 341644, 367994, 378937, 378938, 453353, 465641, 490658, 503779, 667838, 668870, 671656, 724757, 753641, 764925, 777799, 792698, 812499, 812975, 812987, 814369, 817151, 877121, 898662, 983276, 1112627, 1119375, 1153429, 1254426, 1259766, 1266923, 490658, 502854, 503779, 503780, 528024, 540294, 555215, 568268, 656373, 666293, 667838, 668117, 668249, 668870, 670958, 671656, 671658, 671659, 700279, 708367, 718093, 718369, 724757, 724761, 724780, 724786, 724824, 724825, 724826, 724827, 724828, 724829, 724830, 724831, 738243, 738244, 753641, 758836, 758920, 764925, 764935, 777799, 778136, 784632, 792698, 793162, 800788, 803042, 803175, 803252, 803278, 803279, 808236, 808237, 808238, 808239, 808240, 808241, 808242, 808243, 808244, 808245, 808246, 808247, 808248, 808249, 808250, 808251, 808252, 808253, 808254, 808255, 808256, 808257, 808259, 808260, 808261, 808262, 808263, 808264, 808265, 809986, 812499, 812561, 812580, 812581, 812583, 812975, 812987, 813382, 814369, 817151, 817178, 817202, 819246, 821181, 827140, 840827, 861880, 861882, 873796, 875019, 877121, 898662, 905424, 905652, 905765, 914437, 916170, 931884, 931885, 931886, 931887, 931888, 931889, 931890, 932267, 932567, 933299, 933300, 933303, 933312, 937699, 939581, 939839, 939840, 939841, 945216, 947697, 950353, 950568, 957598, 957615, 958338, 960887, 962469, 962649, 974914, 976521, 978098, 981242, 983276, 992317, 1003794, 1004230, 1009998, 1009999, 1010000, 1010001, 1010002, 1010003, 1010004, 1010005, 1010006, 1010145, 1010190, 1010505, 1011375, 1091234...} scopes = {0 <repeats 63708 times>, 3083069555, 0, 0, 3083012398, 135256458, 135256458, 0, 3083902964, 135256453, 5, 2173683752, 3082911727, 2173683788, 135256453, 5, 0, 0, 0, 2173683604, 3082910637, 0, 0, 2173683712, 0 <repeats 12 times>, 2173683936, 0, 0, 0, 0, 0, 0, 0, 0, 0, 4294967295, 25, 135256458, 135256451, 2173683604, 0, 11, 0 <repeats 16 times>, 1931476992, 20, 0 <repeats 29 times>, 135256452, 0, 0, 4294967295, 0, 0, 0, 2173684080, 0 <repeats 20 times>, 1858376075, 2173684964, 134914208, 2173684964, 2173682712, 134914251, 2222693328, 135575384, 0, 0, 0, 135575720, 2173682744, 135122385, 2173684964, 135575704, 0, 2173684964, 2173685080, 2173685084, 2173682776, 134911775, 135557712, 2173684964, 134914208, 0, 2173685080, 2173685084, 2173685000, 134906653, 2173682900, 0, 1032, 0, 0, 0, 0, 0, 2222693328, 0, 0, 2222693330, 0, 0, 0, 0, 0, 2, 135575504, 0 <repeats 32 times>, 135911368, 2173687244, 135822104, 2173683016, 134712206, 2173687244, 2173687824, 2173685096, 134802567, 2173687672, 0 <repeats 14 times>, 135911368, 2173687244, 135556520, 135821720, 134712206, 2173687244, 2173687824, 2173685192, 134802567, 2173687672, 0, 5119, 0 <repeats 15 times>...} e = (Entry *) 0x1 base = {e_id = 1, e_name = {bv_len = 593113393, bv_val = 0x30303030 <Address 0x30303030 out of bounds>}, e_nname = {bv_len = 10, bv_val = 0x7c04b408 "o=example"}, e_attrs = 0x30303030, e_ocflags = 0, e_bv = {bv_len = 3086412783, bv_val = 0x7ff70d80 "0\025\n\001\001\004\020\210¥æy\035\020'\236y©\200\\¿'"}, e_private = 0x821f418} e_root = {e_id = 0, e_name = {bv_len = 0, bv_val = 0x0}, e_nname = {bv_len = 0, bv_val = 0x0}, e_attrs = 0x0, e_ocflags = 0, e_bv = {bv_len = 0, bv_val = 0x0}, e_private = 0x0} matched = (Entry *) 0x0 ei = (EntryInfo *) 0x84012780 ei_root = {bei_parent = 0x0, bei_id = 0, bei_lockpad = 0, bei_state = 0, bei_nrdn = {bv_len = 0, bv_val = 0x0}, bei_e = 0x0, bei_kids = 0x0, bei_kids_mutex = {__m_reserved = 0, __m_count = 0, __m_owner = 0x0, __m_kind = 0, __m_lock = {__status = 0, __spinlock = 0}}, bei_lrunext = 0x0, bei_lruprev = 0x0} realbase = {bv_len = 10, bv_val = 0x7c04b408 "o=example"} manageDSAit = 2 tentries = 1313262 lastid = 4294967295 locker = 169 lock = {off = 288056, ndx = 642, gen = 153211, mode = DB_LOCK_READ} ltid = (DB_TXN *) 0x0 #8 0x080c57e0 in overlay_op_walk (op=0x8249e30, rs=0x818ff244, which=op_search, oi=0x819ed18, on=0x819f0e8) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/servers/slapd/backover.c:650 sc_next = <value optimized out> rc = 32768 #9 0x080c5bde in over_op_func (op=0x8249e30, rs=0x818ff244, which=op_search) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/servers/slapd/backover.c:702 oi = (slap_overinfo *) 0x819ed18 on = (slap_overinst *) 0x819f0e8 be = (BackendDB *) 0x819dc98 db = {bd_info = 0xb7a489c0, be_ctrls = "\000\001\001\001\000\000\001\000\001\000\001\001\001\000\001", '\0' <repeats 17 times>, "\001", be_flags = 256, be_restrictops = 0, be_requires = 0, be_ssf_set = {sss_ssf = 0, sss_transport = 0, sss_tls = 0, sss_sasl = 0, sss_update_ssf = 0, sss_update_transport = 0, sss_update_tls = 0, sss_update_sasl = 0, sss_simple_bind = 0}, be_suffix = 0x819e028, be_nsuffix = 0x819e040, be_schemadn = {bv_len = 0, bv_val = 0x0}, be_schemandn = {bv_len = 0, bv_val = 0x0}, be_rootdn = {bv_len = 18, bv_val = 0x819d880 "cn=root,o=example"}, be_rootndn = {bv_len = 18, bv_val = 0x819e300 "cn=root,o=example"}, be_rootpw = {bv_len = 20, bv_val = 0x819e078 "{crypt}bo3zUPoqIZwko"}, be_max_deref_depth = 15, be_def_limit = {lms_t_soft = 3600, lms_t_hard = 0, lms_s_soft = 500, lms_s_hard = 0, lms_s_unchecked = -1, lms_s_pr = 0, lms_s_pr_hide = 0, lms_s_pr_total = 0}, be_limits = 0x819d900, be_acl = 0x818c9e8, be_dfltaccess = ACL_READ, be_replica = 0x819e680, be_replogfile = 0x819b958 "/var/lib/ldap/replog", be_update_ndn = {bv_len = 0, bv_val = 0x0}, be_update_refs = 0x0, be_pending_csn_list = 0x82257d0, be_pcl_mutex = {__m_reserved = 0, __m_count = 0, __m_owner = 0x0, __m_kind = 0, __m_lock = {__status = 0, __spinlock = 0}}, be_pcl_mutexp = 0x819dd68, be_syncinfo = 0x0, be_pb = 0x0, be_cf_ocs = 0xb7a48660, be_private = 0x819dda0, be_next = {stqe_next = 0x0}} cb = {sc_next = 0x0, sc_response = 0x80c5550 <over_back_response>, sc_cleanup = 0, sc_private = 0x819ed18} rc = -32 __PRETTY_FUNCTION__ = "over_op_func" #10 0x0806f852 in fe_op_search (op=0x8249e30, rs=0x818ff244) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/servers/slapd/search.c:355 entry = (Entry *) 0x11 bd = (BackendDB *) 0x813f120 #11 0x0807015b in do_search (op=0x8249e30, rs=0x818ff244) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/servers/slapd/search.c:217 base = {bv_len = 10, bv_val = 0x7d8ede07 "o=example"} siz = 2 i = 2098471528 #12 0x0806d5cb in connection_operation (ctx=0x818ff2c8, arg_v=0x8249e30) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/servers/slapd/connection.c:1133 curelm = <value optimized out> rc = <value optimized out> rs = {sr_type = REP_SEARCH, sr_tag = 0, sr_msgid = 0, sr_err = 0, sr_matched = 0x0, sr_text = 0x0, sr_ref = 0x0, sr_ctrls = 0x814fefe4, sr_un = {sru_sasl = {r_sasldata = 0x7febea40}, sru_extended = {r_rspoid = 0x7febea40 "æY", r_rspdata = 0x22}, sru_search = {r_entry = 0x7febea40, r_attr_flags = 34, r_operational_attrs = 0x7ff58880, r_attrs = 0x813ff0e4, r_nentries = 18048, r_v2ref = 0x0}}, sr_flags = 0} tag = 99 opidx = SLAP_OP_SEARCH conn = (Connection *) 0x90395258 memctx = (void *) 0x8240460 memctx_null = (void *) 0x0 __PRETTY_FUNCTION__ = "connection_operation" #13 0xb7f80eff in ldap_int_thread_pool_wrapper (xpool=0x814d358) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/libraries/libldap_r/tpool.c:478 ctx = (ldap_int_thread_ctx_t *) 0x7f2a5738 ltc_key = {{ltk_key = 0x80b73c0, ltk_data = 0x8240460, ltk_free = 0x80b6f10 <slap_sl_mem_destroy>}, {ltk_key = 0x8217b18, ltk_data = 0x3e, ltk_free = 0xb7a412e0 <bdb_locker_id_free>}, {ltk_key = 0x821d048, ltk_data = 0xa9, ltk_free = 0xb7a412e0 <bdb_locker_id_free>}, {ltk_key = 0xb7a34800, ltk_data = 0x80bfe008, ltk_free = 0xb7a348d0 <search_stack_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 28 times>} tid = 2173696944 i = 699 hash = <value optimized out> #14 0xb7d130bd in start_thread () from /lib/tls/libpthread.so.0 No symbol table info available. #15 0xb7ca801e in clone () from /lib/tls/libc.so.6 No symbol table info available. Thread 15 (Thread -1965040720 (LWP 16504)): #0 bdb_idl_next (ids=0x87df1008, cursor=0x8ad3bae8) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/servers/slapd/back-bdb/idl.c:1283 No locals. #1 0xb7a3e374 in bdb_idl_union (a=0x87df1008, b=0x87cf1008) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/servers/slapd/back-bdb/idl.c:1155 ida = 2035086 idb = 2075672 cursora = 66972 cursorb = 1 cursorc = 66972 #2 0xb7a39b78 in inequality_candidates (op=0x8db15bd8, ava=0x8a7fc1f4, ids=0x87df1008, tmp=0x87cf1008, gtorlt=165) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/servers/slapd/back-bdb/filterindex.c:1063 db = (DB *) 0x82257e0 rc = 0 mask = 4 prefix = {bv_len = 8, bv_val = 0x8147df8 "entryCSN"} keys = (struct berval *) 0x8a7fc31c mr = <value optimized out> cursor = (DBC *) 0x8225d78 #3 0xb7a3ae77 in bdb_filter_candidates (op=0x8db15bd8, f=0x8a7fc1e4, ids=0x87df1008, tmp=0x87cf1008, stack=0x87e71008) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/servers/slapd/back-bdb/filterindex.c:168 rc = <value optimized out> #4 0xb7a3a0d8 in list_candidates (op=0x8db15bd8, flist=0x8a7fc1e4, ftype=160, ids=0x87d71008, tmp=0x87cf1008, save=0x87df1008) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/servers/slapd/back-bdb/filterindex.c:503 rc = 0 f = (Filter *) 0x8a7fc1e4 #5 0xb7a3a902 in bdb_filter_candidates (op=0x8db15bd8, f=0x8a7fc1d4, ids=0x87d71008, tmp=0x87cf1008, stack=0x87df1008) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/servers/slapd/back-bdb/filterindex.c:183 rc = <value optimized out> #6 0xb7a3a0d8 in list_candidates (op=0x8db15bd8, flist=0x8adfbf74, ftype=160, ids=0x8ad3be7c, tmp=0x87cf1008, save=0x87d71008) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/servers/slapd/back-bdb/filterindex.c:503 rc = 0 f = (Filter *) 0x8a7fc1d4 #7 0xb7a3a902 in bdb_filter_candidates (op=0x8db15bd8, f=0x8adfbf98, ids=0x8ad3be7c, tmp=0x87cf1008, stack=0x87d71008) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/servers/slapd/back-bdb/filterindex.c:183 rc = <value optimized out> #8 0xb7a3588f in bdb_search (op=0x8db15bd8, rs=0x8adfd244) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/servers/slapd/back-bdb/search.c:1124 reqcookie = <value optimized out> bdb = (struct bdb_info *) 0x819d478 id = <value optimized out> cursor = <value optimized out> candidates = {4294967295, 1, 2080041, 1313249, 37648, 55686, 74393, 101230, 123347, 126534, 129256, 132836, 136049, 139750, 142174, 146626, 148982, 185595, 223840, 230794, 237887, 289589, 289590, 289591, 290042, 301562, 317960, 317961, 341643, 341644, 367994, 372843, 378937, 378938, 390817, 424400, 424401, 453353, 464904, 465641, 490657, 490658, 502854, 503779, 503780, 528024, 540294, 555215, 568268, 656373, 666293, 667838, 668117, 668249, 668870, 670958, 671656, 671658, 671659, 700279, 708367, 718093, 718369, 724757, 724761, 724780, 724786, 724824, 724825, 724826, 724827, 724828, 724829, 724830, 724831, 738243, 738244, 753641, 758836, 758920, 764925, 764935, 777799, 778136, 784632, 792698, 793162, 800788, 803042, 803175, 803252, 803278, 803279, 808236, 808237, 808238, 808239, 808240, 808241, 808242, 808243, 808244, 808245, 808246, 808247, 808248, 808249, 808250, 808251, 808252, 808253, 808254, 808255, 808256, 808257, 808259, 808260, 808261, 808262, 808263, 808264, 808265, 809986, 812499, 812561, 812580, 812581, 812583, 812975, 812987, 813382, 814369, 817151, 817178, 817202, 819246, 821181, 827140, 840827, 861880, 861882, 873796, 875019, 877121, 898662, 905424, 905652, 905765, 914437, 916170, 931884, 931885, 931886, 931887, 931888, 931889, 931890, 932267, 932567, 933299, 933300, 933303, 933312, 937699, 939581, 939839, 939840, 939841, 945216, 947697, 950353, 950568, 957598, 957615, 958338, 960887, 962469, 962649, 974914, 976521, 978098, 981242, 983276, 992317, 1003794, 1004230, 1009998, 1009999, 1010000, 1010001, 1010002, 1010003, 1010004, 1010005, 1010006, 1010145, 1010190, 1010505, 1011375, 1091234...} scopes = {0 <repeats 63708 times>, 3083069555, 0, 0, 3083012398, 135256458, 135256458, 0, 3083902964, 135256453, 5, 2329913384, 3082911727, 2329913420, 135256453, 5, 0, 0, 0, 2329913236, 3082910637, 0, 0, 2329913344, 0 <repeats 12 times>, 2329913568, 0, 0, 0, 0, 0, 0, 0, 0, 0, 4294967295, 25, 135256458, 135256451, 2329913236, 0, 11, 0 <repeats 16 times>, 1931476992, 20, 0 <repeats 29 times>, 135256452, 0, 0, 4294967295, 0, 0, 0, 2329913712, 0 <repeats 20 times>, 1858376075, 2329914596, 134914208, 2329914596, 2329912344, 134914251, 161455880, 135575384, 0, 0, 0, 135575720, 2329912376, 135122385, 2329914596, 135575704, 0, 2329914596, 2329914712, 2329914716, 2329912408, 134911775, 135557712, 2329914596, 134914208, 0, 2329914712, 2329914716, 2329914632, 134906653, 2329912532, 0, 1032, 0, 0, 0, 0, 0, 161455880, 0, 0, 161455882, 0, 0, 0, 0, 0, 2, 135575504, 0 <repeats 32 times>, 135911368, 2329916876, 135822104, 2329912648, 134712206, 2329916876, 2329917456, 2329914728, 134802567, 2329917304, 0 <repeats 14 times>, 135911368, 2329916876, 135556520, 135821720, 134712206, 2329916876, 2329917456, 2329914824, 134802567, 2329917304, 0, 5119, 0 <repeats 15 times>...} e = <value optimized out> base = {e_id = 1, e_name = {bv_len = 593114419, bv_val = 0x30303030 <Address 0x30303030 out of bounds>}, e_nname = {bv_len = 6, bv_val = 0x8077c970 "cn=log"}, e_attrs = 0x30303030, e_ocflags = 0, e_bv = {bv_len = 3086412783, bv_val = 0x0}, e_private = 0x8225420} e_root = {e_id = 0, e_name = {bv_len = 0, bv_val = 0x0}, e_nname = {bv_len = 0, bv_val = 0x0}, e_attrs = 0x0, e_ocflags = 0, e_bv = {bv_len = 0, bv_val = 0x0}, e_private = 0x0} matched = (Entry *) 0x0 ei = (EntryInfo *) 0x8225420 ei_root = {bei_parent = 0x0, bei_id = 0, bei_lockpad = 0, bei_state = 0, bei_nrdn = {bv_len = 0, bv_val = 0x0}, bei_e = 0x0, bei_kids = 0x0, bei_kids_mutex = {__m_reserved = 0, __m_count = 0, __m_owner = 0x0, __m_kind = 0, __m_lock = {__status = 0, __spinlock = 0}}, bei_lrunext = 0x0, bei_lruprev = 0x0} realbase = {bv_len = 6, bv_val = 0x8077c970 "cn=log"} manageDSAit = 2 tentries = <value optimized out> lastid = 4294967295 locker = 52 lock = {off = 0, ndx = 386, gen = 30592, mode = DB_LOCK_READ} ltid = (DB_TXN *) 0x0 #9 0x080c57e0 in overlay_op_walk (op=0x8db15bd8, rs=0x8adfd244, which=op_search, oi=0x819d960, on=0x819da60) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/servers/slapd/backover.c:650 sc_next = <value optimized out> rc = 32768 #10 0x080c5bde in over_op_func (op=0x8db15bd8, rs=0x8adfd244, which=op_search) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/servers/slapd/backover.c:702 oi = (slap_overinfo *) 0x819d960 on = (slap_overinst *) 0x819da60 be = (BackendDB *) 0x819d370 db = {bd_info = 0xb7a489c0, be_ctrls = "\000\001\001\001\000\000\001\000\001\000\001\001\001\000\001", '\0' <repeats 17 times>, "\001", be_flags = 256, be_restrictops = 0, be_requires = 0, be_ssf_set = {sss_ssf = 0, sss_transport = 0, sss_tls = 0, sss_sasl = 0, sss_update_ssf = 0, sss_update_transport = 0, sss_update_tls = 0, sss_update_sasl = 0, sss_simple_bind = 0}, be_suffix = 0x819d728, be_nsuffix = 0x819d740, be_schemadn = {bv_len = 0, bv_val = 0x0}, be_schemandn = {bv_len = 0, bv_val = 0x0}, be_rootdn = {bv_len = 14, bv_val = 0x819d5e0 "cn=root,cn=log"}, be_rootndn = {bv_len = 14, bv_val = 0x819d7c8 "cn=root,cn=log"}, be_rootpw = {bv_len = 0, bv_val = 0x0}, be_max_deref_depth = 15, be_def_limit = {lms_t_soft = 3600, lms_t_hard = 0, lms_s_soft = 500, lms_s_hard = 0, lms_s_unchecked = -1, lms_s_pr = 0, lms_s_pr_hide = 0, lms_s_pr_total = 0}, be_limits = 0x819d7b8, be_acl = 0x818c9e8, be_dfltaccess = ACL_READ, be_replica = 0x0, be_replogfile = 0x0, be_update_ndn = {bv_len = 0, bv_val = 0x0}, be_update_refs = 0x0, be_pending_csn_list = 0x8217800, be_pcl_mutex = {__m_reserved = 0, __m_count = 0, __m_owner = 0x0, __m_kind = 0, __m_lock = {__status = 0, __spinlock = 0}}, be_pcl_mutexp = 0x819d440, be_syncinfo = 0x0, be_pb = 0x0, be_cf_ocs = 0xb7a48660, be_private = 0x819d478, be_next = {stqe_next = 0x819dc98}} cb = {sc_next = 0x0, sc_response = 0x80c5550 <over_back_response>, sc_cleanup = 0, sc_private = 0x819d960} rc = 66972 __PRETTY_FUNCTION__ = "over_op_func" #11 0x0806f852 in fe_op_search (op=0x8db15bd8, rs=0x8adfd244) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/servers/slapd/search.c:355 entry = (Entry *) 0x36 bd = (BackendDB *) 0x813f120 #12 0x0807015b in do_search (op=0x8db15bd8, rs=0x8adfd244) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/servers/slapd/search.c:217 base = {bv_len = 6, bv_val = 0x7a8f4e0f "cn=log"} siz = 2 i = 135910464 #13 0x0806d5cb in connection_operation (ctx=0x8adfd2c8, arg_v=0x8db15bd8) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/servers/slapd/connection.c:1133 curelm = <value optimized out> rc = <value optimized out> rs = {sr_type = REP_RESULT, sr_tag = 0, sr_msgid = 0, sr_err = 0, sr_matched = 0x0, sr_text = 0x0, sr_ref = 0x0, sr_ctrls = 0x0, sr_un = {sru_sasl = {r_sasldata = 0x0}, sru_extended = {r_rspoid = 0x0, r_rspdata = 0x0}, sru_search = {r_entry = 0x0, r_attr_flags = 0, r_operational_attrs = 0x0, r_attrs = 0x0, r_nentries = 0, r_v2ref = 0x0}}, sr_flags = 0} tag = 99 opidx = SLAP_OP_SEARCH conn = (Connection *) 0x90395dd8 memctx = (void *) 0x8436bc8 memctx_null = (void *) 0x0 __PRETTY_FUNCTION__ = "connection_operation" #14 0xb7f80eff in ldap_int_thread_pool_wrapper (xpool=0x814d358) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/libraries/libldap_r/tpool.c:478 ctx = (ldap_int_thread_ctx_t *) 0x8db10070 ltc_key = {{ltk_key = 0x80b73c0, ltk_data = 0x8436bc8, ltk_free = 0x80b6f10 <slap_sl_mem_destroy>}, {ltk_key = 0x8217b18, ltk_data = 0x34, ltk_free = 0xb7a412e0 <bdb_locker_id_free>}, {ltk_key = 0x821d048, ltk_data = 0x70, ltk_free = 0xb7a412e0 <bdb_locker_id_free>}, {ltk_key = 0xb7a34800, ltk_data = 0x87cf1008, ltk_free = 0xb7a348d0 <search_stack_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 28 times>} tid = 2329926576 i = 756 hash = <value optimized out> #15 0xb7d130bd in start_thread () from /lib/tls/libpthread.so.0 No symbol table info available. #16 0xb7ca801e in clone () from /lib/tls/libc.so.6 No symbol table info available. Thread 14 (Thread -1960846416 (LWP 16503)): #0 0xb7d15c01 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0 No symbol table info available. #1 0xb7f81754 in ldap_pvt_thread_cond_wait (cond=0x814d374, mutex=0x814d35c) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/libraries/libldap_r/thr_posix.c:299 No locals. #2 0xb7f81033 in ldap_int_thread_pool_wrapper (xpool=0x814d358) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/libraries/libldap_r/tpool.c:466 ctx = (ldap_int_thread_ctx_t *) 0x0 ltc_key = {{ltk_key = 0x80b73c0, ltk_data = 0x8db13408, ltk_free = 0x80b6f10 <slap_sl_mem_destroy>}, {ltk_key = 0x8217b18, ltk_data = 0x38, ltk_free = 0xb7a412e0 <bdb_locker_id_free>}, {ltk_key = 0x821d048, ltk_data = 0x67, ltk_free = 0xb7a412e0 <bdb_locker_id_free>}, {ltk_key = 0xb7a34800, ltk_data = 0x88cf3008, ltk_free = 0xb7a348d0 <search_stack_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 28 times>} tid = 2334120880 i = 565 hash = <value optimized out> #3 0xb7d130bd in start_thread () from /lib/tls/libpthread.so.0 No symbol table info available. #4 0xb7ca801e in clone () from /lib/tls/libc.so.6 No symbol table info available. Thread 13 (Thread -1956652112 (LWP 16502)): #0 0xb7d15c01 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0 No symbol table info available. #1 0xb7f81754 in ldap_pvt_thread_cond_wait (cond=0x814d374, mutex=0x814d35c) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/libraries/libldap_r/thr_posix.c:299 No locals. #2 0xb7f81033 in ldap_int_thread_pool_wrapper (xpool=0x814d358) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/libraries/libldap_r/tpool.c:466 ctx = (ldap_int_thread_ctx_t *) 0x0 ltc_key = {{ltk_key = 0x80b73c0, ltk_data = 0x8a600470, ltk_free = 0x80b6f10 <slap_sl_mem_destroy>}, {ltk_key = 0x8217b18, ltk_data = 0x39, ltk_free = 0xb7a412e0 <bdb_locker_id_free>}, {ltk_key = 0x821d048, ltk_data = 0x7a, ltk_free = 0xb7a412e0 <bdb_locker_id_free>}, {ltk_key = 0xb7a34800, ltk_data = 0x864ee008, ltk_free = 0xb7a348d0 <search_stack_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 28 times>} tid = 2338315184 i = 629 hash = <value optimized out> #3 0xb7d130bd in start_thread () from /lib/tls/libpthread.so.0 No symbol table info available. #4 0xb7ca801e in clone () from /lib/tls/libc.so.6 No symbol table info available. Thread 12 (Thread -1952457808 (LWP 16501)): #0 0xb7d15c01 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0 No symbol table info available. #1 0xb7f81754 in ldap_pvt_thread_cond_wait (cond=0x814d374, mutex=0x814d35c) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/libraries/libldap_r/thr_posix.c:299 No locals. #2 0xb7f81033 in ldap_int_thread_pool_wrapper (xpool=0x814d358) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/libraries/libldap_r/tpool.c:466 ctx = (ldap_int_thread_ctx_t *) 0x0 ltc_key = {{ltk_key = 0x80b73c0, ltk_data = 0x8db11ab0, ltk_free = 0x80b6f10 <slap_sl_mem_destroy>}, {ltk_key = 0x8217b18, ltk_data = 0x35, ltk_free = 0xb7a412e0 <bdb_locker_id_free>}, {ltk_key = 0x821d048, ltk_data = 0x9b, ltk_free = 0xb7a412e0 <bdb_locker_id_free>}, {ltk_key = 0xb7a34800, ltk_data = 0x854ec008, ltk_free = 0xb7a348d0 <search_stack_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 28 times>} tid = 2342509488 i = 693 hash = <value optimized out> #3 0xb7d130bd in start_thread () from /lib/tls/libpthread.so.0 No symbol table info available. #4 0xb7ca801e in clone () from /lib/tls/libc.so.6 No symbol table info available. Thread 11 (Thread -1948263504 (LWP 16500)): #0 0xb7d15c01 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0 No symbol table info available. #1 0xb7f81754 in ldap_pvt_thread_cond_wait (cond=0x814d374, mutex=0x814d35c) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/libraries/libldap_r/thr_posix.c:299 No locals. #2 0xb7f81033 in ldap_int_thread_pool_wrapper (xpool=0x814d358) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/libraries/libldap_r/tpool.c:466 ctx = (ldap_int_thread_ctx_t *) 0x0 ltc_key = {{ltk_key = 0x80b73c0, ltk_data = 0x8438b90, ltk_free = 0x80b6f10 <slap_sl_mem_destroy>}, {ltk_key = 0x8217b18, ltk_data = 0x3d, ltk_free = 0xb7a412e0 <bdb_locker_id_free>}, {ltk_key = 0x821d048, ltk_data = 0x9a, ltk_free = 0xb7a412e0 <bdb_locker_id_free>}, {ltk_key = 0xb7a34800, ltk_data = 0x85ced008, ltk_free = 0xb7a348d0 <search_stack_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 28 times>} tid = 2346703792 i = 757 hash = <value optimized out> #3 0xb7d130bd in start_thread () from /lib/tls/libpthread.so.0 No symbol table info available. #4 0xb7ca801e in clone () from /lib/tls/libc.so.6 No symbol table info available. Thread 10 (Thread -1944069200 (LWP 16499)): #0 0xb7d15c01 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0 No symbol table info available. #1 0xb7f81754 in ldap_pvt_thread_cond_wait (cond=0x814d374, mutex=0x814d35c) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/libraries/libldap_r/thr_posix.c:299 No locals. #2 0xb7f81033 in ldap_int_thread_pool_wrapper (xpool=0x814d358) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/libraries/libldap_r/tpool.c:466 ctx = (ldap_int_thread_ctx_t *) 0x0 ltc_key = {{ltk_key = 0x80b73c0, ltk_data = 0x8a600498, ltk_free = 0x80b6f10 <slap_sl_mem_destroy>}, {ltk_key = 0x8217b18, ltk_data = 0x3c, ltk_free = 0xb7a412e0 <bdb_locker_id_free>}, {ltk_key = 0x821d048, ltk_data = 0x60, ltk_free = 0xb7a412e0 <bdb_locker_id_free>}, {ltk_key = 0xb7a34800, ltk_data = 0x895f5008, ltk_free = 0xb7a348d0 <search_stack_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 28 times>} tid = 2350898096 i = 566 hash = <value optimized out> #3 0xb7d130bd in start_thread () from /lib/tls/libpthread.so.0 No symbol table info available. #4 0xb7ca801e in clone () from /lib/tls/libc.so.6 No symbol table info available. Thread 9 (Thread -1939874896 (LWP 16498)): #0 0xb7d15c01 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0 No symbol table info available. #1 0xb7f81754 in ldap_pvt_thread_cond_wait (cond=0x814d374, mutex=0x814d35c) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/libraries/libldap_r/thr_posix.c:299 No locals. #2 0xb7f81033 in ldap_int_thread_pool_wrapper (xpool=0x814d358) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/libraries/libldap_r/tpool.c:466 ctx = (ldap_int_thread_ctx_t *) 0x0 ltc_key = {{ltk_key = 0x80b73c0, ltk_data = 0x8436b20, ltk_free = 0x80b6f10 <slap_sl_mem_destroy>}, {ltk_key = 0x8217b18, ltk_data = 0x3a, ltk_free = 0xb7a412e0 <bdb_locker_id_free>}, {ltk_key = 0x821d048, ltk_data = 0x68, ltk_free = 0xb7a412e0 <bdb_locker_id_free>}, {ltk_key = 0xb7a34800, ltk_data = 0x884f2008, ltk_free = 0xb7a348d0 <search_stack_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 28 times>} tid = 2355092400 i = 630 hash = <value optimized out> #3 0xb7d130bd in start_thread () from /lib/tls/libpthread.so.0 No symbol table info available. #4 0xb7ca801e in clone () from /lib/tls/libc.so.6 No symbol table info available. Thread 8 (Thread -1935680592 (LWP 16497)): #0 0xb7d15c01 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0 No symbol table info available. #1 0xb7f81754 in ldap_pvt_thread_cond_wait (cond=0x814d374, mutex=0x814d35c) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/libraries/libldap_r/thr_posix.c:299 No locals. #2 0xb7f81033 in ldap_int_thread_pool_wrapper (xpool=0x814d358) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/libraries/libldap_r/tpool.c:466 ctx = (ldap_int_thread_ctx_t *) 0x0 ltc_key = {{ltk_key = 0x80b73c0, ltk_data = 0x8435218, ltk_free = 0x80b6f10 <slap_sl_mem_destroy>}, {ltk_key = 0x8217b18, ltk_data = 0x37, ltk_free = 0xb7a412e0 <bdb_locker_id_free>}, {ltk_key = 0x821d048, ltk_data = 0x73, ltk_free = 0xb7a412e0 <bdb_locker_id_free>}, {ltk_key = 0xb7a34800, ltk_data = 0x86cef008, ltk_free = 0xb7a348d0 <search_stack_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 28 times>} tid = 2359286704 i = 694 hash = <value optimized out> #3 0xb7d130bd in start_thread () from /lib/tls/libpthread.so.0 No symbol table info available. #4 0xb7ca801e in clone () from /lib/tls/libc.so.6 No symbol table info available. Thread 7 (Thread -1931486288 (LWP 16496)): #0 0xb7d15c01 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0 No symbol table info available. #1 0xb7f81754 in ldap_pvt_thread_cond_wait (cond=0x814d374, mutex=0x814d35c) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/libraries/libldap_r/thr_posix.c:299 No locals. #2 0xb7f81033 in ldap_int_thread_pool_wrapper (xpool=0x814d358) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/libraries/libldap_r/tpool.c:466 ctx = (ldap_int_thread_ctx_t *) 0x0 ltc_key = {{ltk_key = 0x80b73c0, ltk_data = 0x8436b48, ltk_free = 0x80b6f10 <slap_sl_mem_destroy>}, {ltk_key = 0x8217b18, ltk_data = 0x3b, ltk_free = 0xb7a412e0 <bdb_locker_id_free>}, {ltk_key = 0x821d048, ltk_data = 0x71, ltk_free = 0xb7a412e0 <bdb_locker_id_free>}, {ltk_key = 0xb7a34800, ltk_data = 0x874f0008, ltk_free = 0xb7a348d0 <search_stack_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 28 times>} tid = 2363481008 i = 758 hash = <value optimized out> #3 0xb7d130bd in start_thread () from /lib/tls/libpthread.so.0 No symbol table info available. #4 0xb7ca801e in clone () from /lib/tls/libc.so.6 No symbol table info available. Thread 6 (Thread -1917846608 (LWP 16495)): #0 0xb7d15c01 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0 No symbol table info available. #1 0xb7f81754 in ldap_pvt_thread_cond_wait (cond=0x814d374, mutex=0x814d35c) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/libraries/libldap_r/thr_posix.c:299 No locals. #2 0xb7f81033 in ldap_int_thread_pool_wrapper (xpool=0x814d358) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/libraries/libldap_r/tpool.c:466 ctx = (ldap_int_thread_ctx_t *) 0x0 ltc_key = {{ltk_key = 0x80b73c0, ltk_data = 0x8437a28, ltk_free = 0x80b6f10 <slap_sl_mem_destroy>}, {ltk_key = 0x821d048, ltk_data = 0x5f, ltk_free = 0xb7a412e0 <bdb_locker_id_free>}, {ltk_key = 0xb7a34800, ltk_data = 0x8cdfe008, ltk_free = 0xb7a348d0 <search_stack_free>}, {ltk_key = 0x8217b18, ltk_data = 0x36, ltk_free = 0xb7a412e0 <bdb_locker_id_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 28 times>} tid = 2377120688 i = 743 hash = <value optimized out> #3 0xb7d130bd in start_thread () from /lib/tls/libpthread.so.0 No symbol table info available. #4 0xb7ca801e in clone () from /lib/tls/libc.so.6 No symbol table info available. Thread 5 (Thread -1538548816 (LWP 16463)): #0 0xb7d18189 in __lll_mutex_lock_wait () from /lib/tls/libpthread.so.0 No symbol table info available. #1 0xb7d14f6d in _L_mutex_lock_29 () from /lib/tls/libpthread.so.0 No symbol table info available. #2 0xa44b6258 in ?? () No symbol table info available. #3 0xb7f6d846 in ber_get_next (sb=0x90395268, len=0x90395258, ber=0x404f) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/libraries/liblber/io.c:504 sblen = <value optimized out> buf = "\000\000" tlen = 2419675752 __PRETTY_FUNCTION__ = "ber_get_next" #4 0xb7f816bd in ldap_pvt_thread_mutex_lock (mutex=0x90395268) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/libraries/libldap_r/thr_posix.c:333 No locals. #5 0x0806bc51 in connection_get (s=35) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/servers/slapd/connection.c:308 sd = <value optimized out> c = (Connection *) 0x90395258 __PRETTY_FUNCTION__ = "connection_get" #6 0x0806d99e in connection_read (s=35) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/servers/slapd/connection.c:1308 rc = <value optimized out> c = <value optimized out> __PRETTY_FUNCTION__ = "connection_read" #7 0x0806a3f1 in slapd_daemon_task (ptr=0x0) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/servers/slapd/daemon.c:2468 r = 1 w = <value optimized out> l = 4 last_idle_check = 0 ebadf = 0 #8 0xb7d130bd in start_thread () from /lib/tls/libpthread.so.0 No symbol table info available. #9 0xb7ca801e in clone () from /lib/tls/libc.so.6 No symbol table info available. Thread 4 (Thread -1875305552 (LWP 16464)): #0 0xb7d15c01 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0 No symbol table info available. #1 0xb7f81754 in ldap_pvt_thread_cond_wait (cond=0x814d374, mutex=0x814d35c) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/libraries/libldap_r/thr_posix.c:299 No locals. #2 0xb7f81033 in ldap_int_thread_pool_wrapper (xpool=0x814d358) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/libraries/libldap_r/tpool.c:466 ctx = (ldap_int_thread_ctx_t *) 0x0 ltc_key = {{ltk_key = 0x80b73c0, ltk_data = 0x823ef08, ltk_free = 0x80b6f10 <slap_sl_mem_destroy>}, {ltk_key = 0x8217b18, ltk_data = 0x1c, ltk_free = 0xb7a412e0 <bdb_locker_id_free>}, {ltk_key = 0xb7a34800, ltk_data = 0x8ee90008, ltk_free = 0xb7a348d0 <search_stack_free>}, {ltk_key = 0x821d048, ltk_data = 0x42, ltk_free = 0xb7a412e0 <bdb_locker_id_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 28 times>} tid = 2419661744 i = 404 hash = <value optimized out> #3 0xb7d130bd in start_thread () from /lib/tls/libpthread.so.0 No symbol table info available. #4 0xb7ca801e in clone () from /lib/tls/libc.so.6 No symbol table info available. Thread 3 (Thread -1879499856 (LWP 16465)): #0 0xb7d15c01 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0 No symbol table info available. #1 0xb7f81754 in ldap_pvt_thread_cond_wait (cond=0x814d374, mutex=0x814d35c) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/libraries/libldap_r/thr_posix.c:299 No locals. #2 0xb7f81033 in ldap_int_thread_pool_wrapper (xpool=0x814d358) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/libraries/libldap_r/tpool.c:466 ctx = (ldap_int_thread_ctx_t *) 0x0 ltc_key = {{ltk_key = 0x80b73c0, ltk_data = 0x8254340, ltk_free = 0x80b6f10 <slap_sl_mem_destroy>}, {ltk_key = 0x821d048, ltk_data = 0x46, ltk_free = 0xb7a412e0 <bdb_locker_id_free>}, {ltk_key = 0xb7a34800, ltk_data = 0x8dc8c008, ltk_free = 0xb7a348d0 <search_stack_free>}, {ltk_key = 0x8217b18, ltk_data = 0x32, ltk_free = 0xb7a412e0 <bdb_locker_id_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 28 times>} tid = 2415467440 i = 595 hash = <value optimized out> #3 0xb7d130bd in start_thread () from /lib/tls/libpthread.so.0 No symbol table info available. #4 0xb7ca801e in clone () from /lib/tls/libc.so.6 No symbol table info available. Thread 2 (Thread -1883694160 (LWP 16466)): #0 0xb7d15c01 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0 No symbol table info available. #1 0xb7f81754 in ldap_pvt_thread_cond_wait (cond=0x814d374, mutex=0x814d35c) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/libraries/libldap_r/thr_posix.c:299 No locals. #2 0xb7f81033 in ldap_int_thread_pool_wrapper (xpool=0x814d358) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/libraries/libldap_r/tpool.c:466 ctx = (ldap_int_thread_ctx_t *) 0x0 ltc_key = {{ltk_key = 0x80b73c0, ltk_data = 0x8246938, ltk_free = 0x80b6f10 <slap_sl_mem_destroy>}, {ltk_key = 0x821d048, ltk_data = 0x34, ltk_free = 0xb7a412e0 <bdb_locker_id_free>}, {ltk_key = 0xb7a34800, ltk_data = 0x8e48d008, ltk_free = 0xb7a348d0 <search_stack_free>}, {ltk_key = 0x8217b18, ltk_data = 0x33, ltk_free = 0xb7a412e0 <bdb_locker_id_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 28 times>} tid = 2411273136 i = 531 hash = <value optimized out> #3 0xb7d130bd in start_thread () from /lib/tls/libpthread.so.0 No symbol table info available. #4 0xb7ca801e in clone () from /lib/tls/libc.so.6 No symbol table info available. Thread 1 (Thread -1212389152 (LWP 16459)): #0 0xb7d14183 in pthread_join () from /lib/tls/libpthread.so.0 No symbol table info available. #1 0xb7f81894 in ldap_pvt_thread_join (thread=2756418480, thread_return=0x0) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/libraries/libldap_r/thr_posix.c:193 No locals. #2 0x08067b06 in slapd_daemon () at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/servers/slapd/daemon.c:2579 listener_tid = 2756418480 rc = 0 #3 0x0805a309 in main (argc=9, argv=0xbf8f7694) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/servers/slapd/main.c:859 save_errno = <value optimized out> fp = <value optimized out> i = 9 no_detach = 0 rc = 1 urls = 0x8140008 "ldap:/// ldaps:///" username = 0x8140030 "gidNumber" groupname = 0x8140020 "\202ﬁ∑∞\213∑" sandbox = 0x0 syslogUser = 160 configfile = 0x8140040 "/etc/ldap/slapd.conf.master" configdir = 0x0 serverName = <value optimized out> scp = <value optimized out> scp_entry = <value optimized out> debug_unknowns = (char **) 0x0 syslog_unknowns = (char **) 0x0 l = <value optimized out> slapd_pid_file_unlink = 1 slapd_args_file_unlink = 1 __PRETTY_FUNCTION__ = "main" #0 0xb7d18391 in __write_nocancel () from /lib/tls/libpthread.so.0

1 0

Re: (ITS#5561) SEGV using TLS/SASL
by hyc＠symas.com 17 Jun '08

17 Jun '08

lea.anthony(a)meirion-dwyfor.ac.uk wrote: > Full_Name: Lea Anthony > Version: 2.3.40 > OS: Arch Linux > URL: http://pastebin.com/f6b680f22 > Submission from: (NULL) (194.82.229.100) > > > I have TLS setup as follows: > > TLSCertificateFile /etc/openldap/certs/cert.pem > TLSCertificateKeyFile /etc/openldap/certs/key.pem > TLSCipherSuite HIGH:MEDIUM:+TLSv1:+SSLv2:+SSLv3 > > The server starts fine and doing "ldapsearch -x -ZZ" will do an anonymous bind > fine. > > However, doing "ldapsearch -ZZ" will cause a segfault on the server. The > pastebin URL contains the post SSL negotiation debug lines from "slapd -d -1". I'm unable to reproduce this crash. Please provide a stack trace. http://www.openldap.org/faq/data/cache/59.html -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5564) Use largest contextCSN to determine staleness?
by hyc＠symas.com 17 Jun '08

17 Jun '08

rein(a)OpenLDAP.org wrote: > This message is in MIME format. The first part should be readable text, > while the remaining parts are likely unreadable without MIME-aware tools. > > --8323329-1817437300-1213728437=:15378 > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > > On Mon, 16 Jun 2008, rein(a)OpenLDAP.org wrote: > > rein(a)OpenLDAP.org wrote: > >> A fix that seems to solve this is that syncprov_findbase(FIND_CSN) >> should search for entries whose entryCSN value is less than the >> largest contextCSN presented by the client. All the test scripts >> succeed if I try this, but I'm not convinced that this is the correct >> fix. Would it not be more correct to ignore the entire CSN set >> presented by the consumer when it has been determined as stale. > > After looking a bit more on this I'm more convinced that the alternative > fix is the correct. A patch that implements this is attached, all tests > succeed with it. Howard, can you approve or comment on it? This patch looks OK to me, go ahead and commit. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5564) Use largest contextCSN to determine staleness?
by rein＠OpenLDAP.org 17 Jun '08

17 Jun '08

This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323329-1817437300-1213728437=:15378 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed On Mon, 16 Jun 2008, rein(a)OpenLDAP.org wrote: rein(a)OpenLDAP.org wrote: > A fix that seems to solve this is that syncprov_findbase(FIND_CSN) > should search for entries whose entryCSN value is less than the > largest contextCSN presented by the client. All the test scripts > succeed if I try this, but I'm not convinced that this is the correct > fix. Would it not be more correct to ignore the entire CSN set > presented by the consumer when it has been determined as stale. After looking a bit more on this I'm more convinced that the alternative fix is the correct. A patch that implements this is attached, all tests succeed with it. Howard, can you approve or comment on it? Rein --8323329-1817437300-1213728437=:15378 Content-Type: TEXT/x-diff; name=ITS-5564.patch Content-Transfer-Encoding: BASE64 Content-ID: <alpine.DEB.1.00.0806172047070.15378(a)monster.tollevik.no> Content-Description: Content-Disposition: attachment; filename=ITS-5564.patch SW5kZXg6IHNlcnZlcnMvc2xhcGQvb3ZlcmxheXMvc3luY3Byb3YuYw0KPT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PQ0KUkNTIGZpbGU6IC9mL0NWU1JPT1QvZHJp ZnQvT3BlbkxEQVAvc2VydmVycy9zbGFwZC9vdmVybGF5cy9zeW5jcHJvdi5j LHYNCnJldHJpZXZpbmcgcmV2aXNpb24gMS4zMA0KZGlmZiAtdSAtdSAtcjEu MzAgc3luY3Byb3YuYw0KLS0tIHNlcnZlcnMvc2xhcGQvb3ZlcmxheXMvc3lu Y3Byb3YuYwkxMyBKdW4gMjAwOCAxMzo0OTozNiAtMDAwMAkxLjMwDQorKysg c2VydmVycy9zbGFwZC9vdmVybGF5cy9zeW5jcHJvdi5jCTE3IEp1biAyMDA4 IDEzOjA3OjUxIC0wMDAwDQpAQCAtMjMyMyw2ICsyMzIzLDE1IEBADQogCQkJ CXNlbmRfbGRhcF9lcnJvciggb3AsIHJzLCBMREFQX1NZTkNfUkVGUkVTSF9S RVFVSVJFRCwgInN5bmMgY29va2llIGlzIHN0YWxlIiApOw0KIAkJCQlyZXR1 cm4gcnMtPnNyX2VycjsNCiAJCQl9DQorCQkJaWYgKCBzcnMtPnNyX3N0YXRl LmN0eGNzbiApIHsNCisJCQkJYmVyX2J2YXJyYXlfZnJlZV94KCBzcnMtPnNy X3N0YXRlLmN0eGNzbiwgb3AtPm9fdG1wbWVtY3R4ICk7DQorCQkJCXNycy0+ c3Jfc3RhdGUuY3R4Y3NuID0gTlVMTDsNCisJCQl9DQorCQkJaWYgKCBzcnMt PnNyX3N0YXRlLnNpZHMgKSB7DQorCQkJCXNsYXBfc2xfZnJlZSggc3JzLT5z cl9zdGF0ZS5zaWRzLCBvcC0+b190bXBtZW1jdHggKTsNCisJCQkJc3JzLT5z cl9zdGF0ZS5zaWRzID0gTlVMTDsNCisJCQl9DQorCQkJc3JzLT5zcl9zdGF0 ZS5udW1jc25zID0gMDsNCiAJCX0gZWxzZSB7DQogCQkJZ290c3RhdGUgPSAx Ow0KIAkJCS8qIElmIGNoYW5nZWQgYW5kIGRvaW5nIFByZXNlbnQgbG9va3Vw LCBzZW5kIFByZXNlbnQgVVVJRHMgKi8NCg== --8323329-1817437300-1213728437=:15378--

1 0

Re: (ITS#5556) ldapadd/slapadd create objects without RDN
by joshua＠itsecureadmin.com 17 Jun '08

17 Jun '08

> Well, pre-2.4.9 versions would reject the Add operation... Is it > 2.4.10 built from the OpenLDAP source, or some prepackaged binary? I built RPMs from the source, without any patches: DB: ../dist/configure \ --enable-shared \ --disable-static \ --program-prefix=slapd \ --bindir=/usr/bin \ --sbindir=/usr/sbin \ --libexecdir=/usr/sbin \ --datadir=/var/lib \ --sysconfdir=/etc \ --localstatedir=/var/lib \ --libdir=/usr/lib \ --includedir=/usr/include \ --mandir=/usr/share/man \ --disable-posixmutexes \ --with-mutex=x86/gcc-assembly \ OL: ./configure \ --bindir=/usr/bin \ --sbindir=/usr/sbin \ --libexecdir=/usr/sbin \ --datadir=/var/lib \ --sysconfdir=/etc \ --localstatedir=/var/lib \ --libdir=/usr/lib \ --includedir=/usr/include \ --mandir=/usr/share/man \ --enable-backends=mod \ --enable-cleartext \ --enable-crypt \ --enable-ipv6 \ --enable-ldap \ --enable-local \ --enable-modules \ --enable-overlays=mod \ --enable-slapd \ --enable-rewrite \ --enable-syslog \ --with-tls \ --with-threads \ > Maybe an overlay or something interferes with auto-adding the naming > attrs? Please post your slapd.conf too, after removing passwords etc. My sanitized slapd.conf: include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/corba.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/java.schema include /etc/openldap/schema/krb5-kdc.schema include /etc/openldap/schema/kerberosobject.schema include /etc/openldap/schema/misc.schema include /etc/openldap/schema/nis.schema include /etc/openldap/schema/openldap.schema include /etc/openldap/schema/autofs.schema include /etc/openldap/schema/samba.schema include /etc/openldap/schema/kolab.schema include /etc/openldap/schema/evolutionperson.schema include /etc/openldap/schema/calendar.schema include /etc/openldap/schema/sudo.schema include /etc/openldap/schema/dnszone.schema include /etc/openldap/schema/dhcp.schema include /etc/openldap/schema/postfix-mail.schema access to dn.exact="" by * read access to dn.subtree="cn=Subschema" by * read access to dn.subtree="ou=people,dc=openldap,dc=example,dc=com" by group="cn=replicator accounts,ou=group,dc=openldap,dc=example,dc=com" read by peername.ip=10.12.31.6 anonymous read by peername.ip=10.12.31.7 anonymous read access to dn.subtree="ou=vmail,dc=openldap,dc=example,dc=com" by group="cn=replicator accounts,ou=group,dc=openldap,dc=example,dc=com" read by peername.ip=10.12.31.6 anonymous read by peername.ip=10.12.31.7 anonymous read access to dn.subtree="ou=idmap,dc=openldap,dc=example,dc=com" by group="cn=idmap admins,ou=group,dc=openldap,dc=example,dc=com" write by group="cn=replicator accounts,ou=group,dc=openldap,dc=example,dc=com" read by users read by * auth access to attrs=userPassword,sambaLMPassword,sambaNTPassword by self write by group="cn=replicator accounts,ou=group,dc=openldap,dc=example,dc=com" read by anonymous auth by * none access to * by group="cn=admins,ou=group,dc=openldap,dc=example,dc=com" write by group="cn=replicator accounts,ou=group,dc=openldap,dc=example,dc=com" read by self read by anonymous auth pidfile /var/run/openldap/slapd.pid argsfile /var/run/openldap/slapd.args #sizelimit unlimited #timelimit unlimited modulepath /usr/sbin/openldap moduleload ppolicy.la moduleload syncprov.la moduleload back_bdb.la moduleload back_monitor.la TLSRandFile /dev/random TLSCipherSuite HIGH:MEDIUM:+SSLv2 TLSCertificateFile /etc/pki/tls/certs/server01.crt TLSCertificateKeyFile /etc/pki/tls/private/server01.key TLSCACertificateFile /etc/pki/tls/certs/domain-server01.crt security ssf=128 loglevel 256 database config rootdn cn=config rootpw secret #serverid 1 ldap://server03.example.com #serverid 2 ldap://server01.example.com #syncrepl rid=001 # provider=ldap://server01.example.com # binddn="cn=config" # bindmethod=simple # credentials=secret # searchbase="cn=config" # type=refreshAndPersist # starttls=yes # tls_reqcert=never # retry="5 5 300 5" # timeout=5 #syncrepl rid=002 # provider=ldap://server03.example.com # binddn="cn=config" # bindmethod=simple # credentials=secret # searchbase="cn=config" # type=refreshAndPersist # starttls=yes # tls_reqcert=never # retry="5 5 300 5" # timeout=5 #mirrormode true #overlay syncprov #syncprov-checkpoint 100 10 #syncprov-sessionlog 100 database monitor rootdn cn=monitor rootpw secret database bdb suffix "dc=openldap,dc=example,dc=com" rootdn "cn=manager,dc=openldap,dc=example,dc=com" rootpw secret directory /var/lib/ldap serverid 3 ldap://server01.example.com serverid 4 ldap://server03.example.com cachesize 10000 checkpoint 256 5 syncrepl rid=003 provider=ldap://server01.example.com binddn="uid=replicator,ou=service-accounts,dc=openldap,dc=example,dc=com" bindmethod=simple credentials=secret searchbase="dc=openldap,dc=example,dc=com" type=refreshAndPersist starttls=yes tls_reqcert=never interval=00:00:00:10 retry="5 5 300 5" timeout=5 syncrepl rid=004 provider=ldap://server03.example.com binddn="uid=replicator,ou=service-accounts,dc=openldap,dc=example,dc=com" bindmethod=simple credentials=secret searchbase="dc=openldap,dc=example,dc=com" type=refreshAndPersist starttls=yes tls_reqcert=never interval=00:00:00:10 retry="5 5 300 5" timeout=5 mirrormode true overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 index objectClass eq index cn,mail,surname,givenname eq,subinitial index uidNumber,gidNumber,memberuid,member,uniqueMember eq index uid eq,subinitial index sambaSID,sambaDomainName,displayName eq index entryCSN,entryUUID eq index mailid eq limits group="cn=replicator accounts,ou=group,dc=openldap,dc=example,dc=com" size=unlimited time=unlimited Thanks! -- Josh Miller, RHCE

1 0

Re: (ITS#5556) ldapadd/slapadd create objects without RDN
by joshua＠itsecureadmin.com 17 Jun '08

17 Jun '08

> joshua(a)itsecureadmin.com wrote: > >> When adding an object with slapadd or ldapadd, it is possible to create >> an >> object which does not have an RDN, and therefore not searchable by RDN. > > Can't reproduce. Works as expected here (adding entry without naming > attributes/distinguished values results in automatically generating that > data, both by slapadd and ldapadd). Can you confirm software versions? To confirm versions: [root@server01 ldifs]# ldapadd -V ldapadd: @(#) $OpenLDAP: ldapmodify 2.4.10 (Jun 12 2008 11:02:00) $ joshm@server03.sky.dom:/home/SKY/joshm/redhat/BUILD/openldap-2.4.10/clients/tools (LDAP library: OpenLDAP 20410) ldap_sasl_interactive_bind_s: Confidentiality required (13) [root@server01 ldifs]# slapd -V @(#) $OpenLDAP: slapd 2.4.10 (Jun 12 2008 11:03:43) $ joshm@server03.sky.dom:/home/SKY/joshm/redhat/BUILD/openldap-2.4.10/servers/slapd I'm running on CentOS 5.1 with DB 4.6 -- I built these RPMs. Thanks, -- Josh Miller, RHCE

1 0

Re: (ITS#5555) authzTo ACL check for wrong principal
by ando＠sys-net.it 17 Jun '08

17 Jun '08

andrew.findlay(a)skills-1st.co.uk wrote: > On Mon, Jun 16, 2008 at 08:06:17PM +0200, Pierangelo Masarati wrote: > >> Ah, OK. Note that since some point in 2.3, authorization is described >> by a specific syntax <http://www.openldap.org/faq/data/cache/1254.html>, >> which should probably be advertised a bit more (and moved out from the >> experimental OID arc). > > If that is used *everywhere* for authorisation then there could well > be more doc errors to correct. I am fairly sure I saw one place where > the docs specifically exclude some of those forms. Yes, I believe in some cases some of the variants of the syntax are not allowed. This is true, for example, in SASL identity mapping, which does not allow the regex, subtree, children, onelevel, group and users styles, only the base and uri forms are allowed (provided the latter only returns a single match). > I notice that '*' excludes anonymous in this spec. There is an > undocumented option to 'allow' that seems relevant: proxy_authz_anon - Why undocumented? It is documented (in 2.4, at least; it does not exist for 2.3). > would allowing this cause anon to be included in '*' generally or is > it not that simple? '*' implies a non-empty value; to include anonymous, use "dn.regex:.*", or "dn.subtree:". p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5555) authzTo ACL check for wrong principal
by andrew.findlay＠skills-1st.co.uk 17 Jun '08

17 Jun '08

On Mon, Jun 16, 2008 at 08:06:17PM +0200, Pierangelo Masarati wrote: > Ah, OK. Note that since some point in 2.3, authorization is described > by a specific syntax <http://www.openldap.org/faq/data/cache/1254.html>, > which should probably be advertised a bit more (and moved out from the > experimental OID arc). If that is used *everywhere* for authorisation then there could well be more doc errors to correct. I am fairly sure I saw one place where the docs specifically exclude some of those forms. I notice that '*' excludes anonymous in this spec. There is an undocumented option to 'allow' that seems relevant: proxy_authz_anon - would allowing this cause anon to be included in '*' generally or is it not that simple? Andrew -- ----------------------------------------------------------------------- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/ +44 1628 782565 | -----------------------------------------------------------------------

1 0

Re: (ITS#5555) authzTo ACL check for wrong principal
by ando＠sys-net.it 16 Jun '08

16 Jun '08

Andrew Findlay wrote: > I was referring to documentation, where the only bit of the admin > guide that really talks about proxy authorisation is the SASL section. Ah, OK. Note that since some point in 2.3, authorization is described by a specific syntax <http://www.openldap.org/faq/data/cache/1254.html>, which should probably be advertised a bit more (and moved out from the experimental OID arc). p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5555) authzTo ACL check for wrong principal
by andrew.findlay＠skills-1st.co.uk 16 Jun '08

16 Jun '08

On Mon, Jun 16, 2008 at 07:29:12PM +0200, Pierangelo Masarati wrote: > Not sure what you mean there, but I believe the fact that the > implementation is in saslauth.c is for mere historical reasons. Right > now, authorization code is independent from SASL, and is used by a > number of features: SASL authz, RFC 4370, identity assertion, dgIdentity > and more. I was referring to documentation, where the only bit of the admin guide that really talks about proxy authorisation is the SASL section. Andrew -- ----------------------------------------------------------------------- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/ +44 1628 782565 | -----------------------------------------------------------------------

1 0

Re: (ITS#5555) authzTo ACL check for wrong principal
by ando＠sys-net.it 16 Jun '08

16 Jun '08

andrew.findlay(a)skills-1st.co.uk wrote: > It might be better still to factor out the concept of proxy > authorisation and its control from the SASL authz mechanism, as it > applies also to the LDAP Proxied Authorization Control. > I have not done this as I was unsure where best to put it. Not sure what you mean there, but I believe the fact that the implementation is in saslauth.c is for mere historical reasons. Right now, authorization code is independent from SASL, and is used by a number of features: SASL authz, RFC 4370, identity assertion, dgIdentity and more. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5555) authzTo ACL check for wrong principal
by andrew.findlay＠skills-1st.co.uk 16 Jun '08

16 Jun '08

On Mon, Jun 16, 2008 at 02:29:21PM +0000, Andrew Findlay wrote: > Thus I think my original report was wrong. This is a documentation > issue, not a bug. I have uploaded a suggested set of patches to make the behaviour clearer: ftp://ftp.openldap.com/incoming/andrew.findlay-20080616.patch The patch is against 2.4.10 It might be better still to factor out the concept of proxy authorisation and its control from the SASL authz mechanism, as it applies also to the LDAP Proxied Authorization Control. I have not done this as I was unsure where best to put it. Andrew -- ----------------------------------------------------------------------- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/ +44 1628 782565 | -----------------------------------------------------------------------

1 0

Re: (ITS#5561) SEGV using TLS/SASL
by lea.anthony＠meirion-dwyfor.ac.uk 16 Jun '08

16 Jun '08

------------------- slapd.conf --------------------------- include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/nis.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/samba.schema include /etc/openldap/schema/misc.schema password-hash {md5} pidfile /var/run/slapd.pid argsfile /var/run/slapd.args TLSCertificateFile /etc/openldap/certs/cert.pem TLSCertificateKeyFile /etc/openldap/certs/key.pem TLSCipherSuite HIGH:MEDIUM:+TLSv1:+SSLv2:+SSLv3 loglevel -1 database bdb suffix "dc=meirion-dwyfor,dc=ac,dc=uk" rootdn "cn=Manager,dc=meirion-dwyfor,dc=ac,dc=uk" directory /var/lib/openldap/openldap-data index objectClass eq index cn pres,sub,eq index sn pres,sub,eq index uid pres,sub,eq index displayName pres,sub,eq index uidNumber eq index gidNumber eq index memberUID eq index sambaSID eq index sambaPrimaryGroupSID eq index sambaDomainName eq index default sub ------------------- ldap.conf ------------------------ BASE dc=meirion-dwyfor,dc=ac,dc=uk URI ldap://localhost TLS_CACERT /etc/openldap/certs/cacert.pem -------------------------------------------------------

1 0

(ITS#5564) Use largest contextCSN to determine staleness?
by rein＠OpenLDAP.org 16 Jun '08

16 Jun '08

Full_Name: Rein Tollevik Version: CVS head OS: linux and solaris URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.93.160.250) Submitted by: rein Scenario: A syncrepl consumer replicates a backend DB where it has at least one entry that is up to date when it starts, but there are newer entries on the producer. The oldest contextCSN presented by the consumer is older than all entryCSN values in the replicated backend on the producer.. When syncprov_findcsn() is called with the FIND_CSN tag it will not find any entries whose entryCSN is <= the oldest csn presented by the consumer, and the cookie set will be determined as stale. Which again means that no present UUIDs will be sent to the consumer. The producer will, during the search that follows, skip sending entries whose entryCSN values are older or equal to a contextCSN with the same sid presented by the client. I.e the consumer will neither get these entries in a present UUID set nor as updated entries, and will therefore incorrectly remove them from its database. A fix that seems to solve this is that syncprov_findbase(FIND_CSN) should search for entries whose entryCSN value is less than the largest contextCSN presented by the client. All the test scripts succeed if I try this, but I'm not convinced that this is the correct fix. Would it not be more correct to ignore the entire CSN set presented by the consumer when it has been determined as stale? Hm, if the oldest contextCSN is from a server that is seldom updated this alternate fix could mean that a full reload would be performed every time the client starts with an outdated contextCSN set. Would the best fix be to do both, i.e search for entryCSN <= the largest csn presented by the client, and also ignore the csn set when it has been determined as stale? Rein Tollevik Basefarm AS

1 0

Re: (ITS#5555) authzTo ACL check for wrong principal
by andrew.findlay＠skills-1st.co.uk 16 Jun '08

16 Jun '08

On Mon, Jun 16, 2008 at 02:45:43PM +0200, Hallvard B Furuseth wrote: > If non-anonymous access is needed, the slapd.access(5) manpage needs an > update too. (Or instead, to avoid duplicating text.) Currently it just > says: > > Auth (=x) privileges are also required on the authzTo attribute > of the authorizing identity and/or on the authzFrom attribute of > the authorized identity. > > but it doesn't mention to who needs that auth access. It is the authenticated ID that needs access in both cases. On further thought I think it is correct that the access is checked without reference to whether that ID has access to entry and parent entries, as (particularly in the case of authzFrom) the authenticated ID may not have any direct access to the entry whose ID it is about to assume. Thus, if principal A has authenticated and wishes to perform an operation using principal B's authorisation, the access required is: A needs auth access to authzTo in its own entry if that attribute is involved in giving A permission to act for B. A needs auth access to authzFrom in B's entry if that attribute is involved in giving A permission to act for B. The rules are the same whether using a SASL authorization identity or using a ProxyAuth control on an LDAP operation. Thus I think my original report was wrong. This is a documentation issue, not a bug. Andrew -- ----------------------------------------------------------------------- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/ +44 1628 782565 | -----------------------------------------------------------------------

1 0

Re: (ITS#5561) SEGV using TLS/SASL
by h.b.furuseth＠usit.uio.no 16 Jun '08

16 Jun '08

Please post your ldap.conf and slapd.conf, minus any passwords. > The pastebin URL contains the post SSL negotiation debug > lines from "slapd -d -1". No need to pastebin data as short as that. -- Hallvard

1 0

Re: (ITS#5555) authzTo ACL check for wrong principal
by h.b.furuseth＠usit.uio.no 16 Jun '08

16 Jun '08

andrew.findlay(a)skills-1st.co.uk writes: > You are right: if I just grant 'auth' access to 'authzTo' the proxy > authorisation succeeds. The philisophy makes sense so I will try to > come up with a suitable patch to the Admin Guide describing how to use > it. At the moment the only note about this is in the ACL Examples > (7.2.5 at present) which says that authentication/authorization > is always done anonymously - obviously not entirely true. If non-anonymous access is needed, the slapd.access(5) manpage needs an update too. (Or instead, to avoid duplicating text.) Currently it just says: Auth (=x) privileges are also required on the authzTo attribute of the authorizing identity and/or on the authzFrom attribute of the authorized identity. but it doesn't mention to who needs that auth access. -- Hallvard

1 0

(ITS#5563) Seg. fault if URL used in ServerID without any listener
by rein＠OpenLDAP.org 16 Jun '08

16 Jun '08

Full_Name: Rein Tollevik Version: CVS head OS: linux and solaris URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.93.160.250) Submitted by: rein Slapd will seg. fault if the URL form of ServerID is used without any active listeners. I stumbled upon this by adding "-d ?" to my regular command line. I.e not exactly a critical bug.. I'll commit a trivial fix shortly. Rein Tollevik Basefarm AS

1 0

Re: (ITS#5555) authzTo ACL check for wrong principal
by andrew.findlay＠skills-1st.co.uk 16 Jun '08

16 Jun '08

On Sat, Jun 14, 2008 at 03:59:37PM +0200, Pierangelo Masarati wrote: > AFAIK, access to that attribute is checked using AUTH rather than read. > The idea is that ACLs should allow to fine-grain control who is > allowed to exploit the authorization feature while giving up as little > as possible (e.g. AUTH instead of READ). You are right: if I just grant 'auth' access to 'authzTo' the proxy authorisation succeeds. The philisophy makes sense so I will try to come up with a suitable patch to the Admin Guide describing how to use it. At the moment the only note about this is in the ACL Examples (7.2.5 at present) which says that authentication/authorization is always done anonymously - obviously not entirely true. I am still a bit worried about the logic of the access test, as in my enviroment I just had to grant the principal auth access to their own authzTo attribute to make proxy authorization work: the principal does not even have 'disclose' access to their own entry or the parent entry. Normally I would expect to need some level of access to everything in the DN before I could make use of an attribute in an entry. Andrew -- ----------------------------------------------------------------------- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/ +44 1628 782565 | -----------------------------------------------------------------------

1 0

Re: (ITS#5554) slapd.conf man page missing TLSCipherSuite
by ghenry＠suretecsystems.com 16 Jun '08

16 Jun '08

hyc(a)symas.com wrote: > ghenry(a)OpenLDAP.org wrote: >> Full_Name: Gavin Henry >> Version: HEAD >> OS: >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (212.159.59.85) >> >> >> http://www.openldap.org/software/man.cgi?query=slapd.conf&sektion=5&apropos… >> missing TLSCipherSuite >> >> >> > No. The Admin Guide is missing the note about GnuTLS under the TLSCipherSuite > description. The note is present in slapd.conf(5). > Where would you like this to be mentioned in the Admin Guide, the only reference to TLSCipherSuite in the guide is in the TLS section, not in the config section. For now I've added: To obtain the list of ciphers in GNUtls use: > gnutls-cli -l in tls.sdf under the openssl cli part. -- Kind Regards, Gavin Henry. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 824887 E ghenry(a)suretecsystems.com Open Source. Open Solutions(tm). http://www.suretecsystems.com/ Suretec Systems is a limited company registered in Scotland. Registered number: SC258005. Registered office: 13 Whiteley Well Place, Inverurie, Aberdeenshire, AB51 4FP.

1 0

Re: (ITS#5562) SEGV using TLS/SASL
by lea.anthony＠meirion-dwyfor.ac.uk 16 Jun '08

16 Jun '08

Duplicate. Please close. ----- Original Message ----- From: openldap-its(a)OpenLDAP.org To: "lea anthony" <lea.anthony(a)meirion-dwyfor.ac.uk> Sent: Monday, June 16, 2008 10:00:49 AM (GMT) Europe/London Subject: Re: (ITS#5562) SEGV using TLS/SASL *** THIS IS AN AUTOMATICALLY GENERATED REPLY *** Thanks for your report to the OpenLDAP Issue Tracking System. Your report has been assigned the tracking number ITS#5562. One of our support engineers will look at your report in due course. Note that this may take some time because our support engineers are volunteers. They only work on OpenLDAP when they have spare time. If you need to provide additional information in regards to your issue report, you may do so by replying to this message. Note that any mail sent to openldap-its(a)openldap.org with (ITS#5562) in the subject will automatically be attached to the issue report. mailto:openldap-its@openldap.org?subject=(ITS#5562) You may follow the progress of this report by loading the following URL in a web browser: http://www.OpenLDAP.org/its/index.cgi?findid=5562 Please remember to retain your issue tracking number (ITS#5562) on any further messages you send to us regarding this report. If you don't then you'll just waste our time and yours because we won't be able to properly track the report. Please note that the Issue Tracking System is not intended to be used to seek help in the proper use of OpenLDAP Software. Such requests will be closed. OpenLDAP Software is user supported. http://www.OpenLDAP.org/support/ -------------- Copyright 1998-2007 The OpenLDAP Foundation, All Rights Reserved.

1 0

(ITS#5562) SEGV using TLS/SASL
by lea.anthony＠meirion-dwyfor.ac.uk 16 Jun '08

16 Jun '08

Full_Name: Lea Anthony Version: 2.3.40 OS: Arch Linux URL: http://pastebin.com/f6b680f22 Submission from: (NULL) (194.82.229.100) I have TLS setup as follows: TLSCertificateFile /etc/openldap/certs/cert.pem TLSCertificateKeyFile /etc/openldap/certs/key.pem TLSCipherSuite HIGH:MEDIUM:+TLSv1:+SSLv2:+SSLv3 The server starts fine and doing "ldapsearch -x -ZZ" will do an anonymous bind fine. However, doing "ldapsearch -ZZ" will cause a segfault on the server. The pastebin URL contains the post SSL negotiation debug lines from "slapd -d -1".

1 0

(ITS#5561) SEGV using TLS/SASL
by lea.anthony＠meirion-dwyfor.ac.uk 16 Jun '08

16 Jun '08

Full_Name: Lea Anthony Version: 2.3.40 OS: Arch Linux URL: http://pastebin.com/f6b680f22 Submission from: (NULL) (194.82.229.100) I have TLS setup as follows: TLSCertificateFile /etc/openldap/certs/cert.pem TLSCertificateKeyFile /etc/openldap/certs/key.pem TLSCipherSuite HIGH:MEDIUM:+TLSv1:+SSLv2:+SSLv3 The server starts fine and doing "ldapsearch -x -ZZ" will do an anonymous bind fine. However, doing "ldapsearch -ZZ" will cause a segfault on the server. The pastebin URL contains the post SSL negotiation debug lines from "slapd -d -1".

1 0

Re: (ITS#5556) ldapadd/slapadd create objects without RDN
by h.b.furuseth＠usit.uio.no 14 Jun '08

14 Jun '08

Well, pre-2.4.9 versions would reject the Add operation... Is it 2.4.10 built from the OpenLDAP source, or some prepackaged binary? Maybe an overlay or something interferes with auto-adding the naming attrs? Please post your slapd.conf too, after removing passwords etc. -- Hallvard

1 0

(ITS#5560) API for assertion control
by michael＠stroeder.com 14 Jun '08

14 Jun '08

Full_Name: Michael Ströder Version: HEAD OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.163.75.195) I would be handy to have an API for generating an assertion control (see RFC 4528). The function should take a string representation of a LDAP search filter as input.

1 0

Re: (ITS#5556) ldapadd/slapadd create objects without RDN
by ando＠sys-net.it 14 Jun '08

14 Jun '08

joshua(a)itsecureadmin.com wrote: > When adding an object with slapadd or ldapadd, it is possible to create an > object which does not have an RDN, and therefore not searchable by RDN. Can't reproduce. Works as expected here (adding entry without naming attributes/distinguished values results in automatically generating that data, both by slapadd and ldapadd). Can you confirm software versions? p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5555) authzTo ACL check for wrong principal
by ando＠sys-net.it 14 Jun '08

14 Jun '08

andrew.findlay(a)skills-1st.co.uk wrote: > When using "authz-policy to" I find that the entity that is trying to do an > operation on behalf of another entity needs read access to its own authzTo > attribute. > This seems wrong: authzTo is defining what the user may do: I do not really want > them to be able to see it. When doing a proxy authz I think ACLs for this > attribute should not be checked at all as the access is effectively being done > by the rootdn. AFAIK, access to that attribute is checked using AUTH rather than read. The idea is that ACLs should allow to fine-grain control who is allowed to exploit the authorization feature while giving up as little as possible (e.g. AUTH instead of READ). p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: ando(a)sys-net.it -----------------------------------

1 0

(ITS#5559) slapo-pcache sizelimit caching not documented
by ando＠sys-net.it 14 Jun '08

14 Jun '08

Full_Name: Pierangelo Masarati Version: HEAD OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.63.140.131) Submitted by: ando The sizelimit caching feature, and related setting, are not documented in slapo-pcache(5) man page.

1 0

Re: (ITS#5549) slapd SEGV faults in entry_partsize when monitoring
by ando＠sys-net.it 14 Jun '08

14 Jun '08

andreas.mueller(a)othello.ch wrote: > Full_Name: Andreas Mueller > Version: 2.4.9 > OS: Solaris 10 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (193.134.170.35) > > > We have four slapd servers in a mirrormode configuration. > This generally works well. We monitor these servers using > ldapsearches to cn=Monitor every minute, and collect > performance data to construct load/performance graphs > with rrdtool. Unfortunately, it sometimes happens that > slapd crashes during the monitoring query. Using gdb, we > were able to get a stack backtrace: > > Core was generated by `/usr/local/libexec/slapd'. > Program terminated with signal 11, Segmentation fault. > #0 0x0005fd48 in entry_partsize () > (gdb) bt > #0 0x0005fd48 in entry_partsize () > #1 0x000603b4 in entry_flatsize () > #2 0x0006a5c8 in slap_send_search_entry () > #3 0x00134330 in monitor_send_children () > #4 0x001348e0 in monitor_back_search () > #5 0x000523ac in fe_op_search () > #6 0x00051b64 in do_search () > #7 0x0004dd8c in connection_operation () > #8 0x0004e4c4 in connection_read_thread () > #9 0x001a22a8 in ldap_int_thread_pool_wrapper () > #10 0xfe3c5800 in __tbl_10_huge_digits () from /lib/libc.so.1 > > All cores obtained so far show that the segmentation fault > occured at the same location inside entry_partsize. > > Unfortunately we cannot systematically reproduce this behaviour, > and we also cannot get the line number (binaries are stripped). > > We have not tried other versions or other platforms. For production, > we use the versions available in package form from www.sunfreeware.com, > but the error also happens on servers we have compiled ourselves from > the sources. You should run a non-stripped binary, in order to allow more useful information to be extracted from those core files. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5558) Buffer Overflow in back_sock and back_shell
by hyc＠symas.com 14 Jun '08

14 Jun '08

stef(a)memberwebs.com wrote: > Full_Name: Stef Walter > Version: openldap 2.4.10 > OS: FreeBSD 6.3-RELEASE-p2 > URL: http://memberwebs.com/stef/scraps/openldap24-buffer-overflow.patch > Submission from: (NULL) (189.162.38.105) > > > The back_sock and back_shell backends have a buffer overflow (off by one) > problem in their result parsing code in read_and_send_results() lines 82-89 in > result.c. The buffer is reallocated when an additional string would be too long > for the buffer, but the string's null terminator is not taken into account. > > This can cause a crash in certain situations. These situations are obviously > data and OS dependent. But with specific data, the crash is reproducible. > > Patch which fixes the problem: Thanks, now fixed in CVS HEAD. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#5558) Buffer Overflow in back_sock and back_shell
by stef＠memberwebs.com 14 Jun '08

14 Jun '08

Full_Name: Stef Walter Version: openldap 2.4.10 OS: FreeBSD 6.3-RELEASE-p2 URL: http://memberwebs.com/stef/scraps/openldap24-buffer-overflow.patch Submission from: (NULL) (189.162.38.105) The back_sock and back_shell backends have a buffer overflow (off by one) problem in their result parsing code in read_and_send_results() lines 82-89 in result.c. The buffer is reallocated when an additional string would be too long for the buffer, but the string's null terminator is not taken into account. This can cause a crash in certain situations. These situations are obviously data and OS dependent. But with specific data, the crash is reproducible. Patch which fixes the problem: --- ../openldap-2.4.10/servers/slapd/back-sock/result.c 2008-02-08 18:46:09.000000000 -0000 +++ servers/slapd/back-sock/result.c 2008-06-13 15:56:46.000000000 -0000 @@ -77,7 +77,7 @@ } len = strlen( line ); - while ( bp + len - buf > bsize ) { + while ( bp + (len + 1) - buf > bsize ) { size_t offset = bp - buf; bsize += BUFSIZ; buf = (char *) ch_realloc( buf, bsize ); --- ../openldap-2.4.10/servers/slapd/back-shell/result.c 2008-02-11 17:26:47.000000000 -0000 +++ servers/slapd/back-shell/result.c 2008-06-13 15:57:02.000000000 -0000 @@ -80,7 +80,7 @@ } len = strlen( line ); - while ( bp + len - buf > bsize ) { + while ( bp + (len + 1) - buf > bsize ) { size_t offset = bp - buf; bsize += BUFSIZ; buf = (char *) ch_realloc( buf, bsize );

1 0

(ITS#5557) memory leak in ACL sets
by hyc＠OpenLDAP.org 13 Jun '08

13 Jun '08

Full_Name: Howard Chu Version: 2.3.39/2.4/HEAD OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.91.220.157) Submitted by: hyc slap_set_join() with an '|' operator will leak values if it detects a duplicate in the rset. A fix will be committed shortly.

1 0

(ITS#5556) ldapadd/slapadd create objects without RDN
by joshua＠itsecureadmin.com 13 Jun '08

13 Jun '08

Full_Name: Josh Miller Version: 2.4.10 OS: CentOS 5.1 URL: http://itsecureadmin.com/uid-test.txt Submission from: (NULL) (65.249.25.3) When adding an object with slapadd or ldapadd, it is possible to create an object which does not have an RDN, and therefore not searchable by RDN. Example data: dn: uid=nouiduser,ou=People,dc=openldap,dc=example,dc=com objectClass: mailAccount maildrop: nouiduser(a)nest.tld mailid: nouiduser(a)nest.tld maildir: nouiduser/ userPassword:: e2NyeXB0fSQxJERCQS5wdmZYJHU0eFp3TndSRDIwSDFkTDBrNmZMRi4= mailquota: 35969216S The above LDIF is added to the directory without any errors and is then missing the uid attribute. ldapsearch will not return any results when filtering on uid, ie: $ ldapsearch -xZZH ldap://server uid=nouiduser - Expected result - return the object. - Actual result - no object returned. - Workaround - use ldapmodify to add the uid attribute. Please see the attached URL for complete event details (add/search/modify).

1 0

(ITS#5555) authzTo ACL check for wrong principal
by andrew.findlay＠skills-1st.co.uk 13 Jun '08

13 Jun '08

Full_Name: Andrew Findlay Version: 2.4.10 OS: Linux: SuSE 10.2 URL: Submission from: (NULL) (88.97.25.132) When using "authz-policy to" I find that the entity that is trying to do an operation on behalf of another entity needs read access to its own authzTo attribute. This seems wrong: authzTo is defining what the user may do: I do not really want them to be able to see it. When doing a proxy authz I think ACLs for this attribute should not be checked at all as the access is effectively being done by the rootdn.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs