openldap-bugs

openldap-bugs@openldap.org

1 participants
21001 discussions

Re: (ITS#7929) memberof overlay supresses accesslog olcAccessLogOps = all
by varkoly＠suse.com 06 Sep '14

06 Sep '14

Hello, I've tested it from git://git.openldap.org/openldap.git/OPENLDAP_REL_ENG_2_4 with same result. http://www.openldap.org/its/index.cgi/Incoming?id=7239 looks vaguely similar, although with a different overlay. Am Donnerstag, den 04.09.2014, 15:55 +0000 schrieb quanah(a)zimbra.com: > --On Thursday, September 04, 2014 10:11 AM +0000 varkoly(a)suse.com wrote: > > > Full_Name: Peter Varkoly > > Version: 2.4.26, 2.4.39 > > Hello, > > Can you please test using the current RE24 code? There have been > significant updates made to the overlay interactions since 2.4.39. > > Thanks! > > --Quanah > > > -- > > Quanah Gibson-Mount > Server Architect > Zimbra, Inc. > -------------------- > Zimbra :: the leader in open source messaging and collaboration > > > > -- Peter Varkoly Sr. Developer SUSE Linux Enterprise Applications SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) Maxfeldstraße 5 90409 Nürnberg Germany

1 0

(ITS#7930) slapo-chain causes double-free with rwm
by hyc＠openldap.org 06 Sep '14

06 Sep '14

Full_Name: Howard Chu Version: RE24 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (78.155.233.73) Submitted by: hyc chaining substitutes op->o_req_dn and then restores its original value after performing the chained op. But rwm tries to cleanup op->o_req_dn when the chained op finishes, and so the original DN will be invalid after that. Partial fix: chain should only resto t the original value if the current value matches the last value that chain used. Additional fix: rwm should not cleanup at this time, because the send_ldap_result() of the chained op is not necessarily the final result of the original op. (E.g., in a search that processes multiple search refs, send_ldap_result will occur for each ref that is chained.)

1 0

Re: (ITS#7929) memberof overlay supresses accesslog olcAccessLogOps = all
by quanah＠zimbra.com 04 Sep '14

04 Sep '14

--On Thursday, September 04, 2014 10:11 AM +0000 varkoly(a)suse.com wrote: > Full_Name: Peter Varkoly > Version: 2.4.26, 2.4.39 Hello, Can you please test using the current RE24 code? There have been significant updates made to the overlay interactions since 2.4.39. Thanks! --Quanah -- Quanah Gibson-Mount Server Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#7929) memberof overlay supresses accesslog olcAccessLogOps = all
by varkoly＠suse.com 04 Sep '14

04 Sep '14

Full_Name: Peter Varkoly Version: 2.4.26, 2.4.39 OS: SUSE Enterprise Server URL: ftp://ftp.suse.com/pub/people/varkoly Submission from: (NULL) (2620:113:80c0:5::2222) Enabling both the "memberof" and "accesslog" overlays in openldap causes accesslog to only log "reads" and "session" operations when logops is set to all (olcAccessLogOps = all). Disabling the "memberof" overlay results in "writes", "reads" and "session" operations to be logged. Setting "olcAccessLogOps = writes" in conjunction with the "memberof" overlay results in "writes" operations to be logged. Expected result is that when "olcAccessLogOps = all" is set for the "accesslog" overlay together with the "memberof" overlay, that all operations (add, modify, delete, modrdn, search, bind, unbind, abandon, compare) are logged to cn=accesslog. The order of activating the overlays is irrelevant. We have tested it by activating first memberof and accesslog too. We are using the config-backend. The configuration will be available soon under the provided URL.

1 0

Re: (ITS#7928) Segfault when cancelling syncprov search
by hyc＠symas.com 28 Aug '14

28 Aug '14

ben(a)morrow.me.uk wrote: > Full_Name: Ben Morrow > Version: 2.4.39 and git head > OS: FreeBSD > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (86.140.232.115) > > > I believe I have found a crashing bug in the syncprov overlay. If I > start a refreshAndPersist search, wait for the persist phase to start > and at least one change to be returned, and then cancel the search, > slapd dies with SIGSEGV. (I don't know how many of these conditions are > necessary. I suspect that cancelling any syncprov search will cause the > same crash, but I haven't investigated that.) > > I also believe the following change to > servers/slapd/overlays/syncprov.c:syncprov_ab_cleanup fixes the prlelem: > > slap_callback *sc = op->o_callback; > op->o_callback = sc->sc_next; > - syncprov_drop_psearch( op->o_callback->sc_private, 0 ); > + syncprov_drop_psearch( sc->sc_private, 0 ); > > The crash I see actually occurs in libthr (FreeBSD's threading library), > because drop_psearch passes its first argument to free_syncop which > starts by trying to lock a mutex; but in fact the object being passed is > not the right type at all, and where there is supposed to be a mutex > there is instead a function pointer. Thanks, looks like you're right. Fixed in git master. > > Ben > > > > -- -- 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#7928) Segfault when cancelling syncprov search
by ben＠morrow.me.uk 28 Aug '14

28 Aug '14

Full_Name: Ben Morrow Version: 2.4.39 and git head OS: FreeBSD URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (86.140.232.115) I believe I have found a crashing bug in the syncprov overlay. If I start a refreshAndPersist search, wait for the persist phase to start and at least one change to be returned, and then cancel the search, slapd dies with SIGSEGV. (I don't know how many of these conditions are necessary. I suspect that cancelling any syncprov search will cause the same crash, but I haven't investigated that.) I also believe the following change to servers/slapd/overlays/syncprov.c:syncprov_ab_cleanup fixes the prlelem: slap_callback *sc = op->o_callback; op->o_callback = sc->sc_next; - syncprov_drop_psearch( op->o_callback->sc_private, 0 ); + syncprov_drop_psearch( sc->sc_private, 0 ); The crash I see actually occurs in libthr (FreeBSD's threading library), because drop_psearch passes its first argument to free_syncop which starts by trying to lock a mutex; but in fact the object being passed is not the right type at all, and where there is supposed to be a mutex there is instead a function pointer. Ben

1 0

(ITS#7927) back-mdb SEGV when using an alias pointing to a referral
by hyc＠openldap.org 26 Aug '14

26 Aug '14

Full_Name: Howard Chu Version: 2.4 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (78.155.233.73) Submitted by: hyc Patch coming shortly

1 0

Re: (ITS#7926) modifying olcListenerThreads crashes slapd
by quanah＠zimbra.com 25 Aug '14

25 Aug '14

--On Monday, August 25, 2014 9:53 PM +0000 quanah(a)openldap.org wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.39 > OS: Linux 3.13 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.111.58.125) > > > After modifying olcListenerThreads for a running slapd, the process died > and I had to restart ldap. Going to see if cores were enabled. > Trivial to reproduce: (gdb) cont Continuing. Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7f963ca41700 (LWP 12048)] 0x0000000000432279 in slapd_clr_read (s=13, wake=0) at daemon.c:981 981 daemon.c: No such file or directory. in daemon.c Thread 6 (Thread 0x7f963ca41700 (LWP 12048)): #0 0x0000000000432279 in slapd_clr_read (s=13, wake=0) at daemon.c:981 rc = 1 id = 1 #1 0x000000000043ab9c in connection_read_activate (s=13) at connection.c:1285 rc = 62 #2 0x0000000000436ddb in slapd_daemon_task (ptr=0x1ba1d28) at daemon.c:2769 rc = 1 fd = 13 w = 0 r = 1 ns = 1 at = 0 nfds = 18 revents = 0x1c40000 tvp = 0x0 cat = {tv_sec = 0, tv_usec = 0} i = 0 nwriters = 0 now = 1409005820 tv = {tv_sec = 0, tv_usec = 0} tdelta = 1 rtask = 0x0 l = 2 last_idle_check = 1408061664 ebadf = 0 tid = 0 #3 0x0000003e130079d1 in start_thread () from /lib64/libpthread.so.0 No symbol table info available. #4 0x0000003e12ce8b5d in clone () from /lib64/libc.so.6 No symbol table info available. Thread 5 (Thread 0x7f963c240700 (LWP 12052)): #0 0x0000003e1300b5bc in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 No symbol table info available. #1 0x00007fa28ef29787 in ldap_pvt_thread_cond_wait (cond=0x1bdc038, mutex=0x1bdc010) at thr_posix.c:277 No locals. #2 0x00007fa28ef27fa2 in ldap_int_thread_pool_wrapper (xpool=0x1bdc000) at tpool.c:927 pq = 0x1bdc000 pool = 0x1da0180 task = 0x0 work_list = 0x1bdc070 ctx = {ltu_pq = 0x1bdc000, ltu_id = 140283230816000, ltu_key = {{ltk_key = 0x43a106, ltk_data = 0x1da4e00, ltk_free = 0x439f4a <conn_counter_destroy>}, {ltk_key = 0x4ad967, ltk_data = 0x3d9c2c0, ltk_free = 0x4ad78c <slap_sl_mem_destroy>}, {ltk_key = 0x455375, ltk_data = 0x20a03c0, ltk_free = 0x4552c8 <slap_op_q_destroy>}, { ltk_key = 0x7fa28b554533, ltk_data = 0x419e000, ltk_free = 0x7fa28b554510 <search_stack_free>}, {ltk_key = 0x7fa28b5515ab, ltk_data = 0x3e9e000, ltk_free = 0x7fa28b551563 <scope_chunk_free>}, {ltk_key = 0x1bdd6c0, ltk_data = 0x1fe2200, ltk_free = 0x7fa28b55f195 <mdb_reader_free>}, {ltk_key = 0x0, ltk_data = 0x9106400, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 25 times>}} kctx = 0x0 i = 32 keyslot = 380 hash = 3641033084 pool_lock = 0 freeme = 0 __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #3 0x0000003e130079d1 in start_thread () from /lib64/libpthread.so.0 No symbol table info available. #4 0x0000003e12ce8b5d in clone () from /lib64/libc.so.6 No symbol table info available. Thread 4 (Thread 0x7f963ba3f700 (LWP 12183)): #0 0x0000003e1300b5bc in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 No symbol table info available. #1 0x00007fa28ef29787 in ldap_pvt_thread_cond_wait (cond=0x1bdc038, mutex=0x1bdc010) at thr_posix.c:277 No locals. #2 0x00007fa28ef27fa2 in ldap_int_thread_pool_wrapper (xpool=0x1bdc000) at tpool.c:927 pq = 0x1bdc000 pool = 0x1da0180 task = 0x0 work_list = 0x1bdc070 ctx = {ltu_pq = 0x1bdc000, ltu_id = 140283222423296, ltu_key = {{ltk_key = 0x43a106, ltk_data = 0x1da4700, ltk_free = 0x439f4a <conn_counter_destroy>}, {ltk_key = 0x4ad967, ltk_data = 0x3d9c9c0, ltk_free = 0x4ad78c <slap_sl_mem_destroy>}, {ltk_key = 0x1bdd6c0, ltk_data = 0x52dc000, ltk_free = 0x7fa28b55f195 <mdb_reader_free>}, { ltk_key = 0x7fa28b554533, ltk_data = 0x55e6000, ltk_free = 0x7fa28b554510 <search_stack_free>}, {ltk_key = 0x7fa28b5515ab, ltk_data = 0x52e6000, ltk_free = 0x7fa28b551563 <scope_chunk_free>}, {ltk_key = 0x455375, ltk_data = 0x237b840, ltk_free = 0x4552c8 <slap_op_q_destroy>}, {ltk_key = 0x0, ltk_data = 0x66ed600, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 25 times>}} kctx = 0x0 i = 32 keyslot = 138 hash = 3676775562 pool_lock = 0 freeme = 0 __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #3 0x0000003e130079d1 in start_thread () from /lib64/libpthread.so.0 No symbol table info available. #4 0x0000003e12ce8b5d in clone () from /lib64/libc.so.6 No symbol table info available. Thread 3 (Thread 0x7f963b23e700 (LWP 24606)): #0 0x0000003e1300b5bc in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 No symbol table info available. #1 0x00007fa28ef29787 in ldap_pvt_thread_cond_wait (cond=0x1bdc038, mutex=0x1bdc010) at thr_posix.c:277 No locals. #2 0x00007fa28ef27fa2 in ldap_int_thread_pool_wrapper (xpool=0x1bdc000) at tpool.c:927 pq = 0x1bdc000 pool = 0x1da0180 task = 0x0 work_list = 0x1bdc070 ctx = {ltu_pq = 0x1bdc000, ltu_id = 140283214030592, ltu_key = {{ltk_key = 0x43a106, ltk_data = 0x2155100, ltk_free = 0x439f4a <conn_counter_destroy>}, {ltk_key = 0x4ad967, ltk_data = 0x66d6b40, ltk_free = 0x4ad78c <slap_sl_mem_destroy>}, {ltk_key = 0x455375, ltk_data = 0x2379a40, ltk_free = 0x4552c8 <slap_op_q_destroy>}, {ltk_key = 0x1bdd6c0, ltk_data = 0x6a60000, ltk_free = 0x7fa28b55f195 <mdb_reader_free>}, {ltk_key = 0x7fa28b554533, ltk_data = 0x6d6e000, ltk_free = 0x7fa28b554510 <search_stack_free>}, { ltk_key = 0x7fa28b5515ab, ltk_data = 0x6a6e000, ltk_free = 0x7fa28b551563 <scope_chunk_free>}, {ltk_key = 0x0, ltk_data = 0x9108800, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 25 times>}} kctx = 0x0 i = 32 keyslot = 250 hash = 907520250 pool_lock = 0 freeme = 0 __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #3 0x0000003e130079d1 in start_thread () from /lib64/libpthread.so.0 No symbol table info available. #4 0x0000003e12ce8b5d in clone () from /lib64/libc.so.6 No symbol table info available. Thread 2 (Thread 0x7f963aa3d700 (LWP 24607)): #0 0x0000003e1300b5bc in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 No symbol table info available. #1 0x00007fa28ef29787 in ldap_pvt_thread_cond_wait (cond=0x1bdc038, mutex=0x1bdc010) at thr_posix.c:277 No locals. #2 0x00007fa28ef27fa2 in ldap_int_thread_pool_wrapper (xpool=0x1bdc000) at tpool.c:927 pq = 0x1bdc000 pool = 0x1da0180 task = 0x0 work_list = 0x1bdc070 ctx = {ltu_pq = 0x1bdc000, ltu_id = 140283205637888, ltu_key = {{ltk_key = 0x43a106, ltk_data = 0x2154f00, ltk_free = 0x439f4a <conn_counter_destroy>}, {ltk_key = 0x4ad967, ltk_data = 0x66d6b80, ltk_free = 0x4ad78c <slap_sl_mem_destroy>}, {ltk_key = 0x455375, ltk_data = 0x66c6000, ltk_free = 0x4552c8 <slap_op_q_destroy>}, {ltk_key = 0x1bdd6c0, ltk_data = 0x6a61a00, ltk_free = 0x7fa28b55f195 <mdb_reader_free>}, {ltk_key = 0x7fa28b554533, ltk_data = 0x806e000, ltk_free = 0x7fa28b554510 <search_stack_free>}, { ltk_key = 0x7fa28b5515ab, ltk_data = 0x7d6e000, ltk_free = 0x7fa28b551563 <scope_chunk_free>}, {ltk_key = 0x0, ltk_data = 0x9108800, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 25 times>}} kctx = 0x0 i = 32 keyslot = 41 hash = 1003389993 pool_lock = 0 freeme = 0 __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #3 0x0000003e130079d1 in start_thread () from /lib64/libpthread.so.0 No symbol table info available. #4 0x0000003e12ce8b5d in clone () from /lib64/libc.so.6 No symbol table info available. Thread 1 (Thread 0x7fa28e26a720 (LWP 12047)): #0 0x0000003e1300822d in pthread_join () from /lib64/libpthread.so.0 No symbol table info available. #1 0x00007fa28ef296c8 in ldap_pvt_thread_join (thread=140283239208704, thread_return=0x0) at thr_posix.c:197 No locals. #2 0x0000000000437587 in slapd_daemon () at daemon.c:2907 i = 0 rc = 0 #3 0x0000000000414afb in main (argc=9, argv=0x7fff33ea3258) at main.c:1012 i = 9 no_detach = 0 rc = 0 urls = 0x1bb0000 "ldap://zre-ldap003.eng.zimbra.com:389 ldapi:///" username = 0x1ba0010 "root" groupname = 0x0 sandbox = 0x0 syslogUser = 128 pid = 0 waitfds = {9, 10} g_argc = 9 g_argv = 0x7fff33ea3258 configfile = 0x0 configdir = 0x1ba4020 "/opt/zimbra/data/ldap/config" serverName = 0x7fff33ea4d76 "slapd" serverMode = 1 scp = 0x0 scp_entry = 0x0 debug_unknowns = 0x0 syslog_unknowns = 0x0 serverNamePrefix = 0x4f19c8 "" l = 5182640 slapd_pid_file_unlink = 1 slapd_args_file_unlink = 1 firstopt = 0 __PRETTY_FUNCTION__ = "main" (gdb) -- Quanah Gibson-Mount Server Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#7926) modifying olcListenerThreads crashes slapd
by quanah＠openldap.org 25 Aug '14

25 Aug '14

Full_Name: Quanah Gibson-Mount Version: 2.4.39 OS: Linux 3.13 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.58.125) After modifying olcListenerThreads for a running slapd, the process died and I had to restart ldap. Going to see if cores were enabled.

1 0

Re: (ITS#7925) mdb_from_db Berkeley DB importer
by hyc＠symas.com 24 Aug '14

24 Aug '14

graehl(a)gmail.com wrote: > Full_Name: Jonathan Graehl > Version: commit 8d346721a60684aeaa7b1e3b2111c972393bfad3 > OS: linux > URL: > Submission from: (NULL) (75.85.99.117) > > > mdb_from_db Berkeley DB->LMDB import utility Interesting, thanks for the submission. > +Additionally, > +.B mdb_from_db > +may write in the > +.B -T > +plain text format understood by > +.BR mdb_load (1) > +which can only understand a single subdatabase at a time. Not true. mdb_load can load multiple DBs from a single input file. Also, I'm not sure if it's your mailer or ours, but this submission text is riddled with corruptions. > + > B2B.SH OPTION0D0D In general I don't think including this utility into LMDB is a good idea since it has an obvious binary dependency on BerkeleyDB. In particular, with the change of BerkeleyDB's license to AGPL it would not be possible for anyone to distribute any binaries for this package. Better to just use BDB db_dump piped into mdb_load. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs