openldap-bugs April 2010

openldap-bugs@openldap.org

45 participants
233 discussions

Re: (ITS#6507) backglue and paged results issue
by masarati＠aero.polimi.it 06 Apr '10

06 Apr '10

> Le 06/04/2010 20:55, masarati(a)aero.polimi.it a écrit : >> When requesting paged results control on glued databases, if a database >> (either >> superior or subordinate) returns one page that ends with the last >> corresponding >> entry in that database, the resulting cookie is empty. Thus, the result >> returned to the client corresponds to the final result of a paged >> response. >> However, other databases may have returned data. A fix is being >> designed. p. > > Your fix for this problem works well in my tests. > > Under the same subject, another problem arises: > > Consider this : > - back null > ---- back ldap 1 returning 3 results to a search > ---- back ldap 2 returning 3 results to a search > > And you search "back null" with a page size of 2: > - The first response contains 2 results from "back ldap 1" and a correct > cookie. > - The second response contains 1 result from "back ldap 1" and 1 result > from "back ldap 2", and another correct cookie. > - The third request, however, goes back to "back ldap 1", and returns > the same results as the first response. > - And so on... forever. > > As I mentioned, it seems that to solve this problem we would have to tie > a paged results cookie to a particular backend under glue... Should work now. The issue was related to the fact that unless the subordinate backends are local, the response to pgaed results has not been parsed into the connection structure... p.

1 0

Re: (ITS#6507) backglue and paged results issue
by jonathan＠phillipoux.net 06 Apr '10

06 Apr '10

Le 06/04/2010 20:55, masarati(a)aero.polimi.it a écrit : > When requesting paged results control on glued databases, if a database (either > superior or subordinate) returns one page that ends with the last corresponding > entry in that database, the resulting cookie is empty. Thus, the result > returned to the client corresponds to the final result of a paged response. > However, other databases may have returned data. A fix is being designed. p. Your fix for this problem works well in my tests. Under the same subject, another problem arises: Consider this : - back null ---- back ldap 1 returning 3 results to a search ---- back ldap 2 returning 3 results to a search And you search "back null" with a page size of 2: - The first response contains 2 results from "back ldap 1" and a correct cookie. - The second response contains 1 result from "back ldap 1" and 1 result from "back ldap 2", and another correct cookie. - The third request, however, goes back to "back ldap 1", and returns the same results as the first response. - And so on... forever. As I mentioned, it seems that to solve this problem we would have to tie a paged results cookie to a particular backend under glue... -- -------------------------------------------------------------- Jonathan Clarke - jonathan(a)phillipoux.net -------------------------------------------------------------- Ldap Synchronization Connector (LSC) - http://lsc-project.org --------------------------------------------------------------

1 0

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

06 Apr '10

Le 05/04/2010 23:40, masarati(a)aero.polimi.it a écrit : >>> 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. No, I don't think it is related to your patch. However, it has just appeared, as a result of going one hurdle further thanks to your patch :) I see you opened a separate ITS in #6507. I'll followup there. -- -------------------------------------------------------------- Jonathan Clarke - jonathan(a)phillipoux.net -------------------------------------------------------------- Ldap Synchronization Connector (LSC) - http://lsc-project.org --------------------------------------------------------------

1 0

Re: (ITS#6507) backglue and paged results issue
by masarati＠aero.polimi.it 06 Apr '10

06 Apr '10

A fix is in HEAD; please test. p.

1 0

(ITS#6507) backglue and paged results issue
by masarati＠aero.polimi.it 06 Apr '10

06 Apr '10

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (129.72.141.24) Submitted by: ando When requesting paged results control on glued databases, if a database (either superior or subordinate) returns one page that ends with the last corresponding entry in that database, the resulting cookie is empty. Thus, the result returned to the client corresponds to the final result of a paged response. However, other databases may have returned data. A fix is being designed. p.

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: > OK, I've found the problem, and it seems to be a configuration problem. > Please read below. Great. Thanks for taking the time to look at this. > ^^^ An entry with the same DN exists in the superior database. As a > consequence, this entry is returned by back-bdb's tool functions, but > backglue tries to release it using back-perl. Since back-perl does not > have any tool functions, what is considered a safe replacement is used. > Unfortunately, the safe replacement doesn't know how to deal with > read-only entries returned by back-bdb. The solution consists in: > > - temporarily commenting the instance of back-perl > > - removing this entry from your back-bdb > > - re-enabling the instance of back-perl > > A follow-on to this ITS could be to devise a means to detect whether a > superior database contains entries that belong to a subordinate one, and > warn the administrator of the inconsistency. Ah I see. I remember thinking at the time whether or not I needed a DN within my master database too (similar to a FS mount point) but obviously it has been this that has been causing the problem. At least now I know that this isn't the case and can work around it. I'd expect a subordinate database to always override the master (similar to the mount point idea again) but in the case of slapcat then I believe it should probably just ignore a subordinate that doesn't have a physical backing store presence such as back-perl. I'm not sure quite how you'd mark this though. An appropriately worded warning would definitely be a good start, especially as when I first started working with back-perl as a subordinate, I was confused that putting the subordinate definition after the master would always fail whereas putting it before would allow it to work. 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

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

OK, I've found the problem, and it seems to be a configuration problem. Please read below. > 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" ^^ This is the suffix where the instance of back-perl is rooted at > 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 ^^^ An entry with the same DN exists in the superior database. As a consequence, this entry is returned by back-bdb's tool functions, but backglue tries to release it using back-perl. Since back-perl does not have any tool functions, what is considered a safe replacement is used. Unfortunately, the safe replacement doesn't know how to deal with read-only entries returned by back-bdb. The solution consists in: - temporarily commenting the instance of back-perl - removing this entry from your back-bdb - re-enabling the instance of back-perl A follow-on to this ITS could be to devise a means to detect whether a superior database contains entries that belong to a subordinate one, and warn the administrator of the inconsistency. p.

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: > >>> *** 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

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs April 2010