- openldap-bugs - openldap.org

(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 22 Mar '09

22 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 22 Mar '09

22 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 22 Mar '09

22 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 18 Mar '09

18 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 18 Mar '09

18 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 17 Mar '09

17 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 16 Mar '09

16 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

(ITS#6020) MMR sends too many redundant messages
by hyc＠OpenLDAP.org 13 Mar '09

13 Mar '09

Full_Name: Howard Chu Version: HEAD/RE24 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.91.220.157) Submitted by: hyc Currently syncprov knows not to send a change back to the originating server, but it will still send changes back to the server that delivered it. (E.g., server 1 replicates to server 2, server 2 to server 3. Server 3 will immediately try to send the same message back to server 2.) Syncrepl isn't providing any information for syncprov to know where a change came from. The fix is for syncrepl to attach the incoming sync_cookie state to the operation it uses when writing to its own database. Coming in HEAD shortly.

1 0

Re: (ITS#6019) puzon@eska.pl
by michael＠stroeder.com 12 Mar '09

12 Mar '09

puzon(a)eska.pl wrote: > Full_Name: Lukasz Brodowski > Version: 2.4.15 > OS: freebsd 7.1 > URL: > Submission from: (NULL) (62.29.173.121) > > > Command like this: 'ldapsearch -x -D "cn=Manager,dc=example" -H > ldap://ldap.example -W' ends segmentation fault 11 (core dumped), when I send > correct password. I use this on several machines and effect is the same. Can you obtain a stack trace with gdb and the core file? See here how to obtain it: http://www.openldap.org/faq/data/cache/59.html Ciao, Michael.

1 0

Re: (ITS#5973) Syncrepl can update more than one csn value
by hyc＠symas.com 12 Mar '09

12 Mar '09

rein(a)OpenLDAP.org wrote: > Full_Name: Rein Tollevik > Version: CVS HEAD > OS: irrelevant > URL: > Submission from: (NULL) (81.93.160.250) > Submitted by: rein > > > Syncrepl can update more than one csn value in one operation, False. An operation can only affect one entry. An entry has only one CSN (entryCSN is single-valued). Multiple changes may have occurred to an entry before a consumer sees it, but the consumer will only see the final result and only the last entryCSN. On the other hand, multiple CSNs may have changed in the cookie that is transmitted to the consumer. That's a separate issue... > but only one can > be passed to syncprov in the csn queue. > Syncprov should instead pick the > updated values from the modify operation. > > A patch that fixes this is coming. This patch depends on the ITS#5972 patch, > and is required for the new test058 to succeed. > > Rein Tollevik > Basefarm AS > > -- -- 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#5973) Syncrepl can update more than one csn value
by hyc＠symas.com 12 Mar '09

12 Mar '09

rein(a)OpenLDAP.org wrote: > Full_Name: Rein Tollevik > Version: CVS HEAD > OS: irrelevant > URL: > Submission from: (NULL) (81.93.160.250) > Submitted by: rein > > > 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. > 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. 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. -- -- 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#6015) ldapsearch can not retrieve same uid that has been added after it was deleted
by michael＠stroeder.com 12 Mar '09

12 Mar '09

arun_patel(a)yahoo.com wrote: > Version: 2.2.13 In general: This is a *very* ancient release. Also there's no information about the underlying Berkeley-DB and the database backend used in your setup. It's very unlikely that anybody can help you track issues down with this setup. > 6) ldapsearch -LLL -x -b uid=tesid,xyz.com > unable to retrieve the testid (Problem) > > I know the testid is in ldap, because went thru ldap browser and did see the > entry. > [..] > I then did /etc/init.d/ldap stop and /etc/init.d/ldap start > > After entering ldapsearch -LLL -x -b uid=tesid,xyz.com, it works, > > Why does this happen? Not much information about your setup. You should provide more details (e.g. database backend used, indexing and ACLs in slapd.conf). Preferrably discuss your setup on the openldap-software mailing list. Ciao, Michael.

1 0

Re: (ITS#6012) segmentation fault triggered with slapcat
by martin.konold＠erfrakon.de 12 Mar '09

12 Mar '09

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. 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. Yours, --martin -- e r f r a k o n Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker Sitz: Adolfstraße 23, 70469 Stuttgart, Partnerschaftsregister Stuttgart PR 126 http://www.erfrakon.com/

1 0

(ITS#6019) puzon@eska.pl
by puzon＠eska.pl 12 Mar '09

12 Mar '09

Full_Name: Lukasz Brodowski Version: 2.4.15 OS: freebsd 7.1 URL: Submission from: (NULL) (62.29.173.121) Command like this: 'ldapsearch -x -D "cn=Manager,dc=example" -H ldap://ldap.example -W' ends segmentation fault 11 (core dumped), when I send correct password. I use this on several machines and effect is the same.

1 0

Re: (ITS#6018) TLS memory leak
by ando＠sys-net.it 12 Mar '09

12 Mar '09

timling2003(a)gmail.com wrote: > I have checked it on openldap-2.4.15. But, it still has this problem. > btw, I use cyrus-sasl-2.1.22.tar.gz for building. We cannot assume there's a bug in OpenLDAP code only because your code triggers an unexpected behavior, without seeing your code entirely. The simple fact that your code calls fairly common OpenLDAP functions that appear to behave correctly when used by other software seems to indicate that there is no issue with those functions. 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#6014) rev. 1.121 of clients/tools/common.c makes ldapmodify coredump
by ando＠sys-net.it 12 Mar '09

12 Mar '09

d(a)delphij.net wrote: > Here is a patch that intends to fix #6014. getpassphrase() (which in > turn would be a getpass() call, or lutil_getpass() call), returns a > pointer from a static char * pointer, which should never be free()'ed. > Therefore, a strdup() should be called. > > Note that, since both getpass() implementation could return NULL, we can > not strdup() directly. Instead, we need to detect whether it's NULL and > handle separately. Probably, a better solution would be to implement a lutil_get_terminal_password(char *prompt, struct berval *passwd) routine that mallocs as appropriate. 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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs