openldap-bugs

openldap-bugs@openldap.org

1 participants
20959 discussions

Re: (ITS#6048) All mailing list archives have stopped at March
by Kurt＠OpenLDAP.org 06 Apr '09

06 Apr '09

On Apr 6, 2009, at 2:27 PM, ghenry(a)OpenLDAP.org wrote: > Full_Name: Gavin Henry > Version: > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (212.159.59.85) > Submitted by: ghenry > > > Just a quick ticket to mention that since the upgrade all the > mailing list > archives have stopped at March. This problem has been fixed. Unfortunately, there will be a hole in the archives unless someone happens to have a decent mbox archives for backfill (maybe one of the 3rd party mail archives have mbox archives available). -- Kurt

1 0

(ITS#6048) All mailing list archives have stopped at March
by ghenry＠OpenLDAP.org 06 Apr '09

06 Apr '09

Full_Name: Gavin Henry Version: OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (212.159.59.85) Submitted by: ghenry Just a quick ticket to mention that since the upgrade all the mailing list archives have stopped at March. Thanks.

1 0

Re: (ITS#6047) bdb cache seg. fault
by rein＠OpenLDAP.org 06 Apr '09

06 Apr '09

quanah(a)zimbra.com wrote: > --On Monday, April 06, 2009 6:15 PM +0000 rein(a)OpenLDAP.org wrote: >> I have had a couple of seg. faults in back-bdb cache.c during full resync >> of a consumer. The default bdb *cachesize configuration was being used >> (which was way too low now that cache limits are enforced more >> strictly..). Some info from two of the core files are listed below, the >> core files are available for further analyze. > > DB_CONFIG cachesize or slapd.conf cachesize? DB_CONFIG: set_cachesize 0 75497472 0 set_lk_max_locks 10000 set_lk_max_objects 5000 No *cachesize directives in slapd.conf. Rein

1 0

Re: (ITS#6047) bdb cache seg. fault
by quanah＠zimbra.com 06 Apr '09

06 Apr '09

--On Monday, April 06, 2009 6:15 PM +0000 rein(a)OpenLDAP.org wrote: > Full_Name: Rein Tollevik > Version: 2.4.16 > OS: linux > URL: > Submission from: (NULL) (81.93.160.250) > Submitted by: rein > > > I have had a couple of seg. faults in back-bdb cache.c during full resync > of a consumer. The default bdb *cachesize configuration was being used > (which was way too low now that cache limits are enforced more > strictly..). Some info from two of the core files are listed below, the > core files are available for further analyze. DB_CONFIG cachesize or slapd.conf cachesize? --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6047) bdb cache seg. fault
by rein＠OpenLDAP.org 06 Apr '09

06 Apr '09

Full_Name: Rein Tollevik Version: 2.4.16 OS: linux URL: Submission from: (NULL) (81.93.160.250) Submitted by: rein I have had a couple of seg. faults in back-bdb cache.c during full resync of a consumer. The default bdb *cachesize configuration was being used (which was way too low now that cache limits are enforced more strictly..). Some info from two of the core files are listed below, the core files are available for further analyze. Rein Tollevik Basefarm AS Core 1: Program terminated with signal 11, Segmentation fault. #0 0x0000002a9677ac3c in pthread_mutex_lock () from /lib64/tls/libpthread.so.0 (gdb) where #0 0x0000002a9677ac3c in pthread_mutex_lock () from /lib64/tls/libpthread.so.0 #1 0x0000002a9567eaa3 in ldap_pvt_thread_mutex_lock (mutex=0x38) at thr_posix.c:296 #2 0x00000000004be2ae in bdb_cache_delete_internal (cache=0x8e1970, e=0x2ac86a0b60, decr=0) at cache.c:1372 #3 0x00000000004beafb in bdb_cache_lru_purge (bdb=0x8e1910) at cache.c:776 #4 0x00000000004bf686 in bdb_cache_find_id (op=0x410006b0, tid=0xe82bd0, id=1, eip=<value optimized out>, flag=0, lock=0x40e7f4d0) at cache.c:1053 #5 0x00000000004c3563 in bdb_dn2entry (op=0x410006b0, tid=0xe82bd0, dn=<value optimized out>, e=0x40e7f500, matched=1, lock=0x40e7f4d0) at dn2entry.c:67 #6 0x00000000004ab5ac in bdb_search (op=0x410006b0, rs=0x40ffffb0) at search.c:374 #7 0x0000000000496b9a in overlay_op_walk (op=0x410006b0, rs=0x40ffffb0, which=<value optimized out>, oi=0x8e20a0, on=0x0) at backover.c:669 #8 0x00000000004975a6 in over_op_func (op=0x410006b0, rs=0x1, which=op_bind) at backover.c:721 #9 0x000000000049769e in over_op_search (op=0x38, rs=0x2ac86a0b60) at backover.c:743 #10 0x0000000000494728 in glue_sub_search (op=0x410006b0, rs=0x40ffffb0, b0=0x0, on=0x8e0a40) at backglue.c:342 #11 0x00000000004953b5 in glue_op_search (op=0x410006b0, rs=0x40ffffb0) at backglue.c:465 #12 0x0000000000496b47 in overlay_op_walk (op=0x410006b0, rs=0x40ffffb0, which=<value optimized out>, oi=0x8e5860, on=0x8d88e0) at backover.c:659 #13 0x00000000004975a6 in over_op_func (op=0x410006b0, rs=0x1, which=op_bind) at backover.c:721 #14 0x000000000049769e in over_op_search (op=0x38, rs=0x2ac86a0b60) at backover.c:743 #15 0x000000000048f3ba in syncrepl_entry (si=0x8e5520, op=0x410006b0, entry=0x9f74d8, modlist=0x41000458, syncstate=1, syncUUID=0x41000500, syncCSN=0x0) at syncrepl.c:2132 #16 0x00000000004925ff in do_syncrep2 (op=0x410006b0, si=0x8e5520) at syncrepl.c:892 #17 0x0000000000494166 in do_syncrepl (ctx=<value optimized out>, arg=0x8e52f0) at syncrepl.c:1361 #18 0x00000000004316d4 in connection_read_thread (ctx=0x41000e10, argv=<value optimized out>) at connection.c:1225 #19 0x0000002a9567e297 in ldap_int_thread_pool_wrapper (xpool=<value optimized out>) at tpool.c:663 #20 0x0000002a96779137 in start_thread () from /lib64/tls/libpthread.so.0 #21 0x0000002a9694f543 in clone () from /lib64/tls/libc.so.6 #22 0x0000000000000000 in ?? () (gdb) frame 2 #2 0x00000000004be2ae in bdb_cache_delete_internal (cache=0x8e1970, e=0x2ac86a0b60, decr=0) at cache.c:1372 1372 bdb_cache_entryinfo_lock( e->bei_parent ); (gdb) print *e $1 = {bei_parent = 0x0, bei_id = 14820, bei_lockpad = 0, bei_state = 128, bei_finders = 0, bei_nrdn = {bv_len = 7, bv_val = 0x0}, bei_e = 0x0, bei_kids = 0x0, bei_kids_mutex = {__m_reserved = 2, __m_count = 0, __m_owner = 0x10000186c, __m_kind = 0, __m_lock = {__status = 0, __spinlock = 0}}, bei_lrunext = 0xabf230, bei_lruprev = 0x0} (gdb) frame 3 #3 0x00000000004beafb in bdb_cache_lru_purge (bdb=0x8e1910) at cache.c:776 776 bdb_cache_delete_internal( &bdb->bi_cache, elru, 0 ); (gdb) print eicount $2 = 0 (gdb) print eifree $3 = 10 Core 2: Program terminated with signal 11, Segmentation fault. #0 0x0000002a9677ac3c in pthread_mutex_lock () from /lib64/tls/libpthread.so.0 (gdb) where #0 0x0000002a9677ac3c in pthread_mutex_lock () from /lib64/tls/libpthread.so.0 #1 0x0000002a9567eaa3 in ldap_pvt_thread_mutex_lock (mutex=0x38) at thr_posix.c:296 #2 0x00000000004be2ae in bdb_cache_delete_internal (cache=0x8e1970, e=0x2acdee8af0, decr=0) at cache.c:1372 #3 0x00000000004beafb in bdb_cache_lru_purge (bdb=0x8e1910) at cache.c:776 #4 0x00000000004bf686 in bdb_cache_find_id (op=0x418003a0, tid=0xacf790, id=10150, eip=<value optimized out>, flag=0, lock=0x4167fb90) at cache.c:1053 #5 0x00000000004acde5 in bdb_search (op=0x418003a0, rs=0x41800330) at search.c:706 #6 0x0000000000496b9a in overlay_op_walk (op=0x418003a0, rs=0x41800330, which=<value optimized out>, oi=0x8e20a0, on=0x0) at backover.c:669 #7 0x00000000004975a6 in over_op_func (op=0x418003a0, rs=0x1, which=op_bind) at backover.c:721 #8 0x000000000049769e in over_op_search (op=0x38, rs=0x2acdee8af0) at backover.c:743 #9 0x0000000000494728 in glue_sub_search (op=0x418003a0, rs=0x41800330, b0=0x0, on=0x8e0a40) at backglue.c:342 #10 0x00000000004953b5 in glue_op_search (op=0x418003a0, rs=0x41800330) at backglue.c:465 #11 0x0000000000496b47 in overlay_op_walk (op=0x418003a0, rs=0x41800330, which=<value optimized out>, oi=0x8e5860, on=0x8d88e0) at backover.c:659 #12 0x00000000004975a6 in over_op_func (op=0x418003a0, rs=0x1, which=op_bind) at backover.c:721 #13 0x000000000049769e in over_op_search (op=0x38, rs=0x2acdee8af0) at backover.c:743 #14 0x0000002a9a71c5b9 in syncprov_findcsn (op=0xdc83f0, mode=FIND_PRESENT) at syncprov.c:707 #15 0x0000002a9a71d806 in syncprov_op_search (op=0xdc83f0, rs=0x41801cc0) at syncprov.c:2484 #16 0x0000000000496b47 in overlay_op_walk (op=0xdc83f0, rs=0x41801cc0, which=<value optimized out>, oi=0x8e5860, on=0x8d8dd0) at backover.c:659 #17 0x00000000004975a6 in over_op_func (op=0xdc83f0, rs=0x1, which=op_bind) at backover.c:721 #18 0x000000000049769e in over_op_search (op=0x38, rs=0x2acdee8af0) at backover.c:743 #19 0x000000000043292a in fe_op_search (op=0xdc83f0, rs=0x41801cc0) at search.c:366 #20 0x000000000043336c in do_search (op=0xdc83f0, rs=0x41801cc0) at search.c:217 #21 0x0000000000430775 in connection_operation (ctx=0x41801e10, arg_v=<value optimized out>) at connection.c:1097 #22 0x00000000004316c8 in connection_read_thread (ctx=0x41801e10, argv=<value optimized out>) at connection.c:1223 #23 0x0000002a9567e297 in ldap_int_thread_pool_wrapper (xpool=<value optimized out>) at tpool.c:663 #24 0x0000002a96779137 in start_thread () from /lib64/tls/libpthread.so.0 #25 0x0000002a9694f543 in clone () from /lib64/tls/libc.so.6 #26 0x0000000000000000 in ?? () (gdb) frame 2 #2 0x00000000004be2ae in bdb_cache_delete_internal (cache=0x8e1970, e=0x2acdee8af0, decr=0) at cache.c:1372 1372 bdb_cache_entryinfo_lock( e->bei_parent ); (gdb) print *e $1 = {bei_parent = 0xa775e0, bei_id = 10151, bei_lockpad = 0, bei_state = 128, bei_finders = 0, bei_nrdn = {bv_len = 11, bv_val = 0x2acec4b630 "dc=ud-www01"}, bei_e = 0x0, bei_kids = 0x0, bei_kids_mutex = {__m_reserved = 1, __m_count = 0, __m_owner = 0x100001789, __m_kind = 0, __m_lock = {__status = 0, __spinlock = 0}}, bei_lrunext = 0xd671c0, bei_lruprev = 0xd671c0}

1 0

Re: (ITS#6046) BDB Support -no member named 'lk_handle'
by quanah＠zimbra.com 06 Apr '09

06 Apr '09

--On Monday, April 06, 2009 10:30 AM +0000 alex.ist(a)wirklich.net wrote: > Full_Name: Alexander > Version: 2.4.11 > OS: Fedora 10 > URL: > Submission from: (NULL) (213.150.1.77) > > > Hello, > I would like to install OpenLDAP 2.4.11 on Fedora FC10. > It seems that it comes with BDB Berkeley DB 4.7.25 > I experience an error during make that seems to be related with a wrong > version. > is this combination supported? > should I install an older version of the database? > I used the last stable version of OpenLDAP. BDB 4.7 support only exists in 2.4.12 or later. Please use OpenLDAP 2.4.16 instead of 2.4.11, as there have literally been hundreds of fixes since 2.4.11, and it is magnitudes more stable than 2.4.11. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6046) BDB Support -no member named 'lk_handle'
by alex.ist＠wirklich.net 06 Apr '09

06 Apr '09

Full_Name: Alexander Version: 2.4.11 OS: Fedora 10 URL: Submission from: (NULL) (213.150.1.77) Hello, I would like to install OpenLDAP 2.4.11 on Fedora FC10. It seems that it comes with BDB Berkeley DB 4.7.25 I experience an error during make that seems to be related with a wrong version. is this combination supported? should I install an older version of the database? I used the last stable version of OpenLDAP. br, alex make [...] make[3]: Entering directory `/etc/openldap-2.4.11/servers/slapd/back-bdb' rm -f version.c ../../../build/mkversion -v "2.4.11" back_bdb > version.c /bin/sh ../../..//libtool --tag=disable-shared --mode=compile cc -g -O2 -I../../../include -I../../../include -I.. -I./.. -D_GNU_SOURCE -c init.c cc -g -O2 -I../../../include -I../../../include -I.. -I./.. -D_GNU_SOURCE -c init.c -o init.o init.c: In function 'bdb_db_open': init.c:509: error: 'DB_ENV' has no member named 'lk_handle' init.c: In function 'bdb_back_initialize': init.c:752: warning: passing argument 1 of 'db_env_set_func_yield' from incompatible pointer type make[3]: *** [init.lo] Error 1 make[3]: Leaving directory `/etc/openldap-2.4.11/servers/slapd/back-bdb' make[2]: *** [.backend] Error 1 make[2]: Leaving directory `/etc/openldap-2.4.11/servers/slapd' make[1]: *** [all-common] Error 1 make[1]: Leaving directory `/etc/openldap-2.4.11/servers' make: *** [all-common] Error 1

1 0

Re: (ITS#6044) AnonCVS not working
by hyc＠symas.com 05 Apr '09

05 Apr '09

evaristojosec(a)yahoo.es wrote: > Full_Name: Evaristo Camarero > Version: Not relevant > OS: Fedora Core 10 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (194.237.142.7) > > > I am trying to access to the OpenLDAP repository but it is not possible doing > it > > cvs -d :pserver:anonymous@cvs.OpenLDAP.org:/repo/OpenLDAP login > Logging in to :pserver:anonymous@cvs.openldap.org:2401/repo/OpenLDAP > CVS password: > cvs [login aborted]: end of file from server (consult above messages if any) Several of the OpenLDAP.org services were down for a system upgrade. Everything should now be up though. -- -- 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#6021) slapo-pcache/back-ldap slapd crashes
by hyc＠symas.com 05 Apr '09

05 Apr '09

toby(a)inf.ed.ac.uk wrote: > Hi there, I've been collecting a bit more information on these > crashes... > > Since we started running 2.4.15: > > 26 core files, of these, 15 have crashed in memory.c:152 > > It looks like the majority of these were removing stale entries from > the cache when slapd crashed, which wasn't the case with the original > ticket I submitted. Also, the last thing logged by slapd in quite a > few of these cases was along this lines of ... > > Mar 30 20:50:16 albany slapd[14239]: DELETING ENTRY TEMPLATE=db78c810-0c2a-49de-96af-f5796bbe8ca3 > Mar 30 20:50:17 albany last message repeated 14 times > > ... I don't know whether this is useful? > > Here's the details of the latest crash, slapd log and backtrace: > Program terminated with signal 6, Aborted. > #0 0x00185402 in __kernel_vsyscall () > (gdb) bt When a program aborts it will print an error message on stderr. It would be useful to have that message. Can you please update to RE24, the 2.4.16 candidate, and see if the behavior has changed? Also, can you please be sure to compile without optimization (or with frame pointers intact; gcc -fno-omit-frame-pointer); there seem to be a few functions missing in these stack traces. Also grab the latest overlays/pcache.c (1.168). It probably won't fix things, but it should make the crashes a little more obvious. > #0 0x00185402 in __kernel_vsyscall () > #1 0x00476d20 in raise () from /lib/libc.so.6 > #2 0x00478631 in abort () from /lib/libc.so.6 > #3 0x004aee6b in __libc_message () from /lib/libc.so.6 > #4 0x004b6b16 in _int_free () from /lib/libc.so.6 > #5 0x004ba070 in free () from /lib/libc.so.6 > #6 0x081d5746 in ber_memfree_x (p=0x841e688, ctx=0x0) at memory.c:152 > #7 0x081d630c in ber_bvarray_free_x (a=0x843af58, ctx=0x0) at memory.c:731 > #8 0x081d6343 in ber_bvarray_free (a=0x843af58) at memory.c:741 > #9 0x0807979c in attr_clean (a=0xb62934ec) at attr.c:146 > #10 0x0807983b in attrs_free (a=0xb62934ec) at attr.c:196 > #11 0x0807c059 in entry_clean (e=0xb6727584) at entry.c:504 > #12 0x0807c080 in entry_free (e=0xb6727584) at entry.c:514 > #13 0x08140030 in bdb_entry_return (e=0xb6727584) at id2entry.c:229 > #14 0x08134c0c in bdb_cache_delete_cleanup (cache=0x838956c, ei=0xb332a060) > at cache.c:1316 > #15 0x0813a824 in bdb_delete (op=0xb32fed5c, rs=0xb32febec) at delete.c:575 > #16 0x08177be1 in remove_query_data (op=0xb32fed5c, rs=0xb32fecf8, > query_uuid=0x83ff288) at pcache.c:1460 > #17 0x0817af8f in consistency_check (ctx=0xb32ff1d0, arg=0x83f57e8) > at pcache.c:2611 > #18 0x0819ecad in ldap_int_thread_pool_wrapper (xpool=0x8366f90) at tpool.c:663 > #19 0x005c746b in start_thread () from /lib/libpthread.so.0 > #20 0x0051edbe in clone () from /lib/libc.so.6 > (gdb) > > > Also, I'll include details of another type of crash that I've seen 3 > times since running 2.4.15 in the lab, at the risk of overloading > information into this ticket. I'm including it here as the slapd > behaviour at time of crash was similar to that noted above, > i.e. removing stale entries from the cache: Yeah, based on the debug output it's probably related. -- -- 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#6045) Use copy of db in syncprov_matchops
by hyc＠symas.com 04 Apr '09

04 Apr '09

Rein Tollevik wrote: > Howard Chu wrote: >> Rein Tollevik wrote: >>> hyc(a)symas.com wrote: >>>> rein(a)OpenLDAP.org wrote: >>> >>>>> I had a couple of seg. faults when resync'ing my servers after >>>>> upgrading to the >>>>> upcoming 2.4.16 release. Looks as if a copy of the backend must be >>>>> used when >>>>> testing the filter in syncprov_matchops. See the gdb output at the >>>>> end. Note, >>>>> some function names are incorrect due to optimization. A fix is >>>>> coming. >>>> >>>> The fix makes no sense, or the problem has not yet been analyzed >>>> sufficiently. >>>> Nobody in that call chain should be zeroing out bd_info. And if >>>> someone *is*, >>>> then it will happen in *whatever* BackendDB structure is currently >>>> being used. >>>> >>>> Explain the real cause of the problem, and why the fix is correct. >>> >>> The problem is not zeroing of bd_info, it is that the entire op2.o_bd >>> points to garbage, as the gdb output shows. I did forgot to print >>> ss->s_op->o_bd though. op2 is a copy of *ss->s_op, but op2.o_bd and >>> ss->s_op->o_bd differ. The content of *ss->s_op->o_bd looks reasonable. >>> >>> The copying of *ss->s_op into op2 was introduced in rev 1.233 as a fix >>> to ITS#5486. It doesn't say why this was the correct fix, but I assume >>> it was done because something could modify *ss->s_op while the filter >>> was being tested. >> >> Yes of course, particularly op->o_callback. >> >>> Btw, the gdb output from ITS#5486 shows a db with >>> similar garbage, so I suspect that these ITSes are related. >> >>> Assuming that something could mess with ss->s_op they might as well mess >>> with ss->s_op->o_bd. The copying of the op->o_bd that takes place all >>> around is a nightmare! I have no clue as to who modified *ss->s_op >>> and/or *ss->s_op->o_bd, and I'm not very satisfied with the fact that >>> something did. Finding out why this happened may be the correct fix. >> >> Yes, that's my point. > >> Down the road we need to fix things so that all this copying is >> unnecessary; it just involves adding an op->o_bd_info field so that we >> no longer need to change anything in the op->o_bd itself. > > YES! Would defining o_bd_info as o_bd->bd_info in the meantime ease the > transition? That would allow us to fix the code that accesses bd_info > step by step before actually making the real fix. This would be a 2.5.x change; I'd rather not start this before we have a new 2.4 Stable release. >> But in the >> meantime, we need to find out why an invalid op->o_bd is there. Most >> likely some lower function temporarily put a stack'd copy in there and >> didn't restore the original value before returning. And again, if that's >> the case, then it doesn't matter what value you set higher up, copy or >> not it will still point to garbage. > > I'm more afraid we have a race condition here. I.e, thread A puts a > pointer to a stack copy of the BackendDB into ss->s_op->o_bd. matchops > in thread B copies this op into op2 before thread A restores the > original o_bd. Leaving thread B with a pointer to junk in op2.o_bd. > Some more gdb output below, thread 2 looks suspicious here. Thread 1 > was the failing one, its ss->s_op is the same as the op argument passed > as argument in thread 2. OK, that's the real problem. When a persistent search starts, it's recorded using the op of the active search (ss->s_op), while it's in refresh phase. When the refresh phase ends and it goes into persist, then the op is detached from the connection manager's control, and ss->s_op is replaced by a copy. But if writes occur while the refresh is still happening, they'll be referencing ss->s_op which is still the active refresh op. The fix should be to use the current op's op->o_bd; each of the threads is executing in the same database so the current thread's o_bd should be functionally equivalent to the s_op's o_bd. There's no reason to make a new copy of the db. > Rein > > (gdb) thr app all where > > Thread 18 (process 32255): > #0 0xb7fe97a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 > #1 0xb7c540fd in pthread_join () from /lib/tls/libpthread.so.0 > #2 0xb7fb4460 in ldap_pvt_thread_join (thread=2411723696, > thread_return=0x0) at thr_posix.c:197 > #3 0x0806e88f in slapd_daemon () at daemon.c:2665 > #4 0x0805ac67 in main (argc=13, argv=0xbffffb44) at main.c:955 > > Thread 17 (process 32257): > #0 0xb7fe97a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 > #1 0xb7be3a41 in select () from /lib/tls/libc.so.6 > #2 0x08071aa0 in slapd_daemon_task (ptr=0x0) at daemon.c:2291 > #3 0xb7c53371 in start_thread () from /lib/tls/libpthread.so.0 > #4 0xb7beaffe in clone () from /lib/tls/libc.so.6 > > Thread 16 (process 32258): > #0 0x080f8e01 in bdb_search (op=0x8e193ba4, rs=0x8e193b68) at search.c:798 > #1 0x080e13cf in overlay_op_walk (op=0x8e193ba4, rs=0x8e193b68, > which=op_search, oi=0x8299040, on=0x8299140) at backover.c:669 > #2 0x080e19b5 in over_op_func (op=0x8e193ba4, rs=0x8e193b68, > which=op_search) at backover.c:721 > #3 0x080e1af5 in over_op_search (op=0x8e193ba4, rs=0x8e193b68) at > backover.c:743 > #4 0x080df000 in glue_sub_search (op=0x8e193ba4, rs=0x8e193b68, > b0=0x83f82f4, on=0x8298ed0) at backglue.c:342 > #5 0x080dfc04 in glue_op_search (op=0xae49ec8, rs=0x8e193b68) at > backglue.c:465 > #6 0x080e1379 in overlay_op_walk (op=0x8e193ba4, rs=0x8e193b68, > which=op_search, oi=0x82a3098, on=0x82a3298) at backover.c:659 > #7 0x080e19b5 in over_op_func (op=0x8e193ba4, rs=0x8e193b68, > which=op_search) at backover.c:721 > #8 0x080e1af5 in over_op_search (op=0x8e193ba4, rs=0x8e193b68) at > backover.c:743 > #9 0xb7a39dbb in syncprov_findcsn (op=0x8c22710, mode=FIND_PRESENT) at > syncprov.c:707 > #10 0xb7a3af84 in syncprov_op_search (op=0x8c22710, rs=0x8e1951c0) at > syncprov.c:2484 > #11 0x080e1379 in overlay_op_walk (op=0x8c22710, rs=0x8e1951c0, > which=op_search, oi=0x82a3098, on=0x82935e8) at backover.c:659 > #12 0x080e19b5 in over_op_func (op=0x8c22710, rs=0x8e1951c0, > which=op_search) at backover.c:721 > #13 0x080e1af5 in over_op_search (op=0x8c22710, rs=0x8e1951c0) at > backover.c:743 > #14 0x080771c4 in fe_op_search (op=0x8c22710, rs=0x8e1951c0) at search.c:366 > #15 0x08077d53 in do_search (op=0x8c22710, rs=0x8e1951c0) at search.c:217 > #16 0x08074d3c in connection_operation (ctx=0x8e1952b8, arg_v=0x8c22710) > at connection.c:1097 > #17 0x08075d48 in connection_read_thread (ctx=0x8e1952b8, argv=0x52) at > connection.c:1223 > #18 0xb7fb3a20 in ldap_int_thread_pool_wrapper (xpool=0x81f8cf0) at > tpool.c:663 > #19 0xb7c53371 in start_thread () from /lib/tls/libpthread.so.0 > #20 0xb7beaffe in clone () from /lib/tls/libc.so.6 > > Thread 15 (process 32259): > #0 0xb7fe97a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 > #1 0xb7c55b26 in pthread_cond_wait@@GLIBC_2.3.2 () from > /lib/tls/libpthread.so.0 > #2 0xb7fb435b in ldap_pvt_thread_cond_wait (cond=0x81f8d0c, > mutex=0x81f8cf4) at thr_posix.c:277 > #3 0xb7fb39e4 in ldap_int_thread_pool_wrapper (xpool=0x81f8cf0) at > tpool.c:654 > #4 0xb7c53371 in start_thread () from /lib/tls/libpthread.so.0 > #5 0xb7beaffe in clone () from /lib/tls/libc.so.6 > > Thread 14 (process 32260): > #0 0xb7fe97a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 > #1 0xb7c55b26 in pthread_cond_wait@@GLIBC_2.3.2 () from > /lib/tls/libpthread.so.0 > #2 0xb7fb435b in ldap_pvt_thread_cond_wait (cond=0x81f8d0c, > mutex=0x81f8cf4) at thr_posix.c:277 > #3 0xb7fb39e4 in ldap_int_thread_pool_wrapper (xpool=0x81f8cf0) at > tpool.c:654 > #4 0xb7c53371 in start_thread () from /lib/tls/libpthread.so.0 > #5 0xb7beaffe in clone () from /lib/tls/libc.so.6 > > Thread 13 (process 32261): > #0 0xb7fe97a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 > #1 0xb7c55b26 in pthread_cond_wait@@GLIBC_2.3.2 () from > /lib/tls/libpthread.so.0 > #2 0xb7fb435b in ldap_pvt_thread_cond_wait (cond=0x81f8d0c, > mutex=0x81f8cf4) at thr_posix.c:277 > #3 0xb7fb39e4 in ldap_int_thread_pool_wrapper (xpool=0x81f8cf0) at > tpool.c:654 > #4 0xb7c53371 in start_thread () from /lib/tls/libpthread.so.0 > #5 0xb7beaffe in clone () from /lib/tls/libc.so.6 > > Thread 12 (process 32262): > #0 0xb7ef22ce in __lock_get_internal () from /local/lib/libdb-4.7.so > #1 0xb7ef3758 in __lock_get_pp () from /local/lib/libdb-4.7.so > #2 0x0810adee in bdb_cache_entry_db_lock (bdb=0x8372848, txn=<value > optimized out>, ei=0x75788730, rw=1, tryOnly=1, lock=0x8d0cf3ec) at > cache.c:221 > ---Type<return> to continue, or q<return> to quit--- > #3 0x0810bad7 in bdb_cache_lru_purge (bdb=0x8298bf8) at cache.c:738 > #4 0x0810c6c4 in bdb_cache_find_id (op=0x8d18fba4, tid=0x8bd6bd8, > id=31294, eip=0x8d0cf614, flag=2, lock=0x8d0cf5f8) at cache.c:1053 > #5 0x080f8b57 in bdb_search (op=0x8d18fba4, rs=0x8d18fb68) at search.c:706 > #6 0x080e13cf in overlay_op_walk (op=0x8d18fba4, rs=0x8d18fb68, > which=op_search, oi=0x8299040, on=0x8299140) at backover.c:669 > #7 0x080e19b5 in over_op_func (op=0x8d18fba4, rs=0x8d18fb68, > which=op_search) at backover.c:721 > #8 0x080e1af5 in over_op_search (op=0x8d18fba4, rs=0x8d18fb68) at > backover.c:743 > #9 0x080df000 in glue_sub_search (op=0x8d18fba4, rs=0x8d18fb68, > b0=0x8097, on=0x8298ed0) at backglue.c:342 > #10 0x080dfc04 in glue_op_search (op=0x1, rs=0x8d18fb68) at backglue.c:465 > #11 0x080e1379 in overlay_op_walk (op=0x8d18fba4, rs=0x8d18fb68, > which=op_search, oi=0x82a3098, on=0x82a3298) at backover.c:659 > #12 0x080e19b5 in over_op_func (op=0x8d18fba4, rs=0x8d18fb68, > which=op_search) at backover.c:721 > #13 0x080e1af5 in over_op_search (op=0x8d18fba4, rs=0x8d18fb68) at > backover.c:743 > #14 0xb7a39dbb in syncprov_findcsn (op=0x88cef38, mode=FIND_PRESENT) at > syncprov.c:707 > #15 0xb7a3af84 in syncprov_op_search (op=0x88cef38, rs=0x8d1911c0) at > syncprov.c:2484 > #16 0x080e1379 in overlay_op_walk (op=0x88cef38, rs=0x8d1911c0, > which=op_search, oi=0x82a3098, on=0x82935e8) at backover.c:659 > #17 0x080e19b5 in over_op_func (op=0x88cef38, rs=0x8d1911c0, > which=op_search) at backover.c:721 > #18 0x080e1af5 in over_op_search (op=0x88cef38, rs=0x8d1911c0) at > backover.c:743 > #19 0x080771c4 in fe_op_search (op=0x88cef38, rs=0x8d1911c0) at search.c:366 > #20 0x08077d53 in do_search (op=0x88cef38, rs=0x8d1911c0) at search.c:217 > #21 0x08074d3c in connection_operation (ctx=0x8d1912b8, arg_v=0x88cef38) > at connection.c:1097 > #22 0x08075d48 in connection_read_thread (ctx=0x8d1912b8, argv=0x4a) at > connection.c:1223 > #23 0xb7fb3a20 in ldap_int_thread_pool_wrapper (xpool=0x81f8cf0) at > tpool.c:663 > #24 0xb7c53371 in start_thread () from /lib/tls/libpthread.so.0 > #25 0xb7beaffe in clone () from /lib/tls/libc.so.6 > > Thread 11 (process 32263): > #0 0xb7fe97a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 > #1 0xb7c55b26 in pthread_cond_wait@@GLIBC_2.3.2 () from > /lib/tls/libpthread.so.0 > #2 0xb7fb435b in ldap_pvt_thread_cond_wait (cond=0xb79b3e74, > mutex=0xb79b3e5c) at thr_posix.c:277 > #3 0x0808594c in send_ldap_ber (op=<value optimized out>, > ber=0x8cccea0c) at result.c:218 > #4 0x08087cdc in slap_send_search_entry (op=0x993f938, rs=0x8cd901c0) > at result.c:1247 > #5 0x080f9433 in bdb_search (op=0x993f938, rs=0x8cd901c0) at search.c:960 > #6 0x080e13cf in overlay_op_walk (op=0x993f938, rs=0x8cd901c0, > which=op_search, oi=0x8295890, on=0x8295990) at backover.c:669 > #7 0x080e19b5 in over_op_func (op=0x993f938, rs=0x8cd901c0, > which=op_search) at backover.c:721 > #8 0x080e1af5 in over_op_search (op=0x993f938, rs=0x8cd901c0) at > backover.c:743 > #9 0x080df000 in glue_sub_search (op=0x993f938, rs=0x8cd901c0, b0=0x0, > on=0x82956a0) at backglue.c:342 > #10 0x080dfc04 in glue_op_search (op=0xfffffffc, rs=0x8cd901c0) at > backglue.c:465 > #11 0x080e1379 in overlay_op_walk (op=0x993f938, rs=0x8cd901c0, > which=op_search, oi=0x82a3098, on=0x82a3298) at backover.c:659 > #12 0x080e19b5 in over_op_func (op=0x993f938, rs=0x8cd901c0, > which=op_search) at backover.c:721 > #13 0x080e1af5 in over_op_search (op=0x993f938, rs=0x8cd901c0) at > backover.c:743 > #14 0x080771c4 in fe_op_search (op=0x993f938, rs=0x8cd901c0) at search.c:366 > #15 0x08077d53 in do_search (op=0x993f938, rs=0x8cd901c0) at search.c:217 > #16 0x08074d3c in connection_operation (ctx=0x8cd902b8, arg_v=0x993f938) > at connection.c:1097 > #17 0x08075d48 in connection_read_thread (ctx=0x8cd902b8, argv=0x53) at > connection.c:1223 > #18 0xb7fb3a20 in ldap_int_thread_pool_wrapper (xpool=0x81f8cf0) at > tpool.c:663 > #19 0xb7c53371 in start_thread () from /lib/tls/libpthread.so.0 > #20 0xb7beaffe in clone () from /lib/tls/libc.so.6 > > Thread 10 (process 32265): > #0 0xb7fe97a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 > #1 0xb7c55b26 in pthread_cond_wait@@GLIBC_2.3.2 () from > /lib/tls/libpthread.so.0 > #2 0xb7fb435b in ldap_pvt_thread_cond_wait (cond=0x81f8d0c, > mutex=0x81f8cf4) at thr_posix.c:277 > #3 0xb7fb39e4 in ldap_int_thread_pool_wrapper (xpool=0x81f8cf0) at > tpool.c:654 > #4 0xb7c53371 in start_thread () from /lib/tls/libpthread.so.0 > #5 0xb7beaffe in clone () from /lib/tls/libc.so.6 > > Thread 9 (process 32266): > #0 0xb7fe97a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 > #1 0xb7c55b26 in pthread_cond_wait@@GLIBC_2.3.2 () from > /lib/tls/libpthread.so.0 > #2 0xb7fb435b in ldap_pvt_thread_cond_wait (cond=0x81f8d0c, > mutex=0x81f8cf4) at thr_posix.c:277 > #3 0xb7fb39e4 in ldap_int_thread_pool_wrapper (xpool=0x81f8cf0) at > tpool.c:654 > #4 0xb7c53371 in start_thread () from /lib/tls/libpthread.so.0 > #5 0xb7beaffe in clone () from /lib/tls/libc.so.6 > > Thread 8 (process 32267): > #0 0xb7fe97a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 > #1 0xb7c55b26 in pthread_cond_wait@@GLIBC_2.3.2 () from > /lib/tls/libpthread.so.0 > ---Type<return> to continue, or q<return> to quit--- > #2 0xb7fb435b in ldap_pvt_thread_cond_wait (cond=0x81f8d0c, > mutex=0x81f8cf4) at thr_posix.c:277 > #3 0xb7fb39e4 in ldap_int_thread_pool_wrapper (xpool=0x81f8cf0) at > tpool.c:654 > #4 0xb7c53371 in start_thread () from /lib/tls/libpthread.so.0 > #5 0xb7beaffe in clone () from /lib/tls/libc.so.6 > > Thread 7 (process 32268): > #0 0xb7fe97a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 > #1 0xb7c55b26 in pthread_cond_wait@@GLIBC_2.3.2 () from > /lib/tls/libpthread.so.0 > #2 0xb7fb435b in ldap_pvt_thread_cond_wait (cond=0x81f8d0c, > mutex=0x81f8cf4) at thr_posix.c:277 > #3 0xb7fb39e4 in ldap_int_thread_pool_wrapper (xpool=0x81f8cf0) at > tpool.c:654 > #4 0xb7c53371 in start_thread () from /lib/tls/libpthread.so.0 > #5 0xb7beaffe in clone () from /lib/tls/libc.so.6 > > Thread 6 (process 32269): > #0 0xb7fe97a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 > #1 0xb7c55b26 in pthread_cond_wait@@GLIBC_2.3.2 () from > /lib/tls/libpthread.so.0 > #2 0xb7fb435b in ldap_pvt_thread_cond_wait (cond=0x81f8d0c, > mutex=0x81f8cf4) at thr_posix.c:277 > #3 0xb7fb39e4 in ldap_int_thread_pool_wrapper (xpool=0x81f8cf0) at > tpool.c:654 > #4 0xb7c53371 in start_thread () from /lib/tls/libpthread.so.0 > #5 0xb7beaffe in clone () from /lib/tls/libc.so.6 > > Thread 5 (process 32270): > #0 0xb7fe97a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 > #1 0xb7c55b26 in pthread_cond_wait@@GLIBC_2.3.2 () from > /lib/tls/libpthread.so.0 > #2 0xb7fb435b in ldap_pvt_thread_cond_wait (cond=0x81f8d0c, > mutex=0x81f8cf4) at thr_posix.c:277 > #3 0xb7fb39e4 in ldap_int_thread_pool_wrapper (xpool=0x81f8cf0) at > tpool.c:654 > #4 0xb7c53371 in start_thread () from /lib/tls/libpthread.so.0 > #5 0xb7beaffe in clone () from /lib/tls/libc.so.6 > > Thread 4 (process 32271): > #0 0xb7fe97a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 > #1 0xb7c55b26 in pthread_cond_wait@@GLIBC_2.3.2 () from > /lib/tls/libpthread.so.0 > #2 0xb7fb435b in ldap_pvt_thread_cond_wait (cond=0x81f8d0c, > mutex=0x81f8cf4) at thr_posix.c:277 > #3 0xb7fb39e4 in ldap_int_thread_pool_wrapper (xpool=0x81f8cf0) at > tpool.c:654 > #4 0xb7c53371 in start_thread () from /lib/tls/libpthread.so.0 > #5 0xb7beaffe in clone () from /lib/tls/libc.so.6 > > Thread 3 (process 32272): > #0 0xb7fe97a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 > #1 0xb7c55b26 in pthread_cond_wait@@GLIBC_2.3.2 () from > /lib/tls/libpthread.so.0 > #2 0xb7fb435b in ldap_pvt_thread_cond_wait (cond=0x81f8d0c, > mutex=0x81f8cf4) at thr_posix.c:277 > #3 0xb7fb39e4 in ldap_int_thread_pool_wrapper (xpool=0x81f8cf0) at > tpool.c:654 > #4 0xb7c53371 in start_thread () from /lib/tls/libpthread.so.0 > #5 0xb7beaffe in clone () from /lib/tls/libc.so.6 > > Thread 2 (process 32273): > #0 0xb7b8d481 in memmove () from /lib/tls/libc.so.6 > #1 0xb7f9ec01 in ber_write (ber=0x8a4c4a0c, buf=0x8a4c48b8 > "\004\001�\204\214A��\fJL\212\fJL\212�HL\212?��\001", len=0, nosos=0) > at io.c:116 > #2 0xb7f9c44b in ber_put_tag (ber=0x8a4c4a0c, tag=0, nosos=0) at > encode.c:100 > #3 0xb7f9c83f in ber_put_ostring (ber=0x8a4c4a0c, str=0x81f24f8 > "modifyTimestamp", len=15, tag=2142916662) at encode.c:354 > #4 0xb7f9c961 in ber_put_berval (ber=0x1, bv=0x7fba5036, > tag=4294967295) at encode.c:382 > #5 0xb7f9d5ad in ber_printf (ber=0x8a4c4a0c, fmt=0x1 "") at encode.c:804 > #6 0x08086e50 in slap_send_search_entry (op=0x84e726c8, rs=0x8a5861c0) > at result.c:1019 > #7 0x080f9433 in bdb_search (op=0x84e726c8, rs=0x8a5861c0) at search.c:960 > #8 0x080e13cf in overlay_op_walk (op=0x84e726c8, rs=0x8a5861c0, > which=op_search, oi=0x82970c0, on=0x82971c0) at backover.c:669 > #9 0x080e19b5 in over_op_func (op=0x84e726c8, rs=0x8a5861c0, > which=op_search) at backover.c:721 > #10 0x080e1af5 in over_op_search (op=0x84e726c8, rs=0x8a5861c0) at > backover.c:743 > #11 0x080df000 in glue_sub_search (op=0x84e726c8, rs=0x8a5861c0, b0=0x1, > on=0x8295c40) at backglue.c:342 > #12 0x080dfc04 in glue_op_search (op=0x7fba5036, rs=0x8a5861c0) at > backglue.c:465 > #13 0x080e1379 in overlay_op_walk (op=0x84e726c8, rs=0x8a5861c0, > which=op_search, oi=0x82a3098, on=0x82a3298) at backover.c:659 > #14 0x080e19b5 in over_op_func (op=0x84e726c8, rs=0x8a5861c0, > which=op_search) at backover.c:721 > #15 0x080e1af5 in over_op_search (op=0x84e726c8, rs=0x8a5861c0) at > backover.c:743 > #16 0x080771c4 in fe_op_search (op=0x84e726c8, rs=0x8a5861c0) at > search.c:366 > #17 0x08077d53 in do_search (op=0x84e726c8, rs=0x8a5861c0) at search.c:217 > #18 0x08074d3c in connection_operation (ctx=0x8a5862b8, > arg_v=0x84e726c8) at connection.c:1097 > #19 0x08075d48 in connection_read_thread (ctx=0x8a5862b8, argv=0x51) at > connection.c:1223 > ---Type<return> to continue, or q<return> to quit--- > #20 0xb7fb3a20 in ldap_int_thread_pool_wrapper (xpool=0x81f8cf0) at > tpool.c:663 > #21 0xb7c53371 in start_thread () from /lib/tls/libpthread.so.0 > #22 0xb7beaffe in clone () from /lib/tls/libc.so.6 > > Thread 1 (process 32264): > #0 0x080989a1 in access_allowed_mask (op=0x8c98dc54, e=0x83f827c, > desc=0x81f2008, val=0x0, access=ACL_SEARCH, state=0x0, maskp=0x0) at > acl.c:454 > #1 0x0809603b in test_filter (op=0x8c98dc54, e=0x83f827c, f=0x82ffb0ac) > at filterentry.c:821 > #2 0xb7a3d740 in syncprov_matchops (op=0x8c98edc8, opc=0x7ae2d620, > saveit=0) at syncprov.c:1257 > #3 0xb7a3e5cd in syncprov_op_response (op=0x8c98edc8, rs=0x8c98e890) at > syncprov.c:1801 > #4 0x08084e5d in slap_response_play (op=0x8c98edc8, rs=0x8c98e890) at > result.c:350 > #5 0x0808821c in send_ldap_response (op=0x8c98edc8, rs=0x8c98e890) at > result.c:424 > #6 0x080893b3 in slap_send_ldap_result (op=0x8c98edc8, rs=0x8c98e890) > at result.c:693 > #7 0x08109928 in bdb_add (op=0x8c98edc8, rs=0x8c98e890) at add.c:494 > #8 0x080e13cf in overlay_op_walk (op=0x8c98edc8, rs=0x8c98e890, > which=op_add, oi=0x829a000, on=0x829b2b0) at backover.c:669 > #9 0x080e19b5 in over_op_func (op=0x8c98edc8, rs=0x8c98e890, > which=op_add) at backover.c:721 > #10 0x080e1a95 in over_op_add (op=0x8c98edc8, rs=0x8c98e890) at > backover.c:767 > #11 0x080df61f in glue_op_func (op=0x8c98edc8, rs=0x8c98e890) at > backglue.c:238 > #12 0x080e1379 in overlay_op_walk (op=0x8c98edc8, rs=0x8c98e890, > which=op_add, oi=0x82a3098, on=0x82a3298) at backover.c:659 > #13 0x080e19b5 in over_op_func (op=0x8c98edc8, rs=0x8c98e890, > which=op_add) at backover.c:721 > #14 0x080e1a95 in over_op_add (op=0x8c98edc8, rs=0x8c98e890) at > backover.c:767 > #15 0x080d962f in syncrepl_entry (si=0x829b140, op=0x8c98edc8, > entry=0x83f827c, modlist=0x8c98ebf8, syncstate=1, syncUUID=0x8c98ec50, > syncCSN=0x0) at syncrepl.c:2187 > #16 0x080dca39 in do_syncrep2 (op=0x8c98edc8, si=0x829b140) at > syncrepl.c:892 > #17 0x080de907 in do_syncrepl (ctx=0x8c98f2b8, arg=0x829a760) at > syncrepl.c:1361 > #18 0x08075d59 in connection_read_thread (ctx=0x8c98f2b8, argv=0x4d) at > connection.c:1225 > #19 0xb7fb3a20 in ldap_int_thread_pool_wrapper (xpool=0x81f8cf0) at > tpool.c:663 > #20 0xb7c53371 in start_thread () from /lib/tls/libpthread.so.0 > #21 0xb7beaffe in clone () from /lib/tls/libc.so.6 > #0 0xb7b8d481 in memmove () from /lib/tls/libc.so.6 > (gdb) thr 1 > [Switching to thread 1 (process 32264)]#0 0x080989a1 in > access_allowed_mask (op=0x8c98dc54, e=0x83f827c, desc=0x81f2008, > val=0x0, access=ACL_SEARCH, state=0x0, maskp=0x0) at acl.c:454 > 454 if ( op->o_bd->bd_info->bi_access_allowed ) { > (gdb) fram 2 > #2 0xb7a3d740 in syncprov_matchops (op=0x8c98edc8, opc=0x7ae2d620, > saveit=0) at syncprov.c:1257 > 1257 rc = test_filter(&op2, e, ss->s_op->ors_filter ); > (gdb) print ss->s_op > $7 = (Operation *) 0x84e726c8 > -- -- 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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs