- openldap-bugs - openldap.org

(ITS#8296) slapd suddenly crash when using syncprov
by maurizio.lattuada＠gmail.com 28 Oct '15

28 Oct '15

Full_Name: Maurizio Lattuada Version: 2.4.42 OS: CentOS 6.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (212.51.144.162) Hello @all. some details: * OpenLDAP 2.4.42 ** compiled as "./configure --build=i686-redhat-linux-gnu --host=i686-redhat-linux-gnu --target=i686-redhat-linux-gnu --program-prefix= --prefix=/usr --exec-prefix=/usr --libexecdir=/usr/lib --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib --localstatedir=/var --sharedstatedir=/var/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-threads=posix --enable-dynamic --enable-syslog --enable-slapd --enable-cleartext --enable-crypt --enable-spasswd --enable-modules --enable-rewrite --enable-rlookups --enable-bdb=yes --enable-hdb=yes --enable-ldap=yes --enable-monitor=yes --enable-relay=yes --enable-auditlog=mod --enable-constraint=mod --enable-dyngroup=mod --enable-dynlist=mod --enable-unique=mod" * CentOS 6.6 (32 bit, i686) Here the slapd.conf (converted to slapd.d folder via slapdtest) ---- slapd.conf (begin) ---- include /etc/openldap/schema/rorba.schema include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/duaconf.schema include /etc/openldap/schema/dyngroup.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/java.schema%0nclulude /etc/openldap/schema/misc.schema include /etc/openldap/schema/nis.schema include /etc/openldap/schema/openldap.schema include /etc/openldap/schema/ppolicy.schema include /etc/openldap/schema/collective.schema include /etc/openldap/schema/dicom_supplement_67.schema include /etc/openldap/schema/tiani-spirit.schema include /etc/openldap/schema/tiani-hl7.schema include /etc/openldap/schema/tiani-hl7_pix.schema include /etc/openldap/schema/tiani-xds.schema include /etc/openldap/schema/tiani-authorization.schema include /etc/openldap/schema/spirit-configuration.schema include /etc/openldap/schema/spirit-svs.schema include /etc/openldap/schema/etoile.schema include /etc/openldap/schema/hpd.schema include /etc/openldap/schema/vivates.schema allow bind_v2 pidfile /var/run/openldap/slapd.pid argsfile /var/run/openldap/slapd.args modulepath /usr/lib/openldap moduleload unique.la moduleload syncprov.la # First database definistion database bdb suffix 2o2o=spirit,c=at" checkpoint 1024 15 rootdn "cn=root,o=spirit,c=at" rootpw xxx directory /var/lib/ldap # Second database definistion database bdb suffix "o=vivates,c=ch" checkpoint 1024 15 rootdn "cn=root,o=vivates,c=ch" rootpw yyy direorory /var/lib/ldap-hpd overlay unique unique_attributes hcIdentifier overlay syncprov syncprov-checkpoint 1000 10 syncprov-sessionlog 1000 syncprov-reloadhint TRUE syncprov-nopresent FALSE # enable monitoring database monitor # ppolicy added access to * by self write by users read by users auth by anonymous read ---- slapd.conf (end) ---- I'm loading in a schema and simultaneously I've a client synchronizing with this schema using syncprov module (RFC4533). This schema has about 20k entries to be saved in the 2nd database (see above for the db definition). I notice 2 strange events: 1) the %MEM consumption (as shown by top) increases of 1% every 10s (memory leak?) 2) I always have an assertion failed more or less at the same entry I've to load (about 5k out of 20k), and the memory consumption of slapd is about 66% Both happen * also with OpenLDAP 2.4.41 (compiled as said above) * only when the client application (using syncprov) is running simultaneously with slapd. If I stop that client application, I load all the 20k entries, then I start it: slapd works fine, no assertions are failed and the synchronization with syncprov (used by our client application) work flawless. Here the trace obtained with gdb: ---- GDB (begin) ----- [root@ibb0301 .libs]# pwd /root/openldap/openldap-2.4.42/servers/slapd/.libs [root@ibb0301 .libs]# file ./slapd ./slapd: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, not stripped [root@ibb0301 .libs]# ./slapd -VVV @(#) $OpenLDAP: slapd 2.4.42 (Oct 28 2015 15:36:46) $ root@ibb0301:/root/openldap/openldap-2.4.42/servers/slapd Included static overlays: syncprov Included static backends: config ldif monitor bdb hdb ldap mdb relay [root@ibb0301 .libs]# gdb ./slapd GNU gdb (GDB) Red Hat Enterprise Linux (7.2-83.el6) Copyright (C) 2010 Free Software Foundation, Inc. License GPLv3+: GNU GPL versn n 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "i686-redhat-lin-gnunu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from /root/openldap/openldap-2.4.42/servers/slapd/.libs/slapd...done. (gdb) run -d 1 -h ldap:// Starting program: /root/openldap/openap-2-2.4.42/servers/slapd/.libs/slapd -d 1 -h ldap:// [Thread debugging using libthread_db enabled] ldap_url_parse_ext(ldap://localhost/) ldap_init: trying /etc/openldap/ldap.conf ldap_init: using /etc/openldap/ldap.conf ldap_url_parse_ext(ldap://localhost/) ldap_init: HOME env is /root ldap_init: trying /root/ldaprc ldap_init: trying /root/.ldaprc ldap_init: trying ldaprc ldap_init: LDAPCONF env is NULL ldap_init: LDAPRC env is NULL 5630e030 @(#) $OpenLDAP: slapd 2.4.42 ,tct 28 2015 15:36:46) $ root@ibb0301:/root/openldap/openldap-2.4.42/servers/slapd ldap_pvt_gethostbyname_a: host=ibb0301, r=0 5630e030 daemon_init: listen on ldap:// 5630e030 daemon_init: 1 listeners to open... ldap_url_parse_ext(ldap://) 50e03030 daemon: listener initialized ldap:// 5630e030 daemon_init: 2 listeners opened 5630e030 slapd init: initiated server. 5630e030 slap_sasl_init: initialized! 5630e030 bdb_back_initialize: initialize BDB backend 5630e030 bdb_back_initialize: Berkeley DB 4.7.25: (Septemr r 22, 2015) 5630e030 hdb_back_initialize: initialize HDB backend 5630e030 hdb_back_initialize: Berkeley DB 4.7.25: (September 22, 2015) 5630e030 mdb_back_initialize: initialize MDB backend 5630e030 mdb_back_initialize: LMDB 0.9.16: (August 14, 2015) CUT CUT CUT 5630e9d2 connection_get(22): got connid=1001 5630e9d2 connection_read(22): checking for input on id=1001 ber_get_next ber_get_next: tag 0x30 len 127 contents: 5630e9d2 op tag 0x63, time 1446046162 ber_get_next 5630e9d2 conn=1001 op=45593 do_search ber_scanf fmt ({miiiib) ber: 5630e9d2 >>> dnPrettyNormal: <cn=1000000000000_O2HP,ou=Relationship,dc=HPD,o=vivates,c=ch> 5630e9d2 <<< dnPrettyNormal: <cn=1000000000000_O2HP,ou=Relationship,dc=HPD,o=vivates,c=ch>, <cn=1000000000000_o2hp%ouou=relationship,dc=hpd,o=vivates,c=ch> ber_scanf fmt (m) ber: ber_scanf fmt ({M}}) ber: 5630e9d2 => get_ctrls ber_scanf fmt ({m) ber: 5630e9d2 => get_ctrls: oid="2.16.840.1.113730.3.4.2" (noncritical) 5630e9d2 <= get_ctrls:%n=1 rc=0 err="" 5630e9d2 => bdb_search 5630e9d2 bdb_dn2entry("cn=1000000000000_o2hp,ou=relationship,dc=hpd,o=vivates,c=ch") 5630e9d2 => send_search_entry: conn 1001 dn="cn=1000000000000_O2HP,ou=Relationship,dc=HPD,o=vivates,c=ch" ber_flush2: 412214 bytes to sd 22 5630e9d2 <= send_search_entry: conn 1001 exit. 5630e9d2 send_ldap_result: conn=1001 op=45593 p=3 5630e9d2 send_ldap_response: msgid=45594 tag=101 err=0 ber_flush2: 16 bytes to sd 22 5630e9d2 connection_get(22): got connid=1001 5630e9d2 connection_read(22): checking for input on id=1001 ber_get_next ber_get_next: tag 0x30 len 187 contents: 5630e9d2 op tag 0x66, time 1446046162 ber_get_next 5630e9d2 conn=1001 op=45594 do_modify ber_scanf fmt ({m) ber: ber_scanf fmt ({e{m[W]}}) ber: 5630e9d2 => get_ctrlsŸr_r_scanf fmt ({m) ber: 5630e9d2 => get_ctrls: oid="2.16.840.1.113730.3.4.2" (noncritical) 5630e9d2 <= get_ctrls: n=1 rc=0 err="" 5630e9d2 >>> dnPrettyNormal: <cn=1000000000000_O2HP,ou=Relationship,dc=HPD,o=vivates,c=ch> 5630e9d2 <<< dnPrettyNormal: <cn=1000000000000_O2HP,ou=Relationship,dc=HPD,o=vivates,c=ch>, <cn=1000000000000_o2hp,ou=relationship,dc=hpd,o=vivates,c=ch> 5630e9d2 >>> dnPretty: <cn=Sylvain Roy.7601000348999,ou=HCProfessional,dc=HPD,o=vivates,c=ch> 5630e9d2 <<< dnPretty: <cn=Sylvain Roy.7601000348999,ou=HCProfessional,dc=HPD,o=vivates,c=ch> 5630e9d2 >>> dnNormalize: <cn=Sylvain Roy.7601000348999,ou=HCProfessional,dc=HPD,o=vivates,c=ch> 5630e9d2 <<< dnNormalize: <cn=sylvain roy.7601000348999,ou=hcprofessional,dc=hpd,o=vivat%2,c=ch> 5630e9d2 bdb_dn2entry("cn=1000000000000_o2hp,ou=relationship,dc=hpd,o=vivates,c=ch") 5630e9d2 bdb_entry_get: rc=0 5630e9d2 syncprov_matchops: sid ffffffff fscope 1 rc 6 5630e9d2 ==> unique_modify <cn=1000000000000_O2HP,ou=Relationship,dc=HPD,o=vivates,c=ch> 5630e9d2 bdb_dn2entry("cn=1000000000000_o2hp,ou=relationship,dc=hpd,o=vivates,c=ch") 5630e9d2 bdb_entry_get: rc=0 5630e9d2 unique_modify: administrative bypass, skipping 5630e9d2 bdb_modify: txn1 id: 80005adb 5630e9d2 bdb_dn2entry("cn=1000000000000_o2hp,ou=relationship,dc=hpd,o=vivates,c=ch") 5630e9d2 bdb_modify: txn2 id: 80005adc 5630e9d2 bdb_modify_internal: 0x00000288: cn=1000000000000_O2HP,ou=Relationship,dc=HPD,o=vivates,c=ch 5630e9d2 oc_check_required entry (cn=1000000000000_O2HP,ou=Relationship,dc=HPD,o=vivates,c=ch), objectClass "VivatesHCRelationship" 5630e9d2 oc_check_allowed type "relationshipType" 5630e9d2 oc_check_allowed type "owner" 5630e9d2 oc_check_allowed type "objectClass" 5630e9d2 oc_check_allowed type "cn" 5630e9d2 oc_check_allowed type "member" 5630e9d2 oc_check_allowed type "structuralObjectClass" 5630e9d2 oc_check_allowed type "entryUUID" 5630e9d2 oc_check_allowed type "creatorsName" 5630e9d2 oc_check_allowed type "createTimestamp" 5630e9d2 oc_check_allowed type "entryCSN" 5630e9d2 oc_check_allowed type "modifiersName" 5630e9d2 oc_check_allowed type "modifyTimestamp" 5630e9d2 => key_change(DELETE,288) 5630e9d2 <= key_change 0 5630e9d2 => key_change(ADD,288) 5630e9d2 <= key_change 0 5630e9d2 => entry_encode(0x00000288): cn=1000000000000_O2HP,ou=Relationship,dc=HPD,o=vivates,c=ch 5630e9d2 <= entry_encode(0x00000288): cn=1000000000000_O2HP,ou=Relationship,dc=HPD,o=vivates,c=ch 5630e9d2 bdb_modify: updated id=00000288 dn="cn=1000000000000_O2HP,ou=Relationship,dc=HPD,o=vivates,c=ch" 5630e9d2 send_ldap_result: conn=1001 op=45594 p=3 5630e9d2 bdb_dn2entry("cn=1000000000000_o2hp,ou=relationship,dc=hpd,o=vivates,c=ch") 5630e9d2 bdb_entry_get: rc=0 slapd: attr.c:238: attr_dup2: Assertion `j < i' failed. Program received signaSISIGABRT, Aborted. [Switching to Thread 0xa0afab70 (LWP 2387)] 0x00130424 in __kernel_vsyscall () Missing separate debuginfos, use: debuginfo-install libtool-ltdl-2.2.6-15.5.el6.i686 (gdb) bt #0 0x00130424 in __kernel_vsyscall () #1 0x003ac871 in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #2 0x003ae14a in abort () at abort.c:92 #3 0x003a5b8b in __assert_fail_base (fmt=0x4dad58 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=0x8199ecb "j < i", file=0x8199eaa "attr.c", line=238, function=0x8199ee3 "attr_dup2") at assert.c:96 #4 0x003a5c46 in __assert_fail (assertion=0x8199ecb "j < i", file=0x8199eaa "attr.c", line=238, function=0x8199ee3 "attr_dup2") at assert.c:105 #5 0x08081b5f in attr_dup2 (tmp=0xbd3a26bc, a=0x5c85e354) at attr.c:238 #6 0x08081ecd in attrs_dup (a=0x5c85e354) at attr.c:282 #7 0x08082704 in entry_dup2 (dest=0xb99e6a34, source=0x8372ea4) at entry.c:940 #8 0x08082fea in entry_dup (e=0x8372ea4) at entry.c:949 #9 0x0817a08d in syncprov_matops s (op=0x83820c0, opc=0xa05f936c, saveit=0) at syncprov.c:1220 #10 0x0817ab36 in syncprov_op_response (op=0x83820c0, rs=0xa0afa0dc) at syncprov.c:1969 #11 0x080880a6 in slap_response_play (op=0x83820c0, rs=0xa0afa0dc) at result.c:508 #12 0x08088c94 in send_ldap_response (op=0x83820c0, rs=0xa0afa0dc) at result.c:583 #13 0x08089ad2 in slap_send_ldap_result (op=0x83820c0, rs=0xa0afa0dc) at result.c:861 #14 0x080f1262 in bdb_modify (op=0x83820c0, rs=0xa0afa0dc) at modify.c:802 #15 0x080e3f73 in overlay_op_walk (%3=0x83820c0, rs=0xa0afa0dc, which=op_modify, oi=0x833c680, on=0x0) at backover.c:677 #16 0x080e4a59 in over_op_func (op=0x83820c0, rs=0xa0afa0dc, which=op_modify) at backover.c:730 #17 0x08091371 in fe_op_modify (op=0x83820c0, rs=0xa0afa0dc) at modify.cA3A303 #18 0x08091de7 in do_modify (op=0x83820c0, rs=0xa0afa0dc) at modify.c:177 #19 0x080782bc in connection_operation (ctx=0xa0afa1ec, arg_v=0x83820c0) at connection.c:1155 #20 0x08078b57 in connection_read_thread (ctx=0xa0afa1ec, argv=0x16) at connection.c:1291 #21 0x0013c5e4 in ldap_int_thread_pool_wrapper (xpool=0x8287b80) at tpool.c:696 #22 0x0036db39 in start_thread (arg=0xa0afab70) at pthread_create.c:301 #23 0x00464c2e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:133 (gdb) bt full #0 0x00130424 in __kernel_vsyscall () No symbol table info available. #1 0x003ac871 in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 resultvar = <value optimized out> resultvar =3<value optimized out> pid = 5324788 selftid = 2387 #2 0x003ae14a in abort () at abort.c:92 save_stage = 2 act = {__sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, sa_mask = {__val = {5324788, 64, 1, 4137890, 2695856544, 0, 104, 57, 2718957584, 5324788, 57, 56, 2695856716, 4109330, 1563184960, 57, 2695856756, 1563184960, 0, 4222451712, 1563184960, 1563184960, 1563184960, 1563184960, 1563185016, 1563185060, 1563184960, 1563185060, 0, 0, 0, 0}}, sa_flags = 0, sa_restorer = 0x4d84d8 <_libc_intl_domainname>} sigs = {__val = {32, 0 <repeats 31 times>}} #3 0x003a5b8b in __assert_fail_base (fmt=0x4dad58 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=0x8199ecb "j < i", file=0x8199eaa "attr.c", line=238, function=0x8199ee3 "attr_dup2") at assert.c:96 str = 0x5d2c4f40 "" total = 4096 #4 0x003a5c46 in __assert_fail (assertion=0x8199ecb "j < i", file=0x8199eaa "attr.c", line=238, function=0x8199ee3 "attr_dup2") at assert.c:105 No locals. #5 0x08081b5f in attr_dup2 (tmp=0xbd3a26bc, a=0x5c85e354) at attr.c:238 i = <value optimized out> j = 1171 __PRETTY_FUNCTION__ = "attr_dup2" #6 0x08081ecd in attrs_dup (a=0x5c85e354) at attr.c:282 i = <value optimized out> tmp = 0xbd3a26bc anew = 0x365765ec #7 0x08082704 in entry_dup2 (dest=0xb99e6a34, source=0x8372ea4) at entry.c:940 __PRETTY_FUNCTION__ = "entry_dup2" #8 0x08082fea in entry_dup (e=0x8372ea4) at entry.c:949 No locs.s. #9 0x0817a08d in syncprov_matchops (op=0x83820c0, opc=0xa05f936c, saveit=0) at syncprov.c:1220 on = 0x834c270 si = 0x834c378 fc = {fdn = 0x83820dc, fss = 0x36f3b7, fbase = -1599109284, fscope = 2387} pss = <value optimized out> e = 0x8372ea4 a = <value optimized out> rc = 0 gonext = <value optimized out> newdn = {bv_len = 2721065128, bv_val = 0xa0af8778 "8\210\257\240\066\253\027\b\330\303\064\b\024\210\257\240\034\210\257\240", <incomplete sequence \334>} freefdn = 0 b0 = 0xa0af8cb0 db = {bd_info = 0x3006c4, bd_self = 0x3006c4, be_ctrls = "\350.0\242\210\205\257\240\270\f\000\000P\322.\bE\000\000\000\000\000\000\000\300\316.\b\270\254?\243 ", be_flags = 2, be_restrictops = 0, be_requires = 137286224, be_ssf_set = {sss_ssf = 2739079224, sss_transport = 2739079264, sss_tls = 2738856128, sss_sasl = 137288792, sss_update_ssf = 137284672, sss_update_transport = 2738858688, sss_update_tls = 137122904, sss_update_sasl = 2721067280, sss_simple_bind = 0}, be_suffix = 0xa3430860, be_nsuffix = 0x0, be_schemadn = {bv_len = 2721066704, bv_val = 0x0}, be_schemandn = {bv_len = 1785995, bv_val = 0x3006c4 "\270=\027"}, be_rootdn = {bv_len = 137122904, bv_val = 0xa0af89f8 "8\212\257\240\343I\023\b@\211\037\bx6\204#\340\226?\242"}, be_rootndn = { ---Type <return> to continue, or q <return> to quit--- bv_len = 2695857784, bv_val = 0x1af848 "=P\207\377\377\211\307\017\5%5\315\376\377\377\203}\024\003\017\204", <incomplete sequence \341>}, be_rootpw = {bv_len = 137122904, bv_val = 0xa0af89f8 "8\212\257\240\343I\023\b@\211\037\bx6\204#\340\226?\242"}, be_max_deref_depth = 2695858652, be_def_limit = {lms_t_soft = 6, lms_t_hard = 0, lms_sofoft = -1573902056, lms_s_hard = -1573901176, lms_s_unchecked = -1573899696, lms_s_pr = -1555836884, lms_s_pr_hide = -1555836892, lms_s_pr_total = 2472655}, be_limits = 0x3006c4, be_acl = 0x0, be_dfltaccess = -1573900016, be_extra_anlist = 0xa0af8778, be_update_ndn = {bv_len = 2485336, bv_val = 0x0}, be_update_refs = 0xa0af88a4, be_pending_csn_list = 0xa0af8820, be_pcl_mutex = {__data = {__lock = -1768966555, __count = 137125596, __owner = 137121936, __kind = 24684, __nusers = 0, {__spins = -1599109576, __list = {__next = 0xa0af8638}}}, __size = "e\266\217\226\334^,\b\220P,\bl`\000\000\000\000\000\000\070\206\257\240", __align = -1768966555}, be_syncinfo = 0x3752c2, be_pb = 0xa33e2250, be_cf_ocs = 0x1d, be_private = 0x0, be_next = {stqe_next = 0x606c}} #10 0x0817ab36 in syncprov_op_response (op=0x83820c0, rs=0xa0afa0dc) at syncprov.c:1969 maxcsn = {bv_len = 40, bv_val = 0xa0af87d4 "20151028152922.245192Z#000000#000#000000"} cbuf = "20151028152922.245192Z#000000#000#000000\000\000\000\000\240SQ\000\030\000\000\000\020\067\204#\364\017\030\000x6\204#" do_check = <value optimized out> foundit = 1 csn_changed = 1 have_psearches = 1 opc = 0xa05f936c on = 0x834c270 si = 0x834c378 sm = <value optimized out> #11 0x080880a6 in slap_response_play (op=0x83820c0, rs=0xa0afa0dc) at result.c:508 sc_next = 0xa0af8dac sc_nextp = 0xa05f9358 rc = 32768 sc = 0xa05f9358 scp = 0xa0af886c #12 0x08088c94 in send_ldap_response (op=0x83820c0, rs=0xa0afa0dc) at result.c:583 berbuf = { buffer = "\000\000\000\000\340\066\066\243T\225A\213\250\066\066\243", '\000' <repeats 12 times>, " \000\000\000\000\000\000\000\001\000\000\000\300 6\243\340\326.\b\005\000\000\000\177\222M\000\000\000\002\000\000\000\000\000\n\000\000\000\322\351\060V\000\000\000\000\000\000\000\000\020\000\060\242\377\377\377\377\035\003,\000\304\006\060\000x6\204#P\322.\b良\240G3%3,\000P\322.\bx6\204#\340\066\066\243\005\000\000\000\001\000\000\000\322\351\060V\227\235\376\257\000\000\000\000\350^ڻ", '\000' <repeats 12 times>, "\002\000\000\000\000\000\000\000ˠ\027\000\215\a.\000d':\275\000\000\000\000\230\211\257\240\4%4\211\257\240\267\363\066\000\227\235\376\257\250\066\066\243P\322.\bd':\275\a", '\000' <repeats 31 times>"\354, eW6\370\211\257\000e\266\217\226", ialign = 0, lalign = 0, falign = 0, dalign = -4.663540245266185e-139, palign = 0x0} ber = 0xa0af88c0 rc = 0 bytes = <value optimized out> __PRETTY_FUNCTION__ = "send_ldap_response" #13 0x08089ad2 in slap_send_ldap_result (op=0x83820c0, rs=0xa0afa0dc) at result.c:861 tmp = 0x0 otext = 0x0 oref = 0x0 __PRETTY_FUNCTION__ = "slap_send_ldap_result" #14 0x080f1262 in bdb_modify (op=0x83820c0, rs=0xa0afa0dc) at modify.c:802 bdb = 0x833fb60 e = <value optimized out> ei = 0xa23f96e0 manageDSAit = 2 textbuf = "e\266\217\226Ӹ4\242\000\000\000\000\000\000\000\000\024A\255\000\300 8\b\374=\037\b8\214\257\240\034*\255\000\300 8\b\244.7\b\000\000\000\000 \376\063\b", '\000' <repeats 16 times>"\200, ", '\000' <repeats 11 times>, "\026\000\000\000\220\270\064\242\026\000\000\000 \376\063\b\000\000\000\000\000\000\000\000<\213\257\240", '\000' <repeats 20 times>, "@\377\063\b\000\000\000\000\000\000\000\000\300\223_\240\230!8\bf\000\000\000\322\351\060V\017\000\000\000\260\214\257\240;\000\000\0000%0\222_\240;\000\000\000\020\223_---Type <return> to continue, or q <return> to quit--- \240\000H\224^", '\000' <repeats 71 times> ltid = 0x0 lt2 = 0x396fd3b8 opinfo = {boi_oe = {oe_next = {sle_next = 0x0}, oe_key = 0x0}, boi_txn = 0x23843678, boi_locks = 0x0, boi_err = 0, boi_acl_cache = 0 '\000', boi_flag = 0 '\000'} dummy = {e_id = 648, e_name = {bv_len = 59, bv_val = 0xa23f91f0 "cn=1", '0' <repeats 12 times>, "_O2HP,ou=Relationship,dc=HPD,o=vivates,c=ch"}, e_nname =7B7Bbv_len = 59, bv_val = 0xa23f9230 "cn=1", '0' <repeats 12 times>, "_o2hp,ou=relationship,dc=hpd,o=vivates,c=ch"}, e_attrs = 0x0, e_ocflags = 65792, e_bv = {bv_len = 0, bv_val = 0x0}, e_private = 0xa23f96e0} lock =7B7Boff = 120744, ndx = 605, gen = 6432, mode = DB_LOCK_WRITE} num_retries = 0 preread_ctrl = 0x0 postread_ctrl = 0x0 ctrls = {0x0, 0x16, 0x29be4bb8, 0x0, 0x0, 0x0} num_ctrls = 0 rc = <value optimized out> #15 0x080e3f73 in overlay_op_walk (op=0x83820c0, rs=0xa0afa0dc, which=op_modify, oi=0x833c680, on=0x0) at backover.c:677 func = <value optimized out> rc = <value optimized out> #16 0x080e4a59 in over_op_func (op=0x83820c0, rs=0xa0afa0dc, which=op_modify) at backover.c:730 oi = <value optimized out> on = 0x834c270 be = <value optimized out> db = {bd_info = 0x81f37dc, bd_self = 0x833fa60, be_ctrls = "\000\000\000\001\001\001\000\001\000\000\001\000\000\001\001\000\001\000\000\001", '\000' <repeats 12 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 = 0x82b8268, be_nsuffix = 0x833edc8, be_schemadn = {bv_len = 0, bv_val = 0x0}, be_schemandn = {bv_len = 0, bv_val = 0x0}, be_rootdn = {bv_len = 22, bv_val = 0x832c218 "cn=root,o=vivates,c=ch"}, be_rootndn = {bv_len = 22, bv_val = 0x833ee10 "cn=root,o=vivates,c=ch"}, be_rootpw = {bv_len = 6, bv_val = 0x833f990 "etoile"}, 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_extra_anlist = 0x0, be_update_ndn = {bv_len = 0, bv_val = 0x0}, be_update_refs = 0x0, be_pending_csn_list = 0x82ecc70, be_pcl_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __kind = 0, __nusers = 0, {__spins = 0, __list = {__next = 0x0}}}, __size = '\000' <repeats 23 times>, __align = 0}, be_syncinfo = 0x0, be_pb =x0x0, be_cf_ocs = 0x81f5e00, be_private = 0x833fb60, be_next = {stqe_next = 0x834bee8}} cb = {sc_next = 0x0, sc_response = 0x80e3c90 <over_back_response>, sc_cleanup = 0, sc_writewait = 0, sc_private = 0x833c680} sc = <value optimized out> rc = 32768 __PRETTY_FUNCTION__ = "over_op_func" #17 0x08091371 in fe_op_modify (op=0x83820c0, rs=0xa0afa0dc) at modify.c:303 update = <value optimized out> repl_user = <value optimized out> op_be = <value optimized out> bd = 0x81f9000 textbuf = "\000\000\000\000\000\000\000\000h\216\257\240\362\346\b\b\001\000\000\000\001\000\000\000\"\272\031\b\000K\276)\000\000\000\000\000\000\000\000\b\222_\240(L\276)8\352,\b\020L\276)Ȏ\257\240OK\t\b\202\000\000\000X\311&\b\200\324'\b\020L\276)(L\276)\000\000\000\000Ȏ\257\240\030\000\000\000\240SQ\000\254SQ\000\001\000\000\000\320\347\b\b\240SQ\000\000\000\000\000\250\216\257\240\236m?\000\240SQ\000(\000\000\000p8\204#\364\017\030\000\000\000\000\000\000\000\000\000D\000\000\0002320\064(\232\020\000\000\000\350c,\b\000\000\000\000x\221\061\242\000\000\000\000\000\000\000\000(\217\257\240\301\016\t\b\002\000\000\000x\221\061\242\200\324'\b\020L\276)(L\276)\000\000\000\000\274\274\031\b`\222_\240\020\223_\240\000H\224^x\221\061\242(L\276)\234z\303\bD\000\000\000\320\064(\232@\222_\240" #18 0x08091de7 in do_modify (op=0x83820c0, rs=0xa0afa0dc) at modify.c:177 dn = {bv_len = 59, bv_val = 0x8c37a02 "cn=1", '0' <repeats 12 times>, "_O2HP,ou=Relationship,dc=HPD,o=vivates,c=ch"} textbuf = "h\t\020\242\360{\303\b\230\237\257\240\004F7\000\022F7\000\274\306\027\000\026\000\000\000\373{\303\b\b\000\000\000\364?Q\000\211\306\027\000\364\017\030\000x\240\257\240\243\276\027\000P\t\020\242\373{C3C303\b\b\000\000\000\364?Q\000\200\240\257\240\300!8\b̠\257\240P\267>\000P\267>\000\340\237\257\240\244\203\031\b\373{\303\b\300!8\b\000\000\000\000\340\237\257\240\377\000\000\000\001\200\255\373\000\000\000\000\300!8\b\300!8\b\300!8\b\322!8\b\277\"8\b\300 8\b\350c,%5\0C004\000\020\000\210\240\257\240\371\365\f\b\000\000\000\000\350c,\bl\240\257\240", '\000' <repeats 16 times>"\320, \000\000\000\000\000\000\000\003\000\000\000\030\000\000\000\000\000\000\000\200u\370\267\030\241\257\240\210\240\257\240Qq\a\b\267\363\066

1 0

Re: (ITS#8294) slappasswd can use SHA256 for hash but not SHA384 or SHA512...segfault
by hyc＠symas.com 28 Oct '15

28 Oct '15

Howard Chu wrote: > ktmdms(a)gmail.com wrote: >> --089e0115ec1091312605232ac99f >> Content-Type: text/plain; charset=UTF-8 >> >> To add fuel to the fire, if I use pw-sha2 libraries that were built on a >> 2.6 kernel (specifically 2.6.32-358.el6.x86_64) on the 3.18 machine I can >> generate SHA512/384 hashed passwords with no issues. What should I be >> looking for between the two platforms that might cause the core? > > Strange that the kernel would make any difference - more likely it's your C > compiler making the difference. I may have misread your message. If the same binary works on a newer system, that tends to imply something weird in the runtime environment. Perhaps a problem with ASLR. > I ran a test on one machine and got an abort in glibc saying there was a stack > overrun. On a different machine I got no such error, and running on the > problem system under valgrind produced no errors. > > On the machine that aborted, when I compiled with gcc -fstack-protector-all, > the glibc abort disappeared as well. So, this hasn't helped me identify the > problem yet. (gcc 4.8.4-2ubuntu1~14.04) > -- -- 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#8294) slappasswd can use SHA256 for hash but not SHA384 or SHA512...segfault
by hyc＠symas.com 28 Oct '15

28 Oct '15

ktmdms(a)gmail.com wrote: > --089e0115ec1091312605232ac99f > Content-Type: text/plain; charset=UTF-8 > > To add fuel to the fire, if I use pw-sha2 libraries that were built on a > 2.6 kernel (specifically 2.6.32-358.el6.x86_64) on the 3.18 machine I can > generate SHA512/384 hashed passwords with no issues. What should I be > looking for between the two platforms that might cause the core? Strange that the kernel would make any difference - more likely it's your C compiler making the difference. I ran a test on one machine and got an abort in glibc saying there was a stack overrun. On a different machine I got no such error, and running on the problem system under valgrind produced no errors. On the machine that aborted, when I compiled with gcc -fstack-protector-all, the glibc abort disappeared as well. So, this hasn't helped me identify the problem yet. (gcc 4.8.4-2ubuntu1~14.04) -- -- 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#8223 Windows replication error
by hyc＠symas.com 28 Oct '15

28 Oct '15

> Hello, > > I have additional information. The problem is the entryCSN. > User 1, which got replicated has entryCSN: > 20150827083333.751721Z#000000#001#000000 > user 2, which got NOT replicated has entryCSN: > 20150827083333.119585Z#000000#001#000000, which seems to be in the past > user 3, replicated, 20150827083334.847604Z#000000#001#000000 > user 4, not replicated 20150827083334.228113Z#000000#001#000000, which > seems to be in the past > user 5, replicated 20150827083335.588191Z#000000#001#000000 > user 6, replicated 20150827083335.946835Z#000000#001#000000 > user 7 not replicated 20150827083335.282686Z#000000#001#000000, which > seems to be in the past > > So in previous posts I got the answer, that microseconds exact time > synchronization is only important with master master and concurrent > writes. But now it also seems to be important with delta-synrepl. > > So I suppose this ITS can be closed, since it is not a bug, but worked as > designed? > So how to get a good enough time synchronization with windows (since the > normal time synchronization of windows seems to be not enough)? > Of course, if you close the ITS I can ask this question again in the > technical list. > > Regards, > Frank ITS#8295 may be the problem here. Fixed in git master. Please test and followup to that ticket, thanks. -- -- 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#8294) slappasswd can use SHA256 for hash but not SHA384 or SHA512...segfault
by ktmdms＠gmail.com 28 Oct '15

28 Oct '15

--089e0115ec1091312605232ac99f Content-Type: text/plain; charset=UTF-8 To add fuel to the fire, if I use pw-sha2 libraries that were built on a 2.6 kernel (specifically 2.6.32-358.el6.x86_64) on the 3.18 machine I can generate SHA512/384 hashed passwords with no issues. What should I be looking for between the two platforms that might cause the core? Thanks. Kevin Martin --- Regards, Kevin Martin On Tue, Oct 27, 2015 at 3:11 PM, <openldap-its(a)openldap.org> wrote: > > *** THIS IS AN AUTOMATICALLY GENERATED REPLY *** > > Thanks for your report to the OpenLDAP Issue Tracking System. Your > report has been assigned the tracking number ITS#8294. > > One of our support engineers will look at your report in due course. > Note that this may take some time because our support engineers > are volunteers. They only work on OpenLDAP when they have spare > time. > > If you need to provide additional information in regards to your > issue report, you may do so by replying to this message. Note that > any mail sent to openldap-its(a)openldap.org with (ITS#8294) > in the subject will automatically be attached to the issue report. > > mailto:openldap-its@openldap.org?subject=(ITS#8294) > > You may follow the progress of this report by loading the following > URL in a web browser: > http://www.OpenLDAP.org/its/index.cgi?findid=8294 > > Please remember to retain your issue tracking number (ITS#8294) > on any further messages you send to us regarding this report. If > you don't then you'll just waste our time and yours because we > won't be able to properly track the report. > > Please note that the Issue Tracking System is not intended to > be used to seek help in the proper use of OpenLDAP Software. > Such requests will be closed. > > OpenLDAP Software is user supported. > http://www.OpenLDAP.org/support/ > > -------------- > Copyright 1998-2007 The OpenLDAP Foundation, All Rights Reserved. > > --089e0115ec1091312605232ac99f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">To add fuel to the fire, if I use pw-sha2 libraries that w= ere built on a 2.6 kernel (specifically=C2=A02.6.32-358.el6.x86_64) on the = 3.18 machine I can generate SHA512/384 hashed passwords with no issues.=C2= =A0 What should I be looking for between the two platforms that might cause= the core?<div><br></div><div>Thanks.</div><div><br></div><div>Kevin Martin= </div></div><div class=3D"gmail_extra"><br clear=3D"all"><div><div class=3D= "gmail_signature"><div dir=3D"ltr">---<div><span style=3D"font-size:12.8px"= ><br></span></div><div><span style=3D"font-size:12.8px"><br></span></div><d= iv><span style=3D"font-size:12.8px">Regards,</span></div><div><div><br></di= v><div>Kevin Martin</div></div></div></div></div> <br><div class=3D"gmail_quote">On Tue, Oct 27, 2015 at 3:11 PM, <span dir= =3D"ltr"><<a href=3D"mailto:openldap-its@openldap.org" target=3D"_blank"= >openldap-its(a)openldap.org</a>></span> wrote:<br><blockquote class=3D"gm= ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le= ft:1ex"><br> *** THIS IS AN AUTOMATICALLY GENERATED REPLY ***<br> <br> Thanks for your report to the OpenLDAP Issue Tracking System.=C2=A0 Your<br= > report has been assigned the tracking number ITS#8294.<br> <br> One of our support engineers will look at your report in due course.<br> Note that this may take some time because our support engineers<br> are volunteers.=C2=A0 They only work on OpenLDAP when they have spare<br> time.<br> <br> If you need to provide additional information in regards to your<br> issue report, you may do so by replying to this message.=C2=A0 Note that<br= > any mail sent to <a href=3D"mailto:openldap-its@openldap.org">openldap-its@= openldap.org</a> with (ITS#8294)<br> in the subject will automatically be attached to the issue report.<br> <br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 mailto:<a href=3D"mailto:openldap-its@openldap.= org">openldap-its(a)openldap.org</a>?subject=3D(ITS#8294)<br> <br> You may follow the progress of this report by loading the following<br> URL in a web browser:<br> =C2=A0 =C2=A0 <a href=3D"http://www.OpenLDAP.org/its/index.cgi?findid=3D829= 4" rel=3D"noreferrer" target=3D"_blank">http://www.OpenLDAP.org/its/index.c= gi?findid=3D8294</a><br> <br> Please remember to retain your issue tracking number (ITS#8294)<br> on any further messages you send to us regarding this report.=C2=A0 If<br> you don't then you'll just waste our time and yours because we<br> won't be able to properly track the report.<br> <br> Please note that the Issue Tracking System is not intended to<br> be used to seek help in the proper use of OpenLDAP Software.<br> Such requests will be closed.<br> <br> OpenLDAP Software is user supported.<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 <a href=3D"http://www.OpenLDAP.org/support/" re= l=3D"noreferrer" target=3D"_blank">http://www.OpenLDAP.org/support/</a><br> <br> --------------<br> Copyright 1998-2007 The OpenLDAP Foundation, All Rights Reserved.<br> <br> </blockquote></div><br></div> --089e0115ec1091312605232ac99f--

1 0

(ITS#8295) Windows ldap_pvt_gettime is broken
by hyc＠openldap.org 28 Oct '15

28 Oct '15

Full_Name: Howard Chu Version: 2.4 OS: Win32 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (78.155.231.14) Submitted by: hyc ldap_pvt_gettime is used to to generate CSNs with microsecond precision. On Windows it goes thru some gyrations to calculate microseconds since the normal SystemTime only has a resolution of 10-15 milliseconds. Unfortunately it doesn't properly detect when the microsecond counter wraps around back to zero, so it can occasionally return timestamps 1 second in the past.

1 0

(ITS#8294) slappasswd can use SHA256 for hash but not SHA384 or SHA512...segfault
by ktmdms＠gmail.com 27 Oct '15

27 Oct '15

Full_Name: Kevin Martin Version: 2.4.42 OS: 3.8.13-55.1.6.el7uek.x86_64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (137.254.4.10) Compiled 2.4.42 from source with the following configure options: ./configure --enable-ppolicy --enable-crypt --with-tls --enable-bdb --enable-ldap --enable-slapd --enable-slapi --enable-syslog --enable-modules compiles and installs fine. Built the pw-sha2 contrib module and installed with no problems. The following works fine: /usr/local/sbin/slappasswd -v -v -v -h '{SHA256}' -o module-path=/usr/local/libexec/openldap -o module-load=pw-sha2 -s secret {SHA256}K7gNU3sdo+OL0wNhqoVWhr3g6s1xYv72ol/pe/Unols= /usr/local/sbin/slappasswd -v -v -v -h '{CRYPT}' -c '$6$!4&&.' -s secret {CRYPT}$6$!4&&.$oINsiq8QMkQheQrdy0.qk7qKr7tNVNCX387QMrp8Y/w2y7JcazTvfKhG0mSGIAB1jWZ4xsDbsehH/4yPIns6I. The following create segfaults: /usr/local/sbin/slappasswd -v -v -v -h '{SHA384}' -o module-path=/usr/local/libexec/openldap -o module-load=pw-sha2 -s secret Segmentation fault (core dumped) /usr/local/sbin/slappasswd -v -v -v -h '{SHA512}' -o module-path=/usr/local/libexec/openldap -o module-load=pw-sha2 -s secret Segmentation fault (core dumped) I shouldn't need to use CRYPT with a salt to create a SHA512 hashed password. Bug or something on my machine? Regards, Kevin Martin

1 0

Re: (ITS#8293) ldappasswd error text
by hyc＠symas.com 27 Oct '15

27 Oct '15

samueldarwin(a)yahoo.com wrote: > Full_Name: Sam Darwin > Version: openldap-2.4.31 > OS: Ubuntu 14.04 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (82.169.106.169) > > > Showing informative error messages is very important, especially with complex > software. In this case, the error was misleading, so maybe it can be > updated. > > $ ldappasswd -D "uid=exampleuser,ou=users,dc=example,dc=net"h h ldap01 -W -e > ppolicy > Enter LDAP Password: > Result: Constraint violation (19) > Additional info: Password fails quality checking policy > control: 1.3.6.1.4.1.42.2.27.8.5.1 false MAOBAQY= > ppolicy: error=6 (Password is too short for policy) > > It looks like the password is too short, right? > > Actually, the problem is completely different, which I discovered after some > time. > > -S "uid=exampleuser,ou=users,dc=example,dc=net" should also be added to that > command. > > So, the real error was either that no password at all had been provided, or no > user had been provided, or both. It had not even requested a new password. > The new password was not too short, it was non-existent, which is something else > entirely. > > So, my request is to make the error reporting more sophisticated here, and any > place else that is analogous to this case. make the answer a bit more obvious. Your report is invalid. The ldappasswd(1) manpage clearly states that if you don't provide a new password, the server will be asked to generate one. In this particular case, the password the server generated was too short for your policy. The manpage also states clearly that if you don't specify [user] DN, it will change the password of the user that bound to the server. The error message was correct. Closing this ITS. -- -- 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#8293) ldappasswd error text
by samueldarwin＠yahoo.com 27 Oct '15

27 Oct '15

Full_Name: Sam Darwin Version: openldap-2.4.31 OS: Ubuntu 14.04 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.169.106.169) Showing informative error messages is very important, especially with complex software. In this case, the error was misleading, so maybe it can be updated. $ ldappasswd -D "uid=exampleuser,ou=users,dc=example,dc=net"h h ldap01 -W -e ppolicy Enter LDAP Password: Result: Constraint violation (19) Additional info: Password fails quality checking policy control: 1.3.6.1.4.1.42.2.27.8.5.1 false MAOBAQY= ppolicy: error=6 (Password is too short for policy) It looks like the password is too short, right? Actually, the problem is completely different, which I discovered after some time. -S "uid=exampleuser,ou=users,dc=example,dc=net" should also be added to that command. So, the real error was either that no password at all had been provided, or no user had been provided, or both. It had not even requested a new password. The new password was not too short, it was non-existent, which is something else entirely. So, my request is to make the error reporting more sophisticated here, and any place else that is analogous to this case. make the answer a bit more obvious.

1 0

(ITS#8292) Broken option parsing in tests:ldif-filter
by h.b.furuseth＠usit.uio.no 27 Oct '15

27 Oct '15

Full_Name: Hallvard B Furuseth Version: 2.4.42 OS: URL: Submission from: (NULL) (81.191.45.5) Submitted by: hallvard 'tests/progs/ldif-filter -s SPEC' fails if SPEC has no 'BACKEND='. Fixing.

1 0

Re: (ITS#8291) ./run -b hdb test007 fails
by michael＠stroeder.com 27 Oct '15

27 Oct '15

ondra(a)mistotebe.net wrote: > On Tue, Oct 27, 2015 at 08:24:08AM +0000, michael(a)stroeder.com wrote: >> Currently this test fails with git master >> 0d9b8ebe4bfe584e796f683be6203d4a4eb421a2: >> >> michael@nb2:.../openldap/tests> ./run -b hdb test007 >> Cleaning up test run directory leftover from previous run. >> Running ./scripts/test007-slapmodify for hdb... >> running defines.sh >> Running slapadd to build slapd database... >> Testing modify, add, and delete using slapmodify... >> slapmodify failed (1)! >> >> I can provide more logs if needed. > > Yes please. I am curious which modify/delete failed as I can't > reproduce this failure. Strange: testrun/test.out has zero bytes. :-/ But the DB files are created. Other tests with -b hdb seem to work ok. Maybe it's just the test script? $ git status On branch master Your branch is up-to-date with 'origin/master'. nothing to commit, working directory clean Can't see a problem on my side. BTW: It works with mdb though. Ciao, Michael.

1 0

Re: (ITS#8291) ./run -b hdb test007 fails
by ondra＠mistotebe.net 27 Oct '15

27 Oct '15

On Tue, Oct 27, 2015 at 08:24:08AM +0000, michael(a)stroeder.com wrote: > Currently this test fails with git master > 0d9b8ebe4bfe584e796f683be6203d4a4eb421a2: > > michael@nb2:.../openldap/tests> ./run -b hdb test007 > Cleaning up test run directory leftover from previous run. > Running ./scripts/test007-slapmodify for hdb... > running defines.sh > Running slapadd to build slapd database... > Testing modify, add, and delete using slapmodify... > slapmodify failed (1)! > > I can provide more logs if needed. Yes please. I am curious which modify/delete failed as I can't reproduce this failure. Cheers, Ondrej

1 0

(ITS#8291) ./run -b hdb test007 fails
by michael＠stroeder.com 27 Oct '15

27 Oct '15

Full_Name: Michael Str.der Version: master 0d9b8ebe4bfe584e796f683be6203d4a4eb421a2 OS: openSUSE Linux URL: Submission from: (NULL) (213.240.180.113) Currently this test fails with git master 0d9b8ebe4bfe584e796f683be6203d4a4eb421a2: michael@nb2:/usr/src/michael/openldap-git/master/openldap/tests> ./run -b hdb test007 Cleaning up test run directory leftover from previous run. Running ./scripts/test007-slapmodify for hdb... running defines.sh Running slapadd to build slapd database... Testing modify, add, and delete using slapmodify... slapmodify failed (1)! I can provide more logs if needed.

1 0

Re: (ITS#8289) slapd seg faults with MOD_INCREMENT on derived attribute
by hyc＠symas.com 26 Oct '15

26 Oct '15

michael(a)stroeder.com wrote: > Full_Name: > Version: re24 > OS: openSUSE Linux > URL: > Submission from: (NULL) (213.240.180.113) > > > Attribute type declaration 'bar' with Integer syntax. > > 'foo' SUP 'bar' makes slapd crash when sending LDAP_MOD_INCREMENT on 'foo'. > > LDAP_MOD_INCREMENT on 'foo' works if it's not SUP 'bar' but directly declared > with Integer syntax. > > Fixed now in master -- -- 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#8290) Our system has occured "Server is unwilling to perform" from slapd when syncrepl rid was changed.
by t-ogura＠az.jp.nec.com 26 Oct '15

26 Oct '15

Full_Name: Tom Ogura Version: 2.4.40 OS: Redhat Enterprise Linux 6.2 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (182.250.250.193) Our system use LDAP server. Master server connect two slave nodes , A and B. And, LDAP syncronization configure as below. B server <---> Master server <---> A server rid=27 rid=30 rid=32 Master server is set for LDAP syncronization in slapd.conf. ----- serverID 30 syncrepl rid=27 provider=ldap://xx.xx.xx.xx bindmethod=simple binddn="cn=xxxx" credentials="xxxx" searchbase="xxxx" schemachecking=off type=refreshAndPersist retry="2 30 30 +" syncrepl rid=32 provider=ldap://xx.xx.xx.xx bindmethod=simple binddn="cn=xxxx" credentials="xxxx" searchbase="xxxx" schemachecking=off type=refreshAndPersist retry="2 30 30 +" ----- When master server's slapd restart, B server's slapd disconnect to Master server's slapd. After master server 's slapd start, B server's slapd made Error log as below and didn't syncronize to LDAP updating data from B server to master server. slapd[12491]: do_syncrep2: rid=030 LDAP_RES_SEARCH_RESULT (53) Server is unwilling to perform slapd[12491]: do_syncrep2: rid=030 (53) Server is unwilling to perform slapd[12491]: do_syncrepl: rid=030 rc -2 retrying (23 retries left) Why did it happen ?

1 0

Re: (ITS#8289) slapd seg faults with MOD_INCREMENT on derived attribute
by michael＠stroeder.com 26 Oct '15

26 Oct '15

The last lines before crash: 562eb075 => access_allowed: delete access to "cn=test-hotp-token-42,ou=Testing,dc=stroeder,dc=de" "oathFailureCount" requested 562eb075 => dn: [5] dc=stroeder,dc=de 562eb075 => acl_get: [5] matched 562eb075 => acl_get: [5] attr oathFailureCount 562eb075 => acl_mask: access to entry "cn=test-hotp-token-42,ou=Testing,dc=stroeder,dc=de", attr "oathFailureCount" requested 562eb075 => acl_mask: to all values by "cn=michael ströder+mail=michael(a)stroeder.com,ou=private,dc=stroeder,dc=de", (=0) 562eb075 <= check a_group_pat: cn=slapd admins,ou=groups,dc=stroeder,dc=de 562eb075 <= acl_mask: [1] applying manage(=mwrscxd) (stop) 562eb075 <= acl_mask: [1] mask: manage(=mwrscxd) 562eb075 => slap_access_allowed: delete access granted by manage(=mwrscxd) 562eb075 => access_allowed: delete access granted by manage(=mwrscxd) 562eb075 => access_allowed: result not in cache (oathFailureCount) 562eb075 => access_allowed: add access to "cn=test-hotp-token-42,ou=Testing,dc=stroeder,dc=de" "oathFailureCount" requested 562eb075 => dn: [5] dc=stroeder,dc=de 562eb075 => acl_get: [5] matched 562eb075 => acl_get: [5] attr oathFailureCount 562eb075 => acl_mask: access to entry "cn=test-hotp-token-42,ou=Testing,dc=stroeder,dc=de", attr "oathFailureCount" requested 562eb075 => acl_mask: to value by "cn=michael ströder+mail=michael(a)stroeder.com,ou=private,dc=stroeder,dc=de", (=0) 562eb075 <= check a_group_pat: cn=slapd admins,ou=groups,dc=stroeder,dc=de 562eb075 <= acl_mask: [1] applying manage(=mwrscxd) (stop) 562eb075 <= acl_mask: [1] mask: manage(=mwrscxd) 562eb075 => slap_access_allowed: add access granted by manage(=mwrscxd) 562eb075 => access_allowed: add access granted by manage(=mwrscxd) 562eb075 acl: internal mod entryCSN: modify access granted 562eb075 acl: internal mod modifiersName: modify access granted 562eb075 acl: internal mod modifyTimestamp: modify access granted 562eb075 mdb_modify_internal: increment oathFailureCount Segmentation fault

1 0

(ITS#8289) slapd seg faults with MOD_INCREMENT on derived attribute
by michael＠stroeder.com 26 Oct '15

26 Oct '15

Full_Name: Version: re24 OS: openSUSE Linux URL: Submission from: (NULL) (213.240.180.113) Attribute type declaration 'bar' with Integer syntax. 'foo' SUP 'bar' makes slapd crash when sending LDAP_MOD_INCREMENT on 'foo'. LDAP_MOD_INCREMENT on 'foo' works if it's not SUP 'bar' but directly declared with Integer syntax.

1 0

Re: (ITS#8216) Windows 'make test' failures
by hyc＠symas.com 26 Oct '15

26 Oct '15

h.b.furuseth(a)usit.uio.no wrote: > On 25/10/15 09:57, hyc(a)symas.com wrote: >> mhardin(a)symas.com wrote: >>> test0-c-concurrency: problems reported by slapd-tester >> > test039-glue-ldap-concurrency: seems to fail for the same reasons as test008 >> >> libtool incompatibility; it leaves shell scripts for the actual tester >> programs in the progs directory, with the real executables under progs/.libs. >> Windows' spawn can't execute shell scripts. Solution is to manually copy the >> real executables from .libs before running the test. >> >> Simple workaround. Won't fix this. > > Does it work to change tests/scripts/defines.sh:PROGDIR to > "./progs/.libs"? If so we just need a test for whether or > not to do that, in configure.in and/or in defines.sh. Tried that, it turned out to not be the problem. Windows just wanted the .exe suffix on the command names. Fixed now in master. -- -- 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#8274) Review lmdb cyrus-sasl backend changes
by nacho.resa＠gmail.com 26 Oct '15

26 Oct '15

--f46d04218485a9382e0522fea6a1 Content-Type: text/plain; charset=UTF-8 Done: http://lists.andrew.cmu.edu/pipermail/cyrus-sasl/2015-October/002846.html On Mon, Oct 26, 2015 at 10:06 AM, Howard Chu <hyc(a)symas.com> wrote: > nacho.resa(a)gmail.com wrote: > >> Full_Name: Ignacio Casal Quinteiro >> Version: >> OS: >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (89.202.223.30) >> >> >> Hi Howard Chu, >> >> since you made the backend for cyrus-sasl, any chance you could review the >> patches here: >> https://github.com/nice-software/cyrus-sasl/commits/wip/lmdb >> before they get upstream? >> > > Patches for Cyrus SASL should be discussed on the Cyrus SASL mailing list. > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ > -- Ignacio Casal Quinteiro --f46d04218485a9382e0522fea6a1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">Done: <a href=3D"http://lists.andrew.cmu.edu/pipermail/cyr= us-sasl/2015-October/002846.html">http://lists.andrew.cmu.edu/pipermail/cyr= us-sasl/2015-October/002846.html</a><br></div><div class=3D"gmail_extra"><b= r><div class=3D"gmail_quote">On Mon, Oct 26, 2015 at 10:06 AM, Howard Chu <= span dir=3D"ltr"><<a href=3D"mailto:hyc@symas.com" target=3D"_blank">hyc= @symas.com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style= =3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><a href= =3D"mailto:nacho.resa@gmail.com" target=3D"_blank">nacho.resa(a)gmail.com</a>= wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Full_Name: Ignacio Casal Quinteiro<br> Version:<br> OS:<br> URL: <a href=3D"ftp://ftp.openldap.org/incoming/" rel=3D"noreferrer" target= =3D"_blank">ftp://ftp.openldap.org/incoming/</a><br> Submission from: (NULL) (89.202.223.30)<br> <br> <br> Hi Howard Chu,<br> <br> since you made the backend for cyrus-sasl, any chance you could review the<= br> patches here: <a href=3D"https://github.com/nice-software/cyrus-sasl/commit= s/wip/lmdb" rel=3D"noreferrer" target=3D"_blank">https://github.com/nice-so= ftware/cyrus-sasl/commits/wip/lmdb</a><br> before they get upstream?<br> </blockquote> <br> Patches for Cyrus SASL should be discussed on the Cyrus SASL mailing list.<= span class=3D"HOEnZb"><font color=3D"#888888"><br> <br> -- <br> =C2=A0 -- Howard Chu<br> =C2=A0 CTO, Symas Corp.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<a href=3D"= http://www.symas.com" rel=3D"noreferrer" target=3D"_blank">http://www.symas= .com</a><br> =C2=A0 Director, Highland Sun=C2=A0 =C2=A0 =C2=A0<a href=3D"http://highland= sun.com/hyc/" rel=3D"noreferrer" target=3D"_blank">http://highlandsun.com/h= yc/</a><br> =C2=A0 Chief Architect, OpenLDAP=C2=A0 <a href=3D"http://www.openldap.org/p= roject/" rel=3D"noreferrer" target=3D"_blank">http://www.openldap.org/proje= ct/</a><br> </font></span></blockquote></div><br><br clear=3D"all"><br>-- <br><div clas= s=3D"gmail_signature">Ignacio Casal Quinteiro</div> </div> --f46d04218485a9382e0522fea6a1--

1 0

Re: (ITS#8274) Review lmdb cyrus-sasl backend changes
by hyc＠symas.com 26 Oct '15

26 Oct '15

nacho.resa(a)gmail.com wrote: > Full_Name: Ignacio Casal Quinteiro > Version: > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (89.202.223.30) > > > Hi Howard Chu, > > since you made the backend for cyrus-sasl, any chance you could review the > patches here: https://github.com/nice-software/cyrus-sasl/commits/wip/lmdb > before they get upstream? Patches for Cyrus SASL should be discussed on the Cyrus SASL mailing list. -- -- 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#8270) win32: fix conversion error
by nacho.resa＠gmail.com 26 Oct '15

26 Oct '15

--f46d042184850fb03c0522fcd987 Content-Type: text/plain; charset=UTF-8 Howard, any chance to get this in or should I change something else? Also, any chance you could have a look at "ITS#8274"? Thanks in advance! On Tue, Oct 20, 2015 at 10:37 PM, Ignacio Casal Quinteiro < nacho.resa(a)gmail.com> wrote: > > > On Tue, Oct 20, 2015 at 10:09 PM, Howard Chu <hyc(a)symas.com> wrote: > >> nacho.resa(a)gmail.com wrote: >> >>> --047d7bb03a5ac118d20522842ead >>> Content-Type: text/plain; charset=UTF-8 >>> >>> So I took another closer look at this issue and I went for this possible >>> solution: >>> >>> https://github.com/nice-software/lmdb/commit/03987789735141dc68ae8b2d0e5ad5… >>> >> >> That looks OK. >> >> Basically it errors out because MSVC needs stdcall on that method. >>> >> >> You realize of course, that this change actually has no effect on the >> code here? stdcall uses Pascal argument order instead of C order but it's >> moot since the function only has 1 argument. >> > > yeah... but if this fixes the error I am fine with it, after all it end > ups being just a define > > >> >> >>> Cheers. >>> >>> On Mon, Oct 19, 2015 at 2:55 PM, Ignacio Casal Quinteiro < >>> nacho.resa(a)gmail.com> wrote: >>> >>> Sorry! I did indeed meant to change just the windows part, for some >>>> reason >>>> I thought it was already ifdeffed that part. >>>> >>>> >>>> https://github.com/nice-software/lmdb/commit/42577fe173923c1166f8382a53523a… >>>> >>>> This is the right patch. >>>> >>>> On Mon, Oct 19, 2015 at 1:43 PM, Hallvard Breien Furuseth < >>>> h.b.furuseth(a)usit.uio.no> wrote: >>>> >>>> On 19. okt. 2015 08:57, nacho.resa(a)gmail.com wrote: >>>>> >>>>> I do not understand, I tested also with mingw64 (...) >>>>>> >>>>>> >>>>> There's no LPTHREAD_START_ROUTINE type on non-Windows machines. >>>>> You could replace 'start' with '(LPTHREAD_START_ROUTINE)(start)' >>>>> in the _WIN32 variant of '#define THREAD_CREATE...'. >>>>> >>>>> However, it's still wrong to call a function via another prototype. >>>>> Maybe that'd fall on 32-bit Windows or something, I don't know >>>>> how LPTHREAD_START_ROUTINE is defined. The safe way would be to >>>>> give mdb_env_copythr() a prototype which does not need a cast. >>>>> There is some code for that already. Maybe it can be improved. >>>>> >>>>> -- >>>>> Hallvard >>>>> >>>>> >>>> >>>> >>>> -- >>>> Ignacio Casal Quinteiro >>>> >>>> >>> >>> >>> >> >> -- >> -- Howard Chu >> CTO, Symas Corp. http://www.symas.com >> Director, Highland Sun http://highlandsun.com/hyc/ >> Chief Architect, OpenLDAP http://www.openldap.org/project/ >> > > > > -- > Ignacio Casal Quinteiro > -- Ignacio Casal Quinteiro --f46d042184850fb03c0522fcd987 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div><div>Howard, any chance to get this in or should I ch= ange something else?<br></div>Also, any chance you could have a look at &qu= ot;ITS#8274"?<br><br></div>Thanks in advance!<br></div><div class=3D"g= mail_extra"><br><div class=3D"gmail_quote">On Tue, Oct 20, 2015 at 10:37 PM= , Ignacio Casal Quinteiro <span dir=3D"ltr"><<a href=3D"mailto:nacho.res= a(a)gmail.com" target=3D"_blank">nacho.resa(a)gmail.com</a>></span> wrote:<b= r><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:= 1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><div class=3D"gmail_e= xtra"><br><div class=3D"gmail_quote"><span class=3D"">On Tue, Oct 20, 2015 = at 10:09 PM, Howard Chu <span dir=3D"ltr"><<a href=3D"mailto:hyc@symas.c= om" target=3D"_blank">hyc(a)symas.com</a>></span> wrote:<br><blockquote cl= ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p= adding-left:1ex"><a href=3D"mailto:nacho.resa@gmail.com" target=3D"_blank">= nacho.resa(a)gmail.com</a> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> --047d7bb03a5ac118d20522842ead<br> Content-Type: text/plain; charset=3DUTF-8<span><br> <br> So I took another closer look at this issue and I went for this possible<br= > solution:<br> <a href=3D"https://github.com/nice-software/lmdb/commit/03987789735141dc68a= e8b2d0e5ad52d82cc80d0" rel=3D"noreferrer" target=3D"_blank">https://github.= com/nice-software/lmdb/commit/03987789735141dc68ae8b2d0e5ad52d82cc80d0</a><= br> </span></blockquote> <br> That looks OK.<span><br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Basically it errors out because MSVC needs stdcall on that method.<br> </blockquote> <br></span> You realize of course, that this change actually has no effect on the code = here? stdcall uses Pascal argument order instead of C order but it's mo= ot since the function only has 1 argument.<span><br></span></blockquote><di= v><br></div></span><div>yeah... but if this fixes the error I am fine with = it, after all it end ups being just a define<br></div><div><div class=3D"h5= "><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 = .8ex;border-left:1px #ccc solid;padding-left:1ex"><span> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> <br> Cheers.<br> <br> On Mon, Oct 19, 2015 at 2:55 PM, Ignacio Casal Quinteiro <<br> <a href=3D"mailto:nacho.resa@gmail.com" target=3D"_blank">nacho.resa(a)gmail.= com</a>> wrote:<br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Sorry! I did indeed meant to change just the windows part, for some reason<= br> I thought it was already ifdeffed that part.<br> <br> <a href=3D"https://github.com/nice-software/lmdb/commit/42577fe173923c1166f= 8382a53523a31479f9d43" rel=3D"noreferrer" target=3D"_blank">https://github.= com/nice-software/lmdb/commit/42577fe173923c1166f8382a53523a31479f9d43</a><= br> <br> This is the right patch.<br> <br> On Mon, Oct 19, 2015 at 1:43 PM, Hallvard Breien Furuseth <<br> <a href=3D"mailto:h.b.furuseth@usit.uio.no" target=3D"_blank">h.b.furuseth@= usit.uio.no</a>> wrote:<br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> On 19. okt. 2015 08:57, <a href=3D"mailto:nacho.resa@gmail.com" target=3D"_= blank">nacho.resa(a)gmail.com</a> wrote:<br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> I do not understand, I tested also with mingw64 (...)<br> <br> </blockquote> <br> There's no LPTHREAD_START_ROUTINE type on non-Windows machines.<br> You could replace 'start' with '(LPTHREAD_START_ROUTINE)(start)= '<br> in the _WIN32 variant of '#define THREAD_CREATE...'.<br> <br> However, it's still wrong to call a function via another prototype.<br> Maybe that'd fall on 32-bit Windows or something, I don't know<br> how LPTHREAD_START_ROUTINE is defined.=C2=A0 The safe way would be to<br> give mdb_env_copythr() a prototype which does not need a cast.<br> There is some code for that already. Maybe it can be improved.<br> <br> --<br> Hallvard<br> <br> </blockquote> <br> <br> <br> --<br> Ignacio Casal Quinteiro<br> <br> </blockquote> <br> <br> <br> </blockquote> <br> <br> -- <br></span><div><div> =C2=A0 -- Howard Chu<br> =C2=A0 CTO, Symas Corp.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<a href=3D"= http://www.symas.com" rel=3D"noreferrer" target=3D"_blank">http://www.symas= .com</a><br> =C2=A0 Director, Highland Sun=C2=A0 =C2=A0 =C2=A0<a href=3D"http://highland= sun.com/hyc/" rel=3D"noreferrer" target=3D"_blank">http://highlandsun.com/h= yc/</a><br> =C2=A0 Chief Architect, OpenLDAP=C2=A0 <a href=3D"http://www.openldap.org/p= roject/" rel=3D"noreferrer" target=3D"_blank">http://www.openldap.org/proje= ct/</a><br> </div></div></blockquote></div></div></div><span class=3D"HOEnZb"><font col= or=3D"#888888"><br><br clear=3D"all"><br>-- <br><div>Ignacio Casal Quinteir= o</div> </font></span></div></div> </blockquote></div><br><br clear=3D"all"><br>-- <br><div class=3D"gmail_sig= nature">Ignacio Casal Quinteiro</div> </div> --f46d042184850fb03c0522fcd987--

1 0

(ITS#8288) Asyncronous Disconnect Handlers Not Firing
by jeremyc＠ssimicro.com 25 Oct '15

25 Oct '15

Full_Name: Jeremy Childs Version: 2.4.42 OS: FreeBSD/Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (64.247.138.35) Im seeing an issue with async reconnects in libldap 2.4.42 - when the remote server disconnects unexpectedly and there are requests in the queue, request.c:196 calls ldap_free_connection with the force parameter set to 0. Since apap_free_connection wont actually free anything (or call the disconnect handler) until the refcount is zero, nothing happens. Testing with the force parameter set to 1 addresses the issue, the pending requests get freed, and the connection itself frees, calling the disconnect handler in the process.

1 0

Re: (ITS#8216) Windows 'make test' failures
by h.b.furuseth＠usit.uio.no 25 Oct '15

25 Oct '15

On 25/10/15 09:57, hyc(a)symas.com wrote: > mhardin(a)symas.com wrote: >> test0-c-concurrency: problems reported by slapd-tester > > test039-glue-ldap-concurrency: seems to fail for the same reasons as test008 > > libtool incompatibility; it leaves shell scripts for the actual tester > programs in the progs directory, with the real executables under progs/.libs. > Windows' spawn can't execute shell scripts. Solution is to manually copy the > real executables from .libs before running the test. > > Simple workaround. Won't fix this. Does it work to change tests/scripts/defines.sh:PROGDIR to "./progs/.libs"? If so we just need a test for whether or not to do that, in configure.in and/or in defines.sh.

1 0

Re: (ITS#8216) Windows 'make test' failures
by h.b.furuseth＠usit.uio.no 25 Oct '15

25 Oct '15

On 25/10/15 09:57, hyc(a)symas.com wrote: >> test043-delta-syncrepl: lmdb always fails, hdb/bdb sometimes > > Attribute ordering, the replicated data is correct. Won't fix this. Sounds like you can just replace "$LDIFFILTER -s bdb=a,hdb=a" with "$LDIFFILTER -s a" or add ",mdb=a".

1 0

Re: (ITS#8204) rfc2782 shuffle implementation doesn't treat equal-weight records equally
by hyc＠symas.com 25 Oct '15

25 Oct '15

Sergio.Gelato(a)astro.su.se wrote: > Full_Name: Sergio Gelato > Version: 2.4.40 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (85.225.123.9) > > > As currently implemented (since ITS#7027, > 5de85b922aaa5bfa6eb53db6000adf01ebdb0736) the algorithm to shuffle DNS SRV > records of a given priority according to their weights is flawed: if all records > have the same weight, the implementation is biased towards the first record and > against the last. In the most extreme case of two records of weight 1, the > current implementation will never swap them (whereas one would have hoped for a > swap 50% of the time). The problem can be cured by changing (r <= 0) to (r < 0). > (The wording of the RFC may have contributed to this error; I suspect it was > written with real random deviates in mind, not integer ones. In any event, the > principle that records of equal weight should have the same probability of being > picked trumps the RFC since the latter only says what algorithm SHOULD be > used.) > > I've written and tested a patch for this and found it to solve the above > problem. My patch also addresses another (operationally minor, which is why I'm > not reporting it separately) issue in the same piece of code: what if at least > two, but not all, of the records of a given priority have weight zero? One > should be prepared to switch to a Fisher-Yates shuffle if "total" becomes zero > during the iteration. > > (Yet another potential issue is overflow of "total" on platforms where > INT_MAX==32767 if the sum of the weights exceeds that value. Consider declaring > it uint32_t or u_long.) I see no patch nor URL. -- -- 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

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs