Please test current RE24 CVS. In particular, if people can test:
(a) Building without TLS & without sasl (b) Building without TLS (c) Building without sasl (d) If at least one person can build against GnuTLS instead of OpenSSL
Much appreciated. :)
Thanks,
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
[not filing an ITS (yet) because for now, I just intend discussion...]
I don't recall getting any warnings in late January:
configure.in:666: warning: AC_CACHE_VAL(lt_prog_compiler_static_works, ...): suspicious cache-id, must contain _cv_ to be cached ../../lib/autoconf/general.m4:1973: AC_CACHE_VAL is expanded from... ../../lib/autoconf/general.m4:1993: AC_CACHE_CHECK is expanded from... aclocal.m4:1124: AC_LIBTOOL_LINKER_OPTION is expanded from... aclocal.m4:3043: _LT_AC_LANG_C_CONFIG is expanded from... aclocal.m4:3042: AC_LIBTOOL_LANG_C_CONFIG is expanded from... aclocal.m4:564: AC_LIBTOOL_SETUP is expanded from... aclocal.m4:544: _AC_PROG_LIBTOOL is expanded from... aclocal.m4:509: AC_PROG_LIBTOOL is expanded from... configure.in:666: the top level configure.in:666: warning: AC_CACHE_VAL(lt_prog_compiler_pic_works, ...): suspicious cache-id, must contain _cv_ to be cached aclocal.m4:1079: AC_LIBTOOL_COMPILER_OPTION is expanded from... aclocal.m4:5154: AC_LIBTOOL_PROG_COMPILER_PIC is expanded from...
autoconf-2.62. I thought we were supposed to be autoconf 2.6 clean per previous thread?
Aaron Richton wrote:
[not filing an ITS (yet) because for now, I just intend discussion...]
I don't recall getting any warnings in late January:
autoconf-2.62. I thought we were supposed to be autoconf 2.6 clean per previous thread?
According to the previous thread, we had agreed to move from 2.59 to 2.61. Note that you generally have to blow away the autom4te.cache when changing these things.
And also, when testing release candidates, you should only be using the checked in configure script, not running autoconf yourself.
On 09.02.2009 17:11, Quanah Gibson-Mount wrote:
Please test current RE24 CVS.
test049-sync-config says it succeeds, but then hangs forever with the consumer slapd never stopping.
Output is: 8<----------------------------------------------
Starting test049-sync-config ...
running defines.sh Starting producer slapd on TCP/IP port 9011... Using ldapsearch to check that producer slapd is running... Inserting syncprov overlay on producer... Starting consumer slapd on TCP/IP port 9012... Using ldapsearch to check that consumer slapd is running... Configuring syncrepl on consumer... Waiting 10 seconds for syncrepl to receive changes... Using ldapsearch to check that syncrepl received config changes... Adding schema and databases on producer... Using ldapadd to populate producer... Waiting 20 seconds for syncrepl to receive changes... Using ldapsearch to check that syncrepl received database changes... Replacing olcSyncrepl on producer... Waiting seconds for syncrepl to receive changes... sleep: opérande manquante Pour en savoir davantage, faites: « sleep --help ». Using ldapsearch to read config from the producer... Using ldapsearch to read config from the consumer... Filtering producer results... Filtering consumer results... Comparing retrieved configs from producer and consumer... Using ldapsearch to read all the entries from the producer... Using ldapsearch to read all the entries from the consumer... Filtering producer results... Filtering consumer results... Comparing retrieved entries from producer and consumer...
Test succeeded
[hangs forever] 8<----------------------------------------------
ps shows: 16443 pts/1 Sl+ 0:00 | _ /home/jclarke/cvs/openldap-RE24/openldap-src/tests/../servers/slapd/slapd -s0 -F ./slapd.d -h ldap://localhost:9012/ -d 261
And the end of slapd.2.log is: 8<---------------------------------------------- daemon: shutdown requested and initiated. =>do_syncrepl rid=001 =>do_syncrepl rid=002 =>do_syncrepl rid=002 connection_get(19) connection_get(13) connection_get(13): got connid=0 connection_get(19): got connid=0 ldap_free_request (origid 2, msgid 2) ldap_free_request (origid 2, msgid 2) ldap_free_connection 1 1 ldap_send_unbind slapd shutdown: waiting for 4 operations/tasks to finish ldap_free_connection 1 1 ldap_send_unbind ber_flush2: 7 bytes to sd 13 ber_flush2: 7 bytes to sd 19 ldap_free_connection: actually freed ldap_free_connection: actually freed 8<----------------------------------------------
Note the "waiting for 4 operations/tasks to finish".
I get this on two different boxes, and have observed similar behaviour with RE24 yesterday while testing on yet another box (not the test suite). If it works OK for you, let me know what data I can provide from my hanging slapd. GDB backtraces are below - dunno if they'll help.
Regards, Jonathan
From GDB: (gdb) thread apply all bt
Thread 4 (Thread 0x40b7cb90 (LWP 16444)): #0 0x4001a430 in __kernel_vsyscall () #1 0x40170075 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/i686/cmov/libpthread.so.0 #2 0x0818d44f in ldap_pvt_thread_pool_destroy (tpool=0x82917e4, run_pending=1) at tpool.c:570 #3 0x080634d7 in slapd_daemon_task (ptr=0x0) at daemon.c:2598 #4 0x4016c50f in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #5 0x4044ea0e in clone () from /lib/tls/i686/cmov/libc.so.6
Thread 3 (Thread 0x40f7db90 (LWP 16447)): #0 0x4001a430 in __kernel_vsyscall () #1 0x40172d09 in __lll_lock_wait () from /lib/tls/i686/cmov/libpthread.so.0 #2 0x4016e114 in _L_lock_89 () from /lib/tls/i686/cmov/libpthread.so.0 #3 0x4016da42 in pthread_mutex_lock () from /lib/tls/i686/cmov/libpthread.so.0 #4 0x080c8e11 in syncrepl_updateCookie (si=0x8fe4720, op=0x40f7cd44, pdn=<value optimized out>, syncCookie=0x40f7c9ec) at syncrepl.c:2891 #5 0x080cf40a in do_syncrep2 (op=0x40f7cd44, si=0x8fe4720) at syncrepl.c:894 #6 0x080d1e76 in do_syncrepl (ctx=0x40f7d218, arg=0x8fe3a88) at syncrepl.c:1333 #7 0x0806907b in connection_read_thread (ctx=0x40f7d218, argv=0x8) at connection.c:1225 #8 0x0818d93e in ldap_int_thread_pool_wrapper (xpool=0x8f97580) at tpool.c:663 #9 0x4016c50f in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #10 0x4044ea0e in clone () from /lib/tls/i686/cmov/libc.so.6
Thread 2 (Thread 0x4147fb90 (LWP 16449)): #0 0x4001a430 in __kernel_vsyscall () #1 0x40172d09 in __lll_lock_wait () from /lib/tls/i686/cmov/libpthread.so.0 #2 0x4016e114 in _L_lock_89 () from /lib/tls/i686/cmov/libpthread.so.0 #3 0x4016da42 in pthread_mutex_lock () from /lib/tls/i686/cmov/libpthread.so.0 #4 0x080d1c56 in do_syncrepl (ctx=0x4147f218, arg=0x8fe3a88) at syncrepl.c:1250 #5 0x0818d93e in ldap_int_thread_pool_wrapper (xpool=0x8f97580) at tpool.c:663 #6 0x4016c50f in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #7 0x4044ea0e in clone () from /lib/tls/i686/cmov/libc.so.6
Thread 1 (Thread 0x405a9c00 (LWP 16443)): #0 0x4001a430 in __kernel_vsyscall () #1 0x4016cbf7 in pthread_join () from /lib/tls/i686/cmov/libpthread.so.0 #2 0x080620eb in slapd_daemon () at daemon.c:2663 #3 0x0804edf9 in main (argc=8, argv=0xbfd9ddf4) at main.c:948 #0 0x4001a430 in __kernel_vsyscall ()
Works fine here...
Jonathan Clarke wrote:
I get this on two different boxes, and have observed similar behaviour with RE24 yesterday while testing on yet another box (not the test suite). If it works OK for you, let me know what data I can provide from my hanging slapd. GDB backtraces are below - dunno if they'll help.
In thread 3 frame 4 (syncrepl_updateCookie) print *si print *si->si_cookieState
Regards, Jonathan
From GDB: (gdb) thread apply all bt
Thread 4 (Thread 0x40b7cb90 (LWP 16444)): #0 0x4001a430 in __kernel_vsyscall () #1 0x40170075 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/i686/cmov/libpthread.so.0 #2 0x0818d44f in ldap_pvt_thread_pool_destroy (tpool=0x82917e4, run_pending=1) at tpool.c:570 #3 0x080634d7 in slapd_daemon_task (ptr=0x0) at daemon.c:2598 #4 0x4016c50f in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #5 0x4044ea0e in clone () from /lib/tls/i686/cmov/libc.so.6
Thread 3 (Thread 0x40f7db90 (LWP 16447)): #0 0x4001a430 in __kernel_vsyscall () #1 0x40172d09 in __lll_lock_wait () from /lib/tls/i686/cmov/libpthread.so.0 #2 0x4016e114 in _L_lock_89 () from /lib/tls/i686/cmov/libpthread.so.0 #3 0x4016da42 in pthread_mutex_lock () from /lib/tls/i686/cmov/libpthread.so.0 #4 0x080c8e11 in syncrepl_updateCookie (si=0x8fe4720, op=0x40f7cd44, pdn=<value optimized out>, syncCookie=0x40f7c9ec) at syncrepl.c:2891 #5 0x080cf40a in do_syncrep2 (op=0x40f7cd44, si=0x8fe4720) at syncrepl.c:894 #6 0x080d1e76 in do_syncrepl (ctx=0x40f7d218, arg=0x8fe3a88) at syncrepl.c:1333 #7 0x0806907b in connection_read_thread (ctx=0x40f7d218, argv=0x8) at connection.c:1225 #8 0x0818d93e in ldap_int_thread_pool_wrapper (xpool=0x8f97580) at tpool.c:663 #9 0x4016c50f in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #10 0x4044ea0e in clone () from /lib/tls/i686/cmov/libc.so.6
Thread 2 (Thread 0x4147fb90 (LWP 16449)): #0 0x4001a430 in __kernel_vsyscall () #1 0x40172d09 in __lll_lock_wait () from /lib/tls/i686/cmov/libpthread.so.0 #2 0x4016e114 in _L_lock_89 () from /lib/tls/i686/cmov/libpthread.so.0 #3 0x4016da42 in pthread_mutex_lock () from /lib/tls/i686/cmov/libpthread.so.0 #4 0x080d1c56 in do_syncrepl (ctx=0x4147f218, arg=0x8fe3a88) at syncrepl.c:1250 #5 0x0818d93e in ldap_int_thread_pool_wrapper (xpool=0x8f97580) at tpool.c:663 #6 0x4016c50f in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #7 0x4044ea0e in clone () from /lib/tls/i686/cmov/libc.so.6
Thread 1 (Thread 0x405a9c00 (LWP 16443)): #0 0x4001a430 in __kernel_vsyscall () #1 0x4016cbf7 in pthread_join () from /lib/tls/i686/cmov/libpthread.so.0 #2 0x080620eb in slapd_daemon () at daemon.c:2663 #3 0x0804edf9 in main (argc=8, argv=0xbfd9ddf4) at main.c:948 #0 0x4001a430 in __kernel_vsyscall ()
On 10.02.2009 13:52, Howard Chu wrote:
Works fine here...
Jonathan Clarke wrote:
I get this on two different boxes, and have observed similar behaviour with RE24 yesterday while testing on yet another box (not the test suite). If it works OK for you, let me know what data I can provide from my hanging slapd. GDB backtraces are below - dunno if they'll help.
In thread 3 frame 4 (syncrepl_updateCookie) print *si print *si->si_cookieState
Here it is: (also in text file attached, to avoid line wrapping)
(gdb) thread 3 [Switching to thread 3 (Thread 0x40f7db90 (LWP 16447))]#0 0x4001a430 in __kernel_vsyscall () (gdb) frame 4 #4 0x080c8e11 in syncrepl_updateCookie (si=0x8fe4720, op=0x40f7cd44, pdn=<value optimized out>, syncCookie=0x40f7c9ec) at syncrepl.c:2891 2891 ldap_pvt_thread_mutex_lock( &si->si_cookieState->cs_mutex ); (gdb) print *si $1 = {si_next = 0x0, si_be = 0x8fc45f8, si_wbe = 0x8fc45f8, si_re = 0x8fe3a88, si_rid = 1, si_ridtxt = "rid=001", si_bindconf = {sb_uri = {bv_len = 22, bv_val = 0x8fe4890 "ldap://localhost:9011/"}, sb_version = 3, sb_tls = 0, sb_method = 128, sb_timeout_api = 3, sb_timeout_net = 0, sb_binddn = { bv_len = 9, bv_val = 0x8fe4410 "cn=config"}, sb_cred = {bv_len = 8, bv_val = 0x8fe48d0 "gkdxHLiu"}, sb_saslmech = {bv_len = 0, bv_val = 0x0}, sb_secprops = 0x0, sb_realm = {bv_len = 0, bv_val = 0x0}, sb_authcId = {bv_len = 0, bv_val = 0x0}, sb_authzId = {bv_len = 0, bv_val = 0x0}, sb_tls_ctx = 0x0, sb_tls_cert = 0x0, sb_tls_key = 0x0, sb_tls_cacert = 0x0, sb_tls_cacertdir = 0x0, sb_tls_reqcert = 0x0, sb_tls_cipher_suite = 0x0, sb_tls_protocol_min = 0x0, sb_tls_crlcheck = 0x0, sb_tls_do_init = 0}, si_base = {bv_len = 9, bv_val = 0x8fe48f8 "cn=config"}, si_logbase = { bv_len = 0, bv_val = 0x0}, si_filterstr = {bv_len = 15, bv_val = 0x8fe3b38 "(objectclass=*)"}, si_logfilterstr = {bv_len = 0, bv_val = 0x0}, si_scope = 2, si_attrsonly = 0, si_anfile = 0x0, si_anlist = 0x8fe3b50, si_exanlist = 0x8fe3a70, si_attrs = 0x8fe4948, si_exattrs = 0x0, si_allattrs = 0, si_allopattrs = 0, si_schemachecking = 0, si_type = 3, si_ctype = 0, si_interval = 60, si_retryinterval = 0x8fe4918, si_retrynum_init = 0x8fe4968, si_retrynum = 0x8fe4958, si_syncCookie = {ctxcsn = 0x8fce678, octet_str = {bv_len = 52, bv_val = 0x8fe42b0 "rid=001,csn=20090210103047.821882Z#000000#000#000000"}, rid = 1, sid = -1, numcsns = 1, sids = 0x8fe1ef8, sc_next = { stqe_next = 0x0}}, si_cookieState = 0x8fe4978, si_cookieAge = 9, si_manageDSAit = 0, si_slimit = 0, si_tlimit = 0, si_refreshDelete = 1, si_refreshPresent = 0, si_refreshDone = 1, si_syncdata = 0, si_logstate = 0, si_got = 263443, si_msgid = 2, si_presentlist = 0x8fe4c50, si_ld = 0x8fd5180, si_conn = 0x4060dda8, si_nonpresentlist = {lh_first = 0x0}, si_mutex = {__data = {__lock = 2, __count = 0, __owner = 16447, __kind = 0, __nusers = 1, {__spins = 0, __list = {__next = 0x0}}}, __size = "\002\000\000\000\000\000\000\000?@\000\000\000\000\000\000\001\000\000\000\000\000\000", __align = 2}} (gdb) print *si->si_cookieState $2 = {cs_mutex = {__data = {__lock = 0, __count = 0, __owner = 60, __kind = 0, __nusers = 0, {__spins = 0, __list = {__next = 0x0}}}, __size = "\000\000\000\000\000\000\000\000<", '\0' <repeats 14 times>, __align = 0}, cs_num = 135076832, cs_age = 151446768, cs_vals = 0x81d8b4e, cs_sids = 0x906e504}
Jonathan Clarke wrote:
On 10.02.2009 13:52, Howard Chu wrote:
Works fine here...
Jonathan Clarke wrote:
I get this on two different boxes, and have observed similar behaviour with RE24 yesterday while testing on yet another box (not the test suite). If it works OK for you, let me know what data I can provide from my hanging slapd. GDB backtraces are below - dunno if they'll help.
In thread 3 frame 4 (syncrepl_updateCookie) print *si print *si->si_cookieState
Here it is: (also in text file attached, to avoid line wrapping)
Thanks. Looks like accessing a freed mutex, and valgrind confirms it. Will have to revisit this patch.
Quanah Gibson-Mount quanah@zimbra.com writes:
Please test current RE24 CVS. In particular, if people can test:
(a) Building without TLS & without sasl (b) Building without TLS (c) Building without sasl (d) If at least one person can build against GnuTLS instead of OpenSSL
opensuse-11.1 x86_64 BerkeleyDB-4.7.25 ( with patch patch.16415 and patch.4.7.25.1) export LIBS="-ltcmalloc" test008 and 0039 crashes
(gdb) file lt-slapd Reading symbols from /work/openldap/servers/slapd/.libs/lt-slapd...done. (gdb) core ../../../tests/core.16968 warning: Can't read pathname for load map: Input/output error. Reading symbols from /work/openldap/libraries/libldap_r/.libs/libldap_r-2.4-rele ng.so.2...done. Loaded symbols for /work/openldap/libraries/libldap_r/.libs/libldap_r-2.4-releng .so.2 Reading symbols from /work/openldap/libraries/liblber/.libs/liblber-2.4-releng.s o.2...done. Loaded symbols for /work/openldap/libraries/liblber/.libs/liblber-2.4-releng.so. 2 Reading symbols from /usr/lib64/libltdl.so.7...done. Loaded symbols for /usr/lib64/libltdl.so.7 Reading symbols from /lib64/libuuid.so.1...done. Loaded symbols for /lib64/libuuid.so.1 Reading symbols from /usr/local/BerkeleyDB.4.7/lib/libdb-4.7.so...done. Loaded symbols for /usr/local/BerkeleyDB.4.7/lib/libdb-4.7.so Reading symbols from /usr/lib64/libodbc.so.1...done. Loaded symbols for /usr/lib64/libodbc.so.1 Reading symbols from /lib64/libpthread.so.0...done. Loaded symbols for /lib64/libpthread.so.0 Reading symbols from /usr/lib64/libsasl2.so.2...done. Loaded symbols for /usr/lib64/libsasl2.so.2 Reading symbols from /lib64/libdl.so.2...done. Loaded symbols for /lib64/libdl.so.2 Reading symbols from /usr/lib64/libssl.so.0.9.8...done. Loaded symbols for /usr/lib64/libssl.so.0.9.8 Reading symbols from /usr/lib64/libcrypto.so.0.9.8...done. Loaded symbols for /usr/lib64/libcrypto.so.0.9.8 Reading symbols from /lib64/libresolv.so.2...done. Loaded symbols for /lib64/libresolv.so.2 Reading symbols from /usr/local/lib64/libtcmalloc.so.0...done. Loaded symbols for /usr/local/lib64/libtcmalloc.so.0 Reading symbols from /usr/local/lib64/libunwind.so.7...done. Loaded symbols for /usr/local/lib64/libunwind.so.7 Reading symbols from /lib64/libc.so.6...done. Loaded symbols for /lib64/libc.so.6 Reading symbols from /lib64/ld-linux-x86-64.so.2...done. Loaded symbols for /lib64/ld-linux-x86-64.so.2 Reading symbols from /lib64/libz.so.1...done. Loaded symbols for /lib64/libz.so.1 Reading symbols from /usr/lib64/libstdc++.so.6...done. Loaded symbols for /usr/lib64/libstdc++.so.6 Reading symbols from /lib64/libm.so.6...done. Loaded symbols for /lib64/libm.so.6 Reading symbols from /lib64/libgcc_s.so.1...done. Loaded symbols for /lib64/libgcc_s.so.1 Reading symbols from /usr/lib64/sasl2/liblogin.so...done. Loaded symbols for /usr/lib64/sasl2/liblogin.so Reading symbols from /lib64/libcrypt.so.1...done. Loaded symbols for /lib64/libcrypt.so.1 Reading symbols from /usr/lib64/sasl2/libanonymous.so...done. Loaded symbols for /usr/lib64/sasl2/libanonymous.so Reading symbols from /usr/lib64/sasl2/libdigestmd5.so...done. Loaded symbols for /usr/lib64/sasl2/libdigestmd5.so Reading symbols from /usr/lib64/sasl2/libcrammd5.so...done. Loaded symbols for /usr/lib64/sasl2/libcrammd5.so Reading symbols from /usr/lib64/sasl2/libsasldb.so...done. Loaded symbols for /usr/lib64/sasl2/libsasldb.so Reading symbols from /usr/lib64/libdb-4.5.so...done. Loaded symbols for /usr/lib64/libdb-4.5.so Reading symbols from /usr/lib64/sasl2/libldapdb.so...done. Loaded symbols for /usr/lib64/sasl2/libldapdb.so Reading symbols from /usr/lib64/libldap-2.4.so.2...done. Loaded symbols for /usr/lib64/libldap-2.4.so.2 Reading symbols from /usr/lib64/liblber-2.4.so.2...done. Loaded symbols for /usr/lib64/liblber-2.4.so.2 Reading symbols from /usr/lib64/sasl2/libplain.so...done. Loaded symbols for /usr/lib64/sasl2/libplain.so [New Thread 17155] [New Thread 17127] [New Thread 16968] [New Thread 17308] [New Thread 17305] [New Thread 17296] [New Thread 17229] [New Thread 16983] [New Thread 17188] [New Thread 17261] [New Thread 17283] [New Thread 17311] [New Thread 16984] [New Thread 17276] [New Thread 17171] [New Thread 17284] [New Thread 17262] Core was generated by `/work/openldap/servers/slapd/.libs/lt-slapd -s0 -f /work/ openldap/tests/testrun'. Program terminated with signal 11, Segmentation fault. #0 0x00002aac5ef3512d in __lock_detect () from /usr/local/BerkeleyDB.4.7/lib/libdb-4.7.so Current language: auto; currently asm (gdb) bt #0 0x00002aac5ef3512d in __lock_detect () from /usr/local/BerkeleyDB.4.7/lib/libdb-4.7.so #1 0x00002aac5ef32a56 in __lock_get_internal () from /usr/local/BerkeleyDB.4.7/lib/libdb-4.7.so #2 0x00002aac5ef33cc2 in __lock_vec () from /usr/local/BerkeleyDB.4.7/lib/libdb-4.7.so #3 0x00002aac5ef616a4 in __db_lget () from /usr/local/BerkeleyDB.4.7/lib/libdb-4.7.so #4 0x00002aac5eec29d2 in __bam_search () from /usr/local/BerkeleyDB.4.7/lib/libdb-4.7.so #5 0x00002aac5eeb0f96 in __bamc_search () from /usr/local/BerkeleyDB.4.7/lib/libdb-4.7.so #6 0x00002aac5eeb224a in __bamc_get () from /usr/local/BerkeleyDB.4.7/lib/libdb-4.7.so #7 0x00002aac5ef52e0f in __dbc_get () from /usr/local/BerkeleyDB.4.7/lib/libdb-4.7.so #8 0x00002aac5ef5fac4 in __dbc_get_pp () from /usr/local/BerkeleyDB.4.7/lib/libdb-4.7.so #9 0x0000000000531b7a in hdb_idl_fetch_key (be=0xae08c0, db=0xb84500, txn=0x4435ea0, key=0x2aac65c70340, ids=0x4436000, saved_cursor=0x0, get_flag=0) at idl.c:604 #10 0x0000000000535b29 in hdb_key_read (be=0xae08c0, db=0xb84500, txn=0x4435ea0, k=0x4335308, ids=0x4436000, saved_cursor=0x0, get_flag=0) ---Type <return> to continue, or q <return> to quit--- at key.c:50 #11 0x000000000052db3b in equality_candidates (op=0x4331c00, rtxn=0x4435ea0, ava=0x43351f8, ids=0x4636000, tmp=0x4436000) at filterindex.c:788 #12 0x000000000052b700 in hdb_filter_candidates (op=0x4331c00, rtxn=0x4435ea0, f=0x4335248, ids=0x4636000, tmp=0x4436000, stack=0x4736000) at filterindex.c:154 #13 0x000000000052cf85 in list_candidates (op=0x4331c00, rtxn=0x4435ea0, flist=0x2aac65c70840, ftype=161, ids=0x4536000, tmp=0x4436000, save=0x4636000) at filterindex.c:581 #14 0x000000000052bc1c in hdb_filter_candidates (op=0x4331c00, rtxn=0x4435ea0, f=0x2aac65c70820, ids=0x4536000, tmp=0x4436000, stack=0x4636000) at filterindex.c:204 #15 0x000000000052cf85 in list_candidates (op=0x4331c00, rtxn=0x4435ea0, flist=0x2aac65c70800, ftype=160, ids=0x2aac65cf0a50, tmp=0x4436000, save=0x4536000) at filterindex.c:581 #16 0x000000000052bb74 in hdb_filter_candidates (op=0x4331c00, rtxn=0x4435ea0, f=0x2aac65c70860, ids=0x2aac65cf0a50, tmp=0x4436000, stack=0x4536000) at filterindex.c:198 #17 0x00000000004f48d3 in search_candidates (op=0x4331c00, rs=0x2aac65df1c30, e=0x2aac65c70a00, txn=0x4435ea0, ids=0x2aac65cf0a50, scopes=0x2aac65c70a50) at search.c:1204 #18 0x00000000004f2c59 in hdb_search (op=0x4331c00, rs=0x2aac65df1c30) at search.c:585 ---Type <return> to continue, or q <return> to quit--- #19 0x000000000043f4e4 in fe_op_search (op=0x4331c00, rs=0x2aac65df1c30) at search.c:366 #20 0x000000000043ee4f in do_search (op=0x4331c00, rs=0x2aac65df1c30) at search.c:217 #21 0x000000000043bbc4 in connection_operation (ctx=0x2aac65df1d80, arg_v=0x4331c00) at connection.c:1097 #22 0x000000000043c0e5 in connection_read_thread (ctx=0x2aac65df1d80, argv=0x24) at connection.c:1223 #23 0x00002aac5e5ee6ee in ldap_int_thread_pool_wrapper (xpool=0xabfee0) at tpool.c:663 #24 0x00002aac5f45f070 in start_thread () from /lib64/libpthread.so.0 #25 0x00002aac607cd10d in clone () from /lib64/libc.so.6 #26 0x0000000000000000 in ?? () (gdb)
-Dieter
-
Aaron Richton -
Dieter Kluenter -
Howard Chu -
Jonathan Clarke -
Quanah Gibson-Mount