openldap-bugs

openldap-bugs@openldap.org

1 participants
20969 discussions

(ITS#7303) bdb/hdb search checks aliases unnecessarily
by hyc＠OpenLDAP.org 12 Jun '12

12 Jun '12

Full_Name: Howard Chu Version: HEAD/RE24 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (37.19.96.193) Submitted by: hyc If a search request has derefSearching set in the alias deref option, the search_aliases() function walks thru a (potentially) large number of entries checking to see if they are aliases, even if the objectclass index shows there are no alias entries in the database. It should exit early instead. The bug is also present to a lesser degree in back-mdb; the back-mdb version of search_aliases() would only do a single unneeded entry lookup.

1 0

(ITS#7302) mdb segfault when renaming entry
by quanah＠OpenLDAP.org 12 Jun '12

12 Jun '12

Full_Name: Quanah Gibson-Mount Version: 2.4.31 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.108.184.39) Got the following segfault in mdb when renaming entry X to the same name as a previously deleted entry Y. Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7f076d5c6700 (LWP 15510)] 0x00007f1b6ea5190b in mdb_cursor_del (mc=0x2e09a08, flags=0) at ./../../../libraries/libmdb/mdb.c:4516 4516 ./../../../libraries/libmdb/mdb.c: No such file or directory. in ./../../../libraries/libmdb/mdb.c (gdb) thr apply all bt full Thread 5 (Thread 0x7f076ddc7700 (LWP 15509)): #0 0x00007f1b7261c2d3 in epoll_wait () from /lib/libc.so.6 No symbol table info available. #1 0x00000000004395d9 in slapd_daemon_task (ptr=0x2715d00) at daemon.c:2540 ns = 1 at = 0 nfds = 8 revents = 0x287e000 tvp = 0x7f076ddc4da0 cat = {tv_sec = 1339538180, tv_usec = 0} i = 1 nwriters = 0 now = 1339537971 tv = {tv_sec = 209, tv_usec = 0} tdelta = 1 rtask = 0x2d81950 l = 3 last_idle_check = 1339537880 ebadf = 0 tid = 0 #2 0x00007f1b728be9ca in start_thread () from /lib/libpthread.so.0 No symbol table info available. #3 0x00007f1b7261bcdd in clone () from /lib/libc.so.6 No symbol table info available. #4 0x0000000000000000 in ?? () No symbol table info available. Thread 4 (Thread 0x7f076d5c6700 (LWP 15510)): #0 0x00007f1b6ea5190b in mdb_cursor_del (mc=0x2e09a08, flags=0) at ./../../../libraries/libmdb/mdb.c:4516 leaf = 0x130000004c rc = 0 #1 0x00007f1b6ea519b4 in mdb_cursor_del (mc=0x2e09880, flags=0) at ./../../../libraries/libmdb/mdb.c:4523 leaf = 0x50baacc rc = 0 #2 0x00007f1b6ea42088 in mdb_dn2id_delete (op=0x2c0fc00, mc=0x2e09880, id=75) at dn2id.c:235 key = {mv_size = 8, mv_data = 0x7f076d5c5468} rc = 0 #3 0x00007f1b6ea31abc in mdb_delete (op=0x2c0fc00, rs=0x7f076d5c5a10) at delete.c:336 mdb = 0x2e56000 pdn = {bv_len = 16, bv_val = 0x48e82c2 "dc=zimbra,dc=com"} e = 0x48e8e90 p = 0x48e83f0 manageDSAit = 0 children = 0x2722ec0 entry = 0x2722f00 txn = 0x458c000 mc = 0x2e09880 opinfo = {moi_oe = {oe_next = {sle_next = 0x0}, oe_key = 0x2e56000}, moi_txn = 0x458c000, moi_ref = 1, moi_flag = 0 '\000'} moi = 0x7f076d5c5530 preread_ctrl = 0x0 ctrls = {0x0, 0x151f55373c8e5d00, 0x0, 0x48e8308, 0x7f076d5c5570, 0x27fb280} num_ctrls = 0 parent_is_glue = 0 parent_is_leaf = 0 __PRETTY_FUNCTION__ = "mdb_delete" #4 0x00000000004d4b08 in overlay_op_walk (op=0x2c0fc00, rs=0x7f076d5c5a10, which=op_delete, oi=0x2c62d20, on=0x0) at backover.c:671 func = 0x7f1b6ec60cf8 rc = 32768 #5 0x00000000004d4d46 in over_op_func (op=0x2c0fc00, rs=0x7f076d5c5a10, which=op_delete) at backover.c:723 oi = 0x2c62d20 on = 0x2c62780 be = 0x27589c0 db = {bd_info = 0x7f1b6ec60ca0, bd_self = 0x27589c0, be_ctrls = "\000\001\001\001\000\001\000\000\001\000\000\001\001\000\001\000\000\001", '\000' <repeats 14 times>, "\001", be_flags = 2312, be_restrictops = 0, be_requires = 0, be_ssf_set = {sss_ssf = 0, sss_transport = 0, sss_tls = 0, sss_sasl = 0, sss_update_ssf = 0, sss_update_transport = 0, sss_update_tls = 0, sss_update_sasl = 0, sss_simple_bind = 0}, be_suffix = 0x2be7900, be_nsuffix = 0x2be78c0, be_schemadn = {bv_len = 0, bv_val = 0x0}, be_schemandn = { bv_len = 0, bv_val = 0x0}, be_rootdn = {bv_len = 9, bv_val = 0x2d5eda0 "cn=config"}, be_rootndn = {bv_len = 9, bv_val = 0x2d5ed80 "cn=config"}, be_rootpw = {bv_len = 0, bv_val = 0x0}, be_max_deref_depth = 15, be_def_limit = {lms_t_soft = -1, lms_t_hard = 0, lms_s_soft = -1, lms_s_hard = 0, lms_s_unchecked = -1, lms_s_pr = 0, lms_s_pr_hide = 0, lms_s_pr_total = 0}, be_limits = 0x0, be_acl = 0x2c6f6c0, be_dfltaccess = ACL_READ, be_extra_anlist = 0x0, be_update_ndn = {bv_len = 0, bv_val = 0x0}, be_update_refs = 0x0, be_pending_csn_list = 0x456f610, be_pcl_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __list = { __prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, be_syncinfo = 0x0, be_pb = 0x0, be_cf_ocs = 0x7f1b6ec60aa0, be_private = 0x2e56000, be_next = {stqe_next = 0x0}} cb = {sc_next = 0x48e82e0, sc_response = 0x4d3840 <over_back_response>, sc_cleanup = 0, sc_private = 0x2c62d20} sc = 0x0 rc = 32768 __PRETTY_FUNCTION__ = "over_op_func" #6 0x00000000004d4f2f in over_op_delete (op=0x2c0fc00, rs=0x7f076d5c5a10) at backover.c:780 No locals. #7 0x000000000046149c in fe_op_delete (op=0x2c0fc00, rs=0x7f076d5c5a10) at delete.c:174 org_req_dn = {bv_len = 0, bv_val = 0x0} org_ndn = {bv_len = 0, bv_val = 0x0} org_managedsait = 41923200 org_req_ndn = {bv_len = 0, bv_val = 0x0} org_dn = {bv_len = 0, bv_val = 0x0} repl_user = 0 pdn = {bv_len = 0, bv_val = 0x0} op_be = 0x27589c0 bd = 0x75fdc0 #8 0x000000000046110f in do_delete (op=0x2c0fc00, rs=0x7f076d5c5a10) at delete.c:95 dn = {bv_len = 26, bv_val = 0x4577da5 "ou=people,dc=zimbra,dc=com"} #9 0x000000000043d8c9 in connection_operation (ctx=0x7f076d5c5b50, arg_v=0x2c0fc00) at connection.c:1150 rc = 80 cancel = 0 op = 0x2c0fc00 rs = {sr_type = REP_RESULT, sr_tag = 0, sr_msgid = 0, sr_err = -30798, sr_matched = 0x0, sr_text = 0x0, sr_ref = 0x0, sr_ctrls = 0x0, sr_un = {sru_search = {r_entry = 0x0, r_attr_flags = 0, r_operational_attrs = 0x0, r_attrs = 0x0, r_nentries = 0, r_v2ref = 0x0}, sru_sasl = {r_sasldata = 0x0}, sru_extended = {r_rspoid = 0x0, r_rspdata = 0x0}}, sr_flags = 0} tag = 74 opidx = SLAP_OP_DELETE conn = 0x2f6b440 memctx = 0x27fb280 memctx_null = 0x0 memsiz = 1048576 __PRETTY_FUNCTION__ = "connection_operation" #10 0x000000000043de67 in connection_read_thread (ctx=0x7f076d5c5b50, argv=0x13) at connection.c:1286 rc = 0 cri = {op = 0x2c0fc00, func = 0, arg = 0x0, ctx = 0x7f076d5c5b50, nullop = 0} s = 19 #11 0x00007f1b73db5cc9 in ldap_int_thread_pool_wrapper (xpool=0x273c1c0) at tpool.c:688 pool = 0x273c1c0 task = 0x4576680 work_list = 0x273c258 ctx = {ltu_id = 139669876270848, ltu_key = {{ltk_key = 0x43d429, ltk_data = 0x2c78200, ltk_free = 0x43d26d <conn_counter_destroy>}, {ltk_key = 0x4b388f, ltk_data = 0x27fb280, ltk_free = 0x4b36b4 <slap_sl_mem_destroy>}, {ltk_key = 0x4591ad, ltk_data = 0x0, ltk_free = 0x459100 <slap_op_q_destroy>}, {ltk_key = 0x45e6000, ltk_data = 0x457e000, ltk_free = 0x7f1b6ea4492b <mdb_reader_free>}, {ltk_key = 0x7f1b6ea384d9, ltk_data = 0x49e8000, ltk_free = 0x7f1b6ea38491 <scope_chunk_free>}, {ltk_key = 0x4daa000, ltk_data = 0x4581400, ltk_free = 0x7f1b6ea4492b <mdb_reader_free>}, {ltk_key = 0x7f1b6ea3aaf4, ltk_data = 0x65f2000, ltk_free = 0x7f1b6ea3aad1 <search_stack_free>}, { ltk_key = 0x0, ltk_data = 0x4579200, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 24 times>}} kctx = 0x0 i = 32 keyslot = 854 hash = 2665057110 __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #12 0x00007f1b728be9ca in start_thread () from /lib/libpthread.so.0 No symbol table info available. #13 0x00007f1b7261bcdd in clone () from /lib/libc.so.6 No symbol table info available. #14 0x0000000000000000 in ?? () No symbol table info available. Thread 3 (Thread 0x7ef36cdc3700 (LWP 15671)): #0 0x00007f1b728c385c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 No symbol table info available. #1 0x00007f1b73db72be in ldap_pvt_thread_cond_wait (cond=0x273c1f0, mutex=0x273c1c8) at thr_posix.c:277 No locals. #2 0x00007f1b73db5c22 in ldap_int_thread_pool_wrapper (xpool=0x273c1c0) at tpool.c:675 pool = 0x273c1c0 task = 0x0 work_list = 0x273c258 ctx = {ltu_id = 139583968524032, ltu_key = {{ltk_key = 0x43d429, ltk_data = 0x2c04400, ltk_free = 0x43d26d <conn_counter_destroy>}, {ltk_key = 0x4b388f, ltk_data = 0x2bc1200, ltk_free = 0x4b36b4 <slap_sl_mem_destroy>}, {ltk_key = 0x4591ad, ltk_data = 0x2c0e000, ltk_free = 0x459100 <slap_op_q_destroy>}, {ltk_key = 0x4daa000, ltk_data = 0x4582e00, ltk_free = 0x7f1b6ea4492b <mdb_reader_free>}, {ltk_key = 0x7f1b6ea384d9, ltk_data = 0x51ee000, ltk_free = 0x7f1b6ea38491 <scope_chunk_free>}, {ltk_key = 0x45e6000, ltk_data = 0x4586200, ltk_free = 0x7f1b6ea4492b <mdb_reader_free>}, {ltk_key = 0x7f1b6ea3aaf4, ltk_data = 0x55ee000, ltk_free = 0x7f1b6ea3aad1 <search_stack_free>}, { ltk_key = 0x0, ltk_data = 0x457a400, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 24 times>}} kctx = 0x0 i = 32 keyslot = 464 hash = 81037776 __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #3 0x00007f1b728be9ca in start_thread () from /lib/libpthread.so.0 No symbol table info available. #4 0x00007f1b7261bcdd in clone () from /lib/libc.so.6 No symbol table info available. #5 0x0000000000000000 in ?? () No symbol table info available. Thread 2 (Thread 0x7ef36c5c2700 (LWP 15672)): #0 0x00007f1b728c385c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 No symbol table info available. #1 0x00007f1b73db72be in ldap_pvt_thread_cond_wait (cond=0x273c1f0, mutex=0x273c1c8) at thr_posix.c:277 No locals. #2 0x00007f1b73db5c22 in ldap_int_thread_pool_wrapper (xpool=0x273c1c0) at tpool.c:675 pool = 0x273c1c0 task = 0x0 work_list = 0x273c258 ctx = {ltu_id = 139583960131328, ltu_key = {{ltk_key = 0x43d429, ltk_data = 0x2c04500, ltk_free = 0x43d26d <conn_counter_destroy>}, {ltk_key = 0x4b388f, ltk_data = 0x2bc1300, ltk_free = 0x4b36b4 <slap_sl_mem_destroy>}, {ltk_key = 0x4591ad, ltk_data = 0x2c0e800, ltk_free = 0x459100 <slap_op_q_destroy>}, {ltk_key = 0x45e6000, ltk_data = 0x458e000, ltk_free = 0x7f1b6ea4492b <mdb_reader_free>}, {ltk_key = 0x7f1b6ea384d9, ltk_data = 0x75f6000, ltk_free = 0x7f1b6ea38491 <scope_chunk_free>}, {ltk_key = 0x7f1b6ea3aaf4, ltk_data = 0x78f6000, ltk_free = 0x7f1b6ea3aad1 <search_stack_free>}, {ltk_key = 0x0, ltk_data = 0x457b600, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 25 times>}} kctx = 0x0 i = 32 keyslot = 576 hash = 1606749760 __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #3 0x00007f1b728be9ca in start_thread () from /lib/libpthread.so.0 No symbol table info available. #4 0x00007f1b7261bcdd in clone () from /lib/libc.so.6 No symbol table info available. #5 0x0000000000000000 in ?? () No symbol table info available. Thread 1 (Thread 0x7f1b744e4720 (LWP 15508)): #0 0x00007f1b728c003d in pthread_join () from /lib/libpthread.so.0 No symbol table info available. #1 0x00007f1b73db71ff in ldap_pvt_thread_join (thread=139669884663552, thread_return=0x0) at thr_posix.c:197 No locals. #2 0x000000000043a7ff in slapd_daemon () at daemon.c:2930 i = 0 rc = 0 #3 0x0000000000416d7f in main (argc=9, argv=0x7fffc49fe378) at main.c:1012 i = 9 no_detach = 0 rc = 0 urls = 0x271a000 "ldap://zre-ldap003.eng.vmware.com:389 ldapi:///" username = 0x2714020 "root" groupname = 0x0 sandbox = 0x0 syslogUser = 128 pid = 0 waitfds = {10, 11} g_argc = 9 g_argv = 0x7fffc49fe378 configfile = 0x0 configdir = 0x2712040 "/opt/zimbra/data/ldap/config" serverName = 0x7fffc49ffd92 "slapd" serverMode = 1 scp = 0x0 scp_entry = 0x0 debug_unknowns = 0x0 syslog_unknowns = 0x0 serverNamePrefix = 0x4f9928 "" l = 139755887037800 slapd_pid_file_unlink = 1 slapd_args_file_unlink = 1 firstopt = 0 __PRETTY_FUNCTION__ = "main"

1 0

Re: (ITS#7301) Improve DNS SRV support in OpenLDAP
by quanah＠zimbra.com 12 Jun '12

12 Jun '12

--On Tuesday, June 12, 2012 11:25 AM -0700 Howard Chu <hyc(a)symas.com> wrote: > quanah(a)OpenLDAP.org wrote: >> Full_Name: Quanah Gibson-Mount >> Version: 2.4.31 >> OS: >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (75.108.184.39) >> >> >> LDAP URI handling via SRV records is not in the library. In >> particular, an OpenLDAP library client that specifies a >> (correctly formed or otherwise) LDAP URI of the form: >> >> ldap:///dc=example,dc=com/ >> >> will not be connected to the LDAP servers found in the SRV records >> for _ldap._tcp.example.com. That code is only in the ldapsearch(1) >> and related tools. >> >> The existence of the low-level support functions in the library is >> of no help to users who want to specify URIs that resolve to the >> underlying LDAP servers via SRV records. > > Tough luck. Currently ldap:/// means localhost. Changing the library > behavior here would be a pretty drastic incompatible change and would > break pretty much all existing software. This has been discussed and shot > down before, and rejecting this request is the only correct outcome for > this ITS. What about an ldap_set_option() parameter for enabling it? >> Also, the SRV -> host:port list lookup code that is in the library >> (but not tied to the libraries connection establishment code) is >> broken, it ignores the weight and priority which is not a good >> idea, the published SRV priorities and weights must not be ignored. > > priorities/weights are already the subject of ITS#7027. Ok, so will 7027 be committed, since there is a patch already provided? ;) The discussion around this started at <http://archives.neohapsis.com/archives/postfix/2012-06/0183.html> --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#7301) Improve DNS SRV support in OpenLDAP
by hyc＠symas.com 12 Jun '12

12 Jun '12

quanah(a)OpenLDAP.org wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.31 > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.108.184.39) > > > LDAP URI handling via SRV records is not in the library. In > particular, an OpenLDAP library client that specifies a > (correctly formed or otherwise) LDAP URI of the form: > > ldap:///dc=example,dc=com/ > > will not be connected to the LDAP servers found in the SRV records > for _ldap._tcp.example.com. That code is only in the ldapsearch(1) > and related tools. > > The existence of the low-level support functions in the library is > of no help to users who want to specify URIs that resolve to the > underlying LDAP servers via SRV records. Tough luck. Currently ldap:/// means localhost. Changing the library behavior here would be a pretty drastic incompatible change and would break pretty much all existing software. This has been discussed and shot down before, and rejecting this request is the only correct outcome for this ITS. > Also, the SRV -> host:port list lookup code that is in the library > (but not tied to the libraries connection establishment code) is > broken, it ignores the weight and priority which is not a good > idea, the published SRV priorities and weights must not be ignored. priorities/weights are already the subject of ITS#7027. -- -- 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#7301) Improve DNS SRV support in OpenLDAP
by quanah＠zimbra.com 12 Jun '12

12 Jun '12

--On Tuesday, June 12, 2012 6:09 PM +0000 quanah(a)OpenLDAP.org wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.31 > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.108.184.39) Note: Filed on behalf of the Postfix authors. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#7301) Improve DNS SRV support in OpenLDAP
by quanah＠OpenLDAP.org 12 Jun '12

12 Jun '12

Full_Name: Quanah Gibson-Mount Version: 2.4.31 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.108.184.39) LDAP URI handling via SRV records is not in the library. In particular, an OpenLDAP library client that specifies a (correctly formed or otherwise) LDAP URI of the form: ldap:///dc=example,dc=com/ will not be connected to the LDAP servers found in the SRV records for _ldap._tcp.example.com. That code is only in the ldapsearch(1) and related tools. The existence of the low-level support functions in the library is of no help to users who want to specify URIs that resolve to the underlying LDAP servers via SRV records. Also, the SRV -> host:port list lookup code that is in the library (but not tied to the libraries connection establishment code) is broken, it ignores the weight and priority which is not a good idea, the published SRV priorities and weights must not be ignored.

1 0

Re: (ITS#7300) ACLs
by quanah＠zimbra.com 12 Jun '12

12 Jun '12

--On Tuesday, June 12, 2012 5:57 PM +0000 andre.cardinal(a)bell.ca wrote: > Full_Name: Andre Cardinal > Version: 2.4.30 > OS: Red Hat 5 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (206.47.249.246) This is not a bug report. This ITS will be closed. If you have usage questions, please use the openldap-technical(a)openldap.org mailing list. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#7300) ACLs
by andre.cardinal＠bell.ca 12 Jun '12

12 Jun '12

Full_Name: Andre Cardinal Version: 2.4.30 OS: Red Hat 5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (206.47.249.246) I have the following ACL set up in slapd.conf access to dn.base="" by * read access to attrs=GCSRAAllow,GCSRAGroup,GCSRASubjectdn,userpassword by dn="cn=ProvAdmin,ou=GCSRAAdmin,o=gc,c=ca" write by dn="cn=gateAdmin1,ou=GCSRAAdmin,o=gc,c=ca" read by dn="cn=gateAdmin2,ou=GCSRAAdmin,o=gc,c=ca" read slapacl -f /usr/local/etc/openldap/slapd.conf -D cn=provadmin,ou=gcsraadmin,o=gc,c=ca -b ou=gcsrausers,o=gc,c=ca gcsraallow authcDN: "cn=provadmin,ou=gcsraadmin,o=gc,c=ca" GCSRAAllow: write(=wrscxd) However any modify I try returns: modifying entry "GCSRASubjectDN=my636-test,ou=GCSRAUsers,o=gc,c=ca" ldap_modify: Insufficient access (50)

1 0

(ITS#7299) Memory leaks when using ldapmodify to add members to groupOfNames objectclass
by jsynacek＠redhat.com 12 Jun '12

12 Jun '12

Full_Name: Jan Synacek Version: git (c73ec15) OS: linux-fedora17 URL: http://jsynacek.fedorapeople.org/openldap/leak/openldap-mmr-leak.tar.gz Submission from: (NULL) (209.132.186.34) I'm using a 2-node mmr setup on my local machine - configuration files and 'uploader' scripts are provided in the archive. 1) I have the two nodes running. 2) Execute run.sh (only a wrapper for ldapusradm.sh) and start monitoring slapd's memory usage. 3) After some time (at about 2k users on my system), slapd consumes a large amount of memory which is still growing Note that not using ldapmodify to add members to 'cn=users,dc=yes,dc=my', but using it e.g. for modifying each user's email, does NOT result in any memory leakage. I have also created a massif output using valgrind's massif tool: http://jsynacek.fedorapeople.org/openldap/leak/massif.out.17906 I found a very similar bug (#7292), but I'm not sure if it's related.

1 0

(ITS#7298) permissive modify control misparsed
by ondrej.kuznik＠acision.com 12 Jun '12

12 Jun '12

Full_Name: Ondrej Kuznik Version: HEAD OS: Linux URL: Submission from: (NULL) (62.168.56.1) It appears that an oversight in commit f810e6ed417939ed69b388ad7fb0c696e185f593 has caused the permissive modify control[1] to be parsed as needing a value. Negating the condition in file servers/slapd/controls.c at line 1627 fixes that. [1]: http://msdn.microsoft.com/en-us/library/windows/desktop/aa366984(v=vs.85).a…

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