openldap-bugs

openldap-bugs@openldap.org

1 participants
21001 discussions

Re: (ITS#6506) Use of back-perl in slapd.conf in subordinate database causes slapcat to segfault
by masarati＠aero.polimi.it 06 Apr '10

06 Apr '10

> masarati(a)aero.polimi.it wrote: > >>> *** glibc detected *** ./sbin/slapcat: free(): invalid pointer: >> >> ^^^ this message is not quite informative, nor is what follows below. >> Please read <http://www.openldap.org/faq/data/cache/56.html> carefully, >> and provide the information required. >> >> p. > > Okay. I figured it was easy enough to recreate that I wouldn't need to > build a full debug build myself, but looks like I need to do that > anyway. Also, what is the best way to not get "strip" to be > automatically invoked during "make install"? I ended up temporarily > removing the binary just to get unstripped versions. What about make STRIP="" install ? Apart from the bug you manifest, which should not occur, I'd note that back-perl does not support slaptools, and thus no slaptool'ing should occur when using it. I can't debug this right now because I don't routinely build with back-perl. My guess is that the bug should appear with any other glued backend that does not support tools (but I couldn't reproduce it using back-ldap, for example). A (possible) workaround is to use slapcat -a '(!(entryDN:dnSubtreeMatch:=ou=perl,dc=my-domain,dc=com))' in order to exclude the subtree handled by back-perl. p. > > (gdb) bt full > #0 0x00007f18761dded5 in raise () from /lib/libc.so.6 > No symbol table info available. > #1 0x00007f18761df3f3 in abort () from /lib/libc.so.6 > No symbol table info available. > #2 0x00007f187621a3a8 in ?? () from /lib/libc.so.6 > No symbol table info available. > #3 0x00007f187621f948 in ?? () from /lib/libc.so.6 > No symbol table info available. > #4 0x00007f1876221a56 in free () from /lib/libc.so.6 > No symbol table info available. > #5 0x00007f1877296c52 in ber_memfree_x (p=0xa207b3, ctx=0x0) at > memory.c:152 > __PRETTY_FUNCTION__ = "ber_memfree_x" > #6 0x000000000044f785 in ch_free (ptr=0xa207b3) at ch_malloc.c:139 > ctx = (void *) 0x0 > #7 0x00000000004395e6 in entry_clean (e=0xa0bff8) at entry.c:489 > __PRETTY_FUNCTION__ = "entry_clean" > #8 0x00000000004396ab in entry_free (e=0xa0bff8) at entry.c:514 > No locals. > #9 0x00000000004ae4e4 in glue_entry_release_rw (op=0x7fffe262a540, > e=0xa0bff8, rw=0) at backglue.c:731 > b0 = (BackendDB *) 0x7fffe262a2d0 > rc = -1 > #10 0x00000000004b0952 in overlay_entry_release_ov (op=0x7fffe262a540, > e=0xa0bff8, rw=0, on=0x8997d0) at backover.c:421 > oi = (slap_overinfo *) 0x8995f0 > be = (BackendDB *) 0x89a510 > db = {bd_info = 0x8997d0, bd_self = 0x89a510, be_ctrls = > "\000\001\001\001\000\001\000\000\001\000\000\001\001\000\001", '\0' > <repeats 17 times>, "\001", > be_flags = 2328, 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 = 0x899270, be_nsuffix = 0x8992a0, > be_schemadn = {bv_len = 0, > bv_val = 0x0}, be_schemandn = {bv_len = 0, bv_val = 0x0}, be_rootdn > = {bv_len = 30, bv_val = 0x899570 "cn=Manager,dc=my-domain,dc=com"}, > be_rootndn = {bv_len = 30, > bv_val = 0x8995c0 "cn=manager,dc=my-domain,dc=com"}, be_rootpw = > {bv_len = 6, bv_val = 0x8993b0 "secret"}, be_max_deref_depth = 15, > be_def_limit = { > lms_t_soft = 3600, lms_t_hard = 0, lms_s_soft = 500, 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 = 0x0, be_dfltaccess = ACL_READ, be_update_ndn = {bv_len = 0, > bv_val = 0x0}, be_update_refs = 0x0, be_pending_csn_list = 0x8978c0, > be_pcl_mutex = {__data = { > __lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, > __spins = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\0' > <repeats 39 times>, > __align = 0}, be_syncinfo = 0x0, be_pb = 0x0, be_cf_ocs = 0x7b8c00, > be_private = 0x898a30, be_next = {stqe_next = 0x0}} > bi = (BackendInfo *) 0x8995f0 > rc = 32768 > #11 0x00000000004b0ab2 in over_entry_release_rw (op=0x7fffe262a540, > e=0xa0bff8, rw=0) at backover.c:463 > oi = (slap_overinfo *) 0x8995f0 > on = (slap_overinst *) 0x8997d0 > __PRETTY_FUNCTION__ = "over_entry_release_rw" > #12 0x000000000043d3cf in be_entry_release_rw (op=0x7fffe262a540, > e=0xa0bff8, rw=0) at backend.c:880 > No locals. > #13 0x00000000004b5c5b in slapcat (argc=1, argv=0x7fffe262a8e8) at > slapcat.c:117 > data = 0xa20c50 "dn: ou=perl,dc=my-domain,dc=com\nobjectClass: > organizationalUnit\nobjectClass: top\nou: perl\nstructuralObjectClass: > organizationalUnit\nentryUUID: > 6438973e-d5c0-102e-9c05-81e0ba1bb1f2\ncreatorsName: cn=Man"... > len = 388 > e = (Entry *) 0xa0bff8 > id = 3 > rc = 0 > op = {o_hdr = 0x0, o_tag = 0, o_time = 0, o_tincr = 0, o_bd = > 0x898500, o_req_dn = {bv_len = 0, bv_val = 0x0}, o_req_ndn = {bv_len = > 0, bv_val = 0x0}, > o_request = {oq_add = {rs_modlist = 0x0, rs_e = 0x0}, oq_bind = > {rb_method = 0, rb_cred = {bv_len = 0, bv_val = 0x0}, rb_edn = {bv_len = > 0, bv_val = 0x0}, rb_ssf = 0, > rb_mech = {bv_len = 0, bv_val = 0x0}}, oq_compare = {rs_ava = > 0x0}, oq_modify = {rs_mods = {rs_modlist = 0x0, rs_no_opattrs = 0 '\0'}, > rs_increment = 0}, > oq_modrdn = {rs_mods = {rs_modlist = 0x0, rs_no_opattrs = 0 '\0'}, > rs_deleteoldrdn = 0, rs_newrdn = {bv_len = 0, bv_val = 0x0}, rs_nnewrdn > = {bv_len = 0, > bv_val = 0x0}, rs_newSup = 0x0, rs_nnewSup = 0x0}, oq_search = > {rs_scope = 0, rs_deref = 0, rs_slimit = 0, rs_tlimit = 0, rs_limit = > 0x0, rs_attrsonly = 0, > rs_attrs = 0x0, rs_filter = 0x0, rs_filterstr = {bv_len = 0, > bv_val = 0x0}}, oq_abandon = {rs_msgid = 0}, oq_cancel = {rs_msgid = 0}, > oq_extended = {rs_reqoid = { > bv_len = 0, bv_val = 0x0}, rs_flags = 0, rs_reqdata = 0x0}, > oq_pwdexop = {rs_extended = {rs_reqoid = {bv_len = 0, bv_val = 0x0}, > rs_flags = 0, > rs_reqdata = 0x0}, rs_old = {bv_len = 0, bv_val = 0x0}, rs_new > = {bv_len = 0, bv_val = 0x0}, rs_mods = 0x0, rs_modtail = 0x0}}, > o_abandon = 0, o_cancel = 0, > o_groups = 0x0, o_do_not_cache = 0 '\0', o_is_auth_check = 0 '\0', > o_dont_replicate = 0 '\0', o_acl_priv = ACL_NONE, o_nocaching = 0 '\0', > o_delete_glue_parent = 0 '\0', o_no_schema_check = 0 '\0', > o_no_subordinate_glue = 0 '\0', o_ctrlflag = '\0' <repeats 31 times>, > o_controls = 0x0, o_authz = { > sai_method = 0, sai_mech = {bv_len = 0, bv_val = 0x0}, sai_dn = > {bv_len = 0, bv_val = 0x0}, sai_ndn = {bv_len = 0, bv_val = 0x0}, > sai_ssf = 0, > sai_transport_ssf = 0, sai_tls_ssf = 0, sai_sasl_ssf = 0}, o_ber = > 0x0, o_res_ber = 0x0, o_callback = 0x0, o_ctrls = 0x0, o_csn = {bv_len = > 0, bv_val = 0x0}, > o_private = 0x0, o_extra = {slh_first = 0x0}, o_next = {stqe_next = > 0x0}} > progname = 0x55fc68 "slapcat" > #14 0x00000000004090d3 in main (argc=1, argv=0x7fffe262a8e8) at main.c:403 > i = 1 > no_detach = 0 > rc = 1 > urls = 0x0 > username = 0x0 > groupname = 0x0 > sandbox = 0x0 > syslogUser = 160 > g_argc = 1 > g_argv = (char **) 0x7fffe262a8e8 > configfile = 0x0 > configdir = 0x0 > serverName = 0x7fffe262c75e "slapcat" > serverMode = 1 > scp = (struct sync_cookie *) 0x0 > scp_entry = (struct sync_cookie *) 0x0 > debug_unknowns = (char **) 0x0 > syslog_unknowns = (char **) 0x0 > serverNamePrefix = 0x54076b "" > l = 4223483 > slapd_pid_file_unlink = 0 > slapd_args_file_unlink = 0 > firstopt = 1 > __PRETTY_FUNCTION__ = "main" > (gdb) > > > HTH, > > Mark. > > -- > Mark Cave-Ayland - Senior Technical Architect > PostgreSQL - PostGIS > Sirius Corporation plc - control through freedom > http://www.siriusit.co.uk > t: +44 870 608 0063 > > Sirius Labs: http://www.siriusit.co.uk/labs >

1 0

Re: (ITS#6506) Use of back-perl in slapd.conf in subordinate database causes slapcat to segfault
by mark.cave-ayland＠siriusit.co.uk 06 Apr '10

06 Apr '10

masarati(a)aero.polimi.it wrote: >> *** glibc detected *** ./sbin/slapcat: free(): invalid pointer: > > ^^^ this message is not quite informative, nor is what follows below. > Please read <http://www.openldap.org/faq/data/cache/56.html> carefully, > and provide the information required. > > p. Okay. I figured it was easy enough to recreate that I wouldn't need to build a full debug build myself, but looks like I need to do that anyway. Also, what is the best way to not get "strip" to be automatically invoked during "make install"? I ended up temporarily removing the binary just to get unstripped versions. (gdb) bt full #0 0x00007f18761dded5 in raise () from /lib/libc.so.6 No symbol table info available. #1 0x00007f18761df3f3 in abort () from /lib/libc.so.6 No symbol table info available. #2 0x00007f187621a3a8 in ?? () from /lib/libc.so.6 No symbol table info available. #3 0x00007f187621f948 in ?? () from /lib/libc.so.6 No symbol table info available. #4 0x00007f1876221a56 in free () from /lib/libc.so.6 No symbol table info available. #5 0x00007f1877296c52 in ber_memfree_x (p=0xa207b3, ctx=0x0) at memory.c:152 __PRETTY_FUNCTION__ = "ber_memfree_x" #6 0x000000000044f785 in ch_free (ptr=0xa207b3) at ch_malloc.c:139 ctx = (void *) 0x0 #7 0x00000000004395e6 in entry_clean (e=0xa0bff8) at entry.c:489 __PRETTY_FUNCTION__ = "entry_clean" #8 0x00000000004396ab in entry_free (e=0xa0bff8) at entry.c:514 No locals. #9 0x00000000004ae4e4 in glue_entry_release_rw (op=0x7fffe262a540, e=0xa0bff8, rw=0) at backglue.c:731 b0 = (BackendDB *) 0x7fffe262a2d0 rc = -1 #10 0x00000000004b0952 in overlay_entry_release_ov (op=0x7fffe262a540, e=0xa0bff8, rw=0, on=0x8997d0) at backover.c:421 oi = (slap_overinfo *) 0x8995f0 be = (BackendDB *) 0x89a510 db = {bd_info = 0x8997d0, bd_self = 0x89a510, be_ctrls = "\000\001\001\001\000\001\000\000\001\000\000\001\001\000\001", '\0' <repeats 17 times>, "\001", be_flags = 2328, 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 = 0x899270, be_nsuffix = 0x8992a0, be_schemadn = {bv_len = 0, bv_val = 0x0}, be_schemandn = {bv_len = 0, bv_val = 0x0}, be_rootdn = {bv_len = 30, bv_val = 0x899570 "cn=Manager,dc=my-domain,dc=com"}, be_rootndn = {bv_len = 30, bv_val = 0x8995c0 "cn=manager,dc=my-domain,dc=com"}, be_rootpw = {bv_len = 6, bv_val = 0x8993b0 "secret"}, be_max_deref_depth = 15, be_def_limit = { lms_t_soft = 3600, lms_t_hard = 0, lms_s_soft = 500, 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 = 0x0, be_dfltaccess = ACL_READ, be_update_ndn = {bv_len = 0, bv_val = 0x0}, be_update_refs = 0x0, be_pending_csn_list = 0x8978c0, be_pcl_mutex = {__data = { __lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\0' <repeats 39 times>, __align = 0}, be_syncinfo = 0x0, be_pb = 0x0, be_cf_ocs = 0x7b8c00, be_private = 0x898a30, be_next = {stqe_next = 0x0}} bi = (BackendInfo *) 0x8995f0 rc = 32768 #11 0x00000000004b0ab2 in over_entry_release_rw (op=0x7fffe262a540, e=0xa0bff8, rw=0) at backover.c:463 oi = (slap_overinfo *) 0x8995f0 on = (slap_overinst *) 0x8997d0 __PRETTY_FUNCTION__ = "over_entry_release_rw" #12 0x000000000043d3cf in be_entry_release_rw (op=0x7fffe262a540, e=0xa0bff8, rw=0) at backend.c:880 No locals. #13 0x00000000004b5c5b in slapcat (argc=1, argv=0x7fffe262a8e8) at slapcat.c:117 data = 0xa20c50 "dn: ou=perl,dc=my-domain,dc=com\nobjectClass: organizationalUnit\nobjectClass: top\nou: perl\nstructuralObjectClass: organizationalUnit\nentryUUID: 6438973e-d5c0-102e-9c05-81e0ba1bb1f2\ncreatorsName: cn=Man"... len = 388 e = (Entry *) 0xa0bff8 id = 3 rc = 0 op = {o_hdr = 0x0, o_tag = 0, o_time = 0, o_tincr = 0, o_bd = 0x898500, o_req_dn = {bv_len = 0, bv_val = 0x0}, o_req_ndn = {bv_len = 0, bv_val = 0x0}, o_request = {oq_add = {rs_modlist = 0x0, rs_e = 0x0}, oq_bind = {rb_method = 0, rb_cred = {bv_len = 0, bv_val = 0x0}, rb_edn = {bv_len = 0, bv_val = 0x0}, rb_ssf = 0, rb_mech = {bv_len = 0, bv_val = 0x0}}, oq_compare = {rs_ava = 0x0}, oq_modify = {rs_mods = {rs_modlist = 0x0, rs_no_opattrs = 0 '\0'}, rs_increment = 0}, oq_modrdn = {rs_mods = {rs_modlist = 0x0, rs_no_opattrs = 0 '\0'}, rs_deleteoldrdn = 0, rs_newrdn = {bv_len = 0, bv_val = 0x0}, rs_nnewrdn = {bv_len = 0, bv_val = 0x0}, rs_newSup = 0x0, rs_nnewSup = 0x0}, oq_search = {rs_scope = 0, rs_deref = 0, rs_slimit = 0, rs_tlimit = 0, rs_limit = 0x0, rs_attrsonly = 0, rs_attrs = 0x0, rs_filter = 0x0, rs_filterstr = {bv_len = 0, bv_val = 0x0}}, oq_abandon = {rs_msgid = 0}, oq_cancel = {rs_msgid = 0}, oq_extended = {rs_reqoid = { bv_len = 0, bv_val = 0x0}, rs_flags = 0, rs_reqdata = 0x0}, oq_pwdexop = {rs_extended = {rs_reqoid = {bv_len = 0, bv_val = 0x0}, rs_flags = 0, rs_reqdata = 0x0}, rs_old = {bv_len = 0, bv_val = 0x0}, rs_new = {bv_len = 0, bv_val = 0x0}, rs_mods = 0x0, rs_modtail = 0x0}}, o_abandon = 0, o_cancel = 0, o_groups = 0x0, o_do_not_cache = 0 '\0', o_is_auth_check = 0 '\0', o_dont_replicate = 0 '\0', o_acl_priv = ACL_NONE, o_nocaching = 0 '\0', o_delete_glue_parent = 0 '\0', o_no_schema_check = 0 '\0', o_no_subordinate_glue = 0 '\0', o_ctrlflag = '\0' <repeats 31 times>, o_controls = 0x0, o_authz = { sai_method = 0, sai_mech = {bv_len = 0, bv_val = 0x0}, sai_dn = {bv_len = 0, bv_val = 0x0}, sai_ndn = {bv_len = 0, bv_val = 0x0}, sai_ssf = 0, sai_transport_ssf = 0, sai_tls_ssf = 0, sai_sasl_ssf = 0}, o_ber = 0x0, o_res_ber = 0x0, o_callback = 0x0, o_ctrls = 0x0, o_csn = {bv_len = 0, bv_val = 0x0}, o_private = 0x0, o_extra = {slh_first = 0x0}, o_next = {stqe_next = 0x0}} progname = 0x55fc68 "slapcat" #14 0x00000000004090d3 in main (argc=1, argv=0x7fffe262a8e8) at main.c:403 i = 1 no_detach = 0 rc = 1 urls = 0x0 username = 0x0 groupname = 0x0 sandbox = 0x0 syslogUser = 160 g_argc = 1 g_argv = (char **) 0x7fffe262a8e8 configfile = 0x0 configdir = 0x0 serverName = 0x7fffe262c75e "slapcat" serverMode = 1 scp = (struct sync_cookie *) 0x0 scp_entry = (struct sync_cookie *) 0x0 debug_unknowns = (char **) 0x0 syslog_unknowns = (char **) 0x0 serverNamePrefix = 0x54076b "" l = 4223483 slapd_pid_file_unlink = 0 slapd_args_file_unlink = 0 firstopt = 1 __PRETTY_FUNCTION__ = "main" (gdb) HTH, Mark. -- Mark Cave-Ayland - Senior Technical Architect PostgreSQL - PostGIS Sirius Corporation plc - control through freedom http://www.siriusit.co.uk t: +44 870 608 0063 Sirius Labs: http://www.siriusit.co.uk/labs

1 0

Re: (ITS#6506) Use of back-perl in slapd.conf in subordinate database causes slapcat to segfault
by masarati＠aero.polimi.it 06 Apr '10

06 Apr '10

> masarati(a)aero.polimi.it wrote: > >> ^^^ I think the culprit is here. No point in tracking down further this >> issue unless you re-link as recommended by this message. >> >> p. > > Sorry - I experienced the error on a production box running Debian > packages, and re-built from source on my local machine just to confirm > the bug still exists. However, my local machine already has other LDAP > libraries installed which seems to have resulted in some of the wrong > libraries being picked up at compile time. > > I've now removed all pre-built openldap packages, re-built again from > source and can confirm that the bug still stands since the > "ldap_int_global_options" warning has now disappeared: > > > zeno:/home/build/rel-openldap# ./sbin/slapcat > Here in new > Posix Var 8192 and 4096 > bdb_db_open: database "dc=my-domain,dc=com": unclean shutdown detected; > attempting recovery. > bdb_db_open: warning - no DB_CONFIG file found in directory > /home/build/rel-openldap/var/openldap-data: (2). > Expect poor performance for suffix "dc=my-domain,dc=com". > bdb_db_open: database "dc=my-domain,dc=com": recovery skipped in > read-only mode. Run manual recovery if errors are encountered. > bdb_monitor_db_open: monitoring disabled; configure monitor database to > enable > dn: dc=my-domain,dc=com > objectClass: top > objectClass: dcObject > objectClass: organization > o:: bXlkb21haW4uY29tIA== > dc: my-domain > structuralObjectClass: organization > entryUUID: 0bdc2650-d5c0-102e-9fe7-3350c645132d > creatorsName: cn=Manager,dc=my-domain,dc=com > createTimestamp: 20100406120241Z > entryCSN: 20100406120241.310422Z#000000#000#000000 > modifiersName: cn=Manager,dc=my-domain,dc=com > modifyTimestamp: 20100406120241Z > > dn: ou=real,dc=my-domain,dc=com > objectClass: organizationalUnit > objectClass: top > structuralObjectClass: organizationalUnit > entryUUID: 5644fb04-d5c0-102e-9c04-81e0ba1bb1f2 > creatorsName: cn=Manager,dc=my-domain,dc=com > createTimestamp: 20100406120446Z > ou: real > entryCSN: 20100406120458.545769Z#000000#000#000000 > modifiersName: cn=Manager,dc=my-domain,dc=com > modifyTimestamp: 20100406120458Z > > *** glibc detected *** ./sbin/slapcat: free(): invalid pointer: ^^^ this message is not quite informative, nor is what follows below. Please read <http://www.openldap.org/faq/data/cache/56.html> carefully, and provide the information required. p. > 0x00000000009c4fd3 *** > ======= Backtrace: ========= > /lib/libc.so.6[0x7f4ea6fd0948] > /lib/libc.so.6(cfree+0x76)[0x7f4ea6fd2a56] > ./sbin/slapcat[0x42c11d] > ./sbin/slapcat[0x42c1c9] > ./sbin/slapcat[0x481448] > ./sbin/slapcat[0x484c93] > ./sbin/slapcat[0x4874b9] > ./sbin/slapcat[0x408d40] > /lib/libc.so.6(__libc_start_main+0xe6)[0x7f4ea6f7b1a6] > ./sbin/slapcat[0x4087d9] > > > Many thanks, > > Mark. > > -- > Mark Cave-Ayland - Senior Technical Architect > PostgreSQL - PostGIS > Sirius Corporation plc - control through freedom > http://www.siriusit.co.uk > t: +44 870 608 0063 > > Sirius Labs: http://www.siriusit.co.uk/labs >

1 0

Re: (ITS#6506) Use of back-perl in slapd.conf in subordinate database causes slapcat to segfault
by mark.cave-ayland＠siriusit.co.uk 06 Apr '10

06 Apr '10

masarati(a)aero.polimi.it wrote: > ^^^ I think the culprit is here. No point in tracking down further this > issue unless you re-link as recommended by this message. > > p. Sorry - I experienced the error on a production box running Debian packages, and re-built from source on my local machine just to confirm the bug still exists. However, my local machine already has other LDAP libraries installed which seems to have resulted in some of the wrong libraries being picked up at compile time. I've now removed all pre-built openldap packages, re-built again from source and can confirm that the bug still stands since the "ldap_int_global_options" warning has now disappeared: zeno:/home/build/rel-openldap# ./sbin/slapcat Here in new Posix Var 8192 and 4096 bdb_db_open: database "dc=my-domain,dc=com": unclean shutdown detected; attempting recovery. bdb_db_open: warning - no DB_CONFIG file found in directory /home/build/rel-openldap/var/openldap-data: (2). Expect poor performance for suffix "dc=my-domain,dc=com". bdb_db_open: database "dc=my-domain,dc=com": recovery skipped in read-only mode. Run manual recovery if errors are encountered. bdb_monitor_db_open: monitoring disabled; configure monitor database to enable dn: dc=my-domain,dc=com objectClass: top objectClass: dcObject objectClass: organization o:: bXlkb21haW4uY29tIA== dc: my-domain structuralObjectClass: organization entryUUID: 0bdc2650-d5c0-102e-9fe7-3350c645132d creatorsName: cn=Manager,dc=my-domain,dc=com createTimestamp: 20100406120241Z entryCSN: 20100406120241.310422Z#000000#000#000000 modifiersName: cn=Manager,dc=my-domain,dc=com modifyTimestamp: 20100406120241Z dn: ou=real,dc=my-domain,dc=com objectClass: organizationalUnit objectClass: top structuralObjectClass: organizationalUnit entryUUID: 5644fb04-d5c0-102e-9c04-81e0ba1bb1f2 creatorsName: cn=Manager,dc=my-domain,dc=com createTimestamp: 20100406120446Z ou: real entryCSN: 20100406120458.545769Z#000000#000#000000 modifiersName: cn=Manager,dc=my-domain,dc=com modifyTimestamp: 20100406120458Z *** glibc detected *** ./sbin/slapcat: free(): invalid pointer: 0x00000000009c4fd3 *** ======= Backtrace: ========= /lib/libc.so.6[0x7f4ea6fd0948] /lib/libc.so.6(cfree+0x76)[0x7f4ea6fd2a56] ./sbin/slapcat[0x42c11d] ./sbin/slapcat[0x42c1c9] ./sbin/slapcat[0x481448] ./sbin/slapcat[0x484c93] ./sbin/slapcat[0x4874b9] ./sbin/slapcat[0x408d40] /lib/libc.so.6(__libc_start_main+0xe6)[0x7f4ea6f7b1a6] ./sbin/slapcat[0x4087d9] Many thanks, Mark. -- Mark Cave-Ayland - Senior Technical Architect PostgreSQL - PostGIS Sirius Corporation plc - control through freedom http://www.siriusit.co.uk t: +44 870 608 0063 Sirius Labs: http://www.siriusit.co.uk/labs

1 0

Re: (ITS#6506) Use of back-perl in slapd.conf in subordinate database causes slapcat to segfault
by masarati＠aero.polimi.it 06 Apr '10

06 Apr '10

> Full_Name: Mark Cave-Ayland > Version: 2.4.21 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (81.187.123.11) > > > Hi there, > > Having implemented a custom perl module as a subordinate with back-perl, > we've > found a segfault when using slapcat to dump the database. The backtrace > looks > like this: > > > zeno:/home/build/rel-openldap# ./sbin/slapcat > ./sbin/slapcat: Symbol `ldap_int_global_options' has different size in > shared > object, consider re-linking ^^^ I think the culprit is here. No point in tracking down further this issue unless you re-link as recommended by this message. p. > Here in new > Posix Var 8192 and 4096 > bdb_db_open: warning - no DB_CONFIG file found in directory > /home/build/rel-openldap/var/openldap-data: (2). > Expect poor performance for suffix "dc=my-domain,dc=com". > bdb_monitor_db_open: monitoring disabled; configure monitor database to > enable > dn: dc=my-domain,dc=com > objectClass: top > objectClass: dcObject > objectClass: organization > o:: bXlkb21haW4uY29tIA== > dc: my-domain > structuralObjectClass: organization > entryUUID: 0bdc2650-d5c0-102e-9fe7-3350c645132d > creatorsName: cn=Manager,dc=my-domain,dc=com > createTimestamp: 20100406120241Z > entryCSN: 20100406120241.310422Z#000000#000#000000 > modifiersName: cn=Manager,dc=my-domain,dc=com > modifyTimestamp: 20100406120241Z > > dn: ou=real,dc=my-domain,dc=com > objectClass: organizationalUnit > objectClass: top > structuralObjectClass: organizationalUnit > entryUUID: 5644fb04-d5c0-102e-9c04-81e0ba1bb1f2 > creatorsName: cn=Manager,dc=my-domain,dc=com > createTimestamp: 20100406120446Z > ou: real > entryCSN: 20100406120458.545769Z#000000#000#000000 > modifiersName: cn=Manager,dc=my-domain,dc=com > modifyTimestamp: 20100406120458Z > > *** glibc detected *** ./sbin/slapcat: free(): invalid pointer: > 0x00000000009c5063 *** > ======= Backtrace: ========= > /lib/libc.so.6[0x7f1adc150948] > /lib/libc.so.6(cfree+0x76)[0x7f1adc152a56] > ./sbin/slapcat[0x42c11d] > ./sbin/slapcat[0x42c1c9] > ./sbin/slapcat[0x481448] > ./sbin/slapcat[0x484c93] > ./sbin/slapcat[0x4874b9] > ./sbin/slapcat[0x408d40] > /lib/libc.so.6(__libc_start_main+0xe6)[0x7f1adc0fb1a6] > ./sbin/slapcat[0x4087d9] > > > Looks like an invalid pointer is being deferenced when running slapcat. > > > ATB, > > Mark. > > >

1 0

Re: (ITS#6506) Use of back-perl in slapd.conf in subordinate database causes slapcat to segfault
by mark.cave-ayland＠siriusit.co.uk 06 Apr '10

06 Apr '10

Here is the slapd.conf used in the test: # # See slapd.conf(5) for details on configuration options. # This file should NOT be world readable. # include /home/build/rel-openldap/etc/openldap/schema/core.schema # Define global ACLs to disable default read access. # Do not enable referrals until AFTER you have a working directory # service AND an understanding of referrals. #referral ldap://root.openldap.org pidfile /home/build/rel-openldap/var/run/slapd.pid argsfile /home/build/rel-openldap/var/run/slapd.args # Load dynamic backend modules: # modulepath /home/build/rel-openldap/libexec/openldap # moduleload back_bdb.la # moduleload back_hdb.la # moduleload back_ldap.la # Sample security restrictions # Require integrity protection (prevent hijacking) # Require 112-bit (3DES or better) encryption for updates # Require 63-bit encryption for simple bind # security ssf=1 update_ssf=112 simple_bind=64 # Sample access control policy: # Root DSE: allow anyone to read it # Subschema (sub)entry DSE: allow anyone to read it # Other DSEs: # Allow self write access # Allow authenticated users read access # Allow anonymous users to authenticate # Directives needed to implement policy: # access to dn.base="" by * read # access to dn.base="cn=Subschema" by * read # access to * # by self write # by users read # by anonymous auth # # if no access controls are present, the default policy # allows anyone and everyone to read anything but restricts # updates to rootdn. (e.g., "access to * by * read") # # rootdn can always read and write EVERYTHING! database perl suffix "ou=perl,dc=my-domain,dc=com" subordinate perlModulePath /home/build/rel-openldap/etc/openldap perlModule SampleLDAP ####################################################################### # BDB database definitions ####################################################################### database bdb suffix "dc=my-domain,dc=com" rootdn "cn=Manager,dc=my-domain,dc=com" # Cleartext passwords, especially for the rootdn, should # be avoid. See slappasswd(8) and slapd.conf(5) for details. # Use of strong authentication encouraged. rootpw secret # The database directory MUST exist prior to running slapd AND # should only be accessible by the slapd and slap tools. # Mode 700 recommended. directory /home/build/rel-openldap/var/openldap-data # Indices to maintain index objectClass eq And here is the slapcat output when the perl database is disabled in slapd.conf to prevent the crash: dn: dc=my-domain,dc=com objectClass: top objectClass: dcObject objectClass: organization o:: bXlkb21haW4uY29tIA== dc: my-domain structuralObjectClass: organization entryUUID: 0bdc2650-d5c0-102e-9fe7-3350c645132d creatorsName: cn=Manager,dc=my-domain,dc=com createTimestamp: 20100406120241Z entryCSN: 20100406120241.310422Z#000000#000#000000 modifiersName: cn=Manager,dc=my-domain,dc=com modifyTimestamp: 20100406120241Z dn: ou=real,dc=my-domain,dc=com objectClass: organizationalUnit objectClass: top structuralObjectClass: organizationalUnit entryUUID: 5644fb04-d5c0-102e-9c04-81e0ba1bb1f2 creatorsName: cn=Manager,dc=my-domain,dc=com createTimestamp: 20100406120446Z ou: real entryCSN: 20100406120458.545769Z#000000#000#000000 modifiersName: cn=Manager,dc=my-domain,dc=com modifyTimestamp: 20100406120458Z dn: ou=perl,dc=my-domain,dc=com objectClass: organizationalUnit objectClass: top ou: perl structuralObjectClass: organizationalUnit entryUUID: 6438973e-d5c0-102e-9c05-81e0ba1bb1f2 creatorsName: cn=Manager,dc=my-domain,dc=com createTimestamp: 20100406120509Z entryCSN: 20100406120509.555750Z#000000#000#000000 modifiersName: cn=Manager,dc=my-domain,dc=com modifyTimestamp: 20100406120509Z ATB, Mark. -- Mark Cave-Ayland - Senior Technical Architect PostgreSQL - PostGIS Sirius Corporation plc - control through freedom http://www.siriusit.co.uk t: +44 870 608 0063 Sirius Labs: http://www.siriusit.co.uk/labs

1 0

(ITS#6506) Use of back-perl in slapd.conf in subordinate database causes slapcat to segfault
by mark.cave-ayland＠siriusit.co.uk 06 Apr '10

06 Apr '10

Full_Name: Mark Cave-Ayland Version: 2.4.21 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.187.123.11) Hi there, Having implemented a custom perl module as a subordinate with back-perl, we've found a segfault when using slapcat to dump the database. The backtrace looks like this: zeno:/home/build/rel-openldap# ./sbin/slapcat ./sbin/slapcat: Symbol `ldap_int_global_options' has different size in shared object, consider re-linking Here in new Posix Var 8192 and 4096 bdb_db_open: warning - no DB_CONFIG file found in directory /home/build/rel-openldap/var/openldap-data: (2). Expect poor performance for suffix "dc=my-domain,dc=com". bdb_monitor_db_open: monitoring disabled; configure monitor database to enable dn: dc=my-domain,dc=com objectClass: top objectClass: dcObject objectClass: organization o:: bXlkb21haW4uY29tIA== dc: my-domain structuralObjectClass: organization entryUUID: 0bdc2650-d5c0-102e-9fe7-3350c645132d creatorsName: cn=Manager,dc=my-domain,dc=com createTimestamp: 20100406120241Z entryCSN: 20100406120241.310422Z#000000#000#000000 modifiersName: cn=Manager,dc=my-domain,dc=com modifyTimestamp: 20100406120241Z dn: ou=real,dc=my-domain,dc=com objectClass: organizationalUnit objectClass: top structuralObjectClass: organizationalUnit entryUUID: 5644fb04-d5c0-102e-9c04-81e0ba1bb1f2 creatorsName: cn=Manager,dc=my-domain,dc=com createTimestamp: 20100406120446Z ou: real entryCSN: 20100406120458.545769Z#000000#000#000000 modifiersName: cn=Manager,dc=my-domain,dc=com modifyTimestamp: 20100406120458Z *** glibc detected *** ./sbin/slapcat: free(): invalid pointer: 0x00000000009c5063 *** ======= Backtrace: ========= /lib/libc.so.6[0x7f1adc150948] /lib/libc.so.6(cfree+0x76)[0x7f1adc152a56] ./sbin/slapcat[0x42c11d] ./sbin/slapcat[0x42c1c9] ./sbin/slapcat[0x481448] ./sbin/slapcat[0x484c93] ./sbin/slapcat[0x4874b9] ./sbin/slapcat[0x408d40] /lib/libc.so.6(__libc_start_main+0xe6)[0x7f1adc0fb1a6] ./sbin/slapcat[0x4087d9] Looks like an invalid pointer is being deferenced when running slapcat. ATB, Mark.

1 0

Re: (ITS#6504) Corrupted control value when using pagedresults with subordinate *ldap* database
by masarati＠aero.polimi.it 05 Apr '10

05 Apr '10

>> Well, I've just fixed it. When changing database, I modified the paged >> results control value by setting the page size to pagesize - >> rs->sr_nentries, with an empty cookie. I'll commit tomorrow, as now I >> only have http access. > > Speedy patch - thank you! Just tried it out, and it works great for the > issue I reported. > > Testing further shows a limitation in crossing databases though. A > search that spans over two glued ldap databases, returns n < pagesize > results from the first, and continues over to the second, returning > pagesize-n results from it, making pagesize results all together. So > far, so good. > > However, the subsequent search with the returned pagedresults cookie > just starts a new search over, returning the same set of results. So it > works fine for one page max. > > But it doesn't look simple to solve this issue, unless backglue starts > recording pagedresults cookies, etc... > > Anyway, great improvement on not sending back free'd cookie :-) I see the issue, and it seems to be not related to my patch. Don't know how to fix it (yet). It'll probably need a separate ITS. p.

1 0

Re: (ITS#6504) Corrupted control value when using pagedresults with subordinate *ldap* database
by jonathan＠phillipoux.net 05 Apr '10

05 Apr '10

Le 02/04/2010 06:44, masarati(a)aero.polimi.it a écrit : >> masarati(a)aero.polimi.it wrote: >>>> masarati(a)aero.polimi.it wrote: >>>>>> Also, I note that the glued paged response seems to work incorrectly. >>>>>> I >>>>>> made a simple test system, where the root database contains exactly >>>>>> one >>>>>> entry (the suffix) and a back-ldap is glued on top. If I request >>>>>> entries >>>>>> with a page size of 2, searching the suffix return 3 entries; >>>>>> subsequent >>>>>> searches return 2 entries from the proxy. I haven't figured out yet >>>>>> where >>>>>> the issue is. >>>>> >>>>> I figured out how to fix the issue you reported. It is related to the >>>>> fact that slapd internally assumes that ldctl_oid values are constant >>>>> strings, so it doesn't duplicate nor free them. However, control OIDs >>>>> returned by back-ldap (and friends) have been decoded from the wire by >>>>> the >>>>> client library, so they are actually malloc'ed. That's why backglue >>>>> ends >>>>> up with a dangling pointer. >>>>> >>>>> I'm fixing it by having backglue duplicate (and free) control OIDs >>>>> consistently. Another option would be to replace those values with >>>>> constant strings for known control values. This would prevent gluing >>>>> for >>>>> unknown proxied controls. >>>> >>>> Or just tmpalloc them and don't bother to clean them up. >>> >>> Yes, I've reworked all the temporary controls allocation using tmpalloc. >>> Too bad OIDs are char* and not bervals. >>> >>> With respect to the other issue, to honor the requested pagesize we'd >>> need >>> to intercept pagedresult requests, modify the page size in the request >>> when a page crosses two databases, requesting the original page size >>> minus >>> entries already returned. I wonder whether it's worth the effort, >>> though. >> >> IMO pagedresults should be a (global) overlay, and backends shouldn't do >> anything about it. Note that the sssvlv overlay already intercepts >> pagedresults, it's impossible to handle things correctly otherwise. > > Well, I've just fixed it. When changing database, I modified the paged > results control value by setting the page size to pagesize - > rs->sr_nentries, with an empty cookie. I'll commit tomorrow, as now I > only have http access. Speedy patch - thank you! Just tried it out, and it works great for the issue I reported. Testing further shows a limitation in crossing databases though. A search that spans over two glued ldap databases, returns n < pagesize results from the first, and continues over to the second, returning pagesize-n results from it, making pagesize results all together. So far, so good. However, the subsequent search with the returned pagedresults cookie just starts a new search over, returning the same set of results. So it works fine for one page max. But it doesn't look simple to solve this issue, unless backglue starts recording pagedresults cookies, etc... Anyway, great improvement on not sending back free'd cookie :-) -- -------------------------------------------------------------- Jonathan Clarke - jonathan(a)phillipoux.net -------------------------------------------------------------- Ldap Synchronization Connector (LSC) - http://lsc-project.org --------------------------------------------------------------

1 0

RE: (ITS#6505) ldap_search_* functions missing const qualifiers
by EHASZLA＠transunion.com 05 Apr '10

05 Apr '10

>From: masarati(a)aero.polimi.it [mailto:masarati@aero.polimi.it] > >> hmm... I'm not quite sure how to attach a file to a ticket through the >> web interface, > >In general, upload to ftp.openldap.org according to contribution >instructions, and post a message with the URL; the way you provided it >makes it pretty unusable. Fwiw, I uploaded the two patches as ehaszla-ldap.h-20100405.patch and ehaszla-search.c-20100405.patch eric

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