openldap-bugs

openldap-bugs@openldap.org

1 participants
21002 discussions

(ITS#6309) missing SEARCH information
by quanah＠zimbra.com 28 Sep '09

28 Sep '09

Full_Name: Quanah Gibson-Mount Version: 2.4.18 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.29.239) I see the following logged at level 256: Sep 28 17:35:23 ldap1 slapd[18015]: conn=409 fd=117 ACCEPT from IP=171.67.219.70:51122 (IP=0.0.0.0:389) Sep 28 17:35:23 ldap1 slapd[18015]: conn=409 op=0 BIND dn="" method=163 Sep 28 17:35:23 ldap1 slapd[18015]: conn=409 op=0 RESULT tag=97 err=14 text=SASL(0): successful result: Sep 28 17:35:23 ldap1 slapd[18015]: conn=409 op=1 BIND dn="" method=163 Sep 28 17:35:23 ldap1 slapd[18015]: conn=409 op=1 RESULT tag=97 err=14 text=SASL(0): successful result: Sep 28 17:35:23 ldap1 slapd[18015]: conn=409 op=2 BIND dn="" method=163 Sep 28 17:35:23 ldap1 slapd[18015]: conn=409 op=2 BIND authcid="service/vacation(a)stanford.edu" authzid="service/vacation(a)stanford.edu" Sep 28 17:35:23 ldap1 slapd[18015]: conn=409 op=2 BIND dn="cn=vacation,cn=service,cn=applications,dc=stanford,dc=edu" mech=GSSAPI sasl_ssf=56 ssf=56 Sep 28 17:35:23 ldap1 slapd[18015]: conn=409 op=2 RESULT tag=97 err=0 text= Sep 28 17:35:23 ldap1 slapd[18015]: conn=409 op=3 do_search: invalid dn (basedn) Sep 28 17:35:23 ldap1 slapd[18015]: conn=409 op=3 SEARCH RESULT tag=101 err=34 nentries=0 text=invalid DN Sep 28 17:35:23 ldap1 slapd[18015]: conn=409 fd=117 closed (connection lost) Since the actual search is not logged, there is no way to determine what the invalid DN being used is in this case. This seems faulty. I'd expect to see some additional logging like: Sep 28 10:17:15 ldap1 slapd[18015]: conn=409 op=3 SRCH base="cn=inavlid,dc=base,dc=search" scope=1 deref=3 filter="(uid=xxxxx)"

1 0

Re: (ITS#6252) GnuTLS subjectAltNames broken
by hyc＠symas.com 28 Sep '09

28 Sep '09

Howard Chu wrote: > hyc(a)symas.com wrote: >> The bug was reported against Ubuntu jaunty originally, and still exists in >> current GnuTLS git. So it appears to affect at least 2.4.2-present. The fix is >> trivial and is attached below. I will also submit this to the GnuTLS bug tracker. > > This is https://savannah.gnu.org/support/index.php?106975 > It looks like the fix for this was released in GnuTLS 2.9.4. Closing this ITS. (Current release is 2.9.6) -- -- 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#6217) proxycache not returning cached data
by hyc＠symas.com 28 Sep '09

28 Sep '09

w.van.keulen(a)few.vu.nl wrote: > masarati(a)aero.polimi.it wrote: >>> Here are slapd.conf and proxycache.conf as attachments. >> >> I just wanted to feed back before I leave for a few days. I don't see >> anything critical in your files. You explicitly give the rootdn write >> permissions, which is useless, but apart from this everything looks fine. >> >> I've tested a simple setup and it works as expected. I used HEAD and re24 >> code; the latter is nearly identical to 2.4.17. I also tested with TLS. >> >> At this point, I'm a bit clueless. There must be something we're >> overlooking. > Here is some more info, that I just discovered. > If my filter rule is > '(&(objectClass=sambaSamAccount)(uid=wvk))' > the data is cached the first time, but not returned > the second and later time. However when my filter rule is > (&(objectClass=posixAccount)(uid=wvk))' > it works as expected. Sounds like you may have already had the entry in the cache DB but with an incompatible objectclass before, and the attempt to update it with the new objectclass failed. This seems to be related to ITS#6242 which was recently fixed in HEAD. Can you please retest with the latest overlays/pcache.c? -- -- 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#6201) Double free in syncprov
by quanah＠zimbra.com 28 Sep '09

28 Sep '09

--On Thursday, July 09, 2009 4:54 PM +0000 quanah(a)zimbra.com wrote: > --On Thursday, July 09, 2009 10:18 AM +0000 > Alister.Winfield(a)sns.bskyb.com wrote: > >> I think I have it (bad configuration)... >> >> Okay so it might be a configuration 'error' but I guess its worth trying >> to= avoid the crash. > > Hi Alister, > > Can you provide an example of your misconfigured slapd for ease of > debugging? Obviously, this is non-critical but I agree it would be nice > to make sure this sort of configuration error is caught more gracefully. Ping? Without said info, this ITS will be closed. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6307) opened files
by hyc＠symas.com 28 Sep '09

