- openldap-bugs - openldap.org

(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 04 Apr '09

04 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

Re: (ITS#6045) Use copy of db in syncprov_matchops
by rein＠OpenLDAP.org 04 Apr '09

04 Apr '09

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. > 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. 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

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: > 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. 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. -- -- 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 rein＠OpenLDAP.org 04 Apr '09

04 Apr '09

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. 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. Rein

1 0

Re: (ITS#6045) Use copy of db in syncprov_matchops
by hyc＠symas.com 03 Apr '09

03 Apr '09

rein(a)OpenLDAP.org wrote: > Full_Name: Rein Tollevik > Version: CVS HEAD/RE_24 > OS: Irrelevant > URL: > Submission from: (NULL) (81.93.160.250) > > > 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. -- -- 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#6045) Use copy of db in syncprov_matchops
by rein＠OpenLDAP.org 03 Apr '09

03 Apr '09

Full_Name: Rein Tollevik Version: CVS HEAD/RE_24 OS: Irrelevant URL: Submission from: (NULL) (81.93.160.250) 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. Rein Tollevik Basefarm AS Program terminated with signal 11, Segmentation fault. #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) where #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 (gdb) print op->o_bd->bd_info $1 = (BackendInfo *) 0x0 (gdb) print op->o_bd $2 = (BackendDB *) 0x8a4c4814 (gdb) frame 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 op2.o_bd $3 = (BackendDB *) 0x8a4c4814 (gdb) print *op2.o_bd $4 = {bd_info = 0x0, bd_self = 0x0, be_ctrls = "\000\000\000\000\214\221\030\b�\001�\204\210HL\212\201�\f\b ", '\0' <repeats 11 times>, be_flags = 0, be_restrictops = 0, be_requires = 0, be_ssf_set = {sss_ssf = 0, sss_transport = 0, sss_tls = 0, sss_sasl = 1, sss_update_ssf = 3086609409, sss_update_transport = 2142916662, sss_update_tls = 2320255160, sss_update_sasl = 1, sss_simple_bind = 0}, be_suffix = 0x0, be_nsuffix = 0x1, be_schemadn = {bv_len = 32, bv_val = 0xb7fa418c "\204�"}, be_schemandn = {bv_len = 0, bv_val = 0x8a4c4a0c "\002"}, be_rootdn = {bv_len = 2320255176, bv_val = 0xb7f9c44b "\203�,[^_]�U\211�\203�8\211]�\211u�\211}��w���\201�%}"}, be_rootndn = {bv_len = 2320255500, bv_val = 0x8a4c48b8 "\004\001�\204\214A��\fJL\212\fJL\212�HL\212?���\001"}, be_rootpw = {bv_len = 1, bv_val = 0x0}, be_max_deref_depth = 2229404096, be_def_limit = {lms_t_soft = 1, lms_t_hard = 0, lms_s_soft = -1208355505, lms_s_hard = 1, lms_s_unchecked = 24, lms_s_pr = -2065563388, lms_s_pr_hide = -1208335988, lms_s_pr_total = -1974711796}, be_limits = 0x8a4c4a0c, be_acl = 0x8a4c48f8, be_dfltaccess = -1208367041, be_update_ndn = {bv_len = 1, bv_val = 0x18 ""}, be_update_refs = 0x84e201c0, be_pending_csn_list = 0x818918c, be_pcl_mutex = {__m_reserved = 0, __m_count = 48, __m_owner = 0x7fba5030, __m_kind = -1208335988, __m_lock = {__status = -1, __spinlock = -1974711796}}, be_syncinfo = 0x8a4c4918, be_pb = 0xb7f9c961, be_cf_ocs = 0x8a4c4a0c, be_private = 0x81f24f8, be_next = {stqe_next = 0xf}}

1 0

Re: (ITS#6021) slapo-pcache/back-ldap slapd crashes
by toby＠inf.ed.ac.uk 03 Apr '09

03 Apr '09

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: Mar 30 20:50:16 albany slapd[14239]: Lock CR index = 0x83a5140 Mar 30 20:50:16 albany slapd[14239]: TEMPLATE 0x83a5140 QUERIES-- 0 Mar 30 20:50:16 albany slapd[14239]: Unlock CR index = 0x83a5140 Mar 30 20:50:16 albany slapd[14239]: DELETING ENTRY TEMPLATE=e7ccb20c-d263-4d6c-ba23-62afe55f0158 Mar 30 20:50:16 albany slapd[14239]: STALE QUERY REMOVED, SIZE=1 Mar 30 20:50:16 albany slapd[14239]: STORED QUERIES = 30 Mar 30 20:50:16 albany slapd[14239]: STALE QUERY REMOVED, CACHE =22 entries Mar 30 20:50:16 albany slapd[14239]: Lock CR index = 0x83a4e90 Mar 30 20:50:16 albany slapd[14239]: TEMPLATE 0x83a4e90 QUERIES-- 15 Mar 30 20:50:16 albany slapd[14239]: Unlock CR index = 0x83a4e90 Mar 30 20:50:16 albany slapd[14239]: STALE QUERY REMOVED, SIZE=0 Mar 30 20:50:16 albany slapd[14239]: STORED QUERIES = 29 Mar 30 20:50:16 albany slapd[14239]: STALE QUERY REMOVED, CACHE =22 entries Mar 30 20:50:16 albany slapd[14239]: Lock CR index = 0x83a4e90 Mar 30 20:50:16 albany slapd[14239]: TEMPLATE 0x83a4e90 QUERIES-- 14 Mar 30 20:50:16 albany slapd[14239]: Unlock CR index = 0x83a4e90 Mar 30 20:50:16 albany slapd[14239]: STALE QUERY REMOVED, SIZE=0 Mar 30 20:50:16 albany slapd[14239]: STORED QUERIES = 28 Mar 30 20:50:16 albany slapd[14239]: STALE QUERY REMOVED, CACHE =22 entries Mar 30 20:50:16 albany slapd[14239]: Lock CR index = 0x83a4e90 Mar 30 20:50:16 albany slapd[14239]: TEMPLATE 0x83a4e90 QUERIES-- 13 Mar 30 20:50:16 albany slapd[14239]: Unlock CR index = 0x83a4e90 Mar 30 20:50:16 albany slapd[14239]: STALE QUERY REMOVED, SIZE=0 Mar 30 20:50:16 albany slapd[14239]: STORED QUERIES = 27 Mar 30 20:50:16 albany slapd[14239]: STALE QUERY REMOVED, CACHE =22 entries Mar 30 20:50:16 albany slapd[14239]: Lock CR index = 0x83a4e90 Mar 30 20:50:16 albany slapd[14239]: TEMPLATE 0x83a4e90 QUERIES-- 12 Mar 30 20:50:16 albany slapd[14239]: Unlock CR index = 0x83a4e90 Mar 30 20:50:16 albany slapd[14239]: STALE QUERY REMOVED, SIZE=0 Mar 30 20:50:16 albany slapd[14239]: STORED QUERIES = 26 Mar 30 20:50:16 albany slapd[14239]: STALE QUERY REMOVED, CACHE =22 entries Mar 30 20:50:16 albany slapd[14239]: Lock CR index = 0x83a4e90 Mar 30 20:50:16 albany slapd[14239]: TEMPLATE 0x83a4e90 QUERIES-- 11 Mar 30 20:50:16 albany slapd[14239]: Unlock CR index = 0x83a4e90 Mar 30 20:50:16 albany slapd[14239]: STALE QUERY REMOVED, SIZE=0 Mar 30 20:50:16 albany slapd[14239]: STORED QUERIES = 25 Mar 30 20:50:16 albany slapd[14239]: STALE QUERY REMOVED, CACHE =22 entries Mar 30 20:50:16 albany slapd[14239]: Lock CR index = 0x83a4e90 Mar 30 20:50:16 albany slapd[14239]: TEMPLATE 0x83a4e90 QUERIES-- 10 Mar 30 20:50:16 albany slapd[14239]: Unlock CR index = 0x83a4e90 Mar 30 20:50:16 albany slapd[14239]: STALE QUERY REMOVED, SIZE=0 Mar 30 20:50:16 albany slapd[14239]: STORED QUERIES = 24 Mar 30 20:50:16 albany slapd[14239]: STALE QUERY REMOVED, CACHE =22 entries Mar 30 20:50:16 albany slapd[14239]: Lock CR index = 0x83a4e90 Mar 30 20:50:16 albany slapd[14239]: TEMPLATE 0x83a4e90 QUERIES-- 9 Mar 30 20:50:16 albany slapd[14239]: Unlock CR index = 0x83a4e90 Mar 30 20:50:16 albany slapd[14239]: STALE QUERY REMOVED, SIZE=0 Mar 30 20:50:16 albany slapd[14239]: STORED QUERIES = 23 Mar 30 20:50:16 albany slapd[14239]: STALE QUERY REMOVED, CACHE =22 entries Mar 30 20:50:16 albany slapd[14239]: Lock CR index = 0x83a4e90 Mar 30 20:50:16 albany slapd[14239]: TEMPLATE 0x83a4e90 QUERIES-- 8 Mar 30 20:50:16 albany slapd[14239]: Unlock CR index = 0x83a4e90 Mar 30 20:50:16 albany slapd[14239]: STALE QUERY REMOVED, SIZE=0 Mar 30 20:50:16 albany slapd[14239]: STORED QUERIES = 22 Mar 30 20:50:16 albany slapd[14239]: STALE QUERY REMOVED, CACHE =22 entries Mar 30 20:50:16 albany slapd[14239]: Lock CR index = 0x83a4e90 Mar 30 20:50:16 albany slapd[14239]: TEMPLATE 0x83a4e90 QUERIES-- 7 Mar 30 20:50:16 albany slapd[14239]: Unlock CR index = 0x83a4e90 Mar 30 20:50:16 albany slapd[14239]: STALE QUERY REMOVED, SIZE=0 Mar 30 20:50:16 albany slapd[14239]: STORED QUERIES = 21 Mar 30 20:50:16 albany slapd[14239]: STALE QUERY REMOVED, CACHE =22 entries Mar 30 20:50:16 albany slapd[14239]: Lock CR index = 0x83a4e90 Mar 30 20:50:16 albany slapd[14239]: TEMPLATE 0x83a4e90 QUERIES-- 6 Mar 30 20:50:16 albany slapd[14239]: Unlock CR index = 0x83a4e90 Mar 30 20:50:16 albany slapd[14239]: STALE QUERY REMOVED, SIZE=0 Mar 30 20:50:16 albany slapd[14239]: STORED QUERIES = 20 Mar 30 20:50:16 albany slapd[14239]: STALE QUERY REMOVED, CACHE =22 entries Mar 30 20:50:16 albany slapd[14239]: Lock CR index = 0x83a4e90 Mar 30 20:50:16 albany slapd[14239]: TEMPLATE 0x83a4e90 QUERIES-- 5 Mar 30 20:50:16 albany slapd[14239]: Unlock CR index = 0x83a4e90 Mar 30 20:50:16 albany slapd[14239]: STALE QUERY REMOVED, SIZE=0 Mar 30 20:50:16 albany slapd[14239]: STORED QUERIES = 19 Mar 30 20:50:16 albany slapd[14239]: STALE QUERY REMOVED, CACHE =22 entries Mar 30 20:50:16 albany slapd[14239]: Lock CR index = 0x83a4e90 Mar 30 20:50:16 albany slapd[14239]: TEMPLATE 0x83a4e90 QUERIES-- 4 Mar 30 20:50:16 albany slapd[14239]: Unlock CR index = 0x83a4e90 Mar 30 20:50:16 albany slapd[14239]: STALE QUERY REMOVED, SIZE=0 Mar 30 20:50:16 albany slapd[14239]: STORED QUERIES = 18 Mar 30 20:50:16 albany slapd[14239]: STALE QUERY REMOVED, CACHE =22 entries Mar 30 20:50:16 albany slapd[14239]: Lock CR index = 0x83a4e90 Mar 30 20:50:16 albany slapd[14239]: TEMPLATE 0x83a4e90 QUERIES-- 3 Mar 30 20:50:16 albany slapd[14239]: Unlock CR index = 0x83a4e90 Mar 30 20:50:16 albany slapd[14239]: STALE QUERY REMOVED, SIZE=0 Mar 30 20:50:16 albany slapd[14239]: STORED QUERIES = 17 Mar 30 20:50:16 albany slapd[14239]: STALE QUERY REMOVED, CACHE =22 entries Mar 30 20:50:16 albany slapd[14239]: Lock CR index = 0x83a4e90 Mar 30 20:50:16 albany slapd[14239]: TEMPLATE 0x83a4e90 QUERIES-- 2 Mar 30 20:50:16 albany slapd[14239]: Unlock CR index = 0x83a4e90 Mar 30 20:50:16 albany slapd[14239]: STALE QUERY REMOVED, SIZE=0 Mar 30 20:50:16 albany slapd[14239]: STORED QUERIES = 16 Mar 30 20:50:16 albany slapd[14239]: STALE QUERY REMOVED, CACHE =22 entries Mar 30 20:50:16 albany slapd[14239]: Lock CR index = 0x83a4e90 Mar 30 20:50:16 albany slapd[14239]: TEMPLATE 0x83a4e90 QUERIES-- 1 Mar 30 20:50:16 albany slapd[14239]: Unlock CR index = 0x83a4e90 Mar 30 20:50:16 albany slapd[14239]: STALE QUERY REMOVED, SIZE=0 Mar 30 20:50:16 albany slapd[14239]: STORED QUERIES = 15 Mar 30 20:50:16 albany slapd[14239]: STALE QUERY REMOVED, CACHE =22 entries Mar 30 20:50:16 albany slapd[14239]: Lock CR index = 0x83a4e90 Mar 30 20:50:16 albany slapd[14239]: TEMPLATE 0x83a4e90 QUERIES-- 0 Mar 30 20:50:16 albany slapd[14239]: Unlock CR index = 0x83a4e90 Mar 30 20:50:16 albany slapd[14239]: STALE QUERY REMOVED, SIZE=0 Mar 30 20:50:16 albany slapd[14239]: STORED QUERIES = 14 Mar 30 20:50:16 albany slapd[14239]: STALE QUERY REMOVED, CACHE =22 entries Mar 30 20:50:16 albany slapd[14239]: Lock CR index = 0x83a4e28 Mar 30 20:50:16 albany slapd[14239]: TEMPLATE 0x83a4e28 QUERIES-- 0 Mar 30 20:50:16 albany slapd[14239]: Unlock CR index = 0x83a4e28 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 Program terminated with signal 6, Aborted. #0 0x00185402 in __kernel_vsyscall () (gdb) bt #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: Mar 13 04:37:48 pemberton slapd[6767]: Lock CR index = 0x9ac9188 Mar 13 04:37:48 pemberton slapd[6767]: TEMPLATE 0x9ac9188 QUERIES-- 2 Mar 13 04:37:48 pemberton slapd[6767]: Unlock CR index = 0x9ac9188 Mar 13 04:37:48 pemberton slapd[6767]: DELETING ENTRY TEMPLATE=febcaede-1a2f-42ef-af2e-9206f0a4f678 Mar 13 04:37:48 pemberton slapd[6767]: STALE QUERY REMOVED, SIZE=1 Mar 13 04:37:48 pemberton slapd[6767]: STORED QUERIES = 32 Mar 13 04:37:48 pemberton slapd[6767]: STALE QUERY REMOVED, CACHE =19 entries Mar 13 04:37:48 pemberton slapd[6767]: Lock CR index = 0x9ac8eb0 Mar 13 04:37:48 pemberton slapd[6767]: TEMPLATE 0x9ac8eb0 QUERIES-- 15 Mar 13 04:37:48 pemberton slapd[6767]: Unlock CR index = 0x9ac8eb0 Mar 13 04:37:48 pemberton slapd[6767]: STALE QUERY REMOVED, SIZE=0 Mar 13 04:37:48 pemberton slapd[6767]: STORED QUERIES = 31 Mar 13 04:37:48 pemberton slapd[6767]: STALE QUERY REMOVED, CACHE =19 entries Mar 13 04:37:48 pemberton slapd[6767]: Lock CR index = 0x9ac8eb0 Mar 13 04:37:48 pemberton slapd[6767]: TEMPLATE 0x9ac8eb0 QUERIES-- 14 Mar 13 04:37:48 pemberton slapd[6767]: Unlock CR index = 0x9ac8eb0 Mar 13 04:37:48 pemberton slapd[6767]: STALE QUERY REMOVED, SIZE=0 Mar 13 04:37:48 pemberton slapd[6767]: STORED QUERIES = 30 Mar 13 04:37:48 pemberton slapd[6767]: STALE QUERY REMOVED, CACHE =19 entries Mar 13 04:37:48 pemberton slapd[6767]: Lock CR index = 0x9ac8eb0 Mar 13 04:37:48 pemberton slapd[6767]: TEMPLATE 0x9ac8eb0 QUERIES-- 13 Mar 13 04:37:48 pemberton slapd[6767]: Unlock CR index = 0x9ac8eb0 Mar 13 04:37:48 pemberton slapd[6767]: STALE QUERY REMOVED, SIZE=0 Mar 13 04:37:48 pemberton slapd[6767]: STORED QUERIES = 29 Mar 13 04:37:48 pemberton slapd[6767]: STALE QUERY REMOVED, CACHE =19 entries Mar 13 04:37:48 pemberton slapd[6767]: Lock CR index = 0x9ac8eb0 Mar 13 04:37:48 pemberton slapd[6767]: TEMPLATE 0x9ac8eb0 QUERIES-- 12 Mar 13 04:37:48 pemberton slapd[6767]: Unlock CR index = 0x9ac8eb0 Mar 13 04:37:48 pemberton slapd[6767]: STALE QUERY REMOVED, SIZE=0 Mar 13 04:37:48 pemberton slapd[6767]: STORED QUERIES = 28 Mar 13 04:37:48 pemberton slapd[6767]: STALE QUERY REMOVED, CACHE =19 entries Mar 13 04:37:48 pemberton slapd[6767]: Lock CR index = 0x9ac8eb0 Mar 13 04:37:48 pemberton slapd[6767]: TEMPLATE 0x9ac8eb0 QUERIES-- 11 Mar 13 04:37:48 pemberton slapd[6767]: Unlock CR index = 0x9ac8eb0 Mar 13 04:37:48 pemberton slapd[6767]: STALE QUERY REMOVED, SIZE=0 Mar 13 04:37:48 pemberton slapd[6767]: STORED QUERIES = 27 Mar 13 04:37:48 pemberton slapd[6767]: STALE QUERY REMOVED, CACHE =19 entries Mar 13 04:37:48 pemberton slapd[6767]: Lock CR index = 0x9ac8eb0 Mar 13 04:37:48 pemberton slapd[6767]: TEMPLATE 0x9ac8eb0 QUERIES-- 10 Mar 13 04:37:48 pemberton slapd[6767]: Unlock CR index = 0x9ac8eb0 Mar 13 04:37:48 pemberton slapd[6767]: STALE QUERY REMOVED, SIZE=0 Mar 13 04:37:48 pemberton slapd[6767]: STORED QUERIES = 26 Mar 13 04:37:48 pemberton slapd[6767]: STALE QUERY REMOVED, CACHE =19 entries Mar 13 04:37:48 pemberton slapd[6767]: Lock CR index = 0x9ac8e48 Mar 13 04:37:48 pemberton slapd[6767]: TEMPLATE 0x9ac8e48 QUERIES-- 1 Mar 13 04:37:48 pemberton slapd[6767]: Unlock CR index = 0x9ac8e48 Mar 13 04:37:48 pemberton slapd[6767]: DELETING ENTRY TEMPLATE=3eff8b71-4ca6-4918-b760-c32023dbe215 Mar 13 04:37:48 pemberton last message repeated 12 times Mar 13 04:37:48 pemberton slapd[6767]: REMOVING TEMP ATTR : TEMPLATE=3eff8b71-4ca6-4918-b760-c32023dbe215 Mar 13 04:37:48 pemberton last message repeated 2 times Mar 13 04:37:48 pemberton slapd[6767]: STALE QUERY REMOVED, SIZE=13 Mar 13 04:37:48 pemberton slapd[6767]: STORED QUERIES = 25 Mar 13 04:37:48 pemberton slapd[6767]: STALE QUERY REMOVED, CACHE =6 entries Mar 13 04:37:48 pemberton slapd[6767]: Lock CR index = 0x9ac8da8 Program terminated with signal 11, Segmentation fault. #0 0x081772d2 in remove_from_template (qc=0xaef209a8, template=0x9ac8da8) at pcache.c:1297 1297 qc->prev->next = qc->next; (gdb) bt #0 0x081772d2 in remove_from_template (qc=0xaef209a8, template=0x9ac8da8) at pcache.c:1297 #1 0x0817adc8 in consistency_check (ctx=0xaeeff1d0, arg=0x9b19860) at pcache.c:2594 #2 0x0819ecad in ldap_int_thread_pool_wrapper (xpool=0x9a8afa0) at tpool.c:663 #3 0x00bb046b in start_thread () from /lib/libpthread.so.0 #4 0x00b07dbe in clone () from /lib/libc.so.6 (gdb) (gdb) p qc->prev->next Cannot access memory at address 0x54 (gdb) p qc->prev $2 = (struct cached_query_s *) 0x30 (gdb) p *qc->prev Cannot access memory at address 0x30 (gdb) As always, if there's any more information that would be useful, let me know... Cheers Toby -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.

1 0

Re: (ITS#6043) slapd segfaults in bdb_rdn_cmp
by hyc＠symas.com 02 Apr '09

02 Apr '09

Luca Scamoni wrote: > (gdb) thread apply all bt full > > Thread 4 (process 29343): > #0 0x006487a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 > No symbol table info available. > #1 0x001271d7 in pthread_join () from /lib/tls/libpthread.so.0 > No symbol table info available. > #2 0x008f8926 in ldap_pvt_thread_join (thread=4294967292, > thread_return=0xfffffffc) > at ../../../libraries/libldap_r/thr_posix.c:197 > No locals. > #3 0x080704d7 in slapd_daemon () > No symbol table info available. > #4 0x0805858e in main () > No symbol table info available. > > Thread 3 (process 29344): > #0 0x006487a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 > No symbol table info available. > #1 0x007372be in epoll_wait () from /lib/tls/libc.so.6 > No symbol table info available. > #2 0x0806f3fb in slapd_daemon_destroy () This trace is bogus, there's no call from slapd_daemon_destroy() to epoll_wait() in the code. And you wouldn't have gotten to slapd_daemon_destroy() unless you were shutting down. > No symbol table info available. > #3 0x001263cc in start_thread () from /lib/tls/libpthread.so.0 > No symbol table info available. > #4 0x00736c3e in clone () from /lib/tls/libc.so.6 > No symbol table info available. > > Thread 2 (process 29345): > #0 0x006487a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 > No symbol table info available. > #1 0x00128c26 in pthread_cond_wait@@GLIBC_2.3.2 () from > /lib/tls/libpthread.so.0 > No symbol table info available. > #2 0x008f8a2b in ldap_pvt_thread_cond_wait (cond=0xfffffffc, > mutex=0xfffffffc) > at ../../../libraries/libldap_r/thr_posix.c:277 > No locals. > #3 0x008f7d5a in ldap_int_thread_pool_wrapper (xpool=0x96eeb98) > at ../../../libraries/libldap_r/tpool.c:654 > task = (ldap_int_thread_task_t *) 0x0 > work_list = Variable "work_list" is not available. > > Thread 1 (process 29346): > #0 0x006d7860 in strncmp () from /lib/tls/libc.so.6 > No symbol table info available. > #1 0x0019085e in bdb_rdn_cmp (v_e1=0x17d7270, v_e2=0x9837d58) at > cache.c:301 > rc = 5 > #2 0x080fc1f5 in avl_find () > No symbol table info available. > #3 0x00190abd in hdb_cache_find_ndn (op=0x17d7460, txn=0x9837aa8, > ndn=0x17d73ec, res=0x17d7318) > at cache.c:433 > bdb = (struct bdb_info *) 0x97bf5d8 > ei = {bei_parent = 0x97bf624, bei_id = 0, bei_lockpad = 0, > bei_state = 0, > bei_finders = 0, bei_nrdn = {bv_len = 23, > bv_val = 0xffffffe9<Address 0xffffffe9 out of bounds>}, bei_rdn = > {bv_len = 0, > bv_val = 0x0}, bei_modrdns = 0, bei_ckids = 0, bei_dkids = 0, bei_e > = 0x0, > bei_kids = 0xb7f43994, bei_kids_mutex = {__m_reserved = 0, __m_count = > 0, __m_owner = 0x0, > __m_kind = 0, __m_lock = {__status = 0, __spinlock = 135208867}}, > bei_lrunext = 0x55313c, > bei_lruprev = 0x542022fc} > eip = (EntryInfo *) 0x97bf624 > ei2 = (EntryInfo *) 0x0 > rc = 0 > ptr = Variable "ptr" is not available. This is also bogus; is this an optimized compile? It's always hard to tell how much to trust the debugger here; if there are no further stack frames then possibly the stack was overwritten. But if you compiled with any type of optimization, and didn't use -fno-omit-frame-pointer, then that may be all that's happening here. -- -- 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#6043) slapd segfaults in bdb_rdn_cmp
by luca.scamoni＠sys-net.it 02 Apr '09

02 Apr '09

Howard Chu ha scritto: > Do you still have the data that caused this crash? Will it continue to > re-occur each time you restart a down server? (Can you continue to > reproduce the event...) I still have the data but the behaviour doesn't seem to be reproducible. It happened only on first run. After that we had to switch back to the old instance (it wasn't a real test, more an attempt to push it into production). I started slapd listening on another port after that and it didn't crash anymore (but it's also not receiving modifications). > > Please print *op and *eip as well. Also, what's in frame 4 or higher, > what function called hdb_cache_find_ndn(), does the stack trace stop > there or is there more? > (gdb) thread apply all bt full Thread 4 (process 29343): #0 0x006487a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 No symbol table info available. #1 0x001271d7 in pthread_join () from /lib/tls/libpthread.so.0 No symbol table info available. #2 0x008f8926 in ldap_pvt_thread_join (thread=4294967292, thread_return=0xfffffffc) at ../../../libraries/libldap_r/thr_posix.c:197 No locals. #3 0x080704d7 in slapd_daemon () No symbol table info available. #4 0x0805858e in main () No symbol table info available. Thread 3 (process 29344): #0 0x006487a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 No symbol table info available. #1 0x007372be in epoll_wait () from /lib/tls/libc.so.6 No symbol table info available. #2 0x0806f3fb in slapd_daemon_destroy () No symbol table info available. #3 0x001263cc in start_thread () from /lib/tls/libpthread.so.0 No symbol table info available. #4 0x00736c3e in clone () from /lib/tls/libc.so.6 No symbol table info available. Thread 2 (process 29345): #0 0x006487a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 No symbol table info available. #1 0x00128c26 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0 No symbol table info available. #2 0x008f8a2b in ldap_pvt_thread_cond_wait (cond=0xfffffffc, mutex=0xfffffffc) at ../../../libraries/libldap_r/thr_posix.c:277 No locals. #3 0x008f7d5a in ldap_int_thread_pool_wrapper (xpool=0x96eeb98) at ../../../libraries/libldap_r/tpool.c:654 task = (ldap_int_thread_task_t *) 0x0 work_list = Variable "work_list" is not available. Thread 1 (process 29346): #0 0x006d7860 in strncmp () from /lib/tls/libc.so.6 No symbol table info available. #1 0x0019085e in bdb_rdn_cmp (v_e1=0x17d7270, v_e2=0x9837d58) at cache.c:301 rc = 5 #2 0x080fc1f5 in avl_find () No symbol table info available. #3 0x00190abd in hdb_cache_find_ndn (op=0x17d7460, txn=0x9837aa8, ndn=0x17d73ec, res=0x17d7318) at cache.c:433 bdb = (struct bdb_info *) 0x97bf5d8 ei = {bei_parent = 0x97bf624, bei_id = 0, bei_lockpad = 0, bei_state = 0, bei_finders = 0, bei_nrdn = {bv_len = 23, bv_val = 0xffffffe9 <Address 0xffffffe9 out of bounds>}, bei_rdn = {bv_len = 0, bv_val = 0x0}, bei_modrdns = 0, bei_ckids = 0, bei_dkids = 0, bei_e = 0x0, bei_kids = 0xb7f43994, bei_kids_mutex = {__m_reserved = 0, __m_count = 0, __m_owner = 0x0, __m_kind = 0, __m_lock = {__status = 0, __spinlock = 135208867}}, bei_lrunext = 0x55313c, bei_lruprev = 0x542022fc} eip = (EntryInfo *) 0x97bf624 ei2 = (EntryInfo *) 0x0 rc = 0 ptr = Variable "ptr" is not available. Nothing else... variables contents follow in a private mail... Ing. Luca Scamoni Responsabile Ricerca e Sviluppo SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 0382 573859 (137) Mobile: +39 347 1014425 Fax: +39 0382 476497 Email: luca.scamoni(a)sys-net.it -----------------------------------

1 0

(ITS#6044) AnonCVS not working
by evaristojosec＠yahoo.es 02 Apr '09

02 Apr '09

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) Checking with wireshark (old ethereal), I have checked that my cvs client is able to send the authentication request, but the openLDAP cvs server request the end of the TCP connection BEGIN VERIFICATION REQUEST /repo/OpenLDAP anonymous A#:d=*.9} END VERIFICATION REQUEST I have also checked that the same client is working fine with other CVS servers and I had no problem at all cvs -d :pserver:anonymous@cvs.fedoraproject.org:/cvs/pkgs login Logging in to :pserver:anonymous@cvs.fedoraproject.org:2401/cvs/pkgs CVS password:

1 0

Re: (ITS#6043) slapd segfaults in bdb_rdn_cmp
by hyc＠symas.com 02 Apr '09

02 Apr '09

luca(a)OpenLDAP.org wrote: > Full_Name: Luca Scamoni > Version: RELENG > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (82.63.140.131) > > > Testing releng got this segfaults in a master-slave setup on both machines. Both > traces show the same: > > (gdb) bt full > #0 0x006d7860 in strncmp () from /lib/tls/libc.so.6 > No symbol table info available. > #1 0x0019085e in bdb_rdn_cmp (v_e1=0x17d7270, v_e2=0x9837d58) at cache.c:301 > rc = 5 > #2 0x080fc1f5 in avl_find () > No symbol table info available. > #3 0x00190abd in hdb_cache_find_ndn (op=0x17d7460, txn=0x9837aa8, > ndn=0x17d73ec, res=0x17d7318) at cache.c:433 > bdb = (struct bdb_info *) 0x97bf5d8 > ei = {bei_parent = 0x97bf624, bei_id = 0, bei_lockpad = 0, bei_state = > 0, bei_finders = 0, bei_nrdn = {bv_len = 23, > bv_val = 0xffffffe9<Address 0xffffffe9 out of bounds>}, bei_rdn = {bv_len = > 0, bv_val = 0x0}, bei_modrdns = 0, bei_ckids = 0, bei_dkids = 0, > bei_e = 0x0, bei_kids = 0xb7f43994, bei_kids_mutex = {__m_reserved = 0, > __m_count = 0, __m_owner = 0x0, __m_kind = 0, __m_lock = {__status = 0, > __spinlock = 135208867}}, bei_lrunext = 0x55313c, bei_lruprev = > 0x542022fc} > eip = (EntryInfo *) 0x97bf624 > ei2 = (EntryInfo *) 0x0 > rc = 0 > ptr = Variable "ptr" is not available. > > The core happened on master shortly after starting the slave, then on slave > shortly after staring the master again. > Using HDB and syncrepl (two databases per instance, different suffixes) > > I have access to the core(s) for any further information needed > > Do you still have the data that caused this crash? Will it continue to re-occur each time you restart a down server? (Can you continue to reproduce the event...) Please print *op and *eip as well. Also, what's in frame 4 or higher, what function called hdb_cache_find_ndn(), does the stack trace stop there or is there more? -- -- 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#6043) slapd segfaults in bdb_rdn_cmp
by luca＠OpenLDAP.org 02 Apr '09

02 Apr '09

Full_Name: Luca Scamoni Version: RELENG OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.63.140.131) Testing releng got this segfaults in a master-slave setup on both machines. Both traces show the same: (gdb) bt full #0 0x006d7860 in strncmp () from /lib/tls/libc.so.6 No symbol table info available. #1 0x0019085e in bdb_rdn_cmp (v_e1=0x17d7270, v_e2=0x9837d58) at cache.c:301 rc = 5 #2 0x080fc1f5 in avl_find () No symbol table info available. #3 0x00190abd in hdb_cache_find_ndn (op=0x17d7460, txn=0x9837aa8, ndn=0x17d73ec, res=0x17d7318) at cache.c:433 bdb = (struct bdb_info *) 0x97bf5d8 ei = {bei_parent = 0x97bf624, bei_id = 0, bei_lockpad = 0, bei_state = 0, bei_finders = 0, bei_nrdn = {bv_len = 23, bv_val = 0xffffffe9 <Address 0xffffffe9 out of bounds>}, bei_rdn = {bv_len = 0, bv_val = 0x0}, bei_modrdns = 0, bei_ckids = 0, bei_dkids = 0, bei_e = 0x0, bei_kids = 0xb7f43994, bei_kids_mutex = {__m_reserved = 0, __m_count = 0, __m_owner = 0x0, __m_kind = 0, __m_lock = {__status = 0, __spinlock = 135208867}}, bei_lrunext = 0x55313c, bei_lruprev = 0x542022fc} eip = (EntryInfo *) 0x97bf624 ei2 = (EntryInfo *) 0x0 rc = 0 ptr = Variable "ptr" is not available. The core happened on master shortly after starting the slave, then on slave shortly after staring the master again. Using HDB and syncrepl (two databases per instance, different suffixes) I have access to the core(s) for any further information needed

1 0

Access to pseudoattribute "entry" and rewrite overlay
by Konovalov Andrey 01 Apr '09

01 Apr '09

Hi4All! :) I notice that active RWM/Remap overlay affects ACL-subsystem when ACL checks access to pseudoatribute "entry" and this strange situation occurs even if i not use any rules for rewrite/remap. Нerewith without the loaded overlay RWM all works correctly... In debug mode slapd with active RWM (no rewrite rules!) deny all access to attribute entry except for "root" user => access_allowed: search access to "uid=akkerman,cn=Directory Server Admins,ou=Groups,dc=r2,dc=money,dc=ge,dc=com" "objectClass" requested <= test_filter 5 => acl_get: [13] attr entry => slap_access_allowed: result not in cache (entry) => acl_mask: access to entry "uid=akkerman,cn=Directory Server Admins,ou=Groups,dc=r2,dc=money,dc=ge,dc=com", attr "entry" requested => acl_mask: to all values by "", (none(=0)) <= check a_dn_pat: * <= acl_mask: [1] applying none(=0) (stop) <= acl_mask: [1] mask: none(=0) => slap_access_allowed: read access denied by none(=0) This problem may be solved by adding radically liberate rule to the beginning of olcAccess sequence in cn=config: olcAccess: {1}to * attrs=entry by * read Is it a bug?

2 1

Re: (ITS#6042) Microsoft compatibility patch
by ghenry＠suretecsystems.com 01 Apr '09

01 Apr '09

----- hyc(a)OpenLDAP.org wrote: > Full_Name: Howard Chu > Version: HEAD > OS: Linux > URL: ftp://ftp.openldap.org/incoming/hyc-mscompat.txt > Submission from: (NULL) (76.91.220.157) > > > This patch adds a new olcMsCompat config keyword which enables > ActiveDirectory emulation mode in slapd. It's still experimental, any > feedback > is appreciated. Can we fast track this patch in, as we really need this feature to get more breakfix requests. Stock slapd never goes down enough! -- Kind Regards, Gavin Henry. Managing Director. 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. Subject to disclaimer at http://www.suretecgroup.com/disclaimer.html

1 0

(ITS#6042) Microsoft compatibility patch
by hyc＠OpenLDAP.org 01 Apr '09

01 Apr '09

Full_Name: Howard Chu Version: HEAD OS: Linux URL: ftp://ftp.openldap.org/incoming/hyc-mscompat.txt Submission from: (NULL) (76.91.220.157) This patch adds a new olcMsCompat config keyword which enables ActiveDirectory emulation mode in slapd. It's still experimental, any feedback is appreciated.

1 0

Re: (ITS#6041) opendir() and closedir() bugs on Windows
by hyc＠symas.com 30 Mar '09

30 Mar '09

test.007(a)seznam.cz wrote: > Full_Name: Test Seven > Version: 2.4.15 > OS: Windows > URL: > Submission from: (NULL) (195.113.184.20) Thanks for the patch. The Windows code is known to work fine using gcc. Use of MSVC is discouraged since there have been so many incompatible CRT version changes in such a short span of time. (Actually, use of Microsoft-anything is generally discouraged; the same OpenLDAP code is at least 2-3x faster on the same hardware when using Linux instead of Windows.) > Two problems solved in the patch: > 1. closedir()'s retval is used, thus it must not be void. Windows uses implicit > declaration ``int closedir(int)'' because the function is not declared in > headers, thus the call in ldif.c compiles, but uses random value in EAX. > > 2. opendir() must set errno, because ldif_readdir() reads it. The patch converts > the most common Windows error codes to errno codes after FindFirstFile() WinAPI > call. > > The bugs prevent me from loading cn=config configuration. > > --- utils.c.orig 2009-01-22 01:00:58.000000000 +0100 > +++ utils.c 2009-03-27 14:28:33.500000000 +0100 > @@ -466,6 +466,40 @@ int mkstemp( char * template ) > #endif > > #ifdef _MSC_VER > +/* Equivalent of MS CRT's _dosmaperr(). > + * @param lastError[in] Result of GetLastError(). > + */ > +static errno_t win2errno(DWORD lastError) > +{ > + const struct { > + DWORD windows_code; > + errno_t errno_code; > + } WIN2ERRNO_TABLE[] = { > + { ERROR_SUCCESS, 0 }, > + { ERROR_FILE_NOT_FOUND, ENOENT }, > + { ERROR_PATH_NOT_FOUND, ENOENT }, > + { ERROR_TOO_MANY_OPEN_FILES, EMFILE }, > + { ERROR_ACCESS_DENIED, EACCES }, > + { ERROR_INVALID_HANDLE, EBADF }, > + { ERROR_NOT_ENOUGH_MEMORY, ENOMEM }, > + { ERROR_NOT_ENOUGH_MEMORY, ENOMEM }, > + { ERROR_LOCK_VIOLATION, EACCES }, > + { ERROR_FILE_EXISTS, EEXIST }, > + { ERROR_INVALID_PARAMETER, EINVAL }, > + { ERROR_FILENAME_EXCED_RANGE, ENAMETOOLONG }, > + }; > + const unsigned int WIN2ERRNO_TABLE_SIZE = sizeof(WIN2ERRNO_TABLE) / > sizeof(WIN2ERRNO_TABLE[0]); > + const errno_t DEFAULT_ERRNO_ERROR = -1; > + unsigned int i; > + > + for (i = 0; i< WIN2ERRNO_TABLE_SIZE; ++i) { > + if (WIN2ERRNO_TABLE[i].windows_code == lastError) { > + return WIN2ERRNO_TABLE[i].errno_code; > + } > + } > + return DEFAULT_ERRNO_ERROR; > +} > + > struct dirent { > char *d_name; > }; > @@ -493,9 +527,10 @@ DIR *opendir( char *path ) > > h = FindFirstFile( tmp,&data ); > > - if ( h == INVALID_HANDLE_VALUE ) > + if ( h == INVALID_HANDLE_VALUE ) { > + errno = win2errno(GetLastError()); > return NULL; > - > + } > d = ber_memalloc( sizeof(DIR) ); > if ( !d ) > return NULL; > @@ -518,10 +553,11 @@ struct dirent *readdir(DIR *dir) > } > return&dir->data; > } > -void closedir(DIR *dir) > +int closedir(DIR *dir) > { > FindClose(dir->dir); > ber_memfree(dir); > + return 0; > } > #endif > > > -- -- 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#6041) opendir() and closedir() bugs on Windows
by hyc＠symas.com 30 Mar '09

30 Mar '09

test.007(a)seznam.cz wrote: > Full_Name: Test Seven > Version: 2.4.15 > OS: Windows > URL: > Submission from: (NULL) (195.113.184.20) Thanks for the patch. The Windows code is known to work fine using gcc. Use of MSVC is discouraged since there have been so many incompatible CRT version changes in such a short span of time. (Actually, use of Microsoft-anything is generally discouraged; the same OpenLDAP code is at least 2-3x faster on the same hardware when using Linux instead of Windows.) > Two problems solved in the patch: > 1. closedir()'s retval is used, thus it must not be void. Windows uses implicit > declaration ``int closedir(int)'' because the function is not declared in > headers, thus the call in ldif.c compiles, but uses random value in EAX. > > 2. opendir() must set errno, because ldif_readdir() reads it. The patch converts > the most common Windows error codes to errno codes after FindFirstFile() WinAPI > call. > > The bugs prevent me from loading cn=config configuration. > > --- utils.c.orig 2009-01-22 01:00:58.000000000 +0100 > +++ utils.c 2009-03-27 14:28:33.500000000 +0100 > @@ -466,6 +466,40 @@ int mkstemp( char * template ) > #endif > > #ifdef _MSC_VER > +/* Equivalent of MS CRT's _dosmaperr(). > + * @param lastError[in] Result of GetLastError(). > + */ > +static errno_t win2errno(DWORD lastError) > +{ > + const struct { > + DWORD windows_code; > + errno_t errno_code; > + } WIN2ERRNO_TABLE[] = { > + { ERROR_SUCCESS, 0 }, > + { ERROR_FILE_NOT_FOUND, ENOENT }, > + { ERROR_PATH_NOT_FOUND, ENOENT }, > + { ERROR_TOO_MANY_OPEN_FILES, EMFILE }, > + { ERROR_ACCESS_DENIED, EACCES }, > + { ERROR_INVALID_HANDLE, EBADF }, > + { ERROR_NOT_ENOUGH_MEMORY, ENOMEM }, > + { ERROR_NOT_ENOUGH_MEMORY, ENOMEM }, > + { ERROR_LOCK_VIOLATION, EACCES }, > + { ERROR_FILE_EXISTS, EEXIST }, > + { ERROR_INVALID_PARAMETER, EINVAL }, > + { ERROR_FILENAME_EXCED_RANGE, ENAMETOOLONG }, > + }; > + const unsigned int WIN2ERRNO_TABLE_SIZE = sizeof(WIN2ERRNO_TABLE) / > sizeof(WIN2ERRNO_TABLE[0]); > + const errno_t DEFAULT_ERRNO_ERROR = -1; > + unsigned int i; > + > + for (i = 0; i< WIN2ERRNO_TABLE_SIZE; ++i) { > + if (WIN2ERRNO_TABLE[i].windows_code == lastError) { > + return WIN2ERRNO_TABLE[i].errno_code; > + } > + } > + return DEFAULT_ERRNO_ERROR; > +} > + > struct dirent { > char *d_name; > }; > @@ -493,9 +527,10 @@ DIR *opendir( char *path ) > > h = FindFirstFile( tmp,&data ); > > - if ( h == INVALID_HANDLE_VALUE ) > + if ( h == INVALID_HANDLE_VALUE ) { > + errno = win2errno(GetLastError()); > return NULL; > - > + } > d = ber_memalloc( sizeof(DIR) ); > if ( !d ) > return NULL; > @@ -518,10 +553,11 @@ struct dirent *readdir(DIR *dir) > } > return&dir->data; > } > -void closedir(DIR *dir) > +int closedir(DIR *dir) > { > FindClose(dir->dir); > ber_memfree(dir); > + return 0; > } > #endif > > > -- -- 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#6041) opendir() and closedir() bugs on Windows
by hyc＠symas.com 30 Mar '09

30 Mar '09

test.007(a)seznam.cz wrote: > Full_Name: Test Seven > Version: 2.4.15 > OS: Windows > URL: > Submission from: (NULL) (195.113.184.20) Thanks for the patch. The Windows code is known to work fine using gcc. Use of MSVC is discouraged since there have been so many incompatible CRT version changes in such a short span of time. (Actually, use of Microsoft-anything is generally discouraged; the same OpenLDAP code is at least 2-3x faster on the same hardware when using Linux instead of Windows.) > Two problems solved in the patch: > 1. closedir()'s retval is used, thus it must not be void. Windows uses implicit > declaration ``int closedir(int)'' because the function is not declared in > headers, thus the call in ldif.c compiles, but uses random value in EAX. > > 2. opendir() must set errno, because ldif_readdir() reads it. The patch converts > the most common Windows error codes to errno codes after FindFirstFile() WinAPI > call. > > The bugs prevent me from loading cn=config configuration. > > --- utils.c.orig 2009-01-22 01:00:58.000000000 +0100 > +++ utils.c 2009-03-27 14:28:33.500000000 +0100 > @@ -466,6 +466,40 @@ int mkstemp( char * template ) > #endif > > #ifdef _MSC_VER > +/* Equivalent of MS CRT's _dosmaperr(). > + * @param lastError[in] Result of GetLastError(). > + */ > +static errno_t win2errno(DWORD lastError) > +{ > + const struct { > + DWORD windows_code; > + errno_t errno_code; > + } WIN2ERRNO_TABLE[] = { > + { ERROR_SUCCESS, 0 }, > + { ERROR_FILE_NOT_FOUND, ENOENT }, > + { ERROR_PATH_NOT_FOUND, ENOENT }, > + { ERROR_TOO_MANY_OPEN_FILES, EMFILE }, > + { ERROR_ACCESS_DENIED, EACCES }, > + { ERROR_INVALID_HANDLE, EBADF }, > + { ERROR_NOT_ENOUGH_MEMORY, ENOMEM }, > + { ERROR_NOT_ENOUGH_MEMORY, ENOMEM }, > + { ERROR_LOCK_VIOLATION, EACCES }, > + { ERROR_FILE_EXISTS, EEXIST }, > + { ERROR_INVALID_PARAMETER, EINVAL }, > + { ERROR_FILENAME_EXCED_RANGE, ENAMETOOLONG }, > + }; > + const unsigned int WIN2ERRNO_TABLE_SIZE = sizeof(WIN2ERRNO_TABLE) / > sizeof(WIN2ERRNO_TABLE[0]); > + const errno_t DEFAULT_ERRNO_ERROR = -1; > + unsigned int i; > + > + for (i = 0; i< WIN2ERRNO_TABLE_SIZE; ++i) { > + if (WIN2ERRNO_TABLE[i].windows_code == lastError) { > + return WIN2ERRNO_TABLE[i].errno_code; > + } > + } > + return DEFAULT_ERRNO_ERROR; > +} > + > struct dirent { > char *d_name; > }; > @@ -493,9 +527,10 @@ DIR *opendir( char *path ) > > h = FindFirstFile( tmp,&data ); > > - if ( h == INVALID_HANDLE_VALUE ) > + if ( h == INVALID_HANDLE_VALUE ) { > + errno = win2errno(GetLastError()); > return NULL; > - > + } > d = ber_memalloc( sizeof(DIR) ); > if ( !d ) > return NULL; > @@ -518,10 +553,11 @@ struct dirent *readdir(DIR *dir) > } > return&dir->data; > } > -void closedir(DIR *dir) > +int closedir(DIR *dir) > { > FindClose(dir->dir); > ber_memfree(dir); > + return 0; > } > #endif > > > -- -- 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#6041) opendir() and closedir() bugs on Windows
by hyc＠symas.com 30 Mar '09

30 Mar '09

test.007(a)seznam.cz wrote: > Full_Name: Test Seven > Version: 2.4.15 > OS: Windows > URL: > Submission from: (NULL) (195.113.184.20) Thanks for the patch. The Windows code is known to work fine using gcc. Use of MSVC is discouraged since there have been so many incompatible CRT version changes in such a short span of time. (Actually, use of Microsoft-anything is generally discouraged; the same OpenLDAP code is at least 2-3x faster on the same hardware when using Linux instead of Windows.) > Two problems solved in the patch: > 1. closedir()'s retval is used, thus it must not be void. Windows uses implicit > declaration ``int closedir(int)'' because the function is not declared in > headers, thus the call in ldif.c compiles, but uses random value in EAX. > > 2. opendir() must set errno, because ldif_readdir() reads it. The patch converts > the most common Windows error codes to errno codes after FindFirstFile() WinAPI > call. > > The bugs prevent me from loading cn=config configuration. > > --- utils.c.orig 2009-01-22 01:00:58.000000000 +0100 > +++ utils.c 2009-03-27 14:28:33.500000000 +0100 > @@ -466,6 +466,40 @@ int mkstemp( char * template ) > #endif > > #ifdef _MSC_VER > +/* Equivalent of MS CRT's _dosmaperr(). > + * @param lastError[in] Result of GetLastError(). > + */ > +static errno_t win2errno(DWORD lastError) > +{ > + const struct { > + DWORD windows_code; > + errno_t errno_code; > + } WIN2ERRNO_TABLE[] = { > + { ERROR_SUCCESS, 0 }, > + { ERROR_FILE_NOT_FOUND, ENOENT }, > + { ERROR_PATH_NOT_FOUND, ENOENT }, > + { ERROR_TOO_MANY_OPEN_FILES, EMFILE }, > + { ERROR_ACCESS_DENIED, EACCES }, > + { ERROR_INVALID_HANDLE, EBADF }, > + { ERROR_NOT_ENOUGH_MEMORY, ENOMEM }, > + { ERROR_NOT_ENOUGH_MEMORY, ENOMEM }, > + { ERROR_LOCK_VIOLATION, EACCES }, > + { ERROR_FILE_EXISTS, EEXIST }, > + { ERROR_INVALID_PARAMETER, EINVAL }, > + { ERROR_FILENAME_EXCED_RANGE, ENAMETOOLONG }, > + }; > + const unsigned int WIN2ERRNO_TABLE_SIZE = sizeof(WIN2ERRNO_TABLE) / > sizeof(WIN2ERRNO_TABLE[0]); > + const errno_t DEFAULT_ERRNO_ERROR = -1; > + unsigned int i; > + > + for (i = 0; i< WIN2ERRNO_TABLE_SIZE; ++i) { > + if (WIN2ERRNO_TABLE[i].windows_code == lastError) { > + return WIN2ERRNO_TABLE[i].errno_code; > + } > + } > + return DEFAULT_ERRNO_ERROR; > +} > + > struct dirent { > char *d_name; > }; > @@ -493,9 +527,10 @@ DIR *opendir( char *path ) > > h = FindFirstFile( tmp,&data ); > > - if ( h == INVALID_HANDLE_VALUE ) > + if ( h == INVALID_HANDLE_VALUE ) { > + errno = win2errno(GetLastError()); > return NULL; > - > + } > d = ber_memalloc( sizeof(DIR) ); > if ( !d ) > return NULL; > @@ -518,10 +553,11 @@ struct dirent *readdir(DIR *dir) > } > return&dir->data; > } > -void closedir(DIR *dir) > +int closedir(DIR *dir) > { > FindClose(dir->dir); > ber_memfree(dir); > + return 0; > } > #endif > > > -- -- 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#6041) opendir() and closedir() bugs on Windows
by hyc＠symas.com 30 Mar '09

30 Mar '09

test.007(a)seznam.cz wrote: > Full_Name: Test Seven > Version: 2.4.15 > OS: Windows > URL: > Submission from: (NULL) (195.113.184.20) Thanks for the patch. The Windows code is known to work fine using gcc. Use of MSVC is discouraged since there have been so many incompatible CRT version changes in such a short span of time. (Actually, use of Microsoft-anything is generally discouraged; the same OpenLDAP code is at least 2-3x faster on the same hardware when using Linux instead of Windows.) > Two problems solved in the patch: > 1. closedir()'s retval is used, thus it must not be void. Windows uses implicit > declaration ``int closedir(int)'' because the function is not declared in > headers, thus the call in ldif.c compiles, but uses random value in EAX. > > 2. opendir() must set errno, because ldif_readdir() reads it. The patch converts > the most common Windows error codes to errno codes after FindFirstFile() WinAPI > call. > > The bugs prevent me from loading cn=config configuration. > > --- utils.c.orig 2009-01-22 01:00:58.000000000 +0100 > +++ utils.c 2009-03-27 14:28:33.500000000 +0100 > @@ -466,6 +466,40 @@ int mkstemp( char * template ) > #endif > > #ifdef _MSC_VER > +/* Equivalent of MS CRT's _dosmaperr(). > + * @param lastError[in] Result of GetLastError(). > + */ > +static errno_t win2errno(DWORD lastError) > +{ > + const struct { > + DWORD windows_code; > + errno_t errno_code; > + } WIN2ERRNO_TABLE[] = { > + { ERROR_SUCCESS, 0 }, > + { ERROR_FILE_NOT_FOUND, ENOENT }, > + { ERROR_PATH_NOT_FOUND, ENOENT }, > + { ERROR_TOO_MANY_OPEN_FILES, EMFILE }, > + { ERROR_ACCESS_DENIED, EACCES }, > + { ERROR_INVALID_HANDLE, EBADF }, > + { ERROR_NOT_ENOUGH_MEMORY, ENOMEM }, > + { ERROR_NOT_ENOUGH_MEMORY, ENOMEM }, > + { ERROR_LOCK_VIOLATION, EACCES }, > + { ERROR_FILE_EXISTS, EEXIST }, > + { ERROR_INVALID_PARAMETER, EINVAL }, > + { ERROR_FILENAME_EXCED_RANGE, ENAMETOOLONG }, > + }; > + const unsigned int WIN2ERRNO_TABLE_SIZE = sizeof(WIN2ERRNO_TABLE) / > sizeof(WIN2ERRNO_TABLE[0]); > + const errno_t DEFAULT_ERRNO_ERROR = -1; > + unsigned int i; > + > + for (i = 0; i< WIN2ERRNO_TABLE_SIZE; ++i) { > + if (WIN2ERRNO_TABLE[i].windows_code == lastError) { > + return WIN2ERRNO_TABLE[i].errno_code; > + } > + } > + return DEFAULT_ERRNO_ERROR; > +} > + > struct dirent { > char *d_name; > }; > @@ -493,9 +527,10 @@ DIR *opendir( char *path ) > > h = FindFirstFile( tmp,&data ); > > - if ( h == INVALID_HANDLE_VALUE ) > + if ( h == INVALID_HANDLE_VALUE ) { > + errno = win2errno(GetLastError()); > return NULL; > - > + } > d = ber_memalloc( sizeof(DIR) ); > if ( !d ) > return NULL; > @@ -518,10 +553,11 @@ struct dirent *readdir(DIR *dir) > } > return&dir->data; > } > -void closedir(DIR *dir) > +int closedir(DIR *dir) > { > FindClose(dir->dir); > ber_memfree(dir); > + return 0; > } > #endif > > > -- -- 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#6041) opendir() and closedir() bugs on Windows
by hyc＠symas.com 30 Mar '09

30 Mar '09

test.007(a)seznam.cz wrote: > Full_Name: Test Seven > Version: 2.4.15 > OS: Windows > URL: > Submission from: (NULL) (195.113.184.20) Thanks for the patch. The Windows code is known to work fine using gcc. Use of MSVC is discouraged since there have been so many incompatible CRT version changes in such a short span of time. (Actually, use of Microsoft-anything is generally discouraged; the same OpenLDAP code is at least 2-3x faster on the same hardware when using Linux instead of Windows.) > Two problems solved in the patch: > 1. closedir()'s retval is used, thus it must not be void. Windows uses implicit > declaration ``int closedir(int)'' because the function is not declared in > headers, thus the call in ldif.c compiles, but uses random value in EAX. > > 2. opendir() must set errno, because ldif_readdir() reads it. The patch converts > the most common Windows error codes to errno codes after FindFirstFile() WinAPI > call. > > The bugs prevent me from loading cn=config configuration. > > --- utils.c.orig 2009-01-22 01:00:58.000000000 +0100 > +++ utils.c 2009-03-27 14:28:33.500000000 +0100 > @@ -466,6 +466,40 @@ int mkstemp( char * template ) > #endif > > #ifdef _MSC_VER > +/* Equivalent of MS CRT's _dosmaperr(). > + * @param lastError[in] Result of GetLastError(). > + */ > +static errno_t win2errno(DWORD lastError) > +{ > + const struct { > + DWORD windows_code; > + errno_t errno_code; > + } WIN2ERRNO_TABLE[] = { > + { ERROR_SUCCESS, 0 }, > + { ERROR_FILE_NOT_FOUND, ENOENT }, > + { ERROR_PATH_NOT_FOUND, ENOENT }, > + { ERROR_TOO_MANY_OPEN_FILES, EMFILE }, > + { ERROR_ACCESS_DENIED, EACCES }, > + { ERROR_INVALID_HANDLE, EBADF }, > + { ERROR_NOT_ENOUGH_MEMORY, ENOMEM }, > + { ERROR_NOT_ENOUGH_MEMORY, ENOMEM }, > + { ERROR_LOCK_VIOLATION, EACCES }, > + { ERROR_FILE_EXISTS, EEXIST }, > + { ERROR_INVALID_PARAMETER, EINVAL }, > + { ERROR_FILENAME_EXCED_RANGE, ENAMETOOLONG }, > + }; > + const unsigned int WIN2ERRNO_TABLE_SIZE = sizeof(WIN2ERRNO_TABLE) / > sizeof(WIN2ERRNO_TABLE[0]); > + const errno_t DEFAULT_ERRNO_ERROR = -1; > + unsigned int i; > + > + for (i = 0; i< WIN2ERRNO_TABLE_SIZE; ++i) { > + if (WIN2ERRNO_TABLE[i].windows_code == lastError) { > + return WIN2ERRNO_TABLE[i].errno_code; > + } > + } > + return DEFAULT_ERRNO_ERROR; > +} > + > struct dirent { > char *d_name; > }; > @@ -493,9 +527,10 @@ DIR *opendir( char *path ) > > h = FindFirstFile( tmp,&data ); > > - if ( h == INVALID_HANDLE_VALUE ) > + if ( h == INVALID_HANDLE_VALUE ) { > + errno = win2errno(GetLastError()); > return NULL; > - > + } > d = ber_memalloc( sizeof(DIR) ); > if ( !d ) > return NULL; > @@ -518,10 +553,11 @@ struct dirent *readdir(DIR *dir) > } > return&dir->data; > } > -void closedir(DIR *dir) > +int closedir(DIR *dir) > { > FindClose(dir->dir); > ber_memfree(dir); > + return 0; > } > #endif > > > -- -- 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#6041) opendir() and closedir() bugs on Windows
by hyc＠symas.com 30 Mar '09

30 Mar '09

test.007(a)seznam.cz wrote: > Full_Name: Test Seven > Version: 2.4.15 > OS: Windows > URL: > Submission from: (NULL) (195.113.184.20) Thanks for the patch. The Windows code is known to work fine using gcc. Use of MSVC is discouraged since there have been so many incompatible CRT version changes in such a short span of time. (Actually, use of Microsoft-anything is generally discouraged; the same OpenLDAP code is at least 2-3x faster on the same hardware when using Linux instead of Windows.) > Two problems solved in the patch: > 1. closedir()'s retval is used, thus it must not be void. Windows uses implicit > declaration ``int closedir(int)'' because the function is not declared in > headers, thus the call in ldif.c compiles, but uses random value in EAX. > > 2. opendir() must set errno, because ldif_readdir() reads it. The patch converts > the most common Windows error codes to errno codes after FindFirstFile() WinAPI > call. > > The bugs prevent me from loading cn=config configuration. > > --- utils.c.orig 2009-01-22 01:00:58.000000000 +0100 > +++ utils.c 2009-03-27 14:28:33.500000000 +0100 > @@ -466,6 +466,40 @@ int mkstemp( char * template ) > #endif > > #ifdef _MSC_VER > +/* Equivalent of MS CRT's _dosmaperr(). > + * @param lastError[in] Result of GetLastError(). > + */ > +static errno_t win2errno(DWORD lastError) > +{ > + const struct { > + DWORD windows_code; > + errno_t errno_code; > + } WIN2ERRNO_TABLE[] = { > + { ERROR_SUCCESS, 0 }, > + { ERROR_FILE_NOT_FOUND, ENOENT }, > + { ERROR_PATH_NOT_FOUND, ENOENT }, > + { ERROR_TOO_MANY_OPEN_FILES, EMFILE }, > + { ERROR_ACCESS_DENIED, EACCES }, > + { ERROR_INVALID_HANDLE, EBADF }, > + { ERROR_NOT_ENOUGH_MEMORY, ENOMEM }, > + { ERROR_NOT_ENOUGH_MEMORY, ENOMEM }, > + { ERROR_LOCK_VIOLATION, EACCES }, > + { ERROR_FILE_EXISTS, EEXIST }, > + { ERROR_INVALID_PARAMETER, EINVAL }, > + { ERROR_FILENAME_EXCED_RANGE, ENAMETOOLONG }, > + }; > + const unsigned int WIN2ERRNO_TABLE_SIZE = sizeof(WIN2ERRNO_TABLE) / > sizeof(WIN2ERRNO_TABLE[0]); > + const errno_t DEFAULT_ERRNO_ERROR = -1; > + unsigned int i; > + > + for (i = 0; i< WIN2ERRNO_TABLE_SIZE; ++i) { > + if (WIN2ERRNO_TABLE[i].windows_code == lastError) { > + return WIN2ERRNO_TABLE[i].errno_code; > + } > + } > + return DEFAULT_ERRNO_ERROR; > +} > + > struct dirent { > char *d_name; > }; > @@ -493,9 +527,10 @@ DIR *opendir( char *path ) > > h = FindFirstFile( tmp,&data ); > > - if ( h == INVALID_HANDLE_VALUE ) > + if ( h == INVALID_HANDLE_VALUE ) { > + errno = win2errno(GetLastError()); > return NULL; > - > + } > d = ber_memalloc( sizeof(DIR) ); > if ( !d ) > return NULL; > @@ -518,10 +553,11 @@ struct dirent *readdir(DIR *dir) > } > return&dir->data; > } > -void closedir(DIR *dir) > +int closedir(DIR *dir) > { > FindClose(dir->dir); > ber_memfree(dir); > + return 0; > } > #endif > > > -- -- 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#6038) Write slapadd progress meter to stdout
by michael＠stroeder.com 27 Mar '09

27 Mar '09

rein(a)OpenLDAP.org wrote: > For programs that produce real output (slapcat, ldapsearch) this might > be true, but for those that don't (slapadd, slapd) I totally disagree. > Stderr is for errors, not chatty progress or debug messages. I always > hate it when the error messages gets burried in lots of noice. > > My preference is to have progress and debug messages on stdout, enabled > by options or at least possible to disable by options. Real output must > be possible to send to a file specified as argument, to separate it from > the progress and debug noice. Stderr is for error messages, and > possibly out-of-band messages. +1 Ciao, Michael.

1 0

(ITS#6041) opendir() and closedir() bugs on Windows
by test.007＠seznam.cz 27 Mar '09

27 Mar '09

Full_Name: Test Seven Version: 2.4.15 OS: Windows URL: Submission from: (NULL) (195.113.184.20) Two problems solved in the patch: 1. closedir()'s retval is used, thus it must not be void. Windows uses implicit declaration ``int closedir(int)'' because the function is not declared in headers, thus the call in ldif.c compiles, but uses random value in EAX. 2. opendir() must set errno, because ldif_readdir() reads it. The patch converts the most common Windows error codes to errno codes after FindFirstFile() WinAPI call. The bugs prevent me from loading cn=config configuration. --- utils.c.orig 2009-01-22 01:00:58.000000000 +0100 +++ utils.c 2009-03-27 14:28:33.500000000 +0100 @@ -466,6 +466,40 @@ int mkstemp( char * template ) #endif #ifdef _MSC_VER +/* Equivalent of MS CRT's _dosmaperr(). + * @param lastError[in] Result of GetLastError(). + */ +static errno_t win2errno(DWORD lastError) +{ + const struct { + DWORD windows_code; + errno_t errno_code; + } WIN2ERRNO_TABLE[] = { + { ERROR_SUCCESS, 0 }, + { ERROR_FILE_NOT_FOUND, ENOENT }, + { ERROR_PATH_NOT_FOUND, ENOENT }, + { ERROR_TOO_MANY_OPEN_FILES, EMFILE }, + { ERROR_ACCESS_DENIED, EACCES }, + { ERROR_INVALID_HANDLE, EBADF }, + { ERROR_NOT_ENOUGH_MEMORY, ENOMEM }, + { ERROR_NOT_ENOUGH_MEMORY, ENOMEM }, + { ERROR_LOCK_VIOLATION, EACCES }, + { ERROR_FILE_EXISTS, EEXIST }, + { ERROR_INVALID_PARAMETER, EINVAL }, + { ERROR_FILENAME_EXCED_RANGE, ENAMETOOLONG }, + }; + const unsigned int WIN2ERRNO_TABLE_SIZE = sizeof(WIN2ERRNO_TABLE) / sizeof(WIN2ERRNO_TABLE[0]); + const errno_t DEFAULT_ERRNO_ERROR = -1; + unsigned int i; + + for (i = 0; i < WIN2ERRNO_TABLE_SIZE; ++i) { + if (WIN2ERRNO_TABLE[i].windows_code == lastError) { + return WIN2ERRNO_TABLE[i].errno_code; + } + } + return DEFAULT_ERRNO_ERROR; +} + struct dirent { char *d_name; }; @@ -493,9 +527,10 @@ DIR *opendir( char *path ) h = FindFirstFile( tmp, &data ); - if ( h == INVALID_HANDLE_VALUE ) + if ( h == INVALID_HANDLE_VALUE ) { + errno = win2errno(GetLastError()); return NULL; - + } d = ber_memalloc( sizeof(DIR) ); if ( !d ) return NULL; @@ -518,10 +553,11 @@ struct dirent *readdir(DIR *dir) } return &dir->data; } -void closedir(DIR *dir) +int closedir(DIR *dir) { FindClose(dir->dir); ber_memfree(dir); + return 0; } #endif

1 0