28 Sep '09

M8R-njfnr31(a)mailinator.com wrote: > Full_Name: Miki Manó > Version: 2.4.18 > OS: debian linux > URL: > Submission from: (NULL) (91.120.147.134) > > > hello > > i'm running slapd server with 100 clients over ssl. i see the server don't close > the file descriptors always and the limit of open files is exceeded. how could i > help your work to find this bug? > Sounds like you need to configure an idletimeout in slapd. Software usage questions belong on the openldap-software mailing list. 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#6298) ldapsearch hangs after ldapadd
by hyc＠symas.com 28 Sep '09

28 Sep '09

Tihomir Culjaga wrote: > Aster recompiling OpenLDAP with changes to servers/slapd/back-bdb/idl.h > > > #define BDB_IDL_LOGN 16 /* DB_SIZE is 2^16, UM_SIZE is 2^17 */ > > #define BDB_IDL_DB_SIZE (1<<(BDB_IDL_LOGN+1)) /* moved from 64k > to 128K */ > #define BDB_IDL_UM_SIZE (1<<(BDB_IDL_LOGN+2)) /* moved from 128k > to 256k */ The point in defining these macros based on BDB_IDL_LOGN is that you can simply change that single value, rather then editing everything else that depends on it. E.g., change BDB_IDL_LOGN to 17 and leave the other two definitions untouched. > I'm unable to reproduce the issue.... it looks like problem solved... > What can we expect as the DB grows? Does it mean i will have to increase > the values again? It all depends on the sequence in which entries are added to the database. If the majority of entries belonging to a particular index slot are created at around the same time, then they will fit easily into the index and there will be no problem. If there is a large gap in entries/time, and the gap exceeds the BDB_IDL_DB_SIZE, then the problem will occur again. > What is the limit and drawback? The limit is simply the amount of RAM you have available on your machine. -- -- 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#6242) PCache cache corruption
by karavelov＠spnet.net 28 Sep '09

28 Sep '09

Howard Chu wrote: > > This is now fixed in HEAD overlays/pcache.c. The bug occurred because > the cache was seeing a child entry first, and so the > dc=justillusion.net object got created as a glue entry. Later when the > actual dc=justillusion.net entry was received, the modify to store its > true values in the cache DB failed because it needed the manageDSAit > control. > Thank you, Howard, I have installed in the morning slapd from CVS, enabled the caches on the servers and they have running the whole day without any cache corruption. Now, from time to time, there appears segmentation fault. I will post another ticket because it seems unrelated to the issue discussed here. Best regards Luben Karavelov

1 0

Re: (ITS#6308) replication locks with delta-syncrepl
by quanah＠zimbra.com 28 Sep '09

28 Sep '09

--On Monday, September 28, 2009 7:00 PM +0000 openldap-its(a)OpenLDAP.org wrote: db_stat -C A output is ftp.openldap.org/incoming/its6308-dbstat.txt --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6308) replication locks with delta-syncrepl
by quanah＠zimbra.com 28 Sep '09

28 Sep '09

Full_Name: Quanah Gibson-Mount Version: 2.4.18 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.29.239) OpenLDAP 2.4.18 with BDB 4.7.25, fully patched. Delta-sync replication works fine as long as the system is not loaded. Once it is loaded, replication will fail after a while, waiting on a transaction. >From the log with sync logging: Sep 28 11:08:14 ldap1 slapd[3241]: do_syncrep2: cookie=csn=20090928180814Z#000000#00#000000,rid=000 Sep 28 11:08:14 ldap1 slapd[3241]: syncrepl_message_to_op: rid=000 be_modify suRegID=109cd894e76211d1bcdf2436000baa77,cn=People,dc=Stanford,dc=edu (0) Sep 28 11:09:18 ldap1 slapd[3241]: do_syncrep2: cookie=csn=20090928180918Z#000000#00#000000,rid=000 Backtrace shows: Thread 10 (Thread 0x40891950 (LWP 3243)): #0 0x00007f05b99e5b78 in epoll_wait () from /lib/libc.so.6 #1 0x00000000004392e6 in slapd_daemon_task (ptr=0x0) at /tmp/buildd/openldap-2.4.18/servers/slapd/daemon.c:2460 #2 0x00007f05b9c6ffc7 in start_thread () from /lib/libpthread.so.0 #3 0x00007f05b99e55ad in clone () from /lib/libc.so.6 #4 0x0000000000000000 in ?? () Thread 9 (Thread 0x4278c950 (LWP 3244)): #0 0x00007f05b9c73d29 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #1 0x00007f05bb96650b in ldap_pvt_thread_cond_wait (cond=0x2210980, mutex=0x2210958) at /tmp/buildd/openldap-2.4.18/libraries/libldap_r/thr_posix.c:277 #2 0x00007f05bb964f6f in ldap_int_thread_pool_wrapper (xpool=0x2210950) at /tmp/buildd/openldap-2.4.18/libraries/libldap_r/tpool.c:672 #3 0x00007f05b9c6ffc7 in start_thread () from /lib/libpthread.so.0 #4 0x00007f05b99e55ad in clone () from /lib/libc.so.6 #5 0x0000000000000000 in ?? () Thread 8 (Thread 0x42f8d950 (LWP 3245)): #0 0x00007f05b9c73d29 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #1 0x00007f05bb96650b in ldap_pvt_thread_cond_wait (cond=0x2210980, mutex=0x2210958) at /tmp/buildd/openldap-2.4.18/libraries/libldap_r/thr_posix.c:277 #2 0x00007f05bb964f6f in ldap_int_thread_pool_wrapper (xpool=0x2210950) at /tmp/buildd/openldap-2.4.18/libraries/libldap_r/tpool.c:672 #3 0x00007f05b9c6ffc7 in start_thread () from /lib/libpthread.so.0 #4 0x00007f05b99e55ad in clone () from /lib/libc.so.6 #5 0x0000000000000000 in ?? () Thread 7 (Thread 0x4378e950 (LWP 3246)): #0 0x00007f05b9c73d29 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #1 0x00007f05bb96650b in ldap_pvt_thread_cond_wait (cond=0x2210980, mutex=0x2210958) at /tmp/buildd/openldap-2.4.18/libraries/libldap_r/thr_posix.c:277 #2 0x00007f05bb964f6f in ldap_int_thread_pool_wrapper (xpool=0x2210950) at /tmp/buildd/openldap-2.4.18/libraries/libldap_r/tpool.c:672 #3 0x00007f05b9c6ffc7 in start_thread () from /lib/libpthread.so.0 #4 0x00007f05b99e55ad in clone () from /lib/libc.so.6 #5 0x0000000000000000 in ?? () Thread 6 (Thread 0x41466950 (LWP 3247)): #0 0x00007f05b9c73d29 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #1 0x00007f05bb38154a in __db_pthread_mutex_lock (env=0x23df7d0, mutex=1575681) at ../dist/../mutex/mut_pthread.c:224 #2 0x00007f05bb43adc2 in __lock_get_internal (lt=0x23df910, sh_locker=0x7f042992e118, flags=0, obj=0x7f03e98ebfa0, lock_mode=DB_LOCK_READ, timeout=0, lock=0x41263868) at ../dist/../lock/lock.c:946 #3 0x00007f05bb437f9d in __lock_vec (env=0x23df7d0, sh_locker=0x7f042992e118, flags=0, list=0x41263850, nlist=2, elistp=0x41263848) at ../dist/../lock/lock.c:136 #4 0x00007f05bb492ff6 in __db_lget (dbc=0x7f03e98ebec0, action=2, pgno=2766, mode=DB_LOCK_READ, lkflags=0, lockp=0x41263ac0) at ../dist/../db/db_meta.c:1062 #5 0x00007f05bb39fe1c in __bam_search (dbc=0x7f03e98ebec0, root_pgno=1, key=0x412e4140, flags=1409, slevel=1, recnop=0x0, exactp=0x41263e24) at ../dist/../btree/bt_search.c:499 #6 0x00007f05bb38ac89 in __bamc_search (dbc=0x7f03e98ebec0, root_pgno=0, key=0x412e4140, flags=26, exactp=0x41263e24) at ../dist/../btree/bt_cursor.c:2501 #7 0x00007f05bb386233 in __bamc_get (dbc=0x7f03e98ebec0, key=0x412e4140, data=0x412e4050, flags=26, pgnop=0x41263ed4) at ../dist/../btree/bt_cursor.c:970 #8 0x00007f05bb47d4bb in __dbc_get (dbc_arg=0x76697e0, key=0x412e4140, data=0x412e4050, flags=26) at ../dist/../db/db_cam.c:700 #9 0x00007f05bb48dfeb in __dbc_get_pp (dbc=0x76697e0, key=0x412e4140, data=0x412e4050, flags=8218) at ../dist/../db/db_iface.c:2095 #10 0x00007f05b6e33d6d in hdb_idl_fetch_key (be=0x41464990, db=0x7271e30, txn=0x2bb4270, key=0x412e4140, ids=0x7f0404d76010, saved_cursor=0x0, get_flag=0) at idl.c:605 #11 0x00007f05b6e29e91 in hdb_key_read (be=0x41464990, db=0x7271e30, txn=0x2bb4270, k=0x2bb53c8, ids=0x7f0404d76010, saved_cursor=0x0, get_flag=0) at key.c:50 #12 0x00007f05b6e2c6c1 in equality_candidates (op=0xc9bac80, rtxn=0x2bb4270, ava=0x2bb5190, ids=0x7f0404f76010, tmp=0x7f0404d76010) at filterindex.c:788 #13 0x00007f05b6e2adb3 in hdb_filter_candidates (op=0xc9bac80, rtxn=0x2bb4270, f=0x2bb51d8, ids=0x7f0404f76010, tmp=0x7f0404d76010, stack=0x7f0405076010) at filterindex.c:154 #14 0x00007f05b6e2ba13 in list_candidates (op=0xc9bac80, rtxn=0x2bb4270, flist=0x412e4610, ftype=161, ids=0x7f0404e76010, tmp=0x7f0404d76010, save=0x7f0404f76010) at filterindex.c:581 #15 0x00007f05b6e2b33f in hdb_filter_candidates (op=0xc9bac80, rtxn=0x2bb4270, f=0x412e45f0, ids=0x7f0404e76010, tmp=0x7f0404d76010, stack=0x7f0404f76010) at filterindex.c:204 #16 0x00007f05b6e2ba13 in list_candidates (op=0xc9bac80, rtxn=0x2bb4270, flist=0x412e45d0, ftype=160, ids=0x41364820, tmp=0x7f0404d76010, save=0x7f0404e76010) at filterindex.c:581 #17 0x00007f05b6e2b287 in hdb_filter_candidates (op=0xc9bac80, rtxn=0x2bb4270, f=0x412e4630, ids=0x41364820, tmp=0x7f0404d76010, stack=0x7f0404e76010) at filterindex.c:198 #18 0x00007f05b6e26e19 in search_candidates (op=0xc9bac80, rs=0x41465ca0, e=0x412e47d0, txn=0x2bb4270, ids=0x41364820, scopes=0x412e4820) at search.c:1206 #19 0x00007f05b6e25090 in hdb_search (op=0xc9bac80, rs=0x41465ca0) at search.c:586 #20 0x00000000004c73c6 in overlay_op_walk (op=0xc9bac80, rs=0x41465ca0, which=op_search, oi=0x22a0c90, on=0x0) at /tmp/buildd/openldap-2.4.18/servers/slapd/backover.c:669 #21 0x00000000004c75ed in over_op_func (op=0xc9bac80, rs=0x41465ca0, which=op_search) at /tmp/buildd/openldap-2.4.18/servers/slapd/backover.c:721 #22 0x00000000004c76bb in over_op_search (op=0xc9bac80, rs=0x41465ca0) at /tmp/buildd/openldap-2.4.18/servers/slapd/backover.c:748 #23 0x0000000000440b4c in fe_op_search (op=0xc9bac80, rs=0x41465ca0) at /tmp/buildd/openldap-2.4.18/servers/slapd/search.c:366 #24 0x00000000004404b7 in do_search (op=0xc9bac80, rs=0x41465ca0) at /tmp/buildd/openldap-2.4.18/servers/slapd/search.c:217 #25 0x000000000043cede in connection_operation (ctx=0x41465df0, arg_v=0xc9bac80) at /tmp/buildd/openldap-2.4.18/servers/slapd/connection.c:1123 #26 0x000000000043d46a in connection_read_thread (ctx=0x41465df0, argv=0x1cb) at /tmp/buildd/openldap-2.4.18/servers/slapd/connection.c:1259 #27 0x00007f05bb96500d in ldap_int_thread_pool_wrapper (xpool=0x2210950) at /tmp/buildd/openldap-2.4.18/libraries/libldap_r/tpool.c:685 #28 0x00007f05b9c6ffc7 in start_thread () from /lib/libpthread.so.0 #29 0x00007f05b99e55ad in clone () from /lib/libc.so.6 #30 0x0000000000000000 in ?? () Thread 5 (Thread 0x41c67950 (LWP 3248)): #0 0x00007f05b9c73d29 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #1 0x00007f05bb38154a in __db_pthread_mutex_lock (env=0x23df7d0, mutex=1575506) at ../dist/../mutex/mut_pthread.c:224 #2 0x00007f05bb43adc2 in __lock_get_internal (lt=0x23df910, sh_locker=0x7f042992dad8, flags=0, obj=0x41ae5510, lock_mode=DB_LOCK_READ, timeout=0, lock=0x41ae5790) at ../dist/../lock/lock.c:946 #3 0x00007f05bb438efc in __lock_get_api (env=0x23df7d0, locker=2147483856, flags=0, obj=0x41ae5510, lock_mode=DB_LOCK_READ, lock=0x41ae5790) at ../dist/../lock/lock.c:423 #4 0x00007f05bb438d8c in __lock_get_pp (dbenv=0x23e5360, locker=2147483856, flags=0, obj=0x41ae5510, lock_mode=DB_LOCK_READ, lock=0x41ae5790) at ../dist/../lock/lock.c:395 #5 0x00007f05b6e3731b in bdb_cache_entry_db_lock (bdb=0x229dcc0, txn=0x2d3df60, ei=0x7f03fae33d20, rw=0, tryOnly=0, lock=0x41ae5790) at cache.c:227 #6 0x00007f05b6e389bc in hdb_cache_find_id (op=0x7f03c12c1bd0, tid=0x2d3df60, id=294299, eip=0x41ae57c0, flag=0, lock=0x41ae5790) at cache.c:979 #7 0x00007f05b6e256a8 in hdb_search (op=0x7f03c12c1bd0, rs=0x41c66ca0) at search.c:707 #8 0x00000000004c73c6 in overlay_op_walk (op=0x7f03c12c1bd0, rs=0x41c66ca0, which=op_search, oi=0x22a0c90, on=0x0) at /tmp/buildd/openldap-2.4.18/servers/slapd/backover.c:669 #9 0x00000000004c75ed in over_op_func (op=0x7f03c12c1bd0, rs=0x41c66ca0, which=op_search) at /tmp/buildd/openldap-2.4.18/servers/slapd/backover.c:721 #10 0x00000000004c76bb in over_op_search (op=0x7f03c12c1bd0, rs=0x41c66ca0) at /tmp/buildd/openldap-2.4.18/servers/slapd/backover.c:748 #11 0x0000000000440b4c in fe_op_search (op=0x7f03c12c1bd0, rs=0x41c66ca0) at /tmp/buildd/openldap-2.4.18/servers/slapd/search.c:366 #12 0x00000000004404b7 in do_search (op=0x7f03c12c1bd0, rs=0x41c66ca0) at /tmp/buildd/openldap-2.4.18/servers/slapd/search.c:217 #13 0x000000000043cede in connection_operation (ctx=0x41c66df0, arg_v=0x7f03c12c1bd0) at /tmp/buildd/openldap-2.4.18/servers/slapd/connection.c:1123 #14 0x000000000043d46a in connection_read_thread (ctx=0x41c66df0, argv=0x13d) at /tmp/buildd/openldap-2.4.18/servers/slapd/connection.c:1259 #15 0x00007f05bb96500d in ldap_int_thread_pool_wrapper (xpool=0x2210950) at /tmp/buildd/openldap-2.4.18/libraries/libldap_r/tpool.c:685 #16 0x00007f05b9c6ffc7 in start_thread () from /lib/libpthread.so.0 #17 0x00007f05b99e55ad in clone () from /lib/libc.so.6 #18 0x0000000000000000 in ?? () Thread 4 (Thread 0x43f8f950 (LWP 3249)): #0 0x00007f05b9c73d29 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #1 0x00007f05bb96650b in ldap_pvt_thread_cond_wait (cond=0x2210980, mutex=0x2210958) at /tmp/buildd/openldap-2.4.18/libraries/libldap_r/thr_posix.c:277 #2 0x00007f05bb964f6f in ldap_int_thread_pool_wrapper (xpool=0x2210950) at /tmp/buildd/openldap-2.4.18/libraries/libldap_r/tpool.c:672 #3 0x00007f05b9c6ffc7 in start_thread () from /lib/libpthread.so.0 #4 0x00007f05b99e55ad in clone () from /lib/libc.so.6 #5 0x0000000000000000 in ?? () Thread 3 (Thread 0x44790950 (LWP 3250)): #0 0x00007f05b9c73d29 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #1 0x00007f05bb38154a in __db_pthread_mutex_lock (env=0x23df7d0, mutex=1574526) at ../dist/../mutex/mut_pthread.c:224 #2 0x00007f05bb43adc2 in __lock_get_internal (lt=0x23df910, sh_locker=0x7f042991e330, flags=0, obj=0x4478e960, lock_mode=DB_LOCK_WRITE, timeout=0, lock=0x4478e948) at ../dist/../lock/lock.c:946 #3 0x00007f05bb437f9d in __lock_vec (env=0x23df7d0, sh_locker=0x7f042991e330, flags=0, list=0x4478e900, nlist=2, elistp=0x0) at ../dist/../lock/lock.c:136 #4 0x00007f05bb437d7f in __lock_vec_api (env=0x23df7d0, lid=2147484554, flags=0, list=0x4478e900, nlist=2, elistp=0x0) at ../dist/../lock/lock.c:84 #5 0x00007f05bb437ccd in __lock_vec_pp (dbenv=0x23e5360, lid=2147484554, flags=0, list=0x4478e900, nlist=2, elistp=0x0) at ../dist/../lock/lock.c:66 #6 0x00007f05b6e37192 in hdb_cache_entry_db_relock (bdb=0x229dcc0, txn=0x969d990, ei=0x7f03fae33d20, rw=1, tryOnly=0, lock=0x4478eae0) at cache.c:192 #7 0x00007f05b6e392ce in hdb_cache_modify (bdb=0x229dcc0, e=0x7f0426b06978, newAttrs=0x7f04169f0d98, txn=0x969d990, lock=0x4478eae0) at cache.c:1210 #8 0x00007f05b6e2027b in hdb_modify (op=0x4478f6a0, rs=0x4478f230) at modify.c:663 #9 0x00000000004c73c6 in overlay_op_walk (op=0x4478f6a0, rs=0x4478f230, which=op_modify, oi=0x22a0c90, on=0x0) at /tmp/buildd/openldap-2.4.18/servers/slapd/backover.c:669 #10 0x00000000004c75ed in over_op_func (op=0x4478f6a0, rs=0x4478f230, which=op_modify) at /tmp/buildd/openldap-2.4.18/servers/slapd/backover.c:721 #11 0x00000000004c7703 in over_op_modify (op=0x4478f6a0, rs=0x4478f230) at /tmp/buildd/openldap-2.4.18/servers/slapd/backover.c:760 #12 0x00000000004b7a58 in syncrepl_message_to_op (si=0x22a1550, op=0x4478f6a0, msg=0x9cf5c90) at /tmp/buildd/openldap-2.4.18/servers/slapd/syncrepl.c:1734 #13 0x00000000004b48ff in do_syncrep2 (op=0x4478f6a0, si=0x22a1550) at /tmp/buildd/openldap-2.4.18/servers/slapd/syncrepl.c:873 #14 0x00000000004b6480 in do_syncrepl (ctx=0x4478fdf0, arg=0x229f730) at /tmp/buildd/openldap-2.4.18/servers/slapd/syncrepl.c:1358 #15 0x000000000043d486 in connection_read_thread (ctx=0x4478fdf0, argv=0xd) at /tmp/buildd/openldap-2.4.18/servers/slapd/connection.c:1261 #16 0x00007f05bb96500d in ldap_int_thread_pool_wrapper (xpool=0x2210950) at /tmp/buildd/openldap-2.4.18/libraries/libldap_r/tpool.c:685 #17 0x00007f05b9c6ffc7 in start_thread () from /lib/libpthread.so.0 #18 0x00007f05b99e55ad in clone () from /lib/libc.so.6 #19 0x0000000000000000 in ?? () Thread 2 (Thread 0x44f91950 (LWP 3251)): #0 0x00007f05b9c73d29 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #1 0x00007f05bb96650b in ldap_pvt_thread_cond_wait (cond=0x2210980, mutex=0x2210958) at /tmp/buildd/openldap-2.4.18/libraries/libldap_r/thr_posix.c:277 #2 0x00007f05bb964f6f in ldap_int_thread_pool_wrapper (xpool=0x2210950) at /tmp/buildd/openldap-2.4.18/libraries/libldap_r/tpool.c:672 #3 0x00007f05b9c6ffc7 in start_thread () from /lib/libpthread.so.0 #4 0x00007f05b99e55ad in clone () from /lib/libc.so.6 #5 0x0000000000000000 in ?? () Thread 1 (Thread 0x7f05bbdbc6e0 (LWP 3241)): #0 0x00007f05b9c70715 in pthread_join () from /lib/libpthread.so.0 #1 0x00007f05bb966463 in ldap_pvt_thread_join (thread=1082726736, thread_return=0x0) at /tmp/buildd/openldap-2.4.18/libraries/libldap_r/thr_posix.c:197 #2 0x000000000043a035 in slapd_daemon () at /tmp/buildd/openldap-2.4.18/servers/slapd/daemon.c:2835 #3 0x000000000041b0ed in main (argc=3, argv=0x7fffc3dcba38) at /tmp/buildd/openldap-2.4.18/servers/slapd/main.c:950 #0 0x00007f05b9c70715 in pthread_join () from /lib/libpthread.so.0 Thread 3 appears to be the replication thread, which is hung.

1 0

(ITS#6200) slapd crashes under load w/ syncrepl
by frank.offermanns＠caseris.de 28 Sep '09

28 Sep '09

Hello, i have the same problem with 2 Ubuntu 9.04 Systems with the current build from HEAD. I created 20000 entries at server1. Then i created another 20000 entries at server1 while reading the old and new entries from server1 and server2. Here is the backtrace: slapd: pthread_mutex_lock.c:289: __pthread_mutex_lock: Assertion `(-(e)) != 3 || !robust' failed. Program received signal SIGABRT, Aborted. [Switching to Thread 0x923f9b90 (LWP 17860)] 0xb7fe0430 in __kernel_vsyscall () (gdb) bt #0 0xb7fe0430 in __kernel_vsyscall () #1 0xb7b756d0 in raise () from /lib/tls/i686/cmov/libc.so.6 #2 0xb7b77098 in abort () from /lib/tls/i686/cmov/libc.so.6 #3 0xb7b6e5ce in __assert_fail () from /lib/tls/i686/cmov/libc.so.6 #4 0xb7e5df29 in pthread_mutex_lock () from /lib/tls/i686/cmov/libpthread.so.0 #5 0x0813fccb in ldap_pvt_thread_mutex_lock (mutex=0x8bc64dc) at thr_posix.c:296 #6 0xb7998e8e in syncprov_op_mod (op=0x8bc3690, rs=0x923f911c) at syncprov.c:1965 #7 0x08105bfd in overlay_op_walk (op=0x8bc3690, rs=0x923f911c, which=op_modify, oi=0x87e9d18, on=0x87eeef0) at backover.c:659 #8 0x08105e9a in over_op_func (op=0x8bc3690, rs=0x923f911c, which=op_modify) at backover.c:721 #9 0x08105fc7 in over_op_modify (op=0x8bc3690, rs=0x923f911c) at backover.c:760 #10 0x080a117e in fe_op_modify (op=0x8bc3690, rs=0x923f911c) at modify.c:301 #11 0x080a0a6d in do_modify (op=0x8bc3690, rs=0x923f911c) at modify.c:175 #12 0x08082a43 in connection_operation (ctx=0x923f9210, arg_v=0x8bc3690) at connection.c:1123 #13 0x08082f8b in connection_read_thread (ctx=0x923f9210, argv=0x12) at connection.c:1259 #14 0x0813eb0e in ldap_int_thread_pool_wrapper (xpool=0x87af8e8) at tpool.c:685 #15 0xb7e5c4ff in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #16 0xb7c2e49e in clone () from /lib/tls/i686/cmov/libc.so.6 Please let me know if i can provide additional information for you. (But please tell me how to do so, my gdb knowledge is fairly poor) Regards, Frank Offermanns

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