Re: (ITS#6033) Segmentation fault - somewhere below syncprov_matchops / test_filter
by Howard Chu 27 Mar '09

27 Mar '09

Please test with RE24 instead of 2.4.15 and followup with your results.

1 0

Re: (ITS#6040) SEGV - hdb_cache_lru_purge / bdb_cache_delete_internal / ldap_pvt_thread_mutex_lock
by Howard Chu 27 Mar '09

27 Mar '09

Please use RE24 instead of 2.4.15 and followup with your results.

1 0

Re: (ITS#6038) Write slapadd progress meter to stdout
by hyc＠symas.com 27 Mar '09

27 Mar '09

Rein Tollevik wrote: > hyc(a)symas.com wrote: >> Hallvard B Furuseth wrote: >>> hyc(a)symas.com writes: >>>> Just redirect stdin, and the meter will automatically turn itself off. >>> It was stderr, not stdin - which after all can be the ldif. >>> Stdout is better. >>> >> No, you misunderstand. >> >> Redirecting stderr (or stdout) merely sends the progress info to that >> destination. Piping input on stdin will turn it off, so there's no progress >> info to redirect. > > No, the code only enables the meter if stdout (was: stderr) is a tty, so > redirecting it anywhere disables it. The meter was enabled both by > "slapadd -l file" and "slapadd< file", but "cat file | slapadd" did > disable it. IMHO not exactly an obvious way.. > > An option sounds more and more like the solution, what about "-m" for > meter? Though I'm not sure whether I prefer that it should be enabled > by default and the option disable it, or the other way around.. We already decided it should be enabled by default. Setting any explicit debug flag already disables it. >> Writing progress to stderr is the correct thing to do, because it's transient >> info that isn't meant to be saved. Checking whether stdout is redirected or >> not is fine, but writing progress info to stdout is not. > > For programs that produce real output (slapcat, ldapsearch) this might > be true, but for those that don't (slapadd, slapd) I totally disagree. > Stderr is for errors, not chatty progress or debug messages. I always > hate it when the error messages gets burried in lots of noice. Stderr is for any diagnostic info. Progress reports are diagnostic, they are certainly not the main purpose of any of these programs. Stdout is for anything related to the primary purpose of these programs. For slapcat, that's obvious. For slapadd/slapindex, these programs' purpose is not to produce any textual output at all; stdout is unused. That doesn't mean it's correct to ignore these long-standard Unix I/O usage conventions and suddenly switch stderr output to stdout. And as already noted, if you're looking for debug messages, then the meter will be disabled. > My preference is to have progress and debug messages on stdout, enabled > by options or at least possible to disable by options. Quite simply, this is completely wrong. It also introduces an unnecessary inconsistency between slapcat and slapadd behavior. Progress belongs on stderr, period. -- -- 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#6040) SEGV - hdb_cache_lru_purge / bdb_cache_delete_internal / ldap_pvt_thread_mutex_lock
by oskar＠deckle.co.za 27 Mar '09

27 Mar '09

Full_Name: Oskar Pearson Version: 2.4.15 OS: Ubuntu hardy URL: ftp://ftp.openldap.org/incoming/slapd-configs-qualica-1.tar.gz Submission from: (NULL) (94.194.140.71) This is the same machine as ITS #6033. Details included here for easy reference: Openldap 2.4.15 (with no patches) was self-compiled with no patches (CFLAGS="-ggdb3 -O0" ./configure), linked against standard OS libraries (ubuntu hardy) for BDB etc. BDB is 4.6.21-6ubuntu1. Kernel is 2.6.24-19-server, libc is libc6-i686/2.7-10ubuntu3. I do not have a debug log of this crash as it occurred on a live server, which is too busy for that level of logging. I also do not have a replaceable example. I have core dumps and can print out whatever is necessary there - I appreciate your time and help. If I've missed some important info, please let me know and I'll rectify asap. System overview: We have a master server which replicates to > 100 machines for Samba purposes across ADSL lines with a VPN. These lines are quite busy, so replication writes may be slow across the network, which may have implications for locks. Config files are included at the url below. I've realised through looking at the code and config files that I should probably increase the dncachesize parameter, as the number of DNs in the db is > 2000. This would help reduce the possibility of the bug occurring, but I think the bug will still exist. gdb --core=/root/core.26366 servers/slapd/slapd ... (gdb) bt #0 0xb7dd3540 in pthread_mutex_lock () from /lib/tls/i686/cmov/libpthread.so.0 #1 0x0817beef in ldap_pvt_thread_mutex_lock (mutex=0x34) at thr_posix.c:296 #2 0x08144215 in bdb_cache_delete_internal (cache=0x82b6df4, e=0x84017d8, decr=0) at cache.c:1335 #3 0x081430e5 in hdb_cache_lru_purge (bdb=0x82b6db8) at cache.c:749 #4 0x081438ba in hdb_cache_find_id (op=0x86c01d0, tid=0x86d0a30, id=1792, eip=0x9f6f1e68, flag=2, lock=0x9f6f1e00) at cache.c:1016 #5 0x08115c29 in hdb_search (op=0x86c01d0, rs=0x9f6f3100) at search.c:705 #6 0x080f179a in overlay_op_walk (op=0x86c01d0, rs=0x9f6f3100, which=op_search, oi=0x82d2b88, on=0x0) at backover.c:669 #7 0x080f19a2 in over_op_func (op=0x86c01d0, rs=0x9f6f3100, which=op_search) at backover.c:721 #8 0x080f1a46 in over_op_search (op=0x86c01d0, rs=0x9f6f3100) at backover.c:743 #9 0x080724ed in fe_op_search (op=0x86c01d0, rs=0x9f6f3100) at search.c:366 #10 0x08071e60 in do_search (op=0x86c01d0, rs=0x9f6f3100) at search.c:217 #11 0x0806eb44 in connection_operation (ctx=0x9f6f31f0, arg_v=0x86c01d0) at connection.c:1133 #12 0x0806f01e in connection_read_thread (ctx=0x9f6f31f0, argv=0x46) at connection.c:1259 #13 0x0817ad1f in ldap_int_thread_pool_wrapper (xpool=0x829caf0) at tpool.c:663 #14 0xb7dd14fb in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #15 0xb7ba0e5e in clone () from /lib/tls/i686/cmov/libc.so.6 (gdb) frame 2 #2 0x08144215 in bdb_cache_delete_internal (cache=0x82b6df4, e=0x84017d8, decr=0) at cache.c:1335 1335 bdb_cache_entryinfo_lock( e->bei_parent ); (gdb) p e->bei_parent $1 = (struct bdb_entry_info *) 0x0 (gdb) up #3 0x081430e5 in hdb_cache_lru_purge (bdb=0x82b6db8) at cache.c:749 749 bdb_cache_delete_internal( &bdb->bi_cache, elru, 0 ); (gdb) p *elru $2 = {bei_parent = 0x0, bei_id = 17, bei_lockpad = 0, bei_state = 0, bei_finders = 0, bei_nrdn = {bv_len = 24, bv_val = 0x0}, bei_rdn = {bv_len = 24, bv_val = 0x0}, bei_modrdns = 0, bei_ckids = 0, bei_dkids = 0, bei_e = 0x0, bei_kids = 0x0, bei_kids_mutex = {__data = {__lock = 1, __count = 0, __owner = 28050, __kind = 0, __nusers = 1, {__spins = 0, __list = {__next = 0x0}}}, __size = "\001\000\000\000\000\000\000\000\222m\000\000\000\000\000\000\001\000\000\000\000\000\000", __align = 1}, bei_lrunext = 0x83b5e70, bei_lruprev = 0x867b980} (gdb) p bdb->bi_cache.c_leaves $3 = 3737 (gdb) p eimax $4 = 2000 (gdb) p bdb->bi_cache $5 = {c_eifree = 0x8665b00, c_idtree = 0x9b322498, c_lruhead = 0x84017d8, c_lrutail = 0x867b980, c_dntree = {bei_parent = 0x0, bei_id = 0, bei_lockpad = 0, bei_state = 128, bei_finders = 0, bei_nrdn = {bv_len = 0, bv_val = 0x0}, bei_rdn = {bv_len = 0, bv_val = 0x0}, bei_modrdns = 0, bei_ckids = 1, bei_dkids = 2, bei_e = 0x8320704, bei_kids = 0x8320248, bei_kids_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __kind = 0, __nusers = 0, { __spins = 0, __list = {__next = 0x0}}}, __size = '\0' <repeats 23 times>, __align = 0}, bei_lrunext = 0x0, bei_lruprev = 0x0}, c_maxsize = 1000, c_cursize = 117171, c_minfree = 1, c_eimax = 2000, c_eiused = 3740, c_leaves = 3737, c_purging = 1, c_txn = 0x8320188, c_rwlock = {__data = {__lock = 0, __nr_readers = 0, __readers_wakeup = 8985, __writer_wakeup = 9500, __nr_readers_queued = 0, __nr_writers_queued = 0, __flags = 0 '\0', __shared = 0 '\0', __pad1 = 0 '\0', __pad2 = 0 '\0', __writer = 0}, __size = "\000\000\000\000\000\000\000\000\031#\000\000\034%", '\0' <repeats 17 times>, __align = 0}, c_lru_mutex = {__data = {__lock = 1, __count = 0, __owner = 28050, __kind = 0, __nusers = 1, {__spins = 0, __list = {__next = 0x0}}}, __size = "\001\000\000\000\000\000\000\000\222m\000\000\000\000\000\000\001\000\000\000\000\000\000", __align = 1}, c_count_mutex = {__data = { __lock = 0, __count = 0, __owner = 0, __kind = 0, __nusers = 0, {__spins = 0, __list = {__next = 0x0}}}, __size = '\0' <repeats 23 times>, __align = 0}, c_eifree_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __kind = 0, __nusers = 0, {__spins = 0, __list = {__next = 0x0}}}, __size = '\0' <repeats 23 times>, __align = 0}} If there's anything else you'd like me to print out, please let me know. thread apply all bt follows: Thread 10 (process 26366): #0 0xb7f18410 in __kernel_vsyscall () #1 0xb7dd2775 in pthread_join () from /lib/tls/i686/cmov/libpthread.so.0 #2 0x0817be19 in ldap_pvt_thread_join (thread=2730888080, thread_return=0x0) at thr_posix.c:197 #3 0x0806bca3 in slapd_daemon () at daemon.c:2740 #4 0x0804e8c7 in main (argc=1, argv=0xbfc63124) at main.c:948 Thread 9 (process 26372): #0 0xb7f18410 in __kernel_vsyscall () #1 0xb7ba1676 in epoll_wait () from /lib/tls/i686/cmov/libc.so.6 #2 0x0806ae3a in slapd_daemon_task (ptr=0x0) at daemon.c:2366 #3 0xb7dd14fb in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #4 0xb7ba0e5e in clone () from /lib/tls/i686/cmov/libc.so.6 Thread 8 (process 26374): #0 0xb7f18410 in __kernel_vsyscall () #1 0xb7dd5aa5 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/i686/cmov/libpthread.so.0 #2 0x0817beae in ldap_pvt_thread_cond_wait (cond=0x829cb0c, mutex=0x829caf4) at thr_posix.c:277 #3 0x0817acac in ldap_int_thread_pool_wrapper (xpool=0x829caf0) at tpool.c:654 #4 0xb7dd14fb in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #5 0xb7ba0e5e in clone () from /lib/tls/i686/cmov/libc.so.6 Thread 7 (process 27916): #0 0xb7f18410 in __kernel_vsyscall () #1 0xb7dd5aa5 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/i686/cmov/libpthread.so.0 #2 0x0817beae in ldap_pvt_thread_cond_wait (cond=0x829cb0c, mutex=0x829caf4) at thr_posix.c:277 #3 0x0817acac in ldap_int_thread_pool_wrapper (xpool=0x829caf0) at tpool.c:654 #4 0xb7dd14fb in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #5 0xb7ba0e5e in clone () from /lib/tls/i686/cmov/libc.so.6 Thread 6 (process 28043): #0 0xb7f18410 in __kernel_vsyscall () #1 0xb7dd5aa5 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/i686/cmov/libpthread.so.0 #2 0x0817beae in ldap_pvt_thread_cond_wait (cond=0x829cb0c, mutex=0x829caf4) at thr_posix.c:277 #3 0x0817acac in ldap_int_thread_pool_wrapper (xpool=0x829caf0) at tpool.c:654 #4 0xb7dd14fb in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #5 0xb7ba0e5e in clone () from /lib/tls/i686/cmov/libc.so.6 Thread 5 (process 28044): #0 0xb7f18410 in __kernel_vsyscall () #1 0xb7dd5aa5 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/i686/cmov/libpthread.so.0 #2 0x0817beae in ldap_pvt_thread_cond_wait (cond=0x829cb0c, mutex=0x829caf4) at thr_posix.c:277 #3 0x0817acac in ldap_int_thread_pool_wrapper (xpool=0x829caf0) at tpool.c:654 #4 0xb7dd14fb in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #5 0xb7ba0e5e in clone () from /lib/tls/i686/cmov/libc.so.6 Thread 4 (process 28045): #0 0xb7f18410 in __kernel_vsyscall () #1 0xb7dd5aa5 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/i686/cmov/libpthread.so.0 #2 0x0817beae in ldap_pvt_thread_cond_wait (cond=0x829cb0c, mutex=0x829caf4) at thr_posix.c:277 #3 0x0817acac in ldap_int_thread_pool_wrapper (xpool=0x829caf0) at tpool.c:654 #4 0xb7dd14fb in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #5 0xb7ba0e5e in clone () from /lib/tls/i686/cmov/libc.so.6 Thread 3 (process 28046): #0 0xb7f18410 in __kernel_vsyscall () #1 0xb7dd5aa5 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/i686/cmov/libpthread.so.0 #2 0x0817beae in ldap_pvt_thread_cond_wait (cond=0x829cb0c, mutex=0x829caf4) at thr_posix.c:277 #3 0x0817acac in ldap_int_thread_pool_wrapper (xpool=0x829caf0) at tpool.c:654 #4 0xb7dd14fb in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #5 0xb7ba0e5e in clone () from /lib/tls/i686/cmov/libc.so.6 Thread 2 (process 28048): #0 0xb7f18410 in __kernel_vsyscall () #1 0xb7dd5aa5 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/i686/cmov/libpthread.so.0 #2 0x0817beae in ldap_pvt_thread_cond_wait (cond=0x829cb0c, mutex=0x829caf4) at thr_posix.c:277 #3 0x0817acac in ldap_int_thread_pool_wrapper (xpool=0x829caf0) at tpool.c:654 #4 0xb7dd14fb in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #5 0xb7ba0e5e in clone () from /lib/tls/i686/cmov/libc.so.6 Thread 1 (process 28050): #0 0xb7dd3540 in pthread_mutex_lock () from /lib/tls/i686/cmov/libpthread.so.0 #1 0x0817beef in ldap_pvt_thread_mutex_lock (mutex=0x34) at thr_posix.c:296 #2 0x08144215 in bdb_cache_delete_internal (cache=0x82b6df4, e=0x84017d8, decr=0) at cache.c:1335 #3 0x081430e5 in hdb_cache_lru_purge (bdb=0x82b6db8) at cache.c:749 #4 0x081438ba in hdb_cache_find_id (op=0x86c01d0, tid=0x86d0a30, id=1792, eip=0x9f6f1e68, flag=2, lock=0x9f6f1e00) at cache.c:1016 #5 0x08115c29 in hdb_search (op=0x86c01d0, rs=0x9f6f3100) at search.c:705 #6 0x080f179a in overlay_op_walk (op=0x86c01d0, rs=0x9f6f3100, which=op_search, oi=0x82d2b88, on=0x0) at backover.c:669 #7 0x080f19a2 in over_op_func (op=0x86c01d0, rs=0x9f6f3100, which=op_search) at backover.c:721 #8 0x080f1a46 in over_op_search (op=0x86c01d0, rs=0x9f6f3100) at backover.c:743 #9 0x080724ed in fe_op_search (op=0x86c01d0, rs=0x9f6f3100) at search.c:366 #10 0x08071e60 in do_search (op=0x86c01d0, rs=0x9f6f3100) at search.c:217 #11 0x0806eb44 in connection_operation (ctx=0x9f6f31f0, arg_v=0x86c01d0) at connection.c:1133 #12 0x0806f01e in connection_read_thread (ctx=0x9f6f31f0, argv=0x46) at connection.c:1259 #13 0x0817ad1f in ldap_int_thread_pool_wrapper (xpool=0x829caf0) at tpool.c:663 #14 0xb7dd14fb in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #15 0xb7ba0e5e in clone () from /lib/tls/i686/cmov/libc.so.6

1 0

Re: (ITS#6038) Write slapadd progress meter to stdout
by rein＠OpenLDAP.org 27 Mar '09

27 Mar '09

hyc(a)symas.com wrote: > Hallvard B Furuseth wrote: >> hyc(a)symas.com writes: >>> Just redirect stdin, and the meter will automatically turn itself off. >> It was stderr, not stdin - which after all can be the ldif. >> Stdout is better. >> > No, you misunderstand. > > Redirecting stderr (or stdout) merely sends the progress info to that > destination. Piping input on stdin will turn it off, so there's no progress > info to redirect. No, the code only enables the meter if stdout (was: stderr) is a tty, so redirecting it anywhere disables it. The meter was enabled both by "slapadd -l file" and "slapadd < file", but "cat file | slapadd" did disable it. IMHO not exactly an obvious way.. An option sounds more and more like the solution, what about "-m" for meter? Though I'm not sure whether I prefer that it should be enabled by default and the option disable it, or the other way around.. > Writing progress to stderr is the correct thing to do, because it's transient > info that isn't meant to be saved. Checking whether stdout is redirected or > not is fine, but writing progress info to stdout is not. For programs that produce real output (slapcat, ldapsearch) this might be true, but for those that don't (slapadd, slapd) I totally disagree. Stderr is for errors, not chatty progress or debug messages. I always hate it when the error messages gets burried in lots of noice. My preference is to have progress and debug messages on stdout, enabled by options or at least possible to disable by options. Real output must be possible to send to a file specified as argument, to separate it from the progress and debug noice. Stderr is for error messages, and possibly out-of-band messages. Rein

1 0

(ITS#6039) Windows sockets initialization and shutdown bugs in slapd
by test.007＠seznam.cz 27 Mar '09

27 Mar '09

Full_Name: Test Seven Version: 2.4.15 OS: Windows URL: Submission from: (NULL) (195.113.184.20) I'm afraid slapd won't run on Windows without the first half of the following patch. AppVerifier will choke on double tcp_close() without the second part. --- daemon.c.orig 2009-02-13 03:35:40.000000000 +0100 +++ daemon.c 2009-03-27 09:24:22.515625000 +0100 @@ -537,6 +537,7 @@ static struct slap_daemon { slap_daemon.sd_flags = (char *)(slapd_ws_sockets + dtblsize); \ slap_daemon.sd_rflags = slap_daemon.sd_flags + dtblsize; \ memset( slapd_ws_sockets, -1, dtblsize * sizeof(SOCKET) ); \ + memset(slap_daemon.sd_flags, 0, dtblsize); /* Don't forget to initialize this, used in slapd_add() called from slapd_daemon_task() */ \ slapd_ws_sockets[0] = wake_sds[0]; \ slapd_ws_sockets[1] = wake_sds[1]; \ wake_sds[0] = 0; \ @@ -1646,7 +1647,7 @@ slapd_daemon_destroy( void ) { connections_destroy(); #ifdef HAVE_WINSOCK - if ( wake_sds[1] != INVALID_SOCKET && wake_sds[1] != wake_sds[0] ) + if ( wake_sds[1] != INVALID_SOCKET && SLAP_FD2SOCK(wake_sds[1]) != SLAP_FD2SOCK(wake_sds[0]) ) #endif /* HAVE_WINSOCK */ tcp_close( SLAP_FD2SOCK(wake_sds[1]) ); #ifdef HAVE_WINSOCK

1 0

RE: (ITS#5919) URI syntaxe (ldap:///dc=my%2cdc=domaine)
by philippe.eychart＠informatique.gov.pf 26 Mar '09

26 Mar '09

"result waited" : sorry, I wanted to say "result such as hoped" ;-)

1 0

RE: (ITS#5919) URI syntaxe (ldap:///dc=my%2cdc=domaine)
by philippe.eychart＠informatique.gov.pf 26 Mar '09

26 Mar '09

Hi, So, no idea about how to save the result of a previous SRV request in the implementation of the weight notion according to the rfc 2782?... >From my part either :-( (perhaps, somewhere in the kernel?...) PE PS: About the patch, I use it for several weeks now and everything seems good : no bugg, functioning and result waited ;-)

1 0

Re: (ITS#6038) Write slapadd progress meter to stdout
by hyc＠symas.com 26 Mar '09

26 Mar '09

Hallvard B Furuseth wrote: > hyc(a)symas.com writes: >> Just redirect stdin, and the meter will automatically turn itself off. > > It was stderr, not stdin - which after all can be the ldif. > Stdout is better. > No, you misunderstand. Redirecting stderr (or stdout) merely sends the progress info to that destination. Piping input on stdin will turn it off, so there's no progress info to redirect. Writing progress to stderr is the correct thing to do, because it's transient info that isn't meant to be saved. Checking whether stdout is redirected or not is fine, but writing progress info to stdout is not. -- -- 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#6038) Write slapadd progress meter to stdout
by h.b.furuseth＠usit.uio.no 26 Mar '09

26 Mar '09

hyc(a)symas.com writes: > Just redirect stdin, and the meter will automatically turn itself off. It was stderr, not stdin - which after all can be the ldif. Stdout is better. -- Hallvard

1 0

Re: (ITS#6038) Write slapadd progress meter to stdout
by hyc＠symas.com 26 Mar '09

26 Mar '09

rein(a)OpenLDAP.org wrote: > Full_Name: Rein Tollevik > Version: CVS HEAD > OS: Irrelevant > URL: > Submission from: (NULL) (84.215.36.97) > Submitted by: rein > > > The slapadd progress meter is written to stderr, and the only way to get rid of > it is currently to redirect stderr. I don't want the meter in my small test > scripts, as it is not very useful on minimal input and clutters the test output. > It should be possible to disable the meter without loosing all error messages, > a fix that writes the meter to stdout instead is coming. > > Options to enable/disable the meter would be nice, but the obvious candidates -q > and -v are both occupied... Just redirect stdin, and the meter will automatically turn itself off. -- -- 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#6038) Write slapadd progress meter to stdout
by rein＠OpenLDAP.org 26 Mar '09

26 Mar '09

Full_Name: Rein Tollevik Version: CVS HEAD OS: Irrelevant URL: Submission from: (NULL) (84.215.36.97) Submitted by: rein The slapadd progress meter is written to stderr, and the only way to get rid of it is currently to redirect stderr. I don't want the meter in my small test scripts, as it is not very useful on minimal input and clutters the test output. It should be possible to disable the meter without loosing all error messages, a fix that writes the meter to stdout instead is coming. Options to enable/disable the meter would be nice, but the obvious candidates -q and -v are both occupied... Rein Tollevik Basefarm AS

1 0

(ITS#6037) errno in signal handlers
by h.b.furuseth＠usit.uio.no 26 Mar '09

26 Mar '09

Full_Name: Hallvard B Furuseth Version: HEAD, RE24 OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard Signal handlers slapd/daemon.c:slap_sig_shutdown()/slap_sig_wake() need to save/restore errno, since they call functions that can modify errno. And/or possibly they need sock_errno() - sock_errset() from ac/socket.h, since they use tcp_write()? I don't know if that's safe inside signal handlers, or if Windows itself saves/restores this code around signal handlers. slapd/main.c:wait4child() can loop forever after EINTR, since it checks for errno even when the waitpid returns 0. I don't know if there is a good reason it does that. Some of the commits have my name on them but I think I copied it from elsewhere. Anyway, I'm doing the minimal changes now: save/restore errno, and set errno=0 in each loop iteration instead of before the loop. Anyone with better ideas can take it from there.

1 0

Re: (ITS#6035) slapd requires restart after modifying olcAuthzRegexp
by ando＠sys-net.it 26 Mar '09

26 Mar '09

quanah(a)zimbra.com wrote: > --On Thursday, March 26, 2009 4:14 PM +0000 hyc(a)symas.com wrote: > >> This is a known limitation in authz regexp support. There are no plans >> to change this any time soon. > > Where's this limitation documented? What other parameters in the config > backend have the same flaw? We've certainly fixed this for a number of > other things. Indeed, it has been finally, although rather inelegantly, fixed in slapo-rwm(5), AFAIR. 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#6035) slapd requires restart after modifying olcAuthzRegexp
by quanah＠zimbra.com 26 Mar '09

26 Mar '09

--On Thursday, March 26, 2009 4:14 PM +0000 hyc(a)symas.com wrote: > This is a known limitation in authz regexp support. There are no plans > to change this any time soon. Where's this limitation documented? What other parameters in the config backend have the same flaw? We've certainly fixed this for a number of other things. I don't even see authz-regexp/olcAuthzRegexp mentioned in chapters 5 or 6 in the admin guide, and the man pages don't note this limitation. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6035) slapd requires restart after modifying olcAuthzRegexp
by hyc＠symas.com 26 Mar '09

26 Mar '09

This is a known limitation in authz regexp support. There are no plans to change this any time soon. On Thu, Mar 26, 2009 at 03:33:37AM +0000, dgbaley27(a)verizon.net wrote: > Full_Name: Matthew Monaco > Version: 2.4.11 > OS: GNU/Linux 2.6.27-7 (Ubuntu 8.10 Server JeOS) > URL: > Submission from: (NULL) (96.242.209.249) > > > After modifying existing olcAuthzRegexp and/or adding/removing additional > olcAuthzRegexp from cn=config, I needed to restart slapd for the changes to take > effect. > > I'm not sure if it matters but I was using ldapvi to do the modification. > > I can however, confirm that the changes immediately appeared in various other > ldap browsers (such as Apache Directory Studio).

1 0

(ITS#6036) Crash: UUIDNormalize doesn't clear output on error
by test.007＠seznam.cz 26 Mar '09

26 Mar '09

Full_Name: Test Seven Version: 2.4.15 OS: Windows URL: Submission from: (NULL) (195.39.55.20) --- schema_init.orig 2009-01-22 01:01:03.000000000 +0100 +++ schema_init.c 2009-03-26 15:12:15.578125000 +0100 @@ -2814,6 +2814,7 @@ UUIDNormalize( } else { slap_sl_free( normalized->bv_val, ctx ); + BER_BVZERO(normalized); return LDAP_INVALID_SYNTAX; } I encountered a crash in str2entry2() final cleanup. It turned out that it called ordered_value_normalize(), which called UUIDNormalize(), which left the value nonzero but already free-d.

1 0

(ITS#6035) slapd requires restart after modifying olcAuthzRegexp
by dgbaley27＠verizon.net 25 Mar '09

25 Mar '09

Full_Name: Matthew Monaco Version: 2.4.11 OS: GNU/Linux 2.6.27-7 (Ubuntu 8.10 Server JeOS) URL: Submission from: (NULL) (96.242.209.249) After modifying existing olcAuthzRegexp and/or adding/removing additional olcAuthzRegexp from cn=config, I needed to restart slapd for the changes to take effect. I'm not sure if it matters but I was using ldapvi to do the modification. I can however, confirm that the changes immediately appeared in various other ldap browsers (such as Apache Directory Studio).

1 0

Re: (ITS#6034) Assert failure - connection_state_closing / send_ldap_ber / slap_send_search_entry / syncprov_sendresp
by hyc＠symas.com 25 Mar '09

25 Mar '09

oskar(a)deckle.co.za wrote: > Full_Name: Oskar Pearson > Version: 2.4.15 > OS: Ubuntu hardy > URL: ftp://ftp.openldap.org/incoming/slapd-configs-qualica-1.tar.gz > Submission from: (NULL) (94.194.140.71) > > > This is the same machine as ITS #6033. Details included here for easy > reference: > > Openldap 2.4.15 (with no patches) was self-compiled with no patches > (CFLAGS="-ggdb3 -O0" ./configure), linked against standard OS libraries (ubuntu > hardy) for BDB etc. BDB is 4.6.21-6ubuntu1. Kernel is 2.6.24-19-server, libc is > libc6-i686/2.7-10ubuntu3. > > I do not have a debug log of this crash as it occurred on a live server, which > is too busy for that level of logging. I also do not have a replaceable > example. > I have core dumps and can print out whatever is necessary there - I appreciate > your time and help. This bug was fixed in CVS already and the fix will be out in 2.4.16 soon. The fix is already in RE24... > gdb --core=../core.29266 --directory=servers/slapd/ > --directory=servers/slapd/overlays servers/slapd/slapd > (gdb) bt > #0 0xb7ef8410 in __kernel_vsyscall () > #1 0xb7ad5085 in raise () from /lib/tls/i686/cmov/libc.so.6 > #2 0xb7ad6a01 in abort () from /lib/tls/i686/cmov/libc.so.6 > #3 0xb7ace10e in __assert_fail () from /lib/tls/i686/cmov/libc.so.6 > #4 0x0806d6c6 in connection_state_closing (c=0xb79c9644) at connection.c:686 > #5 0x08081bdd in send_ldap_ber (conn=0xb79c9644, ber=0xa143ab8c) at > result.c:147 > #6 0x08085b20 in slap_send_search_entry (op=0xa143ae38, rs=0xa143acdc) at > result.c:1246 > #7 0x0815dbcb in syncprov_sendresp (op=0xa143ae38, opc=0xa143adb8, > so=0x9ab66dc8, e=0xa143ade8, mode=1) at syncprov.c:825 > #8 0x0815df12 in syncprov_qplay (op=0xa143ae38, rtask=0x9b303110) at > syncprov.c:896 > #9 0x0815e1a7 in syncprov_qtask (ctx=0xa143b1f0, arg=0x9b303110) at > syncprov.c:959 > #10 0x0817a99b in ldap_int_thread_pool_wrapper (xpool=0x829baf0) at tpool.c:663 > #11 0xb7db14fb in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 > #12 0xb7b80e5e in clone () from /lib/tls/i686/cmov/libc.so.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#6033) Segmentation fault - somewhere below syncprov_matchops / test_filter
by oskar＠deckle.co.za 25 Mar '09

25 Mar '09

Hi Further to this - please note that we know the dbconfig values in the config files are tiny - we use a DB_CONFIG file to override those, created before the ldap database is initialised. On master: set_cachesize 0 268435456 1 set_lg_regionmax 262144 set_lg_bsize 2097152 set_lk_max_objects 5000 set_lk_max_locks 5000 set_lk_max_lockers 5000 On clients: set_cachesize 0 16777216 0 set_lk_max_objects 1500 set_lk_max_locks 1500 set_lk_max_lockers 1500 Oskar

1 0

Re: (ITS#6034) Assert failure - connection_state_closing / send_ldap_ber / slap_send_search_entry / syncprov_sendresp
by oskar＠deckle.co.za 25 Mar '09

25 Mar '09

Hi Further to this - please note that we know the dbconfig values in the config files are tiny - we use a DB_CONFIG file to override those, created before the ldap database is initialised. On master: set_cachesize 0 268435456 1 set_lg_regionmax 262144 set_lg_bsize 2097152 set_lk_max_objects 5000 set_lk_max_locks 5000 set_lk_max_lockers 5000 On clients: set_cachesize 0 16777216 0 set_lk_max_objects 1500 set_lk_max_locks 1500 set_lk_max_lockers 1500 Oskar

1 0

(ITS#6034) Assert failure - connection_state_closing / send_ldap_ber / slap_send_search_entry / syncprov_sendresp
by oskar＠deckle.co.za 25 Mar '09

25 Mar '09

Full_Name: Oskar Pearson Version: 2.4.15 OS: Ubuntu hardy URL: ftp://ftp.openldap.org/incoming/slapd-configs-qualica-1.tar.gz Submission from: (NULL) (94.194.140.71) This is the same machine as ITS #6033. Details included here for easy reference: Openldap 2.4.15 (with no patches) was self-compiled with no patches (CFLAGS="-ggdb3 -O0" ./configure), linked against standard OS libraries (ubuntu hardy) for BDB etc. BDB is 4.6.21-6ubuntu1. Kernel is 2.6.24-19-server, libc is libc6-i686/2.7-10ubuntu3. I do not have a debug log of this crash as it occurred on a live server, which is too busy for that level of logging. I also do not have a replaceable example. I have core dumps and can print out whatever is necessary there - I appreciate your time and help. If I've missed some important info, please let me know and I'll rectify asap. System overview: We have a master server which replicates to > 100 machines for Samba purposes across ADSL lines with a VPN. These lines are quite busy, so replication writes may be slow across the network, which may have implications for locks. Config files are included at the url below. gdb --core=../core.29266 --directory=servers/slapd/ --directory=servers/slapd/overlays servers/slapd/slapd (gdb) bt #0 0xb7ef8410 in __kernel_vsyscall () #1 0xb7ad5085 in raise () from /lib/tls/i686/cmov/libc.so.6 #2 0xb7ad6a01 in abort () from /lib/tls/i686/cmov/libc.so.6 #3 0xb7ace10e in __assert_fail () from /lib/tls/i686/cmov/libc.so.6 #4 0x0806d6c6 in connection_state_closing (c=0xb79c9644) at connection.c:686 #5 0x08081bdd in send_ldap_ber (conn=0xb79c9644, ber=0xa143ab8c) at result.c:147 #6 0x08085b20 in slap_send_search_entry (op=0xa143ae38, rs=0xa143acdc) at result.c:1246 #7 0x0815dbcb in syncprov_sendresp (op=0xa143ae38, opc=0xa143adb8, so=0x9ab66dc8, e=0xa143ade8, mode=1) at syncprov.c:825 #8 0x0815df12 in syncprov_qplay (op=0xa143ae38, rtask=0x9b303110) at syncprov.c:896 #9 0x0815e1a7 in syncprov_qtask (ctx=0xa143b1f0, arg=0x9b303110) at syncprov.c:959 #10 0x0817a99b in ldap_int_thread_pool_wrapper (xpool=0x829baf0) at tpool.c:663 #11 0xb7db14fb in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #12 0xb7b80e5e in clone () from /lib/tls/i686/cmov/libc.so.6 (gdb) frame 4 #4 0x0806d6c6 in connection_state_closing (c=0xb79c9644) at connection.c:686 686 assert( c->c_struct_state == SLAP_C_USED ); (gdb) p c->c_struct_state $1 = 1 # maps to SLAP_C_UNUSED (gdb) p *c $4 = {c_struct_state = 1, c_conn_state = 0, c_conn_idx = 107, c_sd = -1, c_close_reason = 0x81b647b "?", c_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __kind = 0, __nusers = 0, {__spins = 0, __list = {__next = 0x0}}}, __size = '\0' <repeats 23 times>, __align = 0}, c_sb = 0x838c1b8, c_starttime = 0, c_activitytime = 0, c_connid = 4294967295, c_peer_domain = {bv_len = 0, bv_val = 0x0}, c_peer_name = {bv_len = 0, bv_val = 0x0}, c_listener = 0x0, 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 = 128, 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 = 0xb79c96e4}, c_pending_ops = {stqh_first = 0x0, stqh_last = 0xb79c96ec}, c_write1_mutex = {__data = {__lock = 1, __count = 0, __owner = 29297, __kind = 0, __nusers = 1, {__spins = 0, __list = {__next = 0x0}}}, __size = "\001\000\000\000\000\000\000\000qr\000\000\000\000\000\000\001\000\000\000\000\000\000", __align = 1}, c_write1_cv = {__data = {__lock = 0, __futex = 0, __total_seq = 0, __wakeup_seq = 0, __woken_seq = 0, __mutex = 0x0, __nwaiters = 0, __broadcast_seq = 0}, __size = '\0' <repeats 47 times>, __align = 0}, c_write2_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __kind = 0, __nusers = 0, { __spins = 0, __list = {__next = 0x0}}}, __size = '\0' <repeats 23 times>, __align = 0}, c_write2_cv = {__data = {__lock = 0, __futex = 0, __total_seq = 0, __wakeup_seq = 0, __woken_seq = 0, __mutex = 0x0, __nwaiters = 0, __broadcast_seq = 0}, __size = '\0' <repeats 47 times>, __align = 0}, c_currentber = 0x0, c_writers = 0, c_sasl_bind_in_progress = 0 '\0', c_writewaiter = 0 '\0', c_is_tls = 0 '\0', c_needs_tls_accept = 0 '\0', c_sasl_layers = 0 '\0', c_sasl_done = 0 '\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_count = 0, ps_cookie = 0, ps_cookieval = {bv_len = 0, bv_val = 0x0}}, c_n_ops_received = 2, c_n_ops_executing = 0, c_n_ops_pending = 0, c_n_ops_completed = 2, c_n_get = 3, c_n_read = 2, c_n_write = 0, c_extensions = 0x0, c_clientfunc = 0, c_clientarg = 0x0, c_send_ldap_result = 0x8082e44 <slap_send_ldap_result>, c_send_search_entry = 0x8083b12 <slap_send_search_entry>, c_send_search_reference = 0x8085e4b <slap_send_search_reference>, c_send_ldap_extended = 0x8083676 <slap_send_ldap_extended>, c_send_ldap_intermediate = 0x80838fe <slap_send_ldap_intermediate>} frame 6 is the first location I have "op" access, so I then went (gdb) frame 6 (gdb) p *op $10 = {o_hdr = 0xa143af10, o_tag = 99, o_time = 1236686741, o_tincr = 0, o_bd = 0xa143b0b8, o_req_dn = {bv_len = 18, bv_val = 0x9dcd15ee "dc=HIDDEN-gw,dc=com"}, o_req_ndn = {bv_len = 18, bv_val = 0x9dcd1601 "dc=HIDDEN-gw,dc=com"}, o_request = {oq_add = { rs_modlist = 0x2, rs_e = 0x0}, oq_bind = {rb_method = 2, rb_cred = {bv_len = 0, bv_val = 0xffffffff <Address 0xffffffff out of bounds>}, rb_edn = { bv_len = 4294967295, bv_val = 0x0}, rb_ssf = 0, rb_mech = {bv_len = 2647463064, bv_val = 0x9dc1bbe8 "\207"}}, oq_compare = {rs_ava = 0x2}, oq_modify = {rs_mods = {rs_modlist = 0x2, rs_no_opattrs = 0 '\0'}, rs_increment = -1}, oq_modrdn = {rs_mods = {rs_modlist = 0x2, rs_no_opattrs = 0 '\0'}, rs_deleteoldrdn = -1, rs_newrdn = {bv_len = 4294967295, bv_val = 0x0}, rs_nnewrdn = {bv_len = 0, bv_val = 0x9dcd1498 "\t"}, rs_newSup = 0x9dc1bbe8, rs_nnewSup = 0xf}, oq_search = {rs_scope = 2, rs_deref = 0, rs_slimit = -1, rs_tlimit = -1, rs_limit = 0x0, rs_attrsonly = 0, rs_attrs = 0x9dcd1498, rs_filter = 0x9dc1bbe8, rs_filterstr = {bv_len = 15, bv_val = 0x9dcd1614 "(objectClass=*)"}}, oq_abandon = {rs_msgid = 2}, oq_cancel = {rs_msgid = 2}, oq_extended = {rs_reqoid = {bv_len = 2, bv_val = 0x0}, rs_flags = -1, rs_reqdata = 0xffffffff}, oq_pwdexop = {rs_extended = {rs_reqoid = {bv_len = 2, bv_val = 0x0}, rs_flags = -1, rs_reqdata = 0xffffffff}, rs_old = {bv_len = 0, bv_val = 0x0}, rs_new = {bv_len = 2647463064, bv_val = 0x9dc1bbe8 "\207"}, rs_mods = 0xf, rs_modtail = 0x9dcd1614}}, o_abandon = 0, o_cancel = 0, o_groups = 0x0, o_do_not_cache = 1 '\001', o_is_auth_check = 0 '\0', o_dont_replicate = 0 '\0', o_acl_priv = ACL_NONE, o_nocaching = 0 '\0', o_delete_glue_parent = 0 '\0', o_no_schema_check = 0 '\0', o_no_subordinate_glue = 0 '\0', o_ctrlflag = '\0' <repeats 31 times>, o_controls = 0xa143b038, o_authz = {sai_method = 128, sai_mech = {bv_len = 0, bv_val = 0x0}, sai_dn = {bv_len = 27, bv_val = 0x9dcd15d2 "cn=admin,dc=HIDDEN-gw,dc=com"}, sai_ndn = {bv_len = 27, bv_val = 0x9dcd15d2 "cn=admin,dc=HIDDEN-gw,dc=com"}, sai_ssf = 0, sai_transport_ssf = 0, sai_tls_ssf = 0, sai_sasl_ssf = 0}, o_ber = 0x0, o_res_ber = 0x0, o_callback = 0x0, o_ctrls = 0x0, o_csn = {bv_len = 0, bv_val = 0x0}, o_private = 0x0, o_extra = {slh_first = 0x0}, o_next = { stqe_next = 0x0}} Full backtrace: Thread 10 (process 29266): #0 0xb7ef8410 in __kernel_vsyscall () #1 0xb7db2775 in pthread_join () from /lib/tls/i686/cmov/libpthread.so.0 #2 0x0817ba95 in ldap_pvt_thread_join (thread=2730757008, thread_return=0x0) at thr_posix.c:197 #3 0x0806ba57 in slapd_daemon () at daemon.c:2665 #4 0x0804e8c7 in main (argc=1, argv=0xbfe1d2e4) at main.c:948 Thread 9 (process 29268): #0 0xb7ef8410 in __kernel_vsyscall () #1 0xb7b81676 in epoll_wait () from /lib/tls/i686/cmov/libc.so.6 #2 0x0806abee in slapd_daemon_task (ptr=0x0) at daemon.c:2291 #3 0xb7db14fb in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #4 0xb7b80e5e in clone () from /lib/tls/i686/cmov/libc.so.6 Thread 8 (process 29269): #0 0xb7ef8410 in __kernel_vsyscall () #1 0xb7db5aa5 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/i686/cmov/libpthread.so.0 #2 0x0817bb2a in ldap_pvt_thread_cond_wait (cond=0xb79ccf88, mutex=0xb79ccf70) at thr_posix.c:277 #3 0x08081eac in send_ldap_ber (conn=0xb79cce78, ber=0xa203db8c) at result.c:217 #4 0x08085b20 in slap_send_search_entry (op=0xa203de38, rs=0xa203dcdc) at result.c:1246 #5 0x0815dbcb in syncprov_sendresp (op=0xa203de38, opc=0xa203ddb8, so=0x9dc65f10, e=0xa203dde8, mode=1) at syncprov.c:825 #6 0x0815df12 in syncprov_qplay (op=0xa203de38, rtask=0x9b30c640) at syncprov.c:896 #7 0x0815e1a7 in syncprov_qtask (ctx=0xa203e1f0, arg=0x9b30c640) at syncprov.c:959 #8 0x0817a99b in ldap_int_thread_pool_wrapper (xpool=0x829baf0) at tpool.c:663 #9 0xb7db14fb in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #10 0xb7b80e5e in clone () from /lib/tls/i686/cmov/libc.so.6 Thread 7 (process 29295): #0 0xb7ef8410 in __kernel_vsyscall () #1 0xb7db5aa5 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/i686/cmov/libpthread.so.0 #2 0x0817bb2a in ldap_pvt_thread_cond_wait (cond=0xb79ce090, mutex=0xb79ce078) at thr_posix.c:277 #3 0x08081eac in send_ldap_ber (conn=0xb79cdf80, ber=0xa1c3cb8c) at result.c:217 #4 0x08085b20 in slap_send_search_entry (op=0xa1c3ce38, rs=0xa1c3ccdc) at result.c:1246 #5 0x0815dbcb in syncprov_sendresp (op=0xa1c3ce38, opc=0xa1c3cdb8, so=0x9ab8ecd8, e=0xa1c3cde8, mode=1) at syncprov.c:825 #6 0x0815df12 in syncprov_qplay (op=0xa1c3ce38, rtask=0x9af477a8) at syncprov.c:896 #7 0x0815e1a7 in syncprov_qtask (ctx=0xa1c3d1f0, arg=0x9af477a8) at syncprov.c:959 #8 0x0817a99b in ldap_int_thread_pool_wrapper (xpool=0x829baf0) at tpool.c:663 #9 0xb7db14fb in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #10 0xb7b80e5e in clone () from /lib/tls/i686/cmov/libc.so.6 Thread 6 (process 29296): #0 0xb7ef8410 in __kernel_vsyscall () #1 0xb7db5aa5 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/i686/cmov/libpthread.so.0 #2 0x0817bb2a in ldap_pvt_thread_cond_wait (cond=0xb79cf500, mutex=0xb79cf4e8) at thr_posix.c:277 #3 0x08081eac in send_ldap_ber (conn=0xb79cf3f0, ber=0xa183bb8c) at result.c:217 #4 0x08085b20 in slap_send_search_entry (op=0xa183be38, rs=0xa183bcdc) at result.c:1246 #5 0x0815dbcb in syncprov_sendresp (op=0xa183be38, opc=0xa183bdb8, so=0xa0ae45c8, e=0xa183bde8, mode=1) at syncprov.c:825 #6 0x0815df12 in syncprov_qplay (op=0xa183be38, rtask=0x9ab5e400) at syncprov.c:896 #7 0x0815e1a7 in syncprov_qtask (ctx=0xa183c1f0, arg=0x9ab5e400) at syncprov.c:959 #8 0x0817a99b in ldap_int_thread_pool_wrapper (xpool=0x829baf0) at tpool.c:663 #9 0xb7db14fb in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #10 0xb7b80e5e in clone () from /lib/tls/i686/cmov/libc.so.6 Thread 5 (process 29298): #0 0xb7ef8410 in __kernel_vsyscall () #1 0xb7db5aa5 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/i686/cmov/libpthread.so.0 #2 0x0817bb2a in ldap_pvt_thread_cond_wait (cond=0xb79c8d1c, mutex=0xb79c8d04) at thr_posix.c:277 #3 0x08081eac in send_ldap_ber (conn=0xb79c8c0c, ber=0xa1039b8c) at result.c:217 #4 0x08085b20 in slap_send_search_entry (op=0xa1039e38, rs=0xa1039cdc) at result.c:1246 #5 0x0815dbcb in syncprov_sendresp (op=0xa1039e38, opc=0xa1039db8, so=0x9dc0bed0, e=0xa1039de8, mode=2) at syncprov.c:825 #6 0x0815df12 in syncprov_qplay (op=0xa1039e38, rtask=0x83781c8) at syncprov.c:896 #7 0x0815e1a7 in syncprov_qtask (ctx=0xa103a1f0, arg=0x83781c8) at syncprov.c:959 #8 0x0817a99b in ldap_int_thread_pool_wrapper (xpool=0x829baf0) at tpool.c:663 #9 0xb7db14fb in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #10 0xb7b80e5e in clone () from /lib/tls/i686/cmov/libc.so.6 Thread 4 (process 29300): #0 0xb7ef8410 in __kernel_vsyscall () #1 0xb7db5aa5 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/i686/cmov/libpthread.so.0 #2 0x0817bb2a in ldap_pvt_thread_cond_wait (cond=0xb79cefe4, mutex=0xb79cefcc) at thr_posix.c:277 #3 0x08081eac in send_ldap_ber (conn=0xb79ceed4, ber=0x9dbfeb8c) at result.c:217 #4 0x08085b20 in slap_send_search_entry (op=0x9dbfee38, rs=0x9dbfecdc) at result.c:1246 #5 0x0815dbcb in syncprov_sendresp (op=0x9dbfee38, opc=0x9dbfedb8, so=0x9ab63788, e=0x9dbfede8, mode=1) at syncprov.c:825 #6 0x0815df12 in syncprov_qplay (op=0x9dbfee38, rtask=0xa0a03b60) at syncprov.c:896 #7 0x0815e1a7 in syncprov_qtask (ctx=0x9dbff1f0, arg=0xa0a03b60) at syncprov.c:959 #8 0x0817a99b in ldap_int_thread_pool_wrapper (xpool=0x829baf0) at tpool.c:663 #9 0xb7db14fb in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #10 0xb7b80e5e in clone () from /lib/tls/i686/cmov/libc.so.6 Thread 3 (process 29301): #0 0xb7ef8410 in __kernel_vsyscall () #1 0xb7db5aa5 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/i686/cmov/libpthread.so.0 #2 0x0817bb2a in ldap_pvt_thread_cond_wait (cond=0xb79bfaa4, mutex=0xb79bfa8c) at thr_posix.c:277 #3 0x08081eac in send_ldap_ber (conn=0xb79bf994, ber=0x9cefbb8c) at result.c:217 #4 0x08085b20 in slap_send_search_entry (op=0x9cefbe38, rs=0x9cefbcdc) at result.c:1246 #5 0x0815dbcb in syncprov_sendresp (op=0x9cefbe38, opc=0x9cefbdb8, so=0x9af1df00, e=0x9cefbde8, mode=1) at syncprov.c:825 #6 0x0815df12 in syncprov_qplay (op=0x9cefbe38, rtask=0xa0a33d90) at syncprov.c:896 #7 0x0815e1a7 in syncprov_qtask (ctx=0x9cefc1f0, arg=0xa0a33d90) at syncprov.c:959 #8 0x0817a99b in ldap_int_thread_pool_wrapper (xpool=0x829baf0) at tpool.c:663 #9 0xb7db14fb in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #10 0xb7b80e5e in clone () from /lib/tls/i686/cmov/libc.so.6 Thread 2 (process 29302): #0 0xb7ef8410 in __kernel_vsyscall () #1 0xb7db5aa5 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/i686/cmov/libpthread.so.0 #2 0x0817bb2a in ldap_pvt_thread_cond_wait (cond=0xb79cb0e0, mutex=0xb79cb0c8) at thr_posix.c:277 #3 0x08081eac in send_ldap_ber (conn=0xb79cafd0, ber=0x9cafab8c) at result.c:217 #4 0x08085b20 in slap_send_search_entry (op=0x9cafae38, rs=0x9cafacdc) at result.c:1246 #5 0x0815dbcb in syncprov_sendresp (op=0x9cafae38, opc=0x9cafadb8, so=0x9af21c10, e=0x9cafade8, mode=1) at syncprov.c:825 #6 0x0815df12 in syncprov_qplay (op=0x9cafae38, rtask=0xa0a31988) at syncprov.c:896 #7 0x0815e1a7 in syncprov_qtask (ctx=0x9cafb1f0, arg=0xa0a31988) at syncprov.c:959 #8 0x0817a99b in ldap_int_thread_pool_wrapper (xpool=0x829baf0) at tpool.c:663 #9 0xb7db14fb in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #10 0xb7b80e5e in clone () from /lib/tls/i686/cmov/libc.so.6 Thread 1 (process 29297): #0 0xb7ef8410 in __kernel_vsyscall () #1 0xb7ad5085 in raise () from /lib/tls/i686/cmov/libc.so.6 #2 0xb7ad6a01 in abort () from /lib/tls/i686/cmov/libc.so.6 #3 0xb7ace10e in __assert_fail () from /lib/tls/i686/cmov/libc.so.6 #4 0x0806d6c6 in connection_state_closing (c=0xb79c9644) at connection.c:686 #5 0x08081bdd in send_ldap_ber (conn=0xb79c9644, ber=0xa143ab8c) at result.c:147 #6 0x08085b20 in slap_send_search_entry (op=0xa143ae38, rs=0xa143acdc) at result.c:1246 #7 0x0815dbcb in syncprov_sendresp (op=0xa143ae38, opc=0xa143adb8, so=0x9ab66dc8, e=0xa143ade8, mode=1) at syncprov.c:825 #8 0x0815df12 in syncprov_qplay (op=0xa143ae38, rtask=0x9b303110) at syncprov.c:896 #9 0x0815e1a7 in syncprov_qtask (ctx=0xa143b1f0, arg=0x9b303110) at syncprov.c:959 #10 0x0817a99b in ldap_int_thread_pool_wrapper (xpool=0x829baf0) at tpool.c:663 #11 0xb7db14fb in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #12 0xb7b80e5e in clone () from /lib/tls/i686/cmov/libc.so.6 Thanks for your time! Oskar

1 0

(ITS#6033) Segmentation fault - somewhere below syncprov_matchops / test_filter
by oskar＠deckle.co.za 25 Mar '09

25 Mar '09

Full_Name: Oskar Pearson Version: 2.4.15 OS: Ubuntu hardy URL: ftp://ftp.openldap.org/incoming/slapd-configs-qualica-1.tar.gz Submission from: (NULL) (94.194.140.71) Openldap 2.4.15 (with no patches) was self-compiled with no patches (CFLAGS="-ggdb3 -O0" ./configure), linked against standard OS libraries (ubuntu hardy) for BDB etc. BDB is 4.6.21-6ubuntu1. Kernel is 2.6.24-19-server, libc is libc6-i686/2.7-10ubuntu3. I do not have a debug log of this crash as it occurred on a live server, which is too busy for that level of logging. I also do not have a replaceable example. I have core dumps and can print out whatever is necessary there - I appreciate your time and help. If I've missed some important info, please let me know and I'll rectify asap. System overview: We have a master server which replicates to > 100 machines for Samba purposes across ADSL lines with a VPN. These lines are quite busy, so replication writes may be slow across the network, which may have implications for locks. Config files are included at the url below. The specific crash was in thread 1. Other threads are included in a full backtrace below. gdb --core=../core.24122 --directory=servers/slapd/ --directory=servers/slapd/overlays servers/slapd/slapd #0 0x080c0e82 in is_ad_subtype (sub=0x0, super=0x8294e08) at ad.c:502 502 for ( a = sub->ad_type; a; a=a->sat_sup ) { Thread 1 (process 24208): #0 0x080c0e82 in is_ad_subtype (sub=0x0, super=0x8294e08) at ad.c:502 #1 0x0807a6da in attrs_find (a=0xa2d39fa4, desc=0x8294e08) at attr.c:645 #2 0x080964dd in test_presence_filter (op=0x9e6f1b08, e=0x83277f4, desc=0x8294e08) at filterentry.c:848 #3 0x080951ce in test_filter (op=0x9e6f1b08, e=0x83277f4, f=0x9ae022a8) at filterentry.c:108 #4 0x0815efdf in syncprov_matchops (op=0x83455c8, opc=0x9cfed214, saveit=1) at syncprov.c:1251 #5 0x08160fd9 in syncprov_op_mod (op=0x83455c8, rs=0x9e6f3100) at syncprov.c:1905 #6 0x080f1396 in overlay_op_walk (op=0x83455c8, rs=0x9e6f3100, which=op_modify, oi=0x82d19c8, on=0x82d1ac8) at backover.c:659 #7 0x080f161e in over_op_func (op=0x83455c8, rs=0x9e6f3100, which=op_modify) at backover.c:721 #8 0x080f1706 in over_op_modify (op=0x83455c8, rs=0x9e6f3100) at backover.c:755 #9 0x0808c802 in fe_op_modify (op=0x83455c8, rs=0x9e6f3100) at modify.c:301 #10 0x0808c115 in do_modify (op=0x83455c8, rs=0x9e6f3100) at modify.c:175 #11 0x0806e7c2 in connection_operation (ctx=0x9e6f31f0, arg_v=0x83455c8) at connection.c:1097 #12 0x0806ec9c in connection_read_thread (ctx=0x9e6f31f0, argv=0x39) at connection.c:1223 #13 0x0817a99b in ldap_int_thread_pool_wrapper (xpool=0x829baf0) at tpool.c:663 #14 0xb7da14fb in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #15 0xb7b70e5e in clone () from /lib/tls/i686/cmov/libc.so.6 (gdb) p sub $15 = (AttributeDescription *) 0x0 (gdb) up #1 0x0807a6da in attrs_find (a=0xa2d39fa4, desc=0x8294e08) at attr.c:645 645 if ( is_ad_subtype( a->a_desc, desc ) ) { (gdb) p *a $24 = {a_desc = 0x0, a_vals = 0x0, a_nvals = 0x0, a_numvals = 0, a_flags = 0, a_next = 0xa2d39d1c} (gdb) p *desc $32 = {ad_next = 0x0, ad_type = 0x8294d30, ad_cname = {bv_len = 11, bv_val = 0x8294ca8 "objectClass"}, ad_tags = {bv_len = 0, bv_val = 0x0}, ad_flags = 0} (gdb) p *op $33 = {o_hdr = 0x9e6f18e8, o_tag = 99, o_time = 1236840350, o_tincr = 0, o_bd = 0x82b5af8, o_req_dn = {bv_len = 18, bv_val = 0x9ae0360e "dc=HIDDEN-gw,dc=com"}, o_req_ndn = {bv_len = 18, bv_val = 0x9ae03621 "dc=HIDDEN-gw,dc=com"}, o_request = {oq_add = { rs_modlist = 0x2, rs_e = 0x0}, oq_bind = {rb_method = 2, rb_cred = {bv_len = 0, bv_val = 0xffffffff <Address 0xffffffff out of bounds>}, rb_edn = { bv_len = 4294967295, bv_val = 0x0}, rb_ssf = 0, rb_mech = {bv_len = 2598384824, bv_val = 0x9ae022a8 "\207"}}, oq_compare = {rs_ava = 0x2}, oq_modify = {rs_mods = {rs_modlist = 0x2, rs_no_opattrs = 0 '\0'}, rs_increment = -1}, oq_modrdn = {rs_mods = {rs_modlist = 0x2, rs_no_opattrs = 0 '\0'}, rs_deleteoldrdn = -1, rs_newrdn = {bv_len = 4294967295, bv_val = 0x0}, rs_nnewrdn = {bv_len = 0, bv_val = 0x9ae034b8 "\t"}, rs_newSup = 0x9ae022a8, rs_nnewSup = 0xf}, oq_search = {rs_scope = 2, rs_deref = 0, rs_slimit = -1, rs_tlimit = -1, rs_limit = 0x0, rs_attrsonly = 0, rs_attrs = 0x9ae034b8, rs_filter = 0x9ae022a8, rs_filterstr = {bv_len = 15, bv_val = 0x9ae03634 "(objectClass=*)"}}, oq_abandon = {rs_msgid = 2}, oq_cancel = {rs_msgid = 2}, oq_extended = {rs_reqoid = {bv_len = 2, bv_val = 0x0}, rs_flags = -1, rs_reqdata = 0xffffffff}, oq_pwdexop = {rs_extended = {rs_reqoid = {bv_len = 2, bv_val = 0x0}, rs_flags = -1, rs_reqdata = 0xffffffff}, rs_old = {bv_len = 0, bv_val = 0x0}, rs_new = {bv_len = 2598384824, bv_val = 0x9ae022a8 "\207"}, rs_mods = 0xf, rs_modtail = 0x9ae03634}}, o_abandon = 0, o_cancel = 0, o_groups = 0x0, o_do_not_cache = 1 '\001', o_is_auth_check = 0 '\0', o_dont_replicate = 0 '\0', o_acl_priv = ACL_NONE, o_nocaching = 0 '\0', o_delete_glue_parent = 0 '\0', o_no_schema_check = 0 '\0', o_no_subordinate_glue = 0 '\0', o_ctrlflag = '\0' <repeats 31 times>, o_controls = 0x0, o_authz = {sai_method = 128, sai_mech = {bv_len = 0, bv_val = 0x0}, sai_dn = {bv_len = 27, bv_val = 0x9ae035f2 "cn=admin,dc=HIDDEN-gw,dc=com"}, sai_ndn = {bv_len = 27, bv_val = 0x9ae035f2 "cn=admin,dc=HIDDEN-gw,dc=com"}, sai_ssf = 0, sai_transport_ssf = 0, sai_tls_ssf = 0, sai_sasl_ssf = 0}, o_ber = 0x0, o_res_ber = 0x0, o_callback = 0x0, o_ctrls = 0x0, o_csn = {bv_len = 0, bv_val = 0x0}, o_private = 0x0, o_extra = {slh_first = 0x9cfed24c}, o_next = { stqe_next = 0x0}} (gdb) p *e $34 = {e_id = 0, e_name = {bv_len = 39, bv_val = 0x0}, e_nname = {bv_len = 39, bv_val = 0x0}, e_attrs = 0x0, e_ocflags = 0, e_bv = {bv_len = 0, bv_val = 0x0}, e_private = 0x83277a4} (gdb) p *desc $35 = {ad_next = 0x0, ad_type = 0x8294d30, ad_cname = {bv_len = 11, bv_val = 0x8294ca8 "objectClass"}, ad_tags = {bv_len = 0, bv_val = 0x0}, ad_flags = 0} --- full backtrace follows: thread apply all bt Thread 10 (process 24122): #0 0xb7ee8410 in __kernel_vsyscall () #1 0xb7da2775 in pthread_join () from /lib/tls/i686/cmov/libpthread.so.0 #2 0x0817ba95 in ldap_pvt_thread_join (thread=2730691472, thread_return=0x0) at thr_posix.c:197 #3 0x0806ba57 in slapd_daemon () at daemon.c:2665 #4 0x0804e8c7 in main (argc=1, argv=0xbffcccc4) at main.c:948 Thread 9 (process 24127): #0 0xb7ee8410 in __kernel_vsyscall () #1 0xb7b71676 in epoll_wait () from /lib/tls/i686/cmov/libc.so.6 #2 0x0806abee in slapd_daemon_task (ptr=0x0) at daemon.c:2291 #3 0xb7da14fb in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #4 0xb7b70e5e in clone () from /lib/tls/i686/cmov/libc.so.6 Thread 8 (process 24128): #0 0xb7ee8410 in __kernel_vsyscall () #1 0xb7da5aa5 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/i686/cmov/libpthread.so.0 #2 0x0817bb2a in ldap_pvt_thread_cond_wait (cond=0xb79af8f0, mutex=0xb79af8d8) at thr_posix.c:277 #3 0x08081eac in send_ldap_ber (conn=0xb79af7e0, ber=0xa202db8c) at result.c:217 #4 0x08085b20 in slap_send_search_entry (op=0xa202de38, rs=0xa202dcdc) at result.c:1246 #5 0x0815dbcb in syncprov_sendresp (op=0xa202de38, opc=0xa202ddb8, so=0xa1bb3490, e=0xa202dde8, mode=2) at syncprov.c:825 #6 0x0815df12 in syncprov_qplay (op=0xa202de38, rtask=0x9ae030b8) at syncprov.c:896 #7 0x0815e1a7 in syncprov_qtask (ctx=0xa202e1f0, arg=0x9ae030b8) at syncprov.c:959 #8 0x0817a99b in ldap_int_thread_pool_wrapper (xpool=0x829baf0) at tpool.c:663 #9 0xb7da14fb in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #10 0xb7b70e5e in clone () from /lib/tls/i686/cmov/libc.so.6 Thread 7 (process 24169): #0 0xb7ee8410 in __kernel_vsyscall () #1 0xb7da5aa5 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/i686/cmov/libpthread.so.0 #2 0x0817bb2a in ldap_pvt_thread_cond_wait (cond=0xb79b6958, mutex=0xb79b6940) at thr_posix.c:277 #3 0x08081eac in send_ldap_ber (conn=0xb79b6848, ber=0xa1afeb8c) at result.c:217 #4 0x08085b20 in slap_send_search_entry (op=0xa1afee38, rs=0xa1afecdc) at result.c:1246 #5 0x0815dbcb in syncprov_sendresp (op=0xa1afee38, opc=0xa1afedb8, so=0x8a0deb0, e=0xa1afede8, mode=2) at syncprov.c:825 #6 0x0815df12 in syncprov_qplay (op=0xa1afee38, rtask=0x8a12e20) at syncprov.c:896 #7 0x0815e1a7 in syncprov_qtask (ctx=0xa1aff1f0, arg=0x8a12e20) at syncprov.c:959 #8 0x0817a99b in ldap_int_thread_pool_wrapper (xpool=0x829baf0) at tpool.c:663 #9 0xb7da14fb in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #10 0xb7b70e5e in clone () from /lib/tls/i686/cmov/libc.so.6 Thread 3 (process 24209): #0 0xb7ee8410 in __kernel_vsyscall () #1 0xb7da5aa5 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/i686/cmov/libpthread.so.0 #2 0x0817bb2a in ldap_pvt_thread_cond_wait (cond=0xb79b28a0, mutex=0xb79b2888) at thr_posix.c:277 #3 0x08081eac in send_ldap_ber (conn=0xb79b2790, ber=0x9d9efb8c) at result.c:217 #4 0x08085b20 in slap_send_search_entry (op=0x9d9efe38, rs=0x9d9efcdc) at result.c:1246 #5 0x0815dbcb in syncprov_sendresp (op=0x9d9efe38, opc=0x9d9efdb8, so=0x8a01da0, e=0x9d9efde8, mode=2) at syncprov.c:825 #6 0x0815df12 in syncprov_qplay (op=0x9d9efe38, rtask=0x9ad957e0) at syncprov.c:896 #7 0x0815e1a7 in syncprov_qtask (ctx=0x9d9f01f0, arg=0x9ad957e0) at syncprov.c:959 #8 0x0817a99b in ldap_int_thread_pool_wrapper (xpool=0x829baf0) at tpool.c:663 #9 0xb7da14fb in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #10 0xb7b70e5e in clone () from /lib/tls/i686/cmov/libc.so.6 Thread 2 (process 24210): #0 0xb7b0d9bc in memcpy () from /lib/tls/i686/cmov/libc.so.6 #1 0xb7e7e6cd in __db_retcopy () from /usr/lib/libdb-4.6.so #2 0xb7e7e80b in __db_ret () from /usr/lib/libdb-4.6.so #3 0xb7e6126b in __dbc_get () from /usr/lib/libdb-4.6.so #4 0xb7e6a04b in __dbc_get_pp () from /usr/lib/libdb-4.6.so #5 0x0814fd28 in hdb_id2entry (be=0x9d5edefc, tid=0xa1b11180, id=2355, e=0x9d52d958) at id2entry.c:151 #6 0x081431e9 in hdb_cache_find_id (op=0x9d5edc24, tid=0xa1b11180, id=2355, eip=0x9d5edaf8, flag=2, lock=0x9d5eda90) at cache.c:923 #7 0x081158a5 in hdb_search (op=0x9d5edc24, rs=0x9d5edb78) at search.c:705 #8 0x08160364 in syncprov_playlog (op=0xa1b0a300, rs=0x9d5ef100, sl=0x82d1c50, srs=0x9c6eb264, ctxcsn=0x9c6eb31c, numcsns=1, sids=0x9c6eb364) at syncprov.c:1592 #9 0x08162893 in syncprov_op_search (op=0xa1b0a300, rs=0x9d5ef100) at syncprov.c:2348 #10 0x080f1396 in overlay_op_walk (op=0xa1b0a300, rs=0x9d5ef100, which=op_search, oi=0x82d19c8, on=0x82d1ac8) at backover.c:659 #11 0x080f161e in over_op_func (op=0xa1b0a300, rs=0x9d5ef100, which=op_search) at backover.c:721 #12 0x080f16c2 in over_op_search (op=0xa1b0a300, rs=0x9d5ef100) at backover.c:743 #13 0x08072169 in fe_op_search (op=0xa1b0a300, rs=0x9d5ef100) at search.c:366 #14 0x08071adc in do_search (op=0xa1b0a300, rs=0x9d5ef100) at search.c:217 #15 0x0806e7c2 in connection_operation (ctx=0x9d5ef1f0, arg_v=0xa1b0a300) at connection.c:1097 #16 0x0806ec9c in connection_read_thread (ctx=0x9d5ef1f0, argv=0x1d) at connection.c:1223 #17 0x0817a99b in ldap_int_thread_pool_wrapper (xpool=0x829baf0) at tpool.c:663 #18 0xb7da14fb in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #19 0xb7b70e5e in clone () from /lib/tls/i686/cmov/libc.so.6 Thread 1 (process 24208): #0 0x080c0e82 in is_ad_subtype (sub=0x0, super=0x8294e08) at ad.c:502 #1 0x0807a6da in attrs_find (a=0xa2d39fa4, desc=0x8294e08) at attr.c:645 #2 0x080964dd in test_presence_filter (op=0x9e6f1b08, e=0x83277f4, desc=0x8294e08) at filterentry.c:848 #3 0x080951ce in test_filter (op=0x9e6f1b08, e=0x83277f4, f=0x9ae022a8) at filterentry.c:108 #4 0x0815efdf in syncprov_matchops (op=0x83455c8, opc=0x9cfed214, saveit=1) at syncprov.c:1251 #5 0x08160fd9 in syncprov_op_mod (op=0x83455c8, rs=0x9e6f3100) at syncprov.c:1905 #6 0x080f1396 in overlay_op_walk (op=0x83455c8, rs=0x9e6f3100, which=op_modify, oi=0x82d19c8, on=0x82d1ac8) at backover.c:659 #7 0x080f161e in over_op_func (op=0x83455c8, rs=0x9e6f3100, which=op_modify) at backover.c:721 #8 0x080f1706 in over_op_modify (op=0x83455c8, rs=0x9e6f3100) at backover.c:755 #9 0x0808c802 in fe_op_modify (op=0x83455c8, rs=0x9e6f3100) at modify.c:301 #10 0x0808c115 in do_modify (op=0x83455c8, rs=0x9e6f3100) at modify.c:175 #11 0x0806e7c2 in connection_operation (ctx=0x9e6f31f0, arg_v=0x83455c8) at connection.c:1097 #12 0x0806ec9c in connection_read_thread (ctx=0x9e6f31f0, argv=0x39) at connection.c:1223 #13 0x0817a99b in ldap_int_thread_pool_wrapper (xpool=0x829baf0) at tpool.c:663 #14 0xb7da14fb in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #15 0xb7b70e5e in clone () from /lib/tls/i686/cmov/libc.so.6 Thanks for your time, Oskar

1 0

Re: (ITS#6032) lap_add: Invalid DN syntax (34) additional info: invalid DN
by quanah＠zimbra.com 25 Mar '09

25 Mar '09

--On Wednesday, March 25, 2009 11:52 AM +0000 sudeshchandimal(a)gmail.com wrote: > Full_Name: sudesh chandimal > Version: openldap-2.4.15 > OS: fedora > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (124.43.51.7) > > > lap_add: Invalid DN syntax (34) > additional info: invalid DN > > this is the error i'm getting after runing this ldif file.. > ># Base object for Request Balance > dn: dview=ECS1_request_bal, dc=my-domain, dc=com > dview: ECS1_request_bal > objectClass: top > objectClass: dview > userPassword: balance Send usage questions to openldap-software(a)openldap.org, not the ITS system. The ITS system is for reporting bugs in the software. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6032) lap_add: Invalid DN syntax (34) additional info: invalid DN
by sudeshchandimal＠gmail.com 25 Mar '09

25 Mar '09

Full_Name: sudesh chandimal Version: openldap-2.4.15 OS: fedora URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (124.43.51.7) lap_add: Invalid DN syntax (34) additional info: invalid DN this is the error i'm getting after runing this ldif file.. # Base object for Request Balance dn: dview=ECS1_request_bal, dc=my-domain, dc=com dview: ECS1_request_bal objectClass: top objectClass: dview userPassword: balance ldif file.............. ldapadd -x -D "cn=Manager, dc=my-domain, dc=com" -w secret -f add_request_bal_entry.ldif please please help me.. quickly....!

1 0

(ITS#6031) An account locked on consumer is unlocked only when password is changed twice in a row on provider
by stlist＠gmail.com 24 Mar '09

24 Mar '09

Full_Name: Samuel Tran Version: 2.3.43 OS: CentOS 5.x URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (216.73.248.203) If I lock an account on a consumer 'pwdMaxFailure' consecutive failed bind attempts, two password changes on the provider is required to unlock the account on the consumer. The first password change updates 'userPassword', 'pwdChangedTime' and removes 'pwdFailureTime'. The second updates 'userPassword', 'pwdChangedTime' and removes 'pwdAccountLockedTime'. The replication mode is delta-syncrepl. Here is the configuration file on the provider: #------------------------------------------------- # Accesslog DB definition (slapo-accesslog) #------------------------------------------------- database hdb suffix "cn=accesslog" rootdn "cn=root,cn=accesslog" rootpw {SSHA}xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx directory /var/lib/ldap/accesslog index default eq index entryUUID,entryCSN,objectClass,reqEnd,reqResult,reqStart limits dn.exact="cn=syncrepl,ou=Accounts,ou=Apps,dc=example,dc=com" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited overlay syncprov syncprov-nopresent TRUE syncprov-reloadhint TRUE #------------------------------------------------- # Primary example.com database definition #------------------------------------------------- database hdb suffix "dc=example,dc=com" rootdn "cn=Manager,dc=example,dc=com" rootpw {SSHA}xxxxxxxxxxxxxxxxxxxxxxxxxxx directory /var/lib/ldap/example.com [snip] index objectClass,uidNumber,gidNumber,memberUid,employeeNumber eq,pres index employeeType,accountActive,ftpActive,mailActive,vacationActive,ou,mailRoutingAddress eq index cn,mail,surname,givenname eq,pres,subinitial index displayName,gecos,telephoneNumber sub,subany index uid,aliasUid eq,sub,subany index entryUUID,entryCSN eq limits dn.exact="cn=syncrepl,ou=Accounts,ou=Apps,dc=example,dc=com" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited overlay syncprov syncprov-checkpoint 100 30 syncprov-sessionlog 100 overlay accesslog logdb cn=accesslog logops writes logsuccess TRUE logpurge 28+00:00 01+00:00 overlay ppolicy ppolicy_use_lockout Here is the configuration file on the consumer: #------------------------------------------------- # Primary example.com database definition #------------------------------------------------- database hdb suffix "dc=example,dc=com" rootdn "cn=Manager,dc=example,dc=com" rootpw {SSHA}xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx directory /var/lib/ldap/example.com [snip] index objectClass,uidNumber,gidNumber,memberUid,employeeNumber eq,pres index employeeType,accountActive,ftpActive,mailActive,vacationActive,ou,mailRoutingAddress,mailAlternateAddress,mailAliasActive,allowedService eq index cn,mail,surname,givenname eq,pres,subinitial index displayName,gecos,telephoneNumber sub,subany index uid,aliasUid eq,sub,subany index entryUUID eq ############################################################# # Syncrepl - Consumer configuration ############################################################# syncrepl rid=002 provider=ldaps://info-ldap-001.example.com:636 bindmethod=simple binddn="cn=syncrepl,ou=Accounts,ou=Apps,dc=example,dc=com" credentials=xxxxxxxx type=refreshAndPersist retry="5 +" searchbase="dc=example,dc=com" logbase="cn=accesslog" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" schemachecking=on syncdata=accesslog overlay ppolicy ppolicy_use_lockout The problem is similar to the one reported in ITS #5398 for OL 2.4.8. I saw Howard's reply stating that he was not able to reproduce the problem in the current OL 2.4.x code. I was wondering if someone was able to reproduce the problem using OL 2.3.43. Thanks.

1 0

Re: (ITS#6030) slapd segfaults when loading already present module
by luca.scamoni＠sys-net.it 23 Mar '09

23 Mar '09

Tested latest commit and it's fixed now thanks Ing. Luca Scamoni Responsabile Ricerca e Sviluppo SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 0382 573859 (137) Mobile: +39 347 1014425 Fax: +39 0382 476497 Email: luca.scamoni(a)sys-net.it -----------------------------------

1 0

Re: (ITS#6030) slapd segfaults when loading already present module
by hyc＠symas.com 23 Mar '09

23 Mar '09

Luca Scamoni wrote: > Howard Chu ha scritto: >> HEAD has been changed to silently ignore these cases, please test. >> >> (I guess we could log something at LDAP_DEBUG_CONFIG level but that >> seems unnecessary at the moment.) >> > thanks, > now it doesn't segfaults anymore but something like: > modulepath /usr/local/openldap/sbin > moduleload syncprov.la > moduleload back_hdb.la > moduleload syncprov.la > > becomes: > dn: cn=module{0},cn=config > objectClass: olcModuleList > cn: module{0} > olcModulePath: /usr/local/openldap/sbin > olcModuleLoad: {0}syncprov.la > olcModuleLoad: {1}back_hdb.la > olcModuleLoad: {2}syncprov.la > > any chance this can cause problems? It's a bit redundant. Perhaps we should fail it instead. > about logging I vote for it > > > Ing. Luca Scamoni > Responsabile Ricerca e Sviluppo > > SysNet s.r.l. > via Dossi, 8 - 27100 Pavia - ITALIA > http://www.sys-net.it > ----------------------------------- > Office: +39 0382 573859 (137) > Mobile: +39 347 1014425 > Fax: +39 0382 476497 > Email: luca.scamoni(a)sys-net.it > ----------------------------------- > > -- -- 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#6030) slapd segfaults when loading already present module
by luca.scamoni＠sys-net.it 23 Mar '09

23 Mar '09

Howard Chu ha scritto: > HEAD has been changed to silently ignore these cases, please test. > > (I guess we could log something at LDAP_DEBUG_CONFIG level but that > seems unnecessary at the moment.) > thanks, now it doesn't segfaults anymore but something like: modulepath /usr/local/openldap/sbin moduleload syncprov.la moduleload back_hdb.la moduleload syncprov.la becomes: dn: cn=module{0},cn=config objectClass: olcModuleList cn: module{0} olcModulePath: /usr/local/openldap/sbin olcModuleLoad: {0}syncprov.la olcModuleLoad: {1}back_hdb.la olcModuleLoad: {2}syncprov.la any chance this can cause problems? about logging I vote for it Ing. Luca Scamoni Responsabile Ricerca e Sviluppo SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 0382 573859 (137) Mobile: +39 347 1014425 Fax: +39 0382 476497 Email: luca.scamoni(a)sys-net.it -----------------------------------

1 0

Re: (ITS#6030) slapd segfaults when loading already present module
by hyc＠symas.com 23 Mar '09

23 Mar '09

HEAD has been changed to silently ignore these cases, please test. (I guess we could log something at LDAP_DEBUG_CONFIG level but that seems unnecessary at the moment.) luca(a)OpenLDAP.org wrote: > Full_Name: Luca Scamoni > Version: RE24/HEAD > OS: any > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (82.63.140.131) > > > When loading a module through cn=config or slapd.conf moduleload directive, if > the module has already been loaded, slapd segfaults. Since it correctly finds > out the module is already registered shouldn't it refuse the modification when > the operation is attempted through cn=config or simply refuse to start when done > through slapd.conf? > > Last log lines (-d -1): > line 20 (moduleload syncprov.la) > loaded module syncprov.la > Control 1.3.6.1.4.1.4203.1.9.1.1 already registered. > syncprov_init: Failed to register control -9 > Segmentation fault > > backtrace: > #0 0x0000000b in ?? () > No symbol table info available. > #1 0x080dcb94 in module_load (file_name=0x89746bb "syncprov.la", argc=0, > argv=0x0) > at module.c:218 > module = (module_loaded_t *) 0x8976718 > error = 0x0 > rc = -9 > initialize = (MODULE_INIT_FN) 0x5f6936<init_module> > #2 0x0805bd1c in config_generic (c=0x8967970) at bconfig.c:1940 > i = 11784196 > __PRETTY_FUNCTION__ = "config_generic" > #3 0x0806a586 in config_set_vals (Conf=0x8168160, c=0x8967970) at config.c:314 > rc = 0 > arg_type = -2013265890 > ptr = (void *) 0x0 > #4 0x0806aa68 in config_add_vals (Conf=0x8168160, c=0x8967970) at config.c:383 > rc = 0 > arg_type = -2013265890 > #5 0x0806ba42 in read_config_file (fname=0x8932308 > "/usr/local/openldap/etc/slapd.conf", > depth=0, cf=0x0, cft=0x8167bc0) at config.c:736 > fp = (FILE *) 0x89692f8 > ct = (ConfigTable *) 0x8168160 > c = (ConfigArgs *) 0x8967970 > rc = 0 > s = {st_dev = 64768, __pad1 = 0, st_ino = 172196293, st_mode = 33152, > st_nlink = 1, > st_uid = 0, st_gid = 0, st_rdev = 0, __pad2 = 0, st_size = 1087, st_blksize = > 4096, > st_blocks = 8, st_atim = {tv_sec = 1237802811, tv_nsec = 0}, st_mtim = {tv_sec > = 1237802556, > tv_nsec = 0}, st_ctim = {tv_sec = 1237802556, tv_nsec = 0}, __unused4 = 0, > __unused5 = 0} > #6 0x08061626 in read_config (fname=0x8932308 > "/usr/local/openldap/etc/slapd.conf", dir=0x0) > at bconfig.c:3613 > be = (BackendDB *) 0x8967800 > cfb = (CfBackInfo *) 0x816c340 > cfdir = 0x11f0bc "" > cfname = 0x8932308 "/usr/local/openldap/etc/slapd.conf" > rc = 0 > __PRETTY_FUNCTION__ = "read_config" > #7 0x08057a5d in main (argc=5, argv=0xbfc1ce24) at main.c:754 > i = -1 > no_detach = 0 > rc = 0 > urls = 0x89323f0 "ldap://:9000" > username = 0x0 > groupname = 0x0 > sandbox = 0x0 > syslogUser = 160 > g_argc = 5 > g_argv = (char **) 0xbfc1ce24 > configfile = 0x8932308 "/usr/local/openldap/etc/slapd.conf" > configdir = 0x0 > serverName = 0xbfc1eb66 "slapd" > serverMode = 1 > scp = (struct sync_cookie *) 0x0 > scp_entry = (struct sync_cookie *) 0x0 > debug_unknowns = (char **) 0x0 > syslog_unknowns = (char **) 0x0 > serverNamePrefix = 0x811b537 "" > l = 1347407256 > slapd_pid_file_unlink = 0 > slapd_args_file_unlink = 0 > firstopt = 0 > __PRETTY_FUNCTION__ = "main" > > > -- -- 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#6030) slapd segfaults when loading already present module
by luca＠OpenLDAP.org 23 Mar '09

23 Mar '09

Full_Name: Luca Scamoni Version: RE24/HEAD OS: any URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.63.140.131) When loading a module through cn=config or slapd.conf moduleload directive, if the module has already been loaded, slapd segfaults. Since it correctly finds out the module is already registered shouldn't it refuse the modification when the operation is attempted through cn=config or simply refuse to start when done through slapd.conf? Last log lines (-d -1): line 20 (moduleload syncprov.la) loaded module syncprov.la Control 1.3.6.1.4.1.4203.1.9.1.1 already registered. syncprov_init: Failed to register control -9 Segmentation fault backtrace: #0 0x0000000b in ?? () No symbol table info available. #1 0x080dcb94 in module_load (file_name=0x89746bb "syncprov.la", argc=0, argv=0x0) at module.c:218 module = (module_loaded_t *) 0x8976718 error = 0x0 rc = -9 initialize = (MODULE_INIT_FN) 0x5f6936 <init_module> #2 0x0805bd1c in config_generic (c=0x8967970) at bconfig.c:1940 i = 11784196 __PRETTY_FUNCTION__ = "config_generic" #3 0x0806a586 in config_set_vals (Conf=0x8168160, c=0x8967970) at config.c:314 rc = 0 arg_type = -2013265890 ptr = (void *) 0x0 #4 0x0806aa68 in config_add_vals (Conf=0x8168160, c=0x8967970) at config.c:383 rc = 0 arg_type = -2013265890 #5 0x0806ba42 in read_config_file (fname=0x8932308 "/usr/local/openldap/etc/slapd.conf", depth=0, cf=0x0, cft=0x8167bc0) at config.c:736 fp = (FILE *) 0x89692f8 ct = (ConfigTable *) 0x8168160 c = (ConfigArgs *) 0x8967970 rc = 0 s = {st_dev = 64768, __pad1 = 0, st_ino = 172196293, st_mode = 33152, st_nlink = 1, st_uid = 0, st_gid = 0, st_rdev = 0, __pad2 = 0, st_size = 1087, st_blksize = 4096, st_blocks = 8, st_atim = {tv_sec = 1237802811, tv_nsec = 0}, st_mtim = {tv_sec = 1237802556, tv_nsec = 0}, st_ctim = {tv_sec = 1237802556, tv_nsec = 0}, __unused4 = 0, __unused5 = 0} #6 0x08061626 in read_config (fname=0x8932308 "/usr/local/openldap/etc/slapd.conf", dir=0x0) at bconfig.c:3613 be = (BackendDB *) 0x8967800 cfb = (CfBackInfo *) 0x816c340 cfdir = 0x11f0bc "" cfname = 0x8932308 "/usr/local/openldap/etc/slapd.conf" rc = 0 __PRETTY_FUNCTION__ = "read_config" #7 0x08057a5d in main (argc=5, argv=0xbfc1ce24) at main.c:754 i = -1 no_detach = 0 rc = 0 urls = 0x89323f0 "ldap://:9000" username = 0x0 groupname = 0x0 sandbox = 0x0 syslogUser = 160 g_argc = 5 g_argv = (char **) 0xbfc1ce24 configfile = 0x8932308 "/usr/local/openldap/etc/slapd.conf" configdir = 0x0 serverName = 0xbfc1eb66 "slapd" serverMode = 1 scp = (struct sync_cookie *) 0x0 scp_entry = (struct sync_cookie *) 0x0 debug_unknowns = (char **) 0x0 syslog_unknowns = (char **) 0x0 serverNamePrefix = 0x811b537 "" l = 1347407256 slapd_pid_file_unlink = 0 slapd_args_file_unlink = 0 firstopt = 0 __PRETTY_FUNCTION__ = "main"

1 0

Re: (ITS#6027) Debug() accesses free()-d memory in register_at() on error
by test.007＠seznam.cz 23 Mar '09

23 Mar '09

Verified. Thanks. Mr. Chu, you're right my build was broken.

1 0

Re: patch filed (ITS#5366)
by peter＠adpm.de 22 Mar '09

22 Mar '09

Hi, I filed a patch that should fix this ITS. It can be found at ftp://ftp.openldap.org/incoming/PeterMarschall-090322.patch and brings the man page in line with the code. Regards Peter -- Peter Marschall peter(a)adpm.de

1 0

Re: (ITS#6029) slapadd lockup
by quanah＠zimbra.com 21 Mar '09

21 Mar '09

After around 24 hours, backtrace is the same: (gdb) thr apply all bt Thread 5 (Thread 1106889024 (LWP 9361)): #0 0x00002b7817902496 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002b7819f27de9 in bdb_tool_trickle_task (ctx=<value optimized out>, ptr=<value optimized out>) at tools.c:1124 #2 0x00002b781715a2ca in ldap_int_thread_pool_wrapper (xpool=0x17e07fd0) at ../../../libraries/libldap_r/tpool.c:663 #3 0x00002b78178fe2f7 in start_thread () from /lib64/libpthread.so.0 #4 0x000000395e0d1e3d in clone () from /lib64/libc.so.6 Thread 4 (Thread 1115281728 (LWP 9362)): #0 0x00002b7817902496 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002b7819f28163 in bdb_tool_index_task (ctx=<value optimized out>, ptr=<value optimized out>) at tools.c:1147 #2 0x00002b781715a2ca in ldap_int_thread_pool_wrapper (xpool=0x17e07fd0) at ../../../libraries/libldap_r/tpool.c:663 #3 0x00002b78178fe2f7 in start_thread () from /lib64/libpthread.so.0 #4 0x000000395e0d1e3d in clone () from /lib64/libc.so.6 Thread 3 (Thread 1123674432 (LWP 9363)): #0 0x00002b7817902496 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002b7819f28163 in bdb_tool_index_task (ctx=<value optimized out>, ptr=<value optimized out>) at tools.c:1147 #2 0x00002b781715a2ca in ldap_int_thread_pool_wrapper (xpool=0x17e07fd0) at ../../../libraries/libldap_r/tpool.c:663 #3 0x00002b78178fe2f7 in start_thread () from /lib64/libpthread.so.0 #4 0x000000395e0d1e3d in clone () from /lib64/libc.so.6 Thread 2 (Thread 1132067136 (LWP 9360)): #0 0x00002b7817902496 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002b7819f28014 in bdb_tool_index_add (op=0x7fff93950310, txn=<value optimized out>, e=0x2b7b521d2068) at tools.c:475 #2 0x00002b7819f28970 in hdb_tool_entry_put (be=0x17f39240, e=0x2b7b521d2068, text=0x7fff93960cc0) at tools.c:545 #3 0x00000000004906f9 in slapadd (argc=<value optimized out>, argv=0x7fff93960ec8) at ../../../servers/slapd/slapadd.c:350 #4 0x0000000000416c59 in main (argc=6, argv=0x7fff93960ec8) at ../../../servers/slapd/main.c:391 Thread 1 (Thread 47794824997056 (LWP 9360)): #0 0x00002b7817902496 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002b7819f28014 in bdb_tool_index_add (op=0x7fff93950310, txn=<value optimized out>, e=0x2b7b521d2068) at tools.c:475 #2 0x00002b7819f28970 in hdb_tool_entry_put (be=0x17f39240, e=0x2b7b521d2068, text=0x7fff93960cc0) at tools.c:545 #3 0x00000000004906f9 in slapadd (argc=<value optimized out>, argv=0x7fff93960ec8) at ../../../servers/slapd/slapadd.c:350 #4 0x0000000000416c59 in main (argc=6, argv=0x7fff93960ec8) at ../../../servers/slapd/main.c:391 #0 0x00002b7817902496 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 --On Sunday, March 22, 2009 2:37 AM +0000 quanah(a)zimbra.com wrote: > --On Saturday, March 21, 2009 7:09 PM -0700 Howard Chu <hyc(a)symas.com> > wrote: > >> quanah(a)zimbra.com wrote: >>> Full_Name: Quanah Gibson-Mount >>> Version: RE24 3/19/2009 >>> OS: Linux 2.6 >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (75.111.29.239) >>> >>> >>> While testing various load scenarios, slapadd deadlocked on me. >> >> The trace for thread 1 and 2 look identical, so I'm assuming they're the >> same thread. In that case I see 3 tool threads running. How many did you >> have configured? If 1 and 2 are really different threads (certainly their >> thread IDs look quite different), then there's something very wrong in >> the thread library... >> >> print bdb_tool_index_tcount >> > > (gdb) print bdb_tool_index_tcount > $1 = 1 > > >> It looks like one thread has exited early. I'm not sure how that can >> happen since the only way for any index thread to exit is if >> slapd_shutdown is set. Is it set? > > (gdb) print slapd_shutdown > $2 = 0 > > > It's configured with 4 tool threads. > > --Quanah > >>> (gdb) thr apply all bt >>> >>> Thread 5 (Thread 1106889024 (LWP 9361)): >>> # 0 0x00002b7817902496 in pthread_cond_wait@@GLIBC_2.3.2 () from >>> /lib64/libpthread.so.0 >>> # 1 0x00002b7819f27de9 in bdb_tool_trickle_task (ctx=<value optimized >>> # out>, >>> ptr=<value optimized out>) at tools.c:1124 >>> # 2 0x00002b781715a2ca in ldap_int_thread_pool_wrapper >>> # (xpool=0x17e07fd0) at >>> ../../../libraries/libldap_r/tpool.c:663 >>> # 3 0x00002b78178fe2f7 in start_thread () from /lib64/libpthread.so.0 >>> # 4 0x000000395e0d1e3d in clone () from /lib64/libc.so.6 >>> >>> Thread 4 (Thread 1115281728 (LWP 9362)): >>> # 0 0x00002b7817902496 in pthread_cond_wait@@GLIBC_2.3.2 () from >>> /lib64/libpthread.so.0 >>> # 1 0x00002b7819f28163 in bdb_tool_index_task (ctx=<value optimized >>> # out>, >>> ptr=<value optimized out>) at tools.c:1147 >>> # 2 0x00002b781715a2ca in ldap_int_thread_pool_wrapper >>> # (xpool=0x17e07fd0) at >>> ../../../libraries/libldap_r/tpool.c:663 >>> # 3 0x00002b78178fe2f7 in start_thread () from /lib64/libpthread.so.0 >>> # 4 0x000000395e0d1e3d in clone () from /lib64/libc.so.6 >>> >>> Thread 3 (Thread 1123674432 (LWP 9363)): >>> # 0 0x00002b7817902496 in pthread_cond_wait@@GLIBC_2.3.2 () from >>> /lib64/libpthread.so.0 >>> # 1 0x00002b7819f28163 in bdb_tool_index_task (ctx=<value optimized >>> # out>, >>> ptr=<value optimized out>) at tools.c:1147 >>> # 2 0x00002b781715a2ca in ldap_int_thread_pool_wrapper >>> # (xpool=0x17e07fd0) at >>> ../../../libraries/libldap_r/tpool.c:663 >>> # 3 0x00002b78178fe2f7 in start_thread () from /lib64/libpthread.so.0 >>> # 4 0x000000395e0d1e3d in clone () from /lib64/libc.so.6 >>> >>> Thread 2 (Thread 1132067136 (LWP 9360)): >>> # 0 0x00002b7817902496 in pthread_cond_wait@@GLIBC_2.3.2 () from >>> /lib64/libpthread.so.0 >>> # 1 0x00002b7819f28014 in bdb_tool_index_add (op=0x7fff93950310, >>> # txn=<value >>> optimized out>, e=0x2b7b521d2068) at tools.c:475 >>> # 2 0x00002b7819f28970 in hdb_tool_entry_put (be=0x17f39240, >>> # e=0x2b7b521d2068, >>> text=0x7fff93960cc0) at tools.c:545 >>> # 3 0x00000000004906f9 in slapadd (argc=<value optimized out>, >>> argv=0x7fff93960ec8) at ../../../servers/slapd/slapadd.c:350 >>> # 4 0x0000000000416c59 in main (argc=6, argv=0x7fff93960ec8) at >>> ../../../servers/slapd/main.c:391 >>> >>> Thread 1 (Thread 47794824997056 (LWP 9360)): >>> # 0 0x00002b7817902496 in pthread_cond_wait@@GLIBC_2.3.2 () from >>> /lib64/libpthread.so.0 >>> # 1 0x00002b7819f28014 in bdb_tool_index_add (op=0x7fff93950310, >>> # txn=<value >>> optimized out>, e=0x2b7b521d2068) at tools.c:475 >>> # 2 0x00002b7819f28970 in hdb_tool_entry_put (be=0x17f39240, >>> # e=0x2b7b521d2068, >>> text=0x7fff93960cc0) at tools.c:545 >>> # 3 0x00000000004906f9 in slapadd (argc=<value optimized out>, >>> argv=0x7fff93960ec8) at ../../../servers/slapd/slapadd.c:350 >>> # 4 0x0000000000416c59 in main (argc=6, argv=0x7fff93960ec8) at >>> ../../../servers/slapd/main.c:391 >>> # 0 0x00002b7817902496 in pthread_cond_wait@@GLIBC_2.3.2 () from >>> /lib64/libpthread.so.0 >> >> >> -- >> -- Howard Chu >> CTO, Symas Corp. http://www.symas.com >> Director, Highland Sun http://highlandsun.com/hyc/ >> Chief Architect, OpenLDAP http://www.openldap.org/project/ > > > > -- > > Quanah Gibson-Mount > Principal Software Engineer > Zimbra, Inc > -------------------- > Zimbra :: the leader in open source messaging and collaboration > > -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6029) slapadd lockup
by quanah＠zimbra.com 21 Mar '09

21 Mar '09

--On Saturday, March 21, 2009 7:09 PM -0700 Howard Chu <hyc(a)symas.com> wrote: > quanah(a)zimbra.com wrote: >> Full_Name: Quanah Gibson-Mount >> Version: RE24 3/19/2009 >> OS: Linux 2.6 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (75.111.29.239) >> >> >> While testing various load scenarios, slapadd deadlocked on me. > > The trace for thread 1 and 2 look identical, so I'm assuming they're the > same thread. In that case I see 3 tool threads running. How many did you > have configured? If 1 and 2 are really different threads (certainly their > thread IDs look quite different), then there's something very wrong in > the thread library... > > print bdb_tool_index_tcount > (gdb) print bdb_tool_index_tcount $1 = 1 > It looks like one thread has exited early. I'm not sure how that can > happen since the only way for any index thread to exit is if > slapd_shutdown is set. Is it set? (gdb) print slapd_shutdown $2 = 0 It's configured with 4 tool threads. --Quanah >> (gdb) thr apply all bt >> >> Thread 5 (Thread 1106889024 (LWP 9361)): >> # 0 0x00002b7817902496 in pthread_cond_wait@@GLIBC_2.3.2 () from >> /lib64/libpthread.so.0 >> # 1 0x00002b7819f27de9 in bdb_tool_trickle_task (ctx=<value optimized >> # out>, >> ptr=<value optimized out>) at tools.c:1124 >> # 2 0x00002b781715a2ca in ldap_int_thread_pool_wrapper >> # (xpool=0x17e07fd0) at >> ../../../libraries/libldap_r/tpool.c:663 >> # 3 0x00002b78178fe2f7 in start_thread () from /lib64/libpthread.so.0 >> # 4 0x000000395e0d1e3d in clone () from /lib64/libc.so.6 >> >> Thread 4 (Thread 1115281728 (LWP 9362)): >> # 0 0x00002b7817902496 in pthread_cond_wait@@GLIBC_2.3.2 () from >> /lib64/libpthread.so.0 >> # 1 0x00002b7819f28163 in bdb_tool_index_task (ctx=<value optimized >> # out>, >> ptr=<value optimized out>) at tools.c:1147 >> # 2 0x00002b781715a2ca in ldap_int_thread_pool_wrapper >> # (xpool=0x17e07fd0) at >> ../../../libraries/libldap_r/tpool.c:663 >> # 3 0x00002b78178fe2f7 in start_thread () from /lib64/libpthread.so.0 >> # 4 0x000000395e0d1e3d in clone () from /lib64/libc.so.6 >> >> Thread 3 (Thread 1123674432 (LWP 9363)): >> # 0 0x00002b7817902496 in pthread_cond_wait@@GLIBC_2.3.2 () from >> /lib64/libpthread.so.0 >> # 1 0x00002b7819f28163 in bdb_tool_index_task (ctx=<value optimized >> # out>, >> ptr=<value optimized out>) at tools.c:1147 >> # 2 0x00002b781715a2ca in ldap_int_thread_pool_wrapper >> # (xpool=0x17e07fd0) at >> ../../../libraries/libldap_r/tpool.c:663 >> # 3 0x00002b78178fe2f7 in start_thread () from /lib64/libpthread.so.0 >> # 4 0x000000395e0d1e3d in clone () from /lib64/libc.so.6 >> >> Thread 2 (Thread 1132067136 (LWP 9360)): >> # 0 0x00002b7817902496 in pthread_cond_wait@@GLIBC_2.3.2 () from >> /lib64/libpthread.so.0 >> # 1 0x00002b7819f28014 in bdb_tool_index_add (op=0x7fff93950310, >> # txn=<value >> optimized out>, e=0x2b7b521d2068) at tools.c:475 >> # 2 0x00002b7819f28970 in hdb_tool_entry_put (be=0x17f39240, >> # e=0x2b7b521d2068, >> text=0x7fff93960cc0) at tools.c:545 >> # 3 0x00000000004906f9 in slapadd (argc=<value optimized out>, >> argv=0x7fff93960ec8) at ../../../servers/slapd/slapadd.c:350 >> # 4 0x0000000000416c59 in main (argc=6, argv=0x7fff93960ec8) at >> ../../../servers/slapd/main.c:391 >> >> Thread 1 (Thread 47794824997056 (LWP 9360)): >> # 0 0x00002b7817902496 in pthread_cond_wait@@GLIBC_2.3.2 () from >> /lib64/libpthread.so.0 >> # 1 0x00002b7819f28014 in bdb_tool_index_add (op=0x7fff93950310, >> # txn=<value >> optimized out>, e=0x2b7b521d2068) at tools.c:475 >> # 2 0x00002b7819f28970 in hdb_tool_entry_put (be=0x17f39240, >> # e=0x2b7b521d2068, >> text=0x7fff93960cc0) at tools.c:545 >> # 3 0x00000000004906f9 in slapadd (argc=<value optimized out>, >> argv=0x7fff93960ec8) at ../../../servers/slapd/slapadd.c:350 >> # 4 0x0000000000416c59 in main (argc=6, argv=0x7fff93960ec8) at >> ../../../servers/slapd/main.c:391 >> # 0 0x00002b7817902496 in pthread_cond_wait@@GLIBC_2.3.2 () from >> /lib64/libpthread.so.0 > > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6029) slapadd lockup
by hyc＠symas.com 21 Mar '09

21 Mar '09

quanah(a)zimbra.com wrote: > Full_Name: Quanah Gibson-Mount > Version: RE24 3/19/2009 > OS: Linux 2.6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.111.29.239) > > > While testing various load scenarios, slapadd deadlocked on me. The trace for thread 1 and 2 look identical, so I'm assuming they're the same thread. In that case I see 3 tool threads running. How many did you have configured? If 1 and 2 are really different threads (certainly their thread IDs look quite different), then there's something very wrong in the thread library... print bdb_tool_index_tcount It looks like one thread has exited early. I'm not sure how that can happen since the only way for any index thread to exit is if slapd_shutdown is set. Is it set? > > (gdb) thr apply all bt > > Thread 5 (Thread 1106889024 (LWP 9361)): > #0 0x00002b7817902496 in pthread_cond_wait@@GLIBC_2.3.2 () from > /lib64/libpthread.so.0 > #1 0x00002b7819f27de9 in bdb_tool_trickle_task (ctx=<value optimized out>, > ptr=<value optimized out>) at tools.c:1124 > #2 0x00002b781715a2ca in ldap_int_thread_pool_wrapper (xpool=0x17e07fd0) at > ../../../libraries/libldap_r/tpool.c:663 > #3 0x00002b78178fe2f7 in start_thread () from /lib64/libpthread.so.0 > #4 0x000000395e0d1e3d in clone () from /lib64/libc.so.6 > > Thread 4 (Thread 1115281728 (LWP 9362)): > #0 0x00002b7817902496 in pthread_cond_wait@@GLIBC_2.3.2 () from > /lib64/libpthread.so.0 > #1 0x00002b7819f28163 in bdb_tool_index_task (ctx=<value optimized out>, > ptr=<value optimized out>) at tools.c:1147 > #2 0x00002b781715a2ca in ldap_int_thread_pool_wrapper (xpool=0x17e07fd0) at > ../../../libraries/libldap_r/tpool.c:663 > #3 0x00002b78178fe2f7 in start_thread () from /lib64/libpthread.so.0 > #4 0x000000395e0d1e3d in clone () from /lib64/libc.so.6 > > Thread 3 (Thread 1123674432 (LWP 9363)): > #0 0x00002b7817902496 in pthread_cond_wait@@GLIBC_2.3.2 () from > /lib64/libpthread.so.0 > #1 0x00002b7819f28163 in bdb_tool_index_task (ctx=<value optimized out>, > ptr=<value optimized out>) at tools.c:1147 > #2 0x00002b781715a2ca in ldap_int_thread_pool_wrapper (xpool=0x17e07fd0) at > ../../../libraries/libldap_r/tpool.c:663 > #3 0x00002b78178fe2f7 in start_thread () from /lib64/libpthread.so.0 > #4 0x000000395e0d1e3d in clone () from /lib64/libc.so.6 > > Thread 2 (Thread 1132067136 (LWP 9360)): > #0 0x00002b7817902496 in pthread_cond_wait@@GLIBC_2.3.2 () from > /lib64/libpthread.so.0 > #1 0x00002b7819f28014 in bdb_tool_index_add (op=0x7fff93950310, txn=<value > optimized out>, e=0x2b7b521d2068) at tools.c:475 > #2 0x00002b7819f28970 in hdb_tool_entry_put (be=0x17f39240, e=0x2b7b521d2068, > text=0x7fff93960cc0) at tools.c:545 > #3 0x00000000004906f9 in slapadd (argc=<value optimized out>, > argv=0x7fff93960ec8) at ../../../servers/slapd/slapadd.c:350 > #4 0x0000000000416c59 in main (argc=6, argv=0x7fff93960ec8) at > ../../../servers/slapd/main.c:391 > > Thread 1 (Thread 47794824997056 (LWP 9360)): > #0 0x00002b7817902496 in pthread_cond_wait@@GLIBC_2.3.2 () from > /lib64/libpthread.so.0 > #1 0x00002b7819f28014 in bdb_tool_index_add (op=0x7fff93950310, txn=<value > optimized out>, e=0x2b7b521d2068) at tools.c:475 > #2 0x00002b7819f28970 in hdb_tool_entry_put (be=0x17f39240, e=0x2b7b521d2068, > text=0x7fff93960cc0) at tools.c:545 > #3 0x00000000004906f9 in slapadd (argc=<value optimized out>, > argv=0x7fff93960ec8) at ../../../servers/slapd/slapadd.c:350 > #4 0x0000000000416c59 in main (argc=6, argv=0x7fff93960ec8) at > ../../../servers/slapd/main.c:391 > #0 0x00002b7817902496 in pthread_cond_wait@@GLIBC_2.3.2 () from > /lib64/libpthread.so.0 -- -- 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#6029) slapadd lockup
by quanah＠zimbra.com 21 Mar '09

21 Mar '09

Full_Name: Quanah Gibson-Mount Version: RE24 3/19/2009 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.29.239) While testing various load scenarios, slapadd deadlocked on me. (gdb) thr apply all bt Thread 5 (Thread 1106889024 (LWP 9361)): #0 0x00002b7817902496 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002b7819f27de9 in bdb_tool_trickle_task (ctx=<value optimized out>, ptr=<value optimized out>) at tools.c:1124 #2 0x00002b781715a2ca in ldap_int_thread_pool_wrapper (xpool=0x17e07fd0) at ../../../libraries/libldap_r/tpool.c:663 #3 0x00002b78178fe2f7 in start_thread () from /lib64/libpthread.so.0 #4 0x000000395e0d1e3d in clone () from /lib64/libc.so.6 Thread 4 (Thread 1115281728 (LWP 9362)): #0 0x00002b7817902496 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002b7819f28163 in bdb_tool_index_task (ctx=<value optimized out>, ptr=<value optimized out>) at tools.c:1147 #2 0x00002b781715a2ca in ldap_int_thread_pool_wrapper (xpool=0x17e07fd0) at ../../../libraries/libldap_r/tpool.c:663 #3 0x00002b78178fe2f7 in start_thread () from /lib64/libpthread.so.0 #4 0x000000395e0d1e3d in clone () from /lib64/libc.so.6 Thread 3 (Thread 1123674432 (LWP 9363)): #0 0x00002b7817902496 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002b7819f28163 in bdb_tool_index_task (ctx=<value optimized out>, ptr=<value optimized out>) at tools.c:1147 #2 0x00002b781715a2ca in ldap_int_thread_pool_wrapper (xpool=0x17e07fd0) at ../../../libraries/libldap_r/tpool.c:663 #3 0x00002b78178fe2f7 in start_thread () from /lib64/libpthread.so.0 #4 0x000000395e0d1e3d in clone () from /lib64/libc.so.6 Thread 2 (Thread 1132067136 (LWP 9360)): #0 0x00002b7817902496 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002b7819f28014 in bdb_tool_index_add (op=0x7fff93950310, txn=<value optimized out>, e=0x2b7b521d2068) at tools.c:475 #2 0x00002b7819f28970 in hdb_tool_entry_put (be=0x17f39240, e=0x2b7b521d2068, text=0x7fff93960cc0) at tools.c:545 #3 0x00000000004906f9 in slapadd (argc=<value optimized out>, argv=0x7fff93960ec8) at ../../../servers/slapd/slapadd.c:350 #4 0x0000000000416c59 in main (argc=6, argv=0x7fff93960ec8) at ../../../servers/slapd/main.c:391 Thread 1 (Thread 47794824997056 (LWP 9360)): #0 0x00002b7817902496 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002b7819f28014 in bdb_tool_index_add (op=0x7fff93950310, txn=<value optimized out>, e=0x2b7b521d2068) at tools.c:475 #2 0x00002b7819f28970 in hdb_tool_entry_put (be=0x17f39240, e=0x2b7b521d2068, text=0x7fff93960cc0) at tools.c:545 #3 0x00000000004906f9 in slapadd (argc=<value optimized out>, argv=0x7fff93960ec8) at ../../../servers/slapd/slapadd.c:350 #4 0x0000000000416c59 in main (argc=6, argv=0x7fff93960ec8) at ../../../servers/slapd/main.c:391 #0 0x00002b7817902496 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0

1 0

Re: Fw: Re: (ITS#5988) entries skipped in n-way mutimaster replication
by rein＠OpenLDAP.org 20 Mar '09

20 Mar '09

adrien.futschik(a)atosorigin.com wrote: >> Some changes have been made in the syncprov overlay's queue management in >> CVS HEAD. The test050 script has also been changed to test up to 9 masters, >> and it passes for me with several hundred iterations of 9 servers. (Some of >> the timing delays have to be increased though.) >> > I have tested the HEAD version of OpenLDAP (10/03/09 - 14:48) and I still have > problems with some entries not being added. There are important bugfixes committed after 10/03/09, including fixes to this ITS. As of now you should test the RE24 branch, which is being prepared for an upcoming 2.4.16 release. Rein

1 0

Re: Fw: Re: (ITS#5988) entries skipped in n-way mutimaster replication
by adrien.futschik＠atosorigin.com 20 Mar '09

20 Mar '09

--Boundary-00=_8B4wJH+c2cGJw4l Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit > Some changes have been made in the syncprov overlay's queue management in > CVS HEAD. The test050 script has also been changed to test up to 9 masters, > and it passes for me with several hundred iterations of 9 servers. (Some of > the timing delays have to be increased though.) > I have tested the HEAD version of OpenLDAP (10/03/09 - 14:48) and I still have problems with some entries not being added. I did not change my configuration. Here is an example of what I see in the log files : on M2 (where the entry is added) : [...] conn=32 fd=28 ACCEPT from IP=163.106.38.124:49986 (IP=163.106.38.92:9012) conn=32 op=0 BIND dn="cn=admin,c=fr" method=128 conn=32 op=0 BIND dn="cn=admin,c=fr" mech=SIMPLE ssf=0 conn=32 op=0 RESULT tag=97 err=0 text= conn=32 op=1 ADD dn="cn=M2client24(a)laposte.net,ou=clients,o=edf,c=fr" slap_queue_csn: queing 0x41000360 20090320101016.082209Z#000000#002#000000 syncprov_sendresp: cookie=rid=012,sid=003,csn=20090320101016.082209Z#000000#002#000000 syncprov_sendresp: cookie=rid=012,sid=004,csn=20090320101016.082209Z#000000#002#000000 syncprov_sendresp: cookie=rid=012,sid=001,csn=20090320101016.082209Z#000000#002#000000 conn=32 op=1 RESULT tag=105 err=0 text= slap_graduate_commit_csn: removing 0x2aaab00457e0 20090320101016.082209Z#000000#002#000000 conn=32 op=2 UNBIND conn=32 fd=28 closed [...] on M1 : [...] do_syncrep2: rid=014 LDAP_RES_INTERMEDIATE - NEW_COOKIE do_syncrep2: rid=014 NEW_COOKIE: rid=014,sid=001,csn=20090320101016.118097Z#000000#001#000000;20090320101016.082209Z#000000#002#000000 [...] do_syncrep2: cookie=rid=012,sid=001,csn=20090320101016.082209Z#000000#002#000000 do_syncrep2: rid=012 CSN too old, ignoring 20090320101016.082209Z#000000#002#000000 [...] on M3 : [...] do_syncrep2: cookie=rid=012,sid=003,csn=20090320101016.082209Z#000000#002#000000 syncrepl_entry: rid=012 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) syncrepl_entry: rid=012 be_search (0) syncrepl_entry: rid=012 cn=M2client24(a)laposte.net,ou=clients,o=edf,c=fr slap_queue_csn: queing 0x1b35e3d0 20090320101016.082209Z#000000#002#000000 syncprov_sendresp: cookie=rid=013,sid=004,csn=20090320101016.082209Z#000000#002#000000 slap_graduate_commit_csn: removing 0x1b35d660 20090320101016.082209Z#000000#002#000000 syncrepl_entry: rid=012 be_add (0) do_syncrep2: cookie=rid=014,sid=003,csn=20090320101016.075365Z#000000#001#000000 do_syncrep2: rid=014 CSN too old, ignoring 20090320101016.075365Z#000000#001#000000 do_syncrep2: cookie=rid=012,sid=003,csn=20090320101016.075365Z#000000#001#000000 do_syncrep2: rid=012 CSN too old, ignoring 20090320101016.075365Z#000000#001#000000 do_syncrep2: cookie=rid=014,sid=003,csn=20090320101016.118097Z#000000#001#000000 do_syncrep2: rid=014 CSN too old, ignoring 20090320101016.118097Z#000000#001#000000 do_syncrep2: rid=014 LDAP_RES_INTERMEDIATE - NEW_COOKIE do_syncrep2: rid=014 NEW_COOKIE: rid=014,sid=003,csn=20090320101016.118097Z#000000#001#000000;20090320101016.082209Z#000000#002#000000 do_syncrep2: rid=011 LDAP_RES_INTERMEDIATE - NEW_COOKIE do_syncrep2: rid=011 NEW_COOKIE: rid=011,sid=003,csn=20090320101016.205384Z#000000#001#000000;20090320101016.082209Z#000000#002#000000 [...] on M4 : [...] do_syncrep2: cookie=rid=012,sid=004,csn=20090320101016.082209Z#000000#002#000000 syncrepl_entry: rid=012 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) syncprov_sendresp: cookie=rid=014,sid=003,csn=20090320101016.075365Z#000000#001#000000 dn_callback : entries have identical CSN cn=M1client114(a)laposte.net,ou=clients,o=edf,c=fr 20090320101016.075365Z#000000#001#000000 syncrepl_entry: rid=013 be_search (0) syncrepl_entry: rid=013 cn=M1client114(a)laposte.net,ou=clients,o=edf,c=fr syncprov_sendresp: cookie=rid=014,sid=002,csn=20090320101016.075365Z#000000#001#000000 slap_queue_csn: queing 0x38c1610 20090320101016.075365Z#000000#001#000000 syncrepl_entry: rid=013 entry unchanged, ignored (cn=M1client114(a)laposte.net,ou=clients,o=edf,c=fr) slap_graduate_commit_csn: removing 0x38bdce0 20090320101016.075365Z#000000#001#000000 slap_graduate_commit_csn: removing 0x38c20d0 20090320101016.075365Z#000000#001#000000 syncrepl_entry: rid=011 be_add (0) syncrepl_entry: rid=012 be_search (0) syncrepl_entry: rid=012 cn=M2client24(a)laposte.net,ou=clients,o=edf,c=fr slap_queue_csn: queing 0x2aaad0008c70 20090320101016.082209Z#000000#002#000000 slap_graduate_commit_csn: removing 0x2aaad0009ff0 20090320101016.082209Z#000000#002#000000 do_syncrep2: cookie=rid=013,sid=004,csn=20090320101016.118097Z#000000#001#000000 do_syncrep2: cookie=rid=011,sid=004,csn=20090320101016.118097Z#000000#001#000000 syncrepl_entry: rid=011 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) syncrepl_entry: rid=013 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) syncrepl_entry: rid=013 be_search (0) syncrepl_entry: rid=013 cn=M1client115(a)laposte.net,ou=clients,o=edf,c=fr syncrepl_entry: rid=011 be_search (0) syncrepl_entry: rid=011 cn=M1client115(a)laposte.net,ou=clients,o=edf,c=fr slap_queue_csn: queing 0x2aaac40234b0 20090320101016.118097Z#000000#001#000000 slap_queue_csn: queing 0x2aaad00032c0 20090320101016.118097Z#000000#001#000000 syncrepl_entry: rid=012 be_add (0) slap_graduate_commit_csn: removing 0x2aaac40270f0 20090320101016.118097Z#000000#001#000000 syncprov_sendresp: cookie=rid=014,sid=003,csn=20090320101016.118097Z#000000#001#000000 syncprov_sendresp: cookie=rid=014,sid=002,csn=20090320101016.118097Z#000000#001#000000 slap_graduate_commit_csn: removing 0x2aaad000b770 20090320101016.118097Z#000000#001#000000 syncrepl_entry: rid=011 be_add (0) syncrepl_entry: rid=013 be_add (68) dn_callback : entries have identical CSN cn=M1client115(a)laposte.net,ou=clients,o=edf,c=fr 20090320101016.118097Z#000000#001#000000 syncrepl_entry: rid=013 entry unchanged, ignored (cn=M1client115(a)laposte.net,ou=clients,o=edf,c=fr) do_syncrep2: cookie=rid=012,sid=004,csn=20090320101016.075365Z#000000#001#000000 do_syncrep2: rid=012 CSN too old, ignoring 20090320101016.075365Z#000000#001#000000 do_syncrep2: cookie=rid=011,sid=004,csn=20090320101016.162183Z#000000#001#000000 do_syncrep2: cookie=rid=013,sid=004,csn=20090320101016.162183Z#000000#001#000000 syncrepl_entry: rid=011 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) syncrepl_entry: rid=013 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) syncrepl_entry: rid=011 be_search (0) syncrepl_entry: rid=013 be_search (0) syncrepl_entry: rid=013 cn=M1client116(a)laposte.net,ou=clients,o=edf,c=fr syncrepl_entry: rid=011 cn=M1client116(a)laposte.net,ou=clients,o=edf,c=fr slap_queue_csn: queing 0x2aaac4018760 20090320101016.162183Z#000000#001#000000 slap_queue_csn: queing 0x2aaad000a710 20090320101016.162183Z#000000#001#000000 syncprov_sendresp: cookie=rid=014,sid=003,csn=20090320101016.162183Z#000000#001#000000 syncprov_sendresp: cookie=rid=014,sid=002,csn=20090320101016.162183Z#000000#001#000000 do_syncrep2: cookie=rid=012,sid=004,csn=20090320101016.118097Z#000000#001#000000 do_syncrep2: rid=012 CSN too old, ignoring 20090320101016.118097Z#000000#001#000000 slap_graduate_commit_csn: removing 0x2aaac4027050 20090320101016.162183Z#000000#001#000000 syncrepl_entry: rid=011 be_add (0) slap_graduate_commit_csn: removing 0x2aaad0009fb0 20090320101016.162183Z#000000#001#000000 syncrepl_entry: rid=013 be_add (68) dn_callback : entries have identical CSN cn=M1client116(a)laposte.net,ou=clients,o=edf,c=fr 20090320101016.162183Z#000000#001#000000 syncrepl_entry: rid=013 entry unchanged, ignored (cn=M1client116(a)laposte.net,ou=clients,o=edf,c=fr) do_syncrep2: cookie=rid=011,sid=004,csn=20090320101016.205384Z#000000#001#000000 do_syncrep2: cookie=rid=013,sid=004,csn=20090320101016.205384Z#000000#001#000000 syncrepl_entry: rid=013 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) syncrepl_entry: rid=011 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) syncrepl_entry: rid=013 be_search (0) syncrepl_entry: rid=013 cn=M1client117(a)laposte.net,ou=clients,o=edf,c=fr slap_queue_csn: queing 0x2aaad000a660 20090320101016.205384Z#000000#001#000000 syncrepl_entry: rid=011 be_search (0) syncrepl_entry: rid=011 cn=M1client117(a)laposte.net,ou=clients,o=edf,c=fr slap_queue_csn: queing 0x2aaac4018760 20090320101016.205384Z#000000#001#000000 slap_graduate_commit_csn: removing 0x2aaad0008a50 20090320101016.205384Z#000000#001#000000 syncrepl_entry: rid=013 be_add (0) slap_graduate_commit_csn: removing 0x2aaac4027960 20090320101016.205384Z#000000#001#000000 syncprov_sendresp: cookie=rid=014,sid=003,csn=20090320101016.205384Z#000000#001#000000 syncprov_sendresp: cookie=rid=014,sid=002,csn=20090320101016.205384Z#000000#001#000000 do_syncrep2: cookie=rid=012,sid=004,csn=20090320101016.162183Z#000000#001#000000 do_syncrep2: rid=012 CSN too old, ignoring 20090320101016.162183Z#000000#001#000000 syncrepl_entry: rid=011 be_add (68) dn_callback : entries have identical CSN cn=M1client117(a)laposte.net,ou=clients,o=edf,c=fr 20090320101016.205384Z#000000#001#000000 syncrepl_entry: rid=011 entry unchanged, ignored (cn=M1client117(a)laposte.net,ou=clients,o=edf,c=fr) do_syncrep2: rid=011 LDAP_RES_INTERMEDIATE - NEW_COOKIE do_syncrep2: rid=011 NEW_COOKIE: rid=011,sid=004,csn=20090320101016.205384Z#000000#001#000000;20090320101016.082209Z#000000#002#000000 do_syncrep2: cookie=rid=013,sid=004,csn=20090320101016.082209Z#000000#002#000000 do_syncrep2: rid=013 CSN too old, ignoring 20090320101016.082209Z#000000#002#000000 [...] Do you have any idea what's going on ? I hoppe this will help Adrien Futschik --Boundary-00=_8B4wJH+c2cGJw4l Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN" "http://www.w3.org/TR/REC-html40/strict.dtd"><html><head><meta name="qrichtext" content="1" /><style type="text/css">p, li { white-space: pre-wrap; }</style></head><body style=" font-family:'Sans Serif'; font-size:8pt; font-weight:400; font-style:normal;">> Some changes have been made in the syncprov overlay's queue management in > CVS HEAD. The test050 script has also been changed to test up to 9 masters, > and it passes for me with several hundred iterations of 9 servers. (Some of > the timing delays have to be increased though.) > I have tested the HEAD version of OpenLDAP (10/03/09 - 14:48) and I still have problems with some entries not being added. I did not change my configuration. Here is an example of what I see in the log files : on M2 (where the entry is added) : [...] conn=32 fd=28 ACCEPT from IP=163.106.38.124:49986 (IP=163.106.38.92:9012) conn=32 op=0 BIND dn="cn=admin,c=fr" method=128 conn=32 op=0 BIND dn="cn=admin,c=fr" mech=SIMPLE ssf=0 conn=32 op=0 RESULT tag=97 err=0 text= conn=32 op=1 ADD dn="cn=M2client24(a)laposte.net,ou=clients,o=edf,c=fr" slap_queue_csn: queing 0x41000360 20090320101016.082209Z#000000#002#000000 syncprov_sendresp: cookie=rid=012,sid=003,csn=20090320101016.082209Z#000000#002#000000 syncprov_sendresp: cookie=rid=012,sid=004,csn=20090320101016.082209Z#000000#002#000000 syncprov_sendresp: cookie=rid=012,sid=001,csn=20090320101016.082209Z#000000#002#000000 conn=32 op=1 RESULT tag=105 err=0 text= slap_graduate_commit_csn: removing 0x2aaab00457e0 20090320101016.082209Z#000000#002#000000 conn=32 op=2 UNBIND conn=32 fd=28 closed [...] on M1 : [...] do_syncrep2: rid=014 LDAP_RES_INTERMEDIATE - NEW_COOKIE do_syncrep2: rid=014 NEW_COOKIE: rid=014,sid=001,csn=20090320101016.118097Z#000000#001#000000;20090320101016.082209Z#000000#002#000000 [...] do_syncrep2: cookie=rid=012,sid=001,csn=20090320101016.082209Z#000000#002#000000 do_syncrep2: rid=012 CSN too old, ignoring 20090320101016.082209Z#000000#002#000000 [...] on M3 : [...] do_syncrep2: cookie=rid=012,sid=003,csn=20090320101016.082209Z#000000#002#000000 syncrepl_entry: rid=012 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) syncrepl_entry: rid=012 be_search (0) syncrepl_entry: rid=012 cn=M2client24(a)laposte.net,ou=clients,o=edf,c=fr slap_queue_csn: queing 0x1b35e3d0 20090320101016.082209Z#000000#002#000000 syncprov_sendresp: cookie=rid=013,sid=004,csn=20090320101016.082209Z#000000#002#000000 slap_graduate_commit_csn: removing 0x1b35d660 20090320101016.082209Z#000000#002#000000 syncrepl_entry: rid=012 be_add (0) do_syncrep2: cookie=rid=014,sid=003,csn=20090320101016.075365Z#000000#001#000000 do_syncrep2: rid=014 CSN too old, ignoring 20090320101016.075365Z#000000#001#000000 do_syncrep2: cookie=rid=012,sid=003,csn=20090320101016.075365Z#000000#001#000000 do_syncrep2: rid=012 CSN too old, ignoring 20090320101016.075365Z#000000#001#000000 do_syncrep2: cookie=rid=014,sid=003,csn=20090320101016.118097Z#000000#001#000000 do_syncrep2: rid=014 CSN too old, ignoring 20090320101016.118097Z#000000#001#000000 do_syncrep2: rid=014 LDAP_RES_INTERMEDIATE - NEW_COOKIE do_syncrep2: rid=014 NEW_COOKIE: rid=014,sid=003,csn=20090320101016.118097Z#000000#001#000000;20090320101016.082209Z#000000#002#000000 do_syncrep2: rid=011 LDAP_RES_INTERMEDIATE - NEW_COOKIE do_syncrep2: rid=011 NEW_COOKIE: rid=011,sid=003,csn=20090320101016.205384Z#000000#001#000000;20090320101016.082209Z#000000#002#000000 [...] on M4 : [...] do_syncrep2: cookie=rid=012,sid=004,csn=20090320101016.082209Z#000000#002#000000 syncrepl_entry: rid=012 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) syncprov_sendresp: cookie=rid=014,sid=003,csn=20090320101016.075365Z#000000#001#000000 dn_callback : entries have identical CSN cn=M1client114(a)laposte.net,ou=clients,o=edf,c=fr 20090320101016.075365Z#000000#001#000000 syncrepl_entry: rid=013 be_search (0) syncrepl_entry: rid=013 cn=M1client114(a)laposte.net,ou=clients,o=edf,c=fr syncprov_sendresp: cookie=rid=014,sid=002,csn=20090320101016.075365Z#000000#001#000000 slap_queue_csn: queing 0x38c1610 20090320101016.075365Z#000000#001#000000 syncrepl_entry: rid=013 entry unchanged, ignored (cn=M1client114(a)laposte.net,ou=clients,o=edf,c=fr) slap_graduate_commit_csn: removing 0x38bdce0 20090320101016.075365Z#000000#001#000000 slap_graduate_commit_csn: removing 0x38c20d0 20090320101016.075365Z#000000#001#000000 syncrepl_entry: rid=011 be_add (0) syncrepl_entry: rid=012 be_search (0) syncrepl_entry: rid=012 cn=M2client24(a)laposte.net,ou=clients,o=edf,c=fr slap_queue_csn: queing 0x2aaad0008c70 20090320101016.082209Z#000000#002#000000 slap_graduate_commit_csn: removing 0x2aaad0009ff0 20090320101016.082209Z#000000#002#000000 do_syncrep2: cookie=rid=013,sid=004,csn=20090320101016.118097Z#000000#001#000000 do_syncrep2: cookie=rid=011,sid=004,csn=20090320101016.118097Z#000000#001#000000 syncrepl_entry: rid=011 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) syncrepl_entry: rid=013 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) syncrepl_entry: rid=013 be_search (0) syncrepl_entry: rid=013 cn=M1client115(a)laposte.net,ou=clients,o=edf,c=fr syncrepl_entry: rid=011 be_search (0) syncrepl_entry: rid=011 cn=M1client115(a)laposte.net,ou=clients,o=edf,c=fr slap_queue_csn: queing 0x2aaac40234b0 20090320101016.118097Z#000000#001#000000 slap_queue_csn: queing 0x2aaad00032c0 20090320101016.118097Z#000000#001#000000 syncrepl_entry: rid=012 be_add (0) slap_graduate_commit_csn: removing 0x2aaac40270f0 20090320101016.118097Z#000000#001#000000 syncprov_sendresp: cookie=rid=014,sid=003,csn=20090320101016.118097Z#000000#001#000000 syncprov_sendresp: cookie=rid=014,sid=002,csn=20090320101016.118097Z#000000#001#000000 slap_graduate_commit_csn: removing 0x2aaad000b770 20090320101016.118097Z#000000#001#000000 syncrepl_entry: rid=011 be_add (0) syncrepl_entry: rid=013 be_add (68) dn_callback : entries have identical CSN cn=M1client115(a)laposte.net,ou=clients,o=edf,c=fr 20090320101016.118097Z#000000#001#000000 syncrepl_entry: rid=013 entry unchanged, ignored (cn=M1client115(a)laposte.net,ou=clients,o=edf,c=fr) do_syncrep2: cookie=rid=012,sid=004,csn=20090320101016.075365Z#000000#001#000000 do_syncrep2: rid=012 CSN too old, ignoring 20090320101016.075365Z#000000#001#000000 do_syncrep2: cookie=rid=011,sid=004,csn=20090320101016.162183Z#000000#001#000000 do_syncrep2: cookie=rid=013,sid=004,csn=20090320101016.162183Z#000000#001#000000 syncrepl_entry: rid=011 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) syncrepl_entry: rid=013 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) syncrepl_entry: rid=011 be_search (0) syncrepl_entry: rid=013 be_search (0) syncrepl_entry: rid=013 cn=M1client116(a)laposte.net,ou=clients,o=edf,c=fr syncrepl_entry: rid=011 cn=M1client116(a)laposte.net,ou=clients,o=edf,c=fr slap_queue_csn: queing 0x2aaac4018760 20090320101016.162183Z#000000#001#000000 slap_queue_csn: queing 0x2aaad000a710 20090320101016.162183Z#000000#001#000000 syncprov_sendresp: cookie=rid=014,sid=003,csn=20090320101016.162183Z#000000#001#000000 syncprov_sendresp: cookie=rid=014,sid=002,csn=20090320101016.162183Z#000000#001#000000 do_syncrep2: cookie=rid=012,sid=004,csn=20090320101016.118097Z#000000#001#000000 do_syncrep2: rid=012 CSN too old, ignoring 20090320101016.118097Z#000000#001#000000 slap_graduate_commit_csn: removing 0x2aaac4027050 20090320101016.162183Z#000000#001#000000 syncrepl_entry: rid=011 be_add (0) slap_graduate_commit_csn: removing 0x2aaad0009fb0 20090320101016.162183Z#000000#001#000000 syncrepl_entry: rid=013 be_add (68) dn_callback : entries have identical CSN cn=M1client116(a)laposte.net,ou=clients,o=edf,c=fr 20090320101016.162183Z#000000#001#000000 syncrepl_entry: rid=013 entry unchanged, ignored (cn=M1client116(a)laposte.net,ou=clients,o=edf,c=fr) do_syncrep2: cookie=rid=011,sid=004,csn=20090320101016.205384Z#000000#001#000000 do_syncrep2: cookie=rid=013,sid=004,csn=20090320101016.205384Z#000000#001#000000 syncrepl_entry: rid=013 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) syncrepl_entry: rid=011 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) syncrepl_entry: rid=013 be_search (0) syncrepl_entry: rid=013 cn=M1client117(a)laposte.net,ou=clients,o=edf,c=fr slap_queue_csn: queing 0x2aaad000a660 20090320101016.205384Z#000000#001#000000 syncrepl_entry: rid=011 be_search (0) syncrepl_entry: rid=011 cn=M1client117(a)laposte.net,ou=clients,o=edf,c=fr slap_queue_csn: queing 0x2aaac4018760 20090320101016.205384Z#000000#001#000000 slap_graduate_commit_csn: removing 0x2aaad0008a50 20090320101016.205384Z#000000#001#000000 syncrepl_entry: rid=013 be_add (0) slap_graduate_commit_csn: removing 0x2aaac4027960 20090320101016.205384Z#000000#001#000000 syncprov_sendresp: cookie=rid=014,sid=003,csn=20090320101016.205384Z#000000#001#000000 syncprov_sendresp: cookie=rid=014,sid=002,csn=20090320101016.205384Z#000000#001#000000 do_syncrep2: cookie=rid=012,sid=004,csn=20090320101016.162183Z#000000#001#000000 do_syncrep2: rid=012 CSN too old, ignoring 20090320101016.162183Z#000000#001#000000 syncrepl_entry: rid=011 be_add (68) dn_callback : entries have identical CSN cn=M1client117(a)laposte.net,ou=clients,o=edf,c=fr 20090320101016.205384Z#000000#001#000000 syncrepl_entry: rid=011 entry unchanged, ignored (cn=M1client117(a)laposte.net,ou=clients,o=edf,c=fr) do_syncrep2: rid=011 LDAP_RES_INTERMEDIATE - NEW_COOKIE do_syncrep2: rid=011 NEW_COOKIE: rid=011,sid=004,csn=20090320101016.205384Z#000000#001#000000;20090320101016.082209Z#000000#002#000000 do_syncrep2: cookie=rid=013,sid=004,csn=20090320101016.082209Z#000000#002#000000 do_syncrep2: rid=013 CSN too old, ignoring 20090320101016.082209Z#000000#002#000000 [...] Do you have any idea what's going on ? I hoppe this will help Adrien Futschik</body></html> --Boundary-00=_8B4wJH+c2cGJw4l--

1 0

Re: (ITS#4941) incorrect description of TLS_REQCERT setting
by hyc＠symas.com 19 Mar '09

19 Mar '09

Howard Chu wrote: > Philip Guenther wrote: >> On Mon, 30 Apr 2007, Howard Chu wrote: >>> guenther+ldapdev(a)sendmail.com wrote: >> ... >>>> - 'allow' checks the identity of the server vs its cert (per RFC 4513, >>>> section 3.1.3) and will terminate the connection if they don't match >>>> - 'try' is the same as 'demand' and 'hard' >>> Not quite. With both "allow" and "try" it's OK if the server provides no >>> certificate. >> >> That's true of 'demand' and 'hard' as well. The only difference between >> 'try' and 'demand' in the code is that the latter passes >> SSL_CTX_set_verify() the SSL_VERIFY_FAIL_IF_NO_PEER_CERT flag, but that >> flag has NO EFFECT on SSL clients. This is documented on the >> SSL_CTX_set_verify() manpage and confirmed by grepping the openssl source >> for it. >> >> If you don't believe me, I suggest you try configuring your server to >> accept the ADH suites (don't forget to set TLSDHParamFile to /dev/null) >> and give ldapsearch a whirl with >> LDAPTLS_REQCERT=hard >> LDAPTLS_CIPHER_SUITE=ADH-AES256-SHA >> >> in your environment. That's what I did. > > When this text was written, there was no support for anonymous cipher suites. > So the meaning of the text is: assuming a cipher suite that actually uses > certificates, the client would proceed even if the server didn't provide a > cert. It's entirely possible that this circumstance has been overcome by other > developments. Most likely this hasn't been a valid use case for quite a long > time. But it has nothing to do with Diffie-Hellman key exchanges... Aside from clarifying that we're assuming the use of X.509 certificates in the first place, this text is correct. I note that GnuTLS also works with OpenPGP keys, but I've never tested that here. Anyway, the current description is also accurate for GnuTLS. -- -- 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: add option for setting minimum TLS/SSL protocol (ITS#5655)
by guenther＠sendmail.com 19 Mar '09

19 Mar '09

On Fri, 23 Jan 2009, Howard Chu wrote: > guenther(a)sendmail.com wrote: > > I could have sworn I had uploaded the revised version of the patch back in > > August after some cleaning by Kurt, but have no way of confirming it. So > > I've uploaded it again as guenther-20081204.patch. > > Thanks, patch looks good, committed to HEAD. Have you got a manpage > update, by the way? Here's the chunk for ldap.conf(5), diffed against the trunk. None of the LDAP_OPT_X_TLS* options appear to be documented, so I didn't add anything to ldap_get_option(3). Philip Index: doc/man/man5/ldap.conf.5 =================================================================== RCS file: /data/cvs/openldap/pkg/ldap/doc/man/man5/ldap.conf.5,v retrieving revision 1.50 diff -u -r1.50 ldap.conf.5 --- doc/man/man5/ldap.conf.5 26 Jan 2009 01:54:32 -0000 1.50 +++ doc/man/man5/ldap.conf.5 19 Mar 2009 18:22:00 -0000 @@ -336,6 +336,19 @@ gnutls-cli -l .fi .TP +.B TLS_PROTOCOL_MIN <major>[.<minor>] +Specifies minimum SSL protocol version that will be negoiated. +If the server doesn't support at least that version, +the SSL handshake will fail. +To require TLS 1.x or higher, set this option to 3.(x+1), +e.g., +.B TLS_PROTOCOL_MIN 3.2 +would require TLS 1.1. +Specifying a minimum that is higher than that supported by the +OpenLDAP implementation will result it in requiring the +highest level that it does support. +This parameter is currently ignored with GNUtls. +.TP .B TLS_RANDFILE <filename> Specifies the file to obtain random bits from when /dev/[u]random is not available. Generally set to the name of the EGD/PRNGD socket.

1 0

Re: (ITS#5733) core dump in re24's slapd-ldap(5)
by quanah＠zimbra.com 18 Mar '09

18 Mar '09

--On Thursday, October 09, 2008 8:42 PM +0000 ando(a)sys-net.it wrote: > Full_Name: Pierangelo Masarati > Version: re24 > OS: Linux x86 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (81.72.89.40) > Submitted by: ando > > > I had a strange core dump while testing re24 (test039). I'm reporting it > in order to be able to investigate it further later. Backtrace follows: I hit this today in testing RE24 as well: Thread 1 (process 27053): #0 0x000000395e030155 in raise () from /lib64/libc.so.6 #1 0x000000395e031bf0 in abort () from /lib64/libc.so.6 #2 0x000000395e0295d6 in __assert_fail () from /lib64/libc.so.6 #3 0x00002b45fe1d3f51 in ldap_back_conn_delete (li=0xba73080, lc=0x2aaab0003690) at ../../../../servers/slapd/back-ldap/bind.c:157 #4 0x00002b45fe1d4a34 in ldap_back_freeconn (li=0xba73080, lc=0x2aaab0003690, dolock=0) at ../../../../servers/slapd/back-ldap/bind.c:467 #5 0x00002b45fe1d6492 in ldap_back_release_conn_lock (li=0xba73080, lcp=0x45b9c5e8, dolock=1) at ../../../../servers/slapd/back-ldap/bind.c:1144 #6 0x00002b45fe1d46b0 in ldap_back_bind (op=0xc168af0, rs=0x45b9cc40) at ../../../../servers/slapd/back-ldap/bind.c:355 #7 0x00000000004c24da in overlay_op_walk (op=0xc168af0, rs=0x45b9cc40, which=op_bind, oi=0xba2cd90, on=0x0) at ../../../servers/slapd/backover.c:669 #8 0x00000000004c26dd in over_op_func (op=0xc168af0, rs=0x45b9cc40, which=op_bind) at ../../../servers/slapd/backover.c:721 #9 0x00000000004c272b in over_op_bind (op=0xc168af0, rs=0x45b9cc40) at ../../../servers/slapd/backover.c:731 #10 0x0000000000460681 in fe_op_bind (op=0xc168af0, rs=0x45b9cc40) at ../../../servers/slapd/bind.c:383 #11 0x00000000004c24da in overlay_op_walk (op=0xc168af0, rs=0x45b9cc40, which=op_bind, oi=0xba6def0, on=0x0) at ../../../servers/slapd/backover.c:669 #12 0x00000000004c26dd in over_op_func (op=0xc168af0, rs=0x45b9cc40, which=op_bind) at ../../../servers/slapd/backover.c:721 #13 0x00000000004c272b in over_op_bind (op=0xc168af0, rs=0x45b9cc40) at ../../../servers/slapd/backover.c:731 #14 0x000000000045fdb0 in do_bind (op=0xc168af0, rs=0x45b9cc40) at ../../../servers/slapd/bind.c:205 #15 0x0000000000438a70 in connection_operation (ctx=0x45b9cd90, arg_v=0xc168af0) at ../../../servers/slapd/connection.c:1097 #16 0x0000000000438f8b in connection_read_thread (ctx=0x45b9cd90, argv=0x17) at ../../../servers/slapd/connection.c:1223 #17 0x00002b45fad8b6b7 in ldap_int_thread_pool_wrapper (xpool=0xba14330) at ../../../libraries/libldap_r/tpool.c:663 #18 0x00002b45fb5442f7 in start_thread () from /lib64/libpthread.so.0 #19 0x000000395e0d1e3d in clone () from /lib64/libc.so.6 (gdb) frame 6 #6 0x00002b45fe1d46b0 in ldap_back_bind (op=0xc168af0, rs=0x45b9cc40) at ../../../../servers/slapd/back-ldap/bind.c:355 355 ldap_back_release_conn( li, lc ); (gdb) p retrying $1 = LDAP_BACK_RETRYING (gdb) frame 3 #3 0x00002b45fe1d3f51 in ldap_back_conn_delete (li=0xba73080, lc=0x2aaab0003690) at ../../../../servers/slapd/back-ldap/bind.c:157 157 assert( !LDAP_BACK_CONN_TAINTED( lc ) ); (gdb) print *lc $2 = {lc_conn = 0x2b45fea45f50, lc_ld = 0x2aaab00126d0, lc_cred = {bv_len = 0, bv_val = 0x0}, lc_bound_ndn = {bv_len = 46, bv_val = 0x2aaaac126130 "cn=james a jones 4,ou=people,dc=example,dc=com"}, lc_local_ndn = {bv_len = 46, bv_val = 0x2aaaac1192a0 "cn=james a jones 4,ou=people,dc=example,dc=com"}, lc_lcflags = 289, lc_refcnt = 0, lc_flags = 4096, lc_create_time = 0, lc_time = 0, lc_q = {tqe_next = 0x0, tqe_prev = 0x0}} (gdb) p /x lc->lc_lcflags $3 = 0x121 --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5856) adauth overlay contribution
by hyc＠symas.com 18 Mar '09

18 Mar '09

neil.dunbar(a)hp.com wrote: > Still nothing? I can resubmit if the tarball has rotted away to nothing > on the incoming server. ;-) > > I don't mind if the code needs rewriting (it almost certainly does!), or > if it isn't felt to be the right fit for contrib, but a little feedback > would be helpful in getting things right. Sorry, we've been in bugfix-only mode for the past couple months. After this next (2.4.16) release is frozen we'll get back to working on new features. > > Cheers, > > Neil -- -- 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#5856) adauth overlay contribution
by neil.dunbar＠hp.com 18 Mar '09

18 Mar '09

Still nothing? I can resubmit if the tarball has rotted away to nothing on the incoming server. ;-) I don't mind if the code needs rewriting (it almost certainly does!), or if it isn't felt to be the right fit for contrib, but a little feedback would be helpful in getting things right. Cheers, Neil -- SSL, HP Labs/Office of Strategy and Technology Hewlett-Packard Limited Registered Office: Cain Road, Bracknell, Berks RG12 1HN Registered No: 690597 England

1 0

Re: (ITS#6028) accesslog db after main db fails if main db is ""
by quanah＠zimbra.com 17 Mar '09

17 Mar '09

--On Tuesday, March 17, 2009 11:26 PM +0000 quanah(a)zimbra.com wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.15 > OS: Linux 2.6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.111.29.239) > > > If the main database is rooted at "", and you go to create an accesslog > database to set up delta-syncrepl replication, the modification is > erroneously rejected by cn=config: bah, never mind. Still would be nice though. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6028) accesslog db after main db fails if main db is ""
by quanah＠zimbra.com 17 Mar '09

17 Mar '09

Full_Name: Quanah Gibson-Mount Version: 2.4.15 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.29.239) If the main database is rooted at "", and you go to create an accesslog database to set up delta-syncrepl replication, the modification is erroneously rejected by cn=config: ERROR: Unable to add accesslog database to freelancer.lab.zimbra.com - exiting ldap_add: Other (e.g., implementation specific) error (80) additional info: <olcSuffix> namingContext "cn=accesslog" already served by a preceding hdb database adding new entry "olcDatabase={3}hdb,cn=config" Inserting the accesslog DB in front of the existing database works as expected.

1 0

Re: (ITS#6012) segmentation fault triggered with slapcat
by hyc＠symas.com 17 Mar '09

17 Mar '09

martin.konold(a)erfrakon.de wrote: > Am Dienstag, 10. März 2009 06:53:34 schrieben Sie: > >> Please provide steps to reproduce the segfault, thanks. > > Hi Howard, > > I tried to reproduce the problem on either OpenSUSE 11.1 or Fedora but I could > not reproduce the crash. > > The crash was reproducable with OpenPKG though I guess the crash depends on > the version of bdb beeing used. The code fetches an transaction from an > internal table which might have slightly different semantics with regards to > initialization depending on bdb version. > > Anyway if you look at the rather trivial patch you will see that it indeed > solves a problem independent of bdb version used so the code does not depend > on a side effect anymore. > > On one hand the void pointer *data should not be dangeling and therefore > initialization with NULL is correct. *data will only be referenced if ldap_pvt_thread_pool_getkey() succeeds. If that function succeeds, data will have a value. There is no dangling pointer here. > On the other hand TXN_ABORT() must not be called with potentially dangeling > pointers and therefor a trivial check for the validitiy of the pointer is a > good idea. Likewise, bdb_reader_free() will only get called as a result of successful pool_setkey() calls. There will be no dangling pointers there either. Since most of this code has been in place since 2002 and no one else has reported the problem before, it seems to me that OpenPKG is doing something very unusual. And being unable to reproduce the problem ourselves, I'd like to see exactly what they're doing to cause it. I've committed part of the patch in the meantime, but until we see steps to reproduce the crash, I'm unconvinced that this is any meaningful change. -- -- 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: [Fwd: RE: (ITS#6019) puzon@eska.pl]
by hyc＠symas.com 17 Mar '09

17 Mar '09

This appears to be a dup of ITS#6014. Closing this one, send all future followups to #6014. michael(a)stroeder.com wrote: > The stack trace was sent to me personally. :-/ > > -------- Original Message -------- > Subject: RE: (ITS#6019) puzon(a)eska.pl > Date: Fri, 13 Mar 2009 15:09:04 +0100 > From: Lukasz PUZON Brodowski<puzon(a)eska.pl> > To: 'Michael Ströder'<michael(a)stroeder.com> > References:<200903121120.n2CBKHqo032649(a)boole.openldap.org> > <49B90F15.5070309(a)stroeder.com> > > Hi Michael > > Here is gdb: > (15:07:44<~>) 0 # gdb > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 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 "i386-marcel-freebsd". > (gdb) file ldapsearch > Reading symbols from ldapsearch...(no debugging symbols found)...done. > (gdb) run -x -W -D 'cn=Manager,dc=eska' -b "" -s base > Starting program: /usr/local/bin/ldapsearch -x -W -D 'cn=Manager,dc=eska' -b > "" -s base > (no debugging symbols found)...(no debugging symbols found)...(no debugging > symbols found)...(no debugging symbols found)...(no debugging symbols > found)...(no debugging symbols found)...(no debugging symbols found)...(no > debugging symbols found)...(no debugging symbols found)...Enter LDAP > Password: > # extended LDIF > # > # LDAPv3 > # base<> with scope baseObject > # filter: (objectclass=*) > # requesting: ALL > # > > # > dn: > objectClass: top > objectClass: OpenLDAProotDSE > > # search result > search: 2 > result: 0 Success > > # numResponses: 2 > # numEntries: 1 > > Program received signal SIGSEGV, Segmentation fault. > 0x282eb3f0 in free () from /lib/libc.so.7 > > > -- -- 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#6025) ldapdelete cannot handle base64 encoded dns
by hyc＠symas.com 17 Mar '09

17 Mar '09

quanah(a)OpenLDAP.org wrote: > Full_Name: Quanah Gibson-Mount > Version: RE24/HEAD > OS: NA > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.111.29.239) > > > As noted in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=334354 the OpenLDAP > ldapdelete utility cannot handle base-64 encoded DNs, even though the other > ldap* tools can. It would add to the tool consistency for ldapdelete to conform > with the other tools in this respect. Why are you bothering to report this now, when the original bug was filed in 2005 and went unanswered until last month? I agree with Peter Marschall's response - this is not a bug, and your assertion "other ldap* tools can" is false. ldapdelete is documented to take a list of DNs. It does *NOT* say that it takes them in LDIF format, and LDIF is the only relevant format specification that uses base64. As such, "DN" should only be taken to mean RFC4514 compliant strings. The only tool that accepts LDIF is ldapmodify (and ldapadd is just a symlink to ldapmodify). All of the other tools are specifically documented to take DNs, not LDIF. 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#6021) slapo-pcache/back-ldap slapd crashes
by toby＠inf.ed.ac.uk 17 Mar '09

17 Mar '09

> I did my best to reproduce your setup, but I got no crashes. One > thing I'd like to ask is: I see some non-standard attributes in the > pcache configuration. Can you tell whether there might occur some > schema inconsistencies between the remote server and the proxy? No, they're the same - the schema files are distributed via RPM and configured in slapd.conf with the same bit of configuration code. > Also, can you tell how often crashes occur, or any detail about the > type of operation, the workload and so? The machines I'm currently testing with are all in a student lab, running condor jobs when quiet, so a bit difficult to predict - I haven't seen any discernible pattern so far - I've seen crashes on busy machines and quiet ones. For the core file we're looking at here, this machine had answered 9 queries in the second prior to the crash, but had been quiet for 3 minutes prior to that after it had removed stale entries from the cache. I can attach a portion of the slapd log if it would be useful. As for how often the crashes occur, these 24 lab machines have been running 2.4.15 built with no optimisation since 27th Feb and have produced 18 core files in that time. Of these, approximately half have been assertion failures for free(p) in memory.c:152. I've seen 3 cases of segfaults in pcache_filter_cmp, as mentioned in ITS#5756, but I'll submit non-optimised backtraces to that ticket, rather than confuse the issue here. > I also disabled slab allocation, so that true mallocs occur all > times, and valgrind is not showing any memory issue. The difficulty is in trying to reproduce this - my own desktop machine is running with the same setup and has never crashed, despite my best efforts. Cheers Toby -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.

1 0

Re: (ITS#6027) Debug() accesses free()-d memory in register_at() on error
by hyc＠symas.com 17 Mar '09

17 Mar '09

ando(a)sys-net.it wrote: > test.007(a)seznam.cz wrote: >> Full_Name: Test Seven >> Version: 2.4.15 >> OS: Windows >> URL: >> Submission from: (NULL) (195.39.55.20) > > Fixed in HEAD, please test. Thanks, p. The fix looks fine, but I was unable to reproduce the original error. It seems their build is broken. -- -- 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#6027) Debug() accesses free()-d memory in register_at() on error
by ando＠sys-net.it 17 Mar '09

17 Mar '09

test.007(a)seznam.cz wrote: > Full_Name: Test Seven > Version: 2.4.15 > OS: Windows > URL: > Submission from: (NULL) (195.39.55.20) Fixed in HEAD, please test. Thanks, 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

(ITS#6027) Debug() accesses free()-d memory in register_at() on error
by test.007＠seznam.cz 17 Mar '09

17 Mar '09

Full_Name: Test Seven Version: 2.4.15 OS: Windows URL: Submission from: (NULL) (195.39.55.20) http://www.openldap.org/devel/cvsweb.cgi/~checkout~/servers/slapd/at.c?rev=… ldap_attributetype_free( at ); Debug( LDAP_DEBUG_ANY, "register_at: AttributeType \"%s\": %s, %s\n", def, scherr2str(code), err ); You should swap the lines, because ``err'' points inside ``at''. How to reproduce: Compile Debug version with LDAP_DEBUG e.g. with MSVC 2005. Don't configure it slapd.exe -d9 Output: register_at: AttributeType "( OLcfgDbAt:0.1 NAME 'olcDbDirectory' DESC 'Director y for database content' EQUALITY caseIgnoreMatch SYNTAX OMsDirectoryString SINGL E-VALUE )": OID could not be expanded, ŢŢŢŢŢŢŢŢŢŢŢŢŢŢŢŢŢŢ

1 0

Re: (ITS#6018) TLS memory leak
by timling2003＠gmail.com 16 Mar '09

16 Mar '09

I tested it again and found that there is not memory leak on gcc 4.1.2 and openssl 0.9.8c. The leak version is on gcc 3.3.5 and OpenSSL 0.9.7d. So, it may be not a bug of openLDAP but the other old version software.

1 0

Re: (ITS#6021) slapo-pcache/back-ldap slapd crashes
by ando＠sys-net.it 16 Mar '09

16 Mar '09

toby(a)inf.ed.ac.uk wrote: > On 14 Mar 2009, at 15:49, Pierangelo Masarati wrote: > > Hello, > > Thanks for your quick reply. > >>> (gdb) bt >>> #0 0x00b8d402 in __kernel_vsyscall () >>> #1 0x009e8d20 in raise () from /lib/libc.so.6 >>> #2 0x009ea631 in abort () from /lib/libc.so.6 >>> #3 0x00a20e6b in __libc_message () from /lib/libc.so.6 >>> #4 0x00a28b16 in _int_free () from /lib/libc.so.6 >>> #5 0x00a2c070 in free () from /lib/libc.so.6 >>> #6 0x081d5746 in ber_memfree_x (p=0xa6809478, ctx=0x0) at memory.c: >>> 152 >>> #7 0x081d630c in ber_bvarray_free_x (a=0x9049bb8, ctx=0x0) at >>> memory.c:731 >>> #8 0x081d6343 in ber_bvarray_free (a=0x9049bb8) at memory.c:741 >>> #9 0x08079757 in attr_clean (a=0xb62d41bc) at attr.c:134 >> The problem seems to be here; apparently, the a->a_nvals array is >> being incorrectly freed. If you have those core files around, it >> would be interesting to see the contents of those attributes, e.g. >> >> p *a >> p a->a_desc[0] >> p a->a_flags >> p a->a_nvals[0] >> >> from within frame 9. > > > (gdb) up > #9 0x08079757 in attr_clean (a=0xb62d41bc) at attr.c:134 > 134 ber_bvarray_free( a->a_nvals ); > (gdb) p *a > $1 = {a_desc = 0x8faa150, a_vals = 0x90487f0, a_nvals = 0x9049bb8, > a_numvals = 631, a_flags = 0, a_next = 0x0} > (gdb) p a->a_desc[0] > $2 = {ad_next = 0x0, ad_type = 0x8fbba20, ad_cname = {bv_len = 9, > bv_val = 0x8fba5d8 "memberUid"}, ad_tags = {bv_len = 0, bv_val = > 0x0}, > ad_flags = 0} > (gdb) p a->a_flags > $3 = 0 > (gdb) p a->a_nvals[0] > $4 = {bv_len = 8, bv_val = 0x905aac0 "v1ggoodh"} > (gdb) > > >>> #10 0x0807983b in attrs_free (a=0xb62d41bc) at attr.c:196 >>> #11 0x0807c059 in entry_clean (e=0xb5acfdbc) at entry.c:504 >>> #12 0x0811ec17 in ldap_back_search (op=0xa680e5d8, rs=0xb5ad10e0) >>> at search.c:354 >> Also, it would be interesting to see the parameters of the search; >> e.g. >> >> p op->o_req_ndn >> p op->o_request.oq_search >> p op->o_request.oq_search.rs_filterstr >> p op->o_request.oq_search.rs_attrs[0] (unless NULL) >> >> from within frame 12 > > > (gdb) up > #12 0x0811ec17 in ldap_back_search (op=0xa680e5d8, rs=0xb5ad10e0) > at search.c:354 > 354 entry_clean( &ent ); > (gdb) p op->o_req_ndn > $5 = {bv_len = 24, bv_val = 0xb44ce1e4 "dc=inf,dc=ed,dc=ac,dc=uk"} > (gdb) p op->o_request.oq_search > $6 = {rs_scope = 2, rs_deref = 0, rs_slimit = 24576, rs_tlimit = 3600, > rs_limit = 0x8fa88b8, rs_attrsonly = 0, rs_attrs = 0xb44ce904, > rs_filter = 0xb44ce86c, rs_filterstr = {bv_len = 112, > bv_val = 0xb44ce87c "(&(objectClass=posixGroup)(| > (memberUid=vlavrenk) > (uniqueMember=uid=vlavrenk,ou=people,dc=inf,dc=ed,dc=ac,dc=uk)))"}} > (gdb) p op->o_request.oq_search.rs_filterstr > $7 = {bv_len = 112, > bv_val = 0xb44ce87c "(&(objectClass=posixGroup)(| > (memberUid=vlavrenk) > (uniqueMember=uid=vlavrenk,ou=people,dc=inf,dc=ed,dc=ac,dc=uk)))"} > (gdb) p op->o_request.oq_search.rs_attrs[0] > $8 = {an_name = {bv_len = 9, bv_val = 0x907b012 "gidNumber"}, > an_desc = 0x8f85930, an_oc_exclude = 0, an_oc = 0x0} > (gdb) > > >> Finally, it would be great to see your slapd.conf. > > > No problem, this is the database, back-ldap, pcache part of it: > > database ldap > suffix dc=inf,dc=ed,dc=ac,dc=uk > rootdn uid=ldaprep/ > hostname.inf.ed.ac.uk,cn=inf.ed.ac.uk,cn=gssapi,cn=auth > uri "ldap://server1.inf.ed.ac.uk/,ldap:// > server2.inf.ed.ac.uk" > idassert-bind mode=none > bindmethod=sasl > saslmech=GSSAPI > idassert-authzFrom "dn:*" > > overlay pcache > > proxycache bdb 5000 4 500 300 > proxycachequeries 10000 > > proxyattrset 0 cn userPassword memberUid uniqueMember > gidNumber > proxyattrset 1 uid userPassword uidNumber gidNumber cn > homeDirectory > loginShell gecos description objectClass afsHomeDirectory primaryRoles > secondary > Roles > proxyattrset 2 cn nisNetgroupTriple memberNisNetgroup > proxyattrset 3 "*" > > proxytemplate (uid=) 1 1800 1800 > proxytemplate (&(objectClass=)(uid=)) 1 1800 1800 > proxytemplate (&(objectClass=)(cn=)) 0 1800 1800 > proxytemplate (&(objectClass=)(cn=)) 2 1800 1800 > proxytemplate (&(objectClass=)(|(memberUid=) > (uniqueMember=))) 0 1800 1800 > proxytemplate (&(objectClass=)(uniqueMember=)) 0 1800 1800 > proxytemplate (&(objectClass=)(memberUid=)) 0 1800 1800 > proxytemplate (&(objectClass=)(uidNumber=)) 1 1800 1800 > proxytemplate (&(objectClass=)(gidNumber=)) 0 1800 1800 > proxytemplate (&(objectClass=)(amdmapName=)(amdmapKey=)) 3 > 1800 1800 > proxytemplate (&(objectClass=)(uid=)) 3 1800 1800 > > directory /var/openldap-data > > checkpoint 128 60 > cachesize 10000 > idlcachesize 10000 > > dbconfig set_cachesize 0 16777216 1 > dbconfig set_lg_regionmax 262144 > dbconfig set_lg_bsize 2097152 > > > If there's anything else that would be useful, let me know. As I > mentioned, I have a number of other core files, including some that > look the same as this one. I did my best to reproduce your setup, but I got no crashes. One thing I'd like to ask is: I see some non-standard attributes in the pcache configuration. Can you tell whether there might occur some schema inconsistencies between the remote server and the proxy? Also, can you tell how often crashes occur, or any detail about the type of operation, the workload and so? I also disabled slab allocation, so that true mallocs occur all times, and valgrind is not showing any memory issue. 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#6021) slapo-pcache/back-ldap slapd crashes
by toby＠inf.ed.ac.uk 16 Mar '09

16 Mar '09

On 14 Mar 2009, at 15:49, Pierangelo Masarati wrote: Hello, Thanks for your quick reply. >> (gdb) bt >> #0 0x00b8d402 in __kernel_vsyscall () >> #1 0x009e8d20 in raise () from /lib/libc.so.6 >> #2 0x009ea631 in abort () from /lib/libc.so.6 >> #3 0x00a20e6b in __libc_message () from /lib/libc.so.6 >> #4 0x00a28b16 in _int_free () from /lib/libc.so.6 >> #5 0x00a2c070 in free () from /lib/libc.so.6 >> #6 0x081d5746 in ber_memfree_x (p=0xa6809478, ctx=0x0) at memory.c: >> 152 >> #7 0x081d630c in ber_bvarray_free_x (a=0x9049bb8, ctx=0x0) at >> memory.c:731 >> #8 0x081d6343 in ber_bvarray_free (a=0x9049bb8) at memory.c:741 >> #9 0x08079757 in attr_clean (a=0xb62d41bc) at attr.c:134 > > The problem seems to be here; apparently, the a->a_nvals array is > being incorrectly freed. If you have those core files around, it > would be interesting to see the contents of those attributes, e.g. > > p *a > p a->a_desc[0] > p a->a_flags > p a->a_nvals[0] > > from within frame 9. (gdb) up #9 0x08079757 in attr_clean (a=0xb62d41bc) at attr.c:134 134 ber_bvarray_free( a->a_nvals ); (gdb) p *a $1 = {a_desc = 0x8faa150, a_vals = 0x90487f0, a_nvals = 0x9049bb8, a_numvals = 631, a_flags = 0, a_next = 0x0} (gdb) p a->a_desc[0] $2 = {ad_next = 0x0, ad_type = 0x8fbba20, ad_cname = {bv_len = 9, bv_val = 0x8fba5d8 "memberUid"}, ad_tags = {bv_len = 0, bv_val = 0x0}, ad_flags = 0} (gdb) p a->a_flags $3 = 0 (gdb) p a->a_nvals[0] $4 = {bv_len = 8, bv_val = 0x905aac0 "v1ggoodh"} (gdb) >> #10 0x0807983b in attrs_free (a=0xb62d41bc) at attr.c:196 >> #11 0x0807c059 in entry_clean (e=0xb5acfdbc) at entry.c:504 >> #12 0x0811ec17 in ldap_back_search (op=0xa680e5d8, rs=0xb5ad10e0) >> at search.c:354 > > Also, it would be interesting to see the parameters of the search; > e.g. > > p op->o_req_ndn > p op->o_request.oq_search > p op->o_request.oq_search.rs_filterstr > p op->o_request.oq_search.rs_attrs[0] (unless NULL) > > from within frame 12 (gdb) up #12 0x0811ec17 in ldap_back_search (op=0xa680e5d8, rs=0xb5ad10e0) at search.c:354 354 entry_clean( &ent ); (gdb) p op->o_req_ndn $5 = {bv_len = 24, bv_val = 0xb44ce1e4 "dc=inf,dc=ed,dc=ac,dc=uk"} (gdb) p op->o_request.oq_search $6 = {rs_scope = 2, rs_deref = 0, rs_slimit = 24576, rs_tlimit = 3600, rs_limit = 0x8fa88b8, rs_attrsonly = 0, rs_attrs = 0xb44ce904, rs_filter = 0xb44ce86c, rs_filterstr = {bv_len = 112, bv_val = 0xb44ce87c "(&(objectClass=posixGroup)(| (memberUid=vlavrenk) (uniqueMember=uid=vlavrenk,ou=people,dc=inf,dc=ed,dc=ac,dc=uk)))"}} (gdb) p op->o_request.oq_search.rs_filterstr $7 = {bv_len = 112, bv_val = 0xb44ce87c "(&(objectClass=posixGroup)(| (memberUid=vlavrenk) (uniqueMember=uid=vlavrenk,ou=people,dc=inf,dc=ed,dc=ac,dc=uk)))"} (gdb) p op->o_request.oq_search.rs_attrs[0] $8 = {an_name = {bv_len = 9, bv_val = 0x907b012 "gidNumber"}, an_desc = 0x8f85930, an_oc_exclude = 0, an_oc = 0x0} (gdb) > Finally, it would be great to see your slapd.conf. No problem, this is the database, back-ldap, pcache part of it: database ldap suffix dc=inf,dc=ed,dc=ac,dc=uk rootdn uid=ldaprep/ hostname.inf.ed.ac.uk,cn=inf.ed.ac.uk,cn=gssapi,cn=auth uri "ldap://server1.inf.ed.ac.uk/,ldap:// server2.inf.ed.ac.uk" idassert-bind mode=none bindmethod=sasl saslmech=GSSAPI idassert-authzFrom "dn:*" overlay pcache proxycache bdb 5000 4 500 300 proxycachequeries 10000 proxyattrset 0 cn userPassword memberUid uniqueMember gidNumber proxyattrset 1 uid userPassword uidNumber gidNumber cn homeDirectory loginShell gecos description objectClass afsHomeDirectory primaryRoles secondary Roles proxyattrset 2 cn nisNetgroupTriple memberNisNetgroup proxyattrset 3 "*" proxytemplate (uid=) 1 1800 1800 proxytemplate (&(objectClass=)(uid=)) 1 1800 1800 proxytemplate (&(objectClass=)(cn=)) 0 1800 1800 proxytemplate (&(objectClass=)(cn=)) 2 1800 1800 proxytemplate (&(objectClass=)(|(memberUid=) (uniqueMember=))) 0 1800 1800 proxytemplate (&(objectClass=)(uniqueMember=)) 0 1800 1800 proxytemplate (&(objectClass=)(memberUid=)) 0 1800 1800 proxytemplate (&(objectClass=)(uidNumber=)) 1 1800 1800 proxytemplate (&(objectClass=)(gidNumber=)) 0 1800 1800 proxytemplate (&(objectClass=)(amdmapName=)(amdmapKey=)) 3 1800 1800 proxytemplate (&(objectClass=)(uid=)) 3 1800 1800 directory /var/openldap-data checkpoint 128 60 cachesize 10000 idlcachesize 10000 dbconfig set_cachesize 0 16777216 1 dbconfig set_lg_regionmax 262144 dbconfig set_lg_bsize 2097152 If there's anything else that would be useful, let me know. As I mentioned, I have a number of other core files, including some that look the same as this one. Cheers Toby -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.

1 0

ITS#6019
by puzon＠eska.pl 16 Mar '09

16 Mar '09

(15:07:44 <~>) 0 # gdb GNU gdb 6.1.1 [FreeBSD] Copyright 2004 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 "i386-marcel-freebsd". (gdb) file ldapsearch Reading symbols from ldapsearch...(no debugging symbols found)...done. (gdb) run -x -W -D 'cn=Manager,dc=eska' -b "" -s base Starting program: /usr/local/bin/ldapsearch -x -W -D 'cn=Manager,dc=eska' -b "" -s base (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...Enter LDAP Password: # extended LDIF # # LDAPv3 # base <> with scope baseObject # filter: (objectclass=*) # requesting: ALL # # dn: objectClass: top objectClass: OpenLDAProotDSE # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 Program received signal SIGSEGV, Segmentation fault. 0x282eb3f0 in free () from /lib/libc.so.7

1 0

(ITS#6026) Don't run autosaved test scripts
by rein＠OpenLDAP.org 16 Mar '09

16 Mar '09

Full_Name: Rein Tollevik Version: CVS HEAD OS: Irrelevant URL: Submission from: (NULL) (81.93.160.250) Submitted by: rein When running the entire test suite it happily includes autosaved versions of the test scripts. Which can be a bit annoying if the scripts are edited with an editor that loves to leave autosave files around.. A fix is coming. Rein Tollevik Basefarm AS

1 0

Re: (ITS#6018) TLS memory leak
by timling2003＠gmail.com 16 Mar '09

16 Mar '09

As you methioned, I move ldap_set_option() with NULL to the main thread. And, I also use libldap_r instead of libldap. A specific handler is really only used in a single thread. In every thread, it always returns NULL, because it is just a test code and it always print "connect ok" while it is running. I think memory leak may happen when the code of openLDAP uses openssl function such as initialize connection in ldap_start_tls_s(). For every thread, there may be some special structures for SSL/TLS which need to be freed after the end of the thread. I find that Windows has a function ldap_stop_tls_s() related to ldap_start_tls_s(). For my software, I want to create processes instead of threads to avoid this problem.

1 0

Re: (ITS#6018) TLS memory leak
by hyc＠symas.com 16 Mar '09

16 Mar '09

ando(a)sys-net.it wrote: > I see at least two issues in your code. See below for specific comments. The code also fails to compile for me because struct timeval is undefined. Having fixed that, valgrind shows no leaks for me. -- -- 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#6018) TLS memory leak
by ando＠sys-net.it 16 Mar '09

16 Mar '09

I see at least two issues in your code. See below for specific comments. ling qing wrote: > The sample code is as follows. > Make command: > g++ testmem.C lib/libldap-2.4.so.2 lib/libsasl2.so.2 lib/liblber-2.4.so.2 > -Iinclude/ -Llib/ -DLDAP_DEPRECATED -g -lpthread > If mode is normal, it's ok. If mode is TLS, there is memory leak even if you > don't input bind dn. If mode is SSL, memory leak only happens when you input > bind dn and password. > The openLDAP lib is the latest release version 2.4.15. > > I am sure that this is a bug of openLDAP. > > #include "ldap.h" > #include <string> > #include <unistd.h> > > using namespace std; > > typedef enum LDAP_TRANS_METHOD {LDAP_TRANS_NORMAL, LDAP_TRANS_TLS, > LDAP_TRANS_SSL}; > > LDAP_TRANS_METHOD transMethod = LDAP_TRANS_NORMAL; > const char * host = NULL; > const char * binddn = NULL; > const char * bindpwd = NULL; > int connectnum = 0; > > void * connectLDAP(void * param) > { > LDAP * ld; > > int rc; > string url; > if( transMethod == LDAP_TRANS_SSL ) > url = "ldaps://"; > else > url = "ldap://"; > if( host == NULL ) > return NULL; > url.append(host); > > struct timeval tvout; > tvout.tv_sec = 10; > tvout.tv_usec = 0; > > if( ldap_set_option( NULL, LDAP_OPT_NETWORK_TIMEOUT, &tvout ) != > LDAP_OPT_SUCCESS ) > { > printf("ldap_set_option LDAP_OPT_NETWORK_TIMEOUT failed\n"); > return NULL; > } > > rc = ldap_initialize(&ld, url.c_str()); > if( rc != LDAP_SUCCESS || ld == NULL ) > { > printf("ldap_initialize failed!\n"); > return NULL; > } > > if( transMethod == LDAP_TRANS_TLS || transMethod == LDAP_TRANS_SSL ) > { > int protocol = 3; > if( ldap_set_option( ld, LDAP_OPT_PROTOCOL_VERSION, &protocol ) != > LDAP_OPT_SUCCESS ) > { > printf("ldap_set_option LDAP_OPT_PROTOCOL_VERSION failed\n"); > return NULL; > } > int cert = 0; > if( ldap_set_option( NULL, LDAP_OPT_X_TLS_REQUIRE_CERT, &cert ) != > LDAP_OPT_SUCCESS ) You're not supposed to call ldap_set_option() with NULL handler from within a threaded program, as libldap is thread-safe only when a specific handler is only used from within a single thread. I'm not discussing the case of this specific option, nor of its side-effects, if any, as I didn't investigate it and I'm not specifically familiar with that portion of code. > { > printf("ldap_set_option LDAP_OPT_X_TLS_REQUIRE_CERT failed\n"); > return NULL; > } > } > > if( transMethod == LDAP_TRANS_TLS ) > { > rc = ldap_start_tls_s( ld, NULL, NULL ); > if( rc != LDAP_SUCCESS ) > { > printf("ldap_start_tls_s failed\n"); > return NULL; > } > } > > if( binddn != NULL && bindpwd != NULL ) > { > rc = ldap_bind_s(ld, binddn, bindpwd, LDAP_AUTH_SIMPLE); > if ( LDAP_SUCCESS != rc ) > { > printf("ldap_bind_s failed\n"); > return NULL; > } > } This code is filled with "return NULL;" without cleaning up memory if anything goes wrong. Are you sure everything is always going fine for all your threads during your tests? > > ldap_unbind_s(ld); > connectnum++; > printf("%d connect ok\n", connectnum); > return NULL; > } > > int main(int argc, char ** argv) > { > if(argc < 2) > { > printf("Usage: testmem <host> [mode] [bind dn] [bind pwd]\n"); > printf("mode: default: NORMAL; SSL;TLS\n"); > return 0; > } > string mode="NORMAL"; > if( argc > 2 ) > mode = argv[2]; > > if( mode == "SSL" ) > transMethod = LDAP_TRANS_SSL; > if( mode == "TLS" ) > transMethod = LDAP_TRANS_TLS; > host = argv[1]; > > if( argc > 4 ) > { > binddn = argv[3]; > bindpwd = argv[4]; > } > > do > { > pthread_t instance_thread ; > pthread_attr_t attr; > pthread_attr_init(&attr); > pthread_attr_setdetachstate(&attr, PTHREAD_CREATE_DETACHED); > int rc = pthread_create(&instance_thread, &attr, connectLDAP, NULL) ; > pthread_attr_destroy(&attr); > if (rc) > { > printf("Fail to create policy server instance thread\n") ; > break; > } > sleep(1); > }while(1); > return 0; > } > 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#6018) TLS memory leak
by timling2003＠gmail.com 15 Mar '09

15 Mar '09

--000e0cd149d4a04c48046533de2c Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit The sample code is as follows. Make command: g++ testmem.C lib/libldap-2.4.so.2 lib/libsasl2.so.2 lib/liblber-2.4.so.2 -Iinclude/ -Llib/ -DLDAP_DEPRECATED -g -lpthread If mode is normal, it's ok. If mode is TLS, there is memory leak even if you don't input bind dn. If mode is SSL, memory leak only happens when you input bind dn and password. The openLDAP lib is the latest release version 2.4.15. I am sure that this is a bug of openLDAP. #include "ldap.h" #include <string> #include <unistd.h> using namespace std; typedef enum LDAP_TRANS_METHOD {LDAP_TRANS_NORMAL, LDAP_TRANS_TLS, LDAP_TRANS_SSL}; LDAP_TRANS_METHOD transMethod = LDAP_TRANS_NORMAL; const char * host = NULL; const char * binddn = NULL; const char * bindpwd = NULL; int connectnum = 0; void * connectLDAP(void * param) { LDAP * ld; int rc; string url; if( transMethod == LDAP_TRANS_SSL ) url = "ldaps://"; else url = "ldap://"; if( host == NULL ) return NULL; url.append(host); struct timeval tvout; tvout.tv_sec = 10; tvout.tv_usec = 0; if( ldap_set_option( NULL, LDAP_OPT_NETWORK_TIMEOUT, &tvout ) != LDAP_OPT_SUCCESS ) { printf("ldap_set_option LDAP_OPT_NETWORK_TIMEOUT failed\n"); return NULL; } rc = ldap_initialize(&ld, url.c_str()); if( rc != LDAP_SUCCESS || ld == NULL ) { printf("ldap_initialize failed!\n"); return NULL; } if( transMethod == LDAP_TRANS_TLS || transMethod == LDAP_TRANS_SSL ) { int protocol = 3; if( ldap_set_option( ld, LDAP_OPT_PROTOCOL_VERSION, &protocol ) != LDAP_OPT_SUCCESS ) { printf("ldap_set_option LDAP_OPT_PROTOCOL_VERSION failed\n"); return NULL; } int cert = 0; if( ldap_set_option( NULL, LDAP_OPT_X_TLS_REQUIRE_CERT, &cert ) != LDAP_OPT_SUCCESS ) { printf("ldap_set_option LDAP_OPT_X_TLS_REQUIRE_CERT failed\n"); return NULL; } } if( transMethod == LDAP_TRANS_TLS ) { rc = ldap_start_tls_s( ld, NULL, NULL ); if( rc != LDAP_SUCCESS ) { printf("ldap_start_tls_s failed\n"); return NULL; } } if( binddn != NULL && bindpwd != NULL ) { rc = ldap_bind_s(ld, binddn, bindpwd, LDAP_AUTH_SIMPLE); if ( LDAP_SUCCESS != rc ) { printf("ldap_bind_s failed\n"); return NULL; } } ldap_unbind_s(ld); connectnum++; printf("%d connect ok\n", connectnum); return NULL; } int main(int argc, char ** argv) { if(argc < 2) { printf("Usage: testmem <host> [mode] [bind dn] [bind pwd]\n"); printf("mode: default: NORMAL; SSL;TLS\n"); return 0; } string mode="NORMAL"; if( argc > 2 ) mode = argv[2]; if( mode == "SSL" ) transMethod = LDAP_TRANS_SSL; if( mode == "TLS" ) transMethod = LDAP_TRANS_TLS; host = argv[1]; if( argc > 4 ) { binddn = argv[3]; bindpwd = argv[4]; } do { pthread_t instance_thread ; pthread_attr_t attr; pthread_attr_init(&attr); pthread_attr_setdetachstate(&attr, PTHREAD_CREATE_DETACHED); int rc = pthread_create(&instance_thread, &attr, connectLDAP, NULL) ; pthread_attr_destroy(&attr); if (rc) { printf("Fail to create policy server instance thread\n") ; break; } sleep(1); }while(1); return 0; } --000e0cd149d4a04c48046533de2c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The sample code is as follows. Make command: g++ testmem.C lib/liblda= p-2.4.so.2 lib/libsasl2.so.2 lib/liblber-2.4.so.2 -Iinclude/ -Llib/ -DLDAP_= DEPRECATED -g -lpthread If mode is normal, it's ok. If mode is TLS, = there is memory leak even if you don't input bind dn. If mode is SSL, m= emory leak only happens when you input bind dn and password. The openLDAP lib is the latest release version 2.4.15. I am sure tha= t this is a bug of openLDAP. #include "ldap.h" #include= <string> #include <unistd.h> using namespace std;<br= > typedef enum LDAP_TRANS_METHOD {LDAP_TRANS_NORMAL, LDAP_TRANS_TLS, LDAP= _TRANS_SSL}; LDAP_TRANS_METHOD transMethod =3D LDAP_TRANS_NORMAL;<br= >const char * host =3D NULL; const char * binddn =3D NULL; const char= * bindpwd =3D NULL; int connectnum =3D 0; void * connectLDAP(void * param) { =A0= =A0=A0 LDAP * ld; =A0=A0=A0 =A0 int rc; =A0 string url; =A0 if= ( transMethod =3D=3D LDAP_TRANS_SSL ) =A0=A0=A0=A0=A0 url =3D "ldap= s://"; =A0 else =A0=A0=A0=A0=A0 url =3D "ldap://"; =A0 if( host =3D=3D NULL ) =A0 =A0=A0=A0 return NULL; =A0 url.append(= host); =A0=A0=A0 =A0 struct timeval tvout; =A0 tvout.tv_sec =3D 1= 0; =A0 tvout.tv_usec =3D 0; =A0=A0=A0 if( ldap_set_option( NULL, = LDAP_OPT_NETWORK_TIMEOUT, &tvout ) !=3D LDAP_OPT_SUCCESS ) =A0=A0=A0 { =A0=A0=A0 =A0=A0=A0 printf("ldap_set_option LDAP_OPT_NE= TWORK_TIMEOUT failed\n"); =A0=A0=A0 =A0=A0=A0 return NULL; =A0= =A0=A0 } =A0=A0=A0 =A0 rc =3D ldap_initialize(&ld, url.c_str());= =A0 if( rc !=3D LDAP_SUCCESS || ld =3D=3D NULL ) =A0 { =A0 =A0=A0=A0 printf("ldap_initialize failed!\n"); = =A0=A0=A0 return NULL; =A0 } =A0 if( transMethod =3D=3D LDAP_TRAN= S_TLS || transMethod =3D=3D LDAP_TRANS_SSL ) =A0 { =A0=A0=A0 =A0=A0= =A0 int protocol =3D 3; =A0=A0=A0 if( ldap_set_option( ld, LDAP_OPT_PROT= OCOL_VERSION, &protocol ) !=3D LDAP_OPT_SUCCESS ) =A0=A0=A0 { =A0=A0=A0 =A0=A0=A0 =A0=A0=A0 printf("ldap_set_option L= DAP_OPT_PROTOCOL_VERSION failed\n"); =A0=A0=A0=A0=A0=A0=A0 return N= ULL; =A0=A0=A0 } =A0=A0=A0 int cert =3D 0; =A0=A0=A0 if( ldap_set_= option( NULL, LDAP_OPT_X_TLS_REQUIRE_CERT, &cert ) !=3D LDAP_OPT_SUCCES= S ) =A0=A0=A0 { =A0=A0=A0 =A0=A0=A0 =A0 printf("ldap_set_option LDAP_OP= T_X_TLS_REQUIRE_CERT failed\n"); =A0=A0=A0=A0=A0=A0=A0 return NULL;= =A0=A0=A0 } =A0 } =A0 if( transMethod =3D=3D LDAP_TRANS_TLS )= =A0 { =A0=A0=A0 rc =3D ldap_start_tls_s( ld, NULL, NULL ); =A0=A0=A0 if( rc !=3D LDAP_SUCCESS ) =A0=A0=A0 { =A0=A0=A0 =A0=A0=A0 = =A0 printf("ldap_start_tls_s failed\n"); =A0=A0=A0=A0=A0=A0=A0= return NULL; =A0=A0=A0 } =A0 } =A0=A0=A0 if( binddn !=3D NULL= && bindpwd !=3D NULL ) =A0=A0=A0 { =A0=A0=A0 =A0=A0=A0 rc = =3D ldap_bind_s(ld,=A0 binddn, bindpwd, LDAP_AUTH_SIMPLE); =A0 =A0=A0=A0 if ( LDAP_SUCCESS !=3D rc ) =A0 =A0=A0=A0 { =A0 =A0=A0= =A0 =A0=A0=A0 printf("ldap_bind_s failed\n"); =A0=A0=A0=A0=A0 = return NULL; =A0 =A0=A0=A0 } =A0=A0=A0 } =A0=A0=A0 =A0=A0=A0 l= dap_unbind_s(ld); =A0=A0=A0 connectnum++; =A0=A0=A0 printf("%d c= onnect ok\n", connectnum); =A0=A0=A0 return NULL; } int main(int argc, char ** argv) {<br= >=A0=A0=A0 if(argc < 2) =A0=A0=A0 { =A0=A0=A0 =A0=A0=A0 printf(&qu= ot;Usage: testmem <host> [mode] [bind dn] [bind pwd]\n"); =A0= =A0=A0 =A0=A0=A0 printf("mode: default: NORMAL; SSL;TLS\n"); =A0=A0=A0 =A0=A0=A0 return 0; =A0=A0=A0 } =A0=A0=A0 string mode=3D&qu= ot;NORMAL"; =A0=A0=A0 if( argc > 2 ) =A0=A0=A0 =A0=A0=A0 mode= =3D argv[2]; =A0=A0=A0 if( mode =3D=3D "SSL" ) =A0=A0= =A0 =A0=A0=A0 transMethod =3D LDAP_TRANS_SSL; =A0 if( mode =3D=3D "= TLS" ) =A0=A0=A0 transMethod =3D LDAP_TRANS_TLS; =A0 host =3D argv[1]; =A0 <= br>=A0=A0=A0 if( argc > 4 ) =A0=A0=A0 { =A0 =A0=A0=A0 binddn =3D a= rgv[3]; =A0 =A0=A0=A0 bindpwd =3D argv[4]; =A0=A0=A0=A0 } =A0 = =A0 do =A0 { =A0=A0=A0 pthread_t instance_thread ; =A0 =A0=A0=A0 p= thread_attr_t attr; =A0 =A0=A0=A0 pthread_attr_init(&attr); =A0 =A0=A0=A0 pthread_attr_s= etdetachstate(&attr, PTHREAD_CREATE_DETACHED); =A0 =A0=A0=A0 int rc = =3D pthread_create(&instance_thread, &attr, connectLDAP, NULL) ;<br= >=A0 =A0=A0=A0 pthread_attr_destroy(&attr); =A0=A0=A0 if (rc) =A0=A0=A0 { =A0=A0=A0=A0=A0=A0=A0 printf("Fail= to create policy server instance thread\n") ; =A0=A0=A0=A0=A0=A0= =A0 break; =A0=A0=A0 } =A0=A0=A0 sleep(1); =A0=A0=A0 }while(1);<br= >=A0=A0=A0 return 0; } --000e0cd149d4a04c48046533de2c--

1 0

(ITS#6025) ldapdelete cannot handle base64 encoded dns
by quanah＠OpenLDAP.org 15 Mar '09

15 Mar '09

Full_Name: Quanah Gibson-Mount Version: RE24/HEAD OS: NA URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.29.239) As noted in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=334354 the OpenLDAP ldapdelete utility cannot handle base-64 encoded DNs, even though the other ldap* tools can. It would add to the tool consistency for ldapdelete to conform with the other tools in this respect. --Quanah

1 0

(ITS#6024) Don't send cookie with without csn field
by rein＠OpenLDAP.org 15 Mar '09

15 Mar '09

Full_Name: Rein Tollevik Version: CVS HEAD OS: Irrelevant URL: Submission from: (NULL) (84.215.36.97) Submitted by: rein Syncprov sends a cookie to its consumer even when it doesn't have any csn values, i.e the cookie will only have the rid= and sid= fields. This can happen during initial load (as in test050) when a syncrepl consumer enters the present phase before the provider have finished the refresh phase with its own provider. This doesn't seem to harm the consumer, as it appears to silently ignore these cookies. But it can be confusing for somone trying to analyze the logs.. A fix is coming. Rein Tollevik Basefarm AS

1 0

Re: (ITS#6021) slapo-pcache/back-ldap slapd crashes
by ando＠sys-net.it 14 Mar '09

14 Mar '09

toby(a)inf.ed.ac.uk wrote: > Full_Name: Toby Blake > Version: 2.4.15 > OS: Scientific Linux 5.2 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (129.215.197.95) > > > Hi there, > > I have been testing slapo-pcache/back-ldap for some time now, > typically in student lab situations (to provide a localhost > proxycaching slapd with back-ldap connecting (via gssapi) to several > remote servers), initially using 2.3.x but I have recently moved to > using the latest 2.4.x versions, as it's clear that's where the > development effort is going. > > I'm seeing quite a lot of crashes during my testing, with a few > different backtraces. I don't know whether you would prefer I > submitted these separately for different backtraces, so I'm opening > this ITS to get the process started... > > I have seen no way of reproducing these crashes. > > I'm currently using: > - openldap-2.4.15 on scientific linux 5.2 > - bdb 4.7.25 with 3 patches > - We build our own RPMs. I have openldap-2.4.15 with no optimisation > (-O0) for the purposes of debugging. > > The most common backtrace I see is an assertion failure in > memory.c:152. Here's an example: > > Program terminated with signal 6, Aborted. > #0 0x00b8d402 in __kernel_vsyscall () > (gdb) bt > #0 0x00b8d402 in __kernel_vsyscall () > #1 0x009e8d20 in raise () from /lib/libc.so.6 > #2 0x009ea631 in abort () from /lib/libc.so.6 > #3 0x00a20e6b in __libc_message () from /lib/libc.so.6 > #4 0x00a28b16 in _int_free () from /lib/libc.so.6 > #5 0x00a2c070 in free () from /lib/libc.so.6 > #6 0x081d5746 in ber_memfree_x (p=0xa6809478, ctx=0x0) at memory.c:152 > #7 0x081d630c in ber_bvarray_free_x (a=0x9049bb8, ctx=0x0) at memory.c:731 > #8 0x081d6343 in ber_bvarray_free (a=0x9049bb8) at memory.c:741 > #9 0x08079757 in attr_clean (a=0xb62d41bc) at attr.c:134 The problem seems to be here; apparently, the a->a_nvals array is being incorrectly freed. If you have those core files around, it would be interesting to see the contents of those attributes, e.g. p *a p a->a_desc[0] p a->a_flags p a->a_nvals[0] from within frame 9. > #10 0x0807983b in attrs_free (a=0xb62d41bc) at attr.c:196 > #11 0x0807c059 in entry_clean (e=0xb5acfdbc) at entry.c:504 > #12 0x0811ec17 in ldap_back_search (op=0xa680e5d8, rs=0xb5ad10e0) > at search.c:354 Also, it would be interesting to see the parameters of the search; e.g. p op->o_req_ndn p op->o_request.oq_search p op->o_request.oq_search.rs_filterstr p op->o_request.oq_search.rs_attrs[0] (unless NULL) from within frame 12 > #13 0x080f2b02 in overlay_op_walk (op=0xa680e5d8, rs=0xb5ad10e0, > which=op_search, oi=0x8fa9208, on=0x0) at backover.c:669 > #14 0x080f2d0a in over_op_func (op=0xa680e5d8, rs=0xb5ad10e0, which=op_search) > at backover.c:721 > #15 0x080f2dae in over_op_search (op=0xa680e5d8, rs=0xb5ad10e0) > at backover.c:743 > #16 0x080720d6 in fe_op_search (op=0xa680e5d8, rs=0xb5ad10e0) at search.c:366 > #17 0x08071a2c in do_search (op=0xa680e5d8, rs=0xb5ad10e0) at search.c:217 > #18 0x0806e705 in connection_operation (ctx=0xb5ad11d0, arg_v=0xa680e5d8) > at connection.c:1097 > #19 0x0806ebdf in connection_read_thread (ctx=0xb5ad11d0, argv=0x13) > at connection.c:1223 > #20 0x0819ecad in ldap_int_thread_pool_wrapper (xpool=0x8f86fa0) at tpool.c:663 > #21 0x00b3346b in start_thread () from /lib/libpthread.so.0 > #22 0x00a90dbe in clone () from /lib/libc.so.6 > (gdb) > > I have seen quite a few of these backtraces, although sometimes coming > through slap_sl_free (and a couple of other places) instead of > ber_bvarray_free_x. > > Let me know what further information I can provide. Finally, it would be great to see your slapd.conf. 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

[Fwd: RE: (ITS#6019) puzon@eska.pl]
by michael＠stroeder.com 14 Mar '09

14 Mar '09

The stack trace was sent to me personally. :-/ -------- Original Message -------- Subject: RE: (ITS#6019) puzon(a)eska.pl Date: Fri, 13 Mar 2009 15:09:04 +0100 From: Lukasz PUZON Brodowski <puzon(a)eska.pl> To: 'Michael Ströder' <michael(a)stroeder.com> References: <200903121120.n2CBKHqo032649(a)boole.openldap.org> <49B90F15.5070309(a)stroeder.com> Hi Michael Here is gdb: (15:07:44 <~>) 0 # gdb GNU gdb 6.1.1 [FreeBSD] Copyright 2004 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 "i386-marcel-freebsd". (gdb) file ldapsearch Reading symbols from ldapsearch...(no debugging symbols found)...done. (gdb) run -x -W -D 'cn=Manager,dc=eska' -b "" -s base Starting program: /usr/local/bin/ldapsearch -x -W -D 'cn=Manager,dc=eska' -b "" -s base (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...Enter LDAP Password: # extended LDIF # # LDAPv3 # base <> with scope baseObject # filter: (objectclass=*) # requesting: ALL # # dn: objectClass: top objectClass: OpenLDAProotDSE # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 Program received signal SIGSEGV, Segmentation fault. 0x282eb3f0 in free () from /lib/libc.so.7

1 0

Re: (ITS#6022) What is idlcachesize?
by quanah＠zimbra.com 13 Mar '09

13 Mar '09

--On Friday, March 13, 2009 6:47 PM +0000 arun_patel(a)yahoo.com wrote: > Full_Name: Arun Patel > Version: 2.2.13 > OS: linux > URL: > Submission from: (NULL) (135.207.175.192) See the admin guide. Note that question should be sent to an appropriate list. The ITS system is for bug reports. I'd also note that the OpenLDAP 2.2 release is historical. OpenLDAP 2.4 is the current supported release tree. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6022) What is idlcachesize?
by arun_patel＠yahoo.com 13 Mar '09

13 Mar '09

Full_Name: Arun Patel Version: 2.2.13 OS: linux URL: Submission from: (NULL) (135.207.175.192) Can someone explain to me idlcachesize entry in slapd.conf? What is it used for? Does it optimize? Any and all informatin will be helpful Thanks Arun

1 0

Re: (ITS#5973) Syncrepl can update more than one csn value
by rein＠OpenLDAP.org 13 Mar '09

13 Mar '09

hyc(a)symas.com wrote: > rein(a)OpenLDAP.org wrote: >> Syncrepl can update more than one csn value in one operation, but only one can >> be passed to syncprov in the csn queue. Syncprov should instead pick the >> updated values from the modify operation. > The syncrepl patch broke the CSN queue, which has caused out-of-order updates > in test050. I have reverted it. Every write operation begins with a queued CSN > and ends by graduating a CSN. You removed the enqueueing step, and so the > queue contents were invalid. I removed the queuing and graduating of the CSN syncrepl_updateCookie() would update, as that only sent one of the (possibly) many values that could be updated by that operation. With the syncprov half of the patch the queued patch should never be looked at, meaning that this queuing should be unnecessary here. The ordinary queue/graduation of the CSN received with an updated entry is still in place, and should continue to be so. >> A patch that fixes this is coming. This patch depends on the ITS#5972 patch, >> and is required for the new test058 to succeed. > > test058 has the same number of errors with or without the syncrepl patch, so I > don't think it was relevant to the issues you were addressing. It was only the syncprov half of ITS#5793 patch that was relevant for test058. The syncrepl half of the patch only removes code that should be unnecessary.. > I'm still skeptical about the syncprov half of the patch. The two patches were > actually unrelated, the syncprov patch takes effect regardless of the syncrepl > patch. Yes, the syncprov part of the patch doesn't need the syncrepl half, but I found it correct to clean up code that should be made unnecessary by that patch. All updates received during the persistent phase should include an updated CSN value, and should already have been transmitted to syncprov by the commit/graduate queue and have caused it to update its own csn set. I.e, the syncrepl_updateCookie() replace operation should only have caused syncprov to updated its cookie and thereby send NEW_COOKIE messages when syncrepl updated the CSN set at the end of the refresh phase. Apparently, there is something that causes this to break. More on that in another message on -devel. Rein

1 0

(ITS#6021) slapo-pcache/back-ldap slapd crashes
by toby＠inf.ed.ac.uk 13 Mar '09

13 Mar '09

Full_Name: Toby Blake Version: 2.4.15 OS: Scientific Linux 5.2 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (129.215.197.95) Hi there, I have been testing slapo-pcache/back-ldap for some time now, typically in student lab situations (to provide a localhost proxycaching slapd with back-ldap connecting (via gssapi) to several remote servers), initially using 2.3.x but I have recently moved to using the latest 2.4.x versions, as it's clear that's where the development effort is going. I'm seeing quite a lot of crashes during my testing, with a few different backtraces. I don't know whether you would prefer I submitted these separately for different backtraces, so I'm opening this ITS to get the process started... I have seen no way of reproducing these crashes. I'm currently using: - openldap-2.4.15 on scientific linux 5.2 - bdb 4.7.25 with 3 patches - We build our own RPMs. I have openldap-2.4.15 with no optimisation (-O0) for the purposes of debugging. The most common backtrace I see is an assertion failure in memory.c:152. Here's an example: Program terminated with signal 6, Aborted. #0 0x00b8d402 in __kernel_vsyscall () (gdb) bt #0 0x00b8d402 in __kernel_vsyscall () #1 0x009e8d20 in raise () from /lib/libc.so.6 #2 0x009ea631 in abort () from /lib/libc.so.6 #3 0x00a20e6b in __libc_message () from /lib/libc.so.6 #4 0x00a28b16 in _int_free () from /lib/libc.so.6 #5 0x00a2c070 in free () from /lib/libc.so.6 #6 0x081d5746 in ber_memfree_x (p=0xa6809478, ctx=0x0) at memory.c:152 #7 0x081d630c in ber_bvarray_free_x (a=0x9049bb8, ctx=0x0) at memory.c:731 #8 0x081d6343 in ber_bvarray_free (a=0x9049bb8) at memory.c:741 #9 0x08079757 in attr_clean (a=0xb62d41bc) at attr.c:134 #10 0x0807983b in attrs_free (a=0xb62d41bc) at attr.c:196 #11 0x0807c059 in entry_clean (e=0xb5acfdbc) at entry.c:504 #12 0x0811ec17 in ldap_back_search (op=0xa680e5d8, rs=0xb5ad10e0) at search.c:354 #13 0x080f2b02 in overlay_op_walk (op=0xa680e5d8, rs=0xb5ad10e0, which=op_search, oi=0x8fa9208, on=0x0) at backover.c:669 #14 0x080f2d0a in over_op_func (op=0xa680e5d8, rs=0xb5ad10e0, which=op_search) at backover.c:721 #15 0x080f2dae in over_op_search (op=0xa680e5d8, rs=0xb5ad10e0) at backover.c:743 #16 0x080720d6 in fe_op_search (op=0xa680e5d8, rs=0xb5ad10e0) at search.c:366 #17 0x08071a2c in do_search (op=0xa680e5d8, rs=0xb5ad10e0) at search.c:217 #18 0x0806e705 in connection_operation (ctx=0xb5ad11d0, arg_v=0xa680e5d8) at connection.c:1097 #19 0x0806ebdf in connection_read_thread (ctx=0xb5ad11d0, argv=0x13) at connection.c:1223 #20 0x0819ecad in ldap_int_thread_pool_wrapper (xpool=0x8f86fa0) at tpool.c:663 #21 0x00b3346b in start_thread () from /lib/libpthread.so.0 #22 0x00a90dbe in clone () from /lib/libc.so.6 (gdb) I have seen quite a few of these backtraces, although sometimes coming through slap_sl_free (and a couple of other places) instead of ber_bvarray_free_x. Let me know what further information I can provide. Many thanks Toby Blake School of Informatics University of Edinburgh

1 0

SSL/TLS memory leak in multithread mode. more detail about ITS#6018
by timling2003＠gmail.com 13 Mar '09

13 Mar '09

--000e0cd291e2f684b60464fb3237 Content-Type: multipart/alternative; boundary=000e0cd291e2f6849e0464fb3235 --000e0cd291e2f6849e0464fb3235 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit The program is a daemon which will create a thread to query LDAP server for every request. a part of code of socket loop: newfd = accept(listen_fd, &cliaddr, &clilen); pthread_attr_setdetachstate(&attr, PTHREAD_CREATE_DETACHED); pthread_create(&instance_thread, &attr, queryldap, (void *)newfd); a part of code of querying LDAP server: int queryldap() { timeout = 10 ldap_set_option( NULL, LDAP_OPT_NETWORK_TIMEOUT, &timeout ); if SSL ldap_initialize(&ld, "ldaps://..."); else ldap_initialize(&ld, "ldap://..."); protocol = 3; rc = 0; if SSL or TLS ldap_set_option( ld, LDAP_OPT_PROTOCOL_VERSION, &protocol ); ldap_set_option( NULL, LDAP_OPT_X_TLS_REQUIRE_CERT, &rc ); if TLS ldap_start_tls_s( ld, NULL, NULL ); ldap_bind_s(ld, bindDN, bindPasswd, LDAP_AUTH_SIMPLE); ... ldap_unbind_s(ld); } I cannot use ldap_pvt_tls_destroy(), because this function can call only once. If I don't create different thread for every request (one thread for all request), there is no any memory leak. So, I think this case is related to the multithread mode. Maybe, there are some memory that don't be freed after the querying thread finished. In addtion, there is no any memory leak when I use unencryption mode. The attachment is the snippet of memory image which is likely the leak part. The memory leak produced by one thread seems to be about 352 bytes. --000e0cd291e2f6849e0464fb3235 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The program is a daemon which will create a thread to query LDAP server for= every request. a part of code of socket loop: newfd =3D accept(= listen_fd, &cliaddr, &clilen); pthread_attr_setdetachstate(&= attr, PTHREAD_CREATE_DETACHED); pthread_create(&instance_thread, &attr, queryldap, (void *)newfd);<= br> a part of code of querying LDAP server: int queryldap() { = =A0=A0=A0 timeout =3D 10 =A0=A0=A0 ldap_set_option( NULL, LDAP_OPT_NETWO= RK_TIMEOUT, &timeout ); =A0=A0=A0 if SSL =A0 =A0=A0 =A0=A0 ldap_initialize(&ld, "ld= aps://..."); =A0=A0=A0 else =A0=A0=A0=A0=A0=A0=A0 ldap_initializ= e(&ld, "ldap://..."); =A0=A0=A0 protocol =3D 3; =A0= =A0=A0 rc =3D 0; =A0=A0=A0 if SSL or TLS =A0=A0=A0=A0=A0=A0=A0 ldap_s= et_option( ld, LDAP_OPT_PROTOCOL_VERSION, &protocol ); =A0 =A0=A0 =A0=A0 ldap_set_option( NULL, LDAP_OPT_X_TLS_REQUIRE_CERT, &= rc ); =A0=A0=A0 if TLS =A0=A0=A0=A0=A0=A0=A0 ldap_start_tls_s( ld= , NULL, NULL ); =A0=A0=A0 ldap_bind_s(ld,=A0 bindDN, bindPasswd, LDA= P_AUTH_SIMPLE); =A0=A0=A0 ... =A0=A0=A0 ldap_unbind_s(ld); } I cannot use ldap_pvt_tls_destroy(= ), because this function can call only once. If I don't create d= ifferent thread for every request (one thread for all request), there is no= any memory leak. So, I think this case is related to the multithread mode.= Maybe, there are some memory that don't be freed after the querying thr= ead finished. In addtion, there is no any memory leak when I use unencry= ption mode. The attachment is the snippet of memory image which is l= ikely the leak part. The memory leak produced by one thread seems to be abo= ut 352 bytes. --000e0cd291e2f6849e0464fb3235-- --000e0cd291e2f684b60464fb3237 Content-Type: application/octet-stream; name=memory-leak-snippet Content-Disposition: attachment; filename=memory-leak-snippet Content-Transfer-Encoding: base64 X-Attachment-Id: f_fs8k4pwa0 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD///////////////// ////////////////////////////////////////////////////////////////////AAAAAAAA AAARAAAAiDkRCGAMGgh0kgAAUQEAAEkLAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA//// //////////////////////////////////////////////////////////////////////////// /////wAAAAAAAAAAEQAAAOg6EQjADRoItZIAAFEBAABOCwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAP////////////////////////////////////////////////////////////////// //////////////////8AAAAAAAAAABEAAABIPBEIIA8aCPaSAABRAQAAUwsAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAD///////////////////////////////////////////////////// ////////////////////////////////AAAAAAAAAAARAAAAqD0RCIAQGgg3kwAAUQEAAFgLAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA//////////////////////////////////////// /////////////////////////////////////////////wAAAAAAAAAAEQAAAAg/EQjgERoIeJMA AFEBAABdCwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAA= --000e0cd291e2f684b60464fb3237--

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs