Logged in as guest
Viewing Incoming/6096 Full headers
Major security issue: yes no
Notes: Notification:
Date: Thu, 07 May 2009 08:12:18 +0000 From: luca@openldap.org To: openldap-its@OpenLDAP.org Subject: 2.4.16 replica segfault
Full_Name: Luca Scamoni Version: 2.4.16 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.63.140.131) Scenario: OpenLDAP 2.4.16 with patches for back-bdb (up to may 1st) and syncrepl. Master-slave configuration using syncrepl refreshAndPersist. Two hdb databases per instance. Replica hit assert in slap_modrdn2mods and dumped core. Since no MODRDN operation is ever being performed on entries I wonder why. Anyway, here the bt full: #0 0x004017a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 No symbol table info available. #1 0x004427a5 in raise () from /lib/tls/libc.so.6 No symbol table info available. #2 0x00444209 in abort () from /lib/tls/libc.so.6 No symbol table info available. #3 0x0043bd91 in __assert_fail () from /lib/tls/libc.so.6 No symbol table info available. #4 0x0809c7e6 in slap_modrdn2mods (op=0x380acf0, rs=0x380a910) at ../../../servers/slapd/modrdn.c:394 a_cnt = 0 d_cnt = 0 old_rdn = 0x0 new_rdn = 0x0 __PRETTY_FUNCTION__ = "slap_modrdn2mods" #5 0x080f39f4 in syncrepl_entry (si=0x8fdebf8, op=0x380acf0, entry=0x54eba5f4, modlist=0x380aaf4, syncstate=2, syncUUID=0x380ab50, syncCSN=0x4d3e0388) at ../../../servers/slapd/syncrepl.c:2278 noldp = {bv_len = 1294991464, bv_val = 0x4d300048 ""} newp = {bv_len = 0, bv_val = 0x4d3691c8 ""} i = 4707898 got_replace = 0 just_rename = 0 mod = (Modifications *) 0x54a371fc modtail = (Modifications **) 0x1d2d14 ml = (Modifications **) 0x4565bac8 m2 = (Modifications *) 0x4d300010 be = (Backend *) 0x8fdd988 cb = {sc_next = 0x0, sc_response = 0x80f7618 <null_callback>, sc_cleanup = 0, sc_private = 0x8fdebf8} syncuuid_inserted = 0 syncUUID_strrep = {bv_len = 36, bv_val = 0x4ae0300c "6a0ba116-b291-11da-8006-87f6e679f1bd"} rs_search = {sr_type = REP_RESULT, sr_tag = 101, sr_msgid = 0, sr_err = 0, sr_matched = 0x0, sr_text = 0x813b938 "AttributeDescription contains inappropriate characters", sr_ref = 0x0, sr_ctrls = 0x0, sr_un = {sru_sasl = {r_sasldata = 0x0}, sru_extended = {r_rspoid = 0x0, r_rspdata = 0x0}, sru_search = {r_entry = 0x0, r_attr_flags = 0, r_operational_attrs = 0x0, r_attrs = 0x8172ce0, r_nentries = 0, r_v2ref = 0x0}}, sr_flags = 4} rs_delete = {sr_type = REP_RESULT, sr_tag = 0, sr_msgid = 0, sr_err = 0, sr_matched = 0x0, sr_text = 0x0, sr_ref = 0x0, sr_ctrls = 0x0, sr_un = { sru_sasl = {r_sasldata = 0x0}, sru_extended = {r_rspoid = 0x0, r_rspdata = 0x0}, sru_search = {r_entry = 0x0, r_attr_flags = 0, r_operational_attrs = 0x0, r_attrs = 0x0, r_nentries = 0, r_v2ref = 0x0}}, sr_flags = 0} rs_add = {sr_type = REP_RESULT, sr_tag = 0, sr_msgid = 0, sr_err = 0, sr_matched = 0x0, sr_text = 0x0, sr_ref = 0x0, sr_ctrls = 0x0, sr_un = { sru_sasl = {r_sasldata = 0x0}, sru_extended = {r_rspoid = 0x0, r_rspdata = 0x0}, sru_search = {r_entry = 0x0, r_attr_flags = 0, r_operational_attrs = 0x0, r_attrs = 0x0, r_nentries = 0, r_v2ref = 0x0}}, sr_flags = 0} rs_modify = {sr_type = REP_RESULT, sr_tag = 0, sr_msgid = 0, sr_err = 0, sr_matched = 0x0, sr_text = 0x0, sr_ref = 0x0, sr_ctrls = 0x0, sr_un = { sru_sasl = {r_sasldata = 0x0}, sru_extended = {r_rspoid = 0x0, r_rspdata = 0x0}, sru_search = {r_entry = 0x0, r_attr_flags = 0, r_operational_attrs = 0x0, r_attrs = 0x0, r_nentries = 0, r_v2ref = 0x0}}, sr_flags = 0} f = {f_choice = 163, f_un = {f_un_result = 58763504, f_un_desc = 0x380a8f0, f_un_ava = 0x380a8f0, f_un_ssa = 0x380a8f0, f_un_mra = 0x380a8f0, f_un_complex = 0x380a8f0}, f_next = 0x0} ava = {aa_desc = 0x8f08d50, aa_value = {bv_len = 16, bv_val = 0x45614117 "j\v.\026.\221\021.\200\006\207..y.."}} rc = 0 pdn = {bv_len = 0, bv_val = 0x0} dni = {new_entry = 0x54eba5f4, dn = {bv_len = 112, bv_val = 0x4ae03074 "cn=CRL19,ou=Regione Siciliana Certification Authority Cittadini,o=Regione Siciliana,c=IT,dc=a,dc=prod,dc=actalis"}, ndn = { bv_len = 112, bv_val = 0x4ae030ec "cn=crl19,ou=regione siciliana certification authority cittadini,o=regione siciliana,c=it,dc=a,dc=prod,dc=actalis"}, nnewSup = {bv_len = 0, bv_val = 0x4d31cff8 ""}, renamed = 1, delOldRDN = 0, modlist = 0x380aaf4, mods = 0x456172e0, oldNattr = 0x54a38d74, oldDesc = 0x8f0ce90, newDesc = 0x0} retry = 1 freecsn = 1 __PRETTY_FUNCTION__ = "syncrepl_entry" #6 0x080eebcf in do_syncrep2 (op=0x380acf0, si=0x8fdebf8) at ../../../servers/slapd/syncrepl.c:892 rctrlp = (LDAPControl *) 0x45635200 rctrls = (LDAPControl **) 0x4d371e08 berbuf = { buffer = "\002\000\001", '\0' <repeats 17 times>, "\020AaE]AaE]AaE", '\0' <repeats 16 times>, "..\200\003 *T\000\000\000\000\000\017\000\000\000./T\000\017\000\000\000?}S\000..\200\003./T\000\a\000\000\000\000\000\000\000\001\000\000\000\02
Date: Thu, 07 May 2009 01:50:08 -0700 From: Howard Chu <hyc@symas.com> To: luca@OpenLDAP.org CC: openldap-its@OpenLDAP.org Subject: Re: (ITS#6096) 2.4.16 replica segfault
luca@OpenLDAP.org wrote: > Full_Name: Luca Scamoni > Version: 2.4.16 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (82.63.140.131) > > > Scenario: > OpenLDAP 2.4.16 with patches for back-bdb (up to may 1st) and syncrepl. > Master-slave configuration using syncrepl refreshAndPersist. Two hdb databases > per instance. > Replica hit assert in slap_modrdn2mods and dumped core. An assert is not a segfault... > Since no MODRDN > operation is ever being performed on entries I wonder why. Apparently the name of the entry in the consumer doesn't match the name of the entry received from the provider. > Anyway, here the bt > full: In frame 5, print *entry > #0 0x004017a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 > No symbol table info available. > #1 0x004427a5 in raise () from /lib/tls/libc.so.6 > No symbol table info available. > #2 0x00444209 in abort () from /lib/tls/libc.so.6 > No symbol table info available. > #3 0x0043bd91 in __assert_fail () from /lib/tls/libc.so.6 > No symbol table info available. > #4 0x0809c7e6 in slap_modrdn2mods (op=0x380acf0, rs=0x380a910) at > ../../../servers/slapd/modrdn.c:394 > a_cnt = 0 > d_cnt = 0 > old_rdn = 0x0 > new_rdn = 0x0 > __PRETTY_FUNCTION__ = "slap_modrdn2mods" > #5 0x080f39f4 in syncrepl_entry (si=0x8fdebf8, op=0x380acf0, entry=0x54eba5f4, > modlist=0x380aaf4, syncstate=2, syncUUID=0x380ab50, syncCSN=0x4d3e0388) > at ../../../servers/slapd/syncrepl.c:2278 > noldp = {bv_len = 1294991464, bv_val = 0x4d300048 ""} > newp = {bv_len = 0, bv_val = 0x4d3691c8 ""} > i = 4707898 > got_replace = 0 > just_rename = 0 > mod = (Modifications *) 0x54a371fc > modtail = (Modifications **) 0x1d2d14 > ml = (Modifications **) 0x4565bac8 > m2 = (Modifications *) 0x4d300010 > be = (Backend *) 0x8fdd988 > cb = {sc_next = 0x0, sc_response = 0x80f7618<null_callback>, sc_cleanup > = 0, sc_private = 0x8fdebf8} > syncuuid_inserted = 0 > syncUUID_strrep = {bv_len = 36, bv_val = 0x4ae0300c > "6a0ba116-b291-11da-8006-87f6e679f1bd"} > rs_search = {sr_type = REP_RESULT, sr_tag = 101, sr_msgid = 0, sr_err = > 0, sr_matched = 0x0, > sr_text = 0x813b938 "AttributeDescription contains inappropriate characters", > sr_ref = 0x0, sr_ctrls = 0x0, sr_un = {sru_sasl = {r_sasldata = 0x0}, > sru_extended = {r_rspoid = 0x0, r_rspdata = 0x0}, sru_search = {r_entry = > 0x0, r_attr_flags = 0, r_operational_attrs = 0x0, r_attrs = 0x8172ce0, > r_nentries = 0, r_v2ref = 0x0}}, sr_flags = 4} > rs_delete = {sr_type = REP_RESULT, sr_tag = 0, sr_msgid = 0, sr_err = 0, > sr_matched = 0x0, sr_text = 0x0, sr_ref = 0x0, sr_ctrls = 0x0, sr_un = { > sru_sasl = {r_sasldata = 0x0}, sru_extended = {r_rspoid = 0x0, r_rspdata = > 0x0}, sru_search = {r_entry = 0x0, r_attr_flags = 0, > r_operational_attrs = 0x0, r_attrs = 0x0, r_nentries = 0, r_v2ref = 0x0}}, > sr_flags = 0} > rs_add = {sr_type = REP_RESULT, sr_tag = 0, sr_msgid = 0, sr_err = 0, > sr_matched = 0x0, sr_text = 0x0, sr_ref = 0x0, sr_ctrls = 0x0, sr_un = { > sru_sasl = {r_sasldata = 0x0}, sru_extended = {r_rspoid = 0x0, r_rspdata = > 0x0}, sru_search = {r_entry = 0x0, r_attr_flags = 0, > r_operational_attrs = 0x0, r_attrs = 0x0, r_nentries = 0, r_v2ref = 0x0}}, > sr_flags = 0} > rs_modify = {sr_type = REP_RESULT, sr_tag = 0, sr_msgid = 0, sr_err = 0, > sr_matched = 0x0, sr_text = 0x0, sr_ref = 0x0, sr_ctrls = 0x0, sr_un = { > sru_sasl = {r_sasldata = 0x0}, sru_extended = {r_rspoid = 0x0, r_rspdata = > 0x0}, sru_search = {r_entry = 0x0, r_attr_flags = 0, > r_operational_attrs = 0x0, r_attrs = 0x0, r_nentries = 0, r_v2ref = 0x0}}, > sr_flags = 0} > f = {f_choice = 163, f_un = {f_un_result = 58763504, f_un_desc = > 0x380a8f0, f_un_ava = 0x380a8f0, f_un_ssa = 0x380a8f0, f_un_mra = 0x380a8f0, > f_un_complex = 0x380a8f0}, f_next = 0x0} > ava = {aa_desc = 0x8f08d50, aa_value = {bv_len = 16, bv_val = 0x45614117 > "j\v.\026.\221\021.\200\006\207..y.."}} > rc = 0 > pdn = {bv_len = 0, bv_val = 0x0} > dni = {new_entry = 0x54eba5f4, dn = {bv_len = 112, > bv_val = 0x4ae03074 "cn=CRL19,ou=Regione Siciliana Certification Authority > Cittadini,o=Regione Siciliana,c=IT,dc=a,dc=prod,dc=actalis"}, ndn = { > bv_len = 112, bv_val = 0x4ae030ec "cn=crl19,ou=regione siciliana > certification authority cittadini,o=regione > siciliana,c=it,dc=a,dc=prod,dc=actalis"}, > nnewSup = {bv_len = 0, bv_val = 0x4d31cff8 ""}, renamed = 1, delOldRDN = 0, > modlist = 0x380aaf4, mods = 0
Date: Thu, 07 May 2009 11:41:51 +0200 From: Luca Scamoni <luca.scamoni@sys-net.it> To: hyc@symas.com CC: openldap-its@openldap.org Subject: Re: (ITS#6096) 2.4.16 replica segfault
hyc@symas.com ha scritto: > > An assert is not a segfault... > You're right. Let's say that from the perspective of the customer a core file is always a Bad Thing ;-) > > Apparently the name of the entry in the consumer doesn't match the name of the > entry received from the provider. > Yes, but this is very strange. This is a migration from 2.3.37 to 2.4.16 done through slapcat/slapadd procedure on the master. > > In frame 5, print *entry > (gdb) frame 5 #5 0x080f39f4 in syncrepl_entry (si=0x8fdebf8, op=0x380acf0, entry=0x54eba5f4, modlist=0x380aaf4, syncstate=2, syncUUID=0x380ab50, syncCSN=0x4d3e0388) at ../../../servers/slapd/syncrepl.c:2278 2278 ../../../servers/slapd/syncrepl.c: No such file or directory. in ../../../servers/slapd/syncrepl.c (gdb) p *entry $1 = {e_id = 0, e_name = {bv_len = 0, bv_val = 0x4d3691c8 ""}, e_nname = {bv_len = 0, bv_val = 0x4d31cff8 ""}, e_attrs = 0x54a371fc, e_ocflags = 0, e_bv = { bv_len = 0, bv_val = 0x0}, e_private = 0x0} Ing. Luca Scamoni Responsabile Ricerca e Sviluppo SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 0382 573859 (137) Fax: +39 0382 476497 Email: luca.scamoni@sys-net.it -----------------------------------
Date: Thu, 07 May 2009 03:23:28 -0700 From: Howard Chu <hyc@symas.com> To: Luca Scamoni <luca.scamoni@sys-net.it> CC: openldap-its@openldap.org Subject: Re: (ITS#6096) 2.4.16 replica segfault
Luca Scamoni wrote: > hyc@symas.com ha scritto: >> Apparently the name of the entry in the consumer doesn't match the name of the >> entry received from the provider. >> > Yes, but this is very strange. This is a migration from 2.3.37 to 2.4.16 > done through slapcat/slapadd procedure on the master. >> >> In frame 5, print *entry >> > (gdb) frame 5 > #5 0x080f39f4 in syncrepl_entry (si=0x8fdebf8, op=0x380acf0, > entry=0x54eba5f4, modlist=0x380aaf4, syncstate=2, syncUUID=0x380ab50, > syncCSN=0x4d3e0388) > at ../../../servers/slapd/syncrepl.c:2278 > 2278 ../../../servers/slapd/syncrepl.c: No such file or directory. > in ../../../servers/slapd/syncrepl.c > (gdb) p *entry > $1 = {e_id = 0, e_name = {bv_len = 0, bv_val = 0x4d3691c8 ""}, e_nname = > {bv_len = 0, bv_val = 0x4d31cff8 ""}, e_attrs = 0x54a371fc, e_ocflags = > 0, e_bv = { > bv_len = 0, bv_val = 0x0}, e_private = 0x0} > Well, that's certainly odd looking. Did you have SYNC logging at the time, do you have the log messages from just before this occurred? Can you print out the a_desc and values of all of the attributes in entry->e_attrs ? -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Date: Thu, 07 May 2009 14:48:55 +0200 From: Luca Scamoni <luca.scamoni@sys-net.it> To: hyc@symas.com CC: openldap-its@openldap.org Subject: Re: (ITS#6096) 2.4.16 replica segfault
hyc@symas.com ha scritto: > Luca Scamoni wrote: >> hyc@symas.com ha scritto: >>> Apparently the name of the entry in the consumer doesn't match the name of the >>> entry received from the provider. >>> >> Yes, but this is very strange. This is a migration from 2.3.37 to 2.4.16 >> done through slapcat/slapadd procedure on the master. >>> In frame 5, print *entry >>> >> (gdb) frame 5 >> #5 0x080f39f4 in syncrepl_entry (si=0x8fdebf8, op=0x380acf0, >> entry=0x54eba5f4, modlist=0x380aaf4, syncstate=2, syncUUID=0x380ab50, >> syncCSN=0x4d3e0388) >> at ../../../servers/slapd/syncrepl.c:2278 >> 2278 ../../../servers/slapd/syncrepl.c: No such file or directory. >> in ../../../servers/slapd/syncrepl.c >> (gdb) p *entry >> $1 = {e_id = 0, e_name = {bv_len = 0, bv_val = 0x4d3691c8 ""}, e_nname = >> {bv_len = 0, bv_val = 0x4d31cff8 ""}, e_attrs = 0x54a371fc, e_ocflags = >> 0, e_bv = { >> bv_len = 0, bv_val = 0x0}, e_private = 0x0} >> > Well, that's certainly odd looking. Did you have SYNC logging at the time, do > you have the log messages from just before this occurred? > > Can you print out the a_desc and values of all of the attributes in > entry->e_attrs ? > loglevel is stats sync. values in another email here an excerpt of the logs from master: May 7 09:00:13 quercia01 slapd[22251]: conn=144 op=604 MOD attr=certificateRevocationList;binary May 7 09:00:13 quercia01 slapd[22251]: slap_queue_csn: queing 0x1ce3980 20090507070013.853843Z#000000#000#000000 May 7 09:00:13 quercia01 slapd[22251]: conn=571 op=444 RESULT tag=103 err=0 text= May 7 09:00:13 quercia01 slapd[22251]: slap_graduate_commit_csn: removing 0x97c2860 20090507070013.733132Z#000000#000#000000 May 7 09:00:13 quercia01 slapd[22251]: conn=144 op=604 RESULT tag=103 err=0 text= May 7 09:00:14 quercia01 slapd[22251]: slap_graduate_commit_csn: removing 0x4564c8b0 20090507070013.853843Z#000000#000#000000 May 7 09:00:13 quercia01 slapd[22251]: syncprov_sendresp: cookie=rid=002,csn=20090507070013.733132Z#000000#000#000000 May 7 09:00:13 quercia01 slapd[22251]: conn=567 op=445 MOD dn="cn=CRL19,ou=Regione Siciliana Certification Authority Cittadini,o=Regione Siciliana,c=IT,dc=a ,dc=prod,dc=actalis" May 7 09:00:14 quercia01 slapd[22251]: syncprov_sendresp: cookie=rid=002,csn=20090507070013.853843Z#000000#000#000000 May 7 09:00:14 quercia01 slapd[22251]: conn=567 op=445 MOD attr=certificateRevocationList;binary May 7 09:00:14 quercia01 slapd[22251]: conn=130 op=605 MOD dn="cn=CRL7,ou=Regione Siciliana Certification Authority Cittadini,o=Regione Siciliana,c=IT,dc=a, dc=prod,dc=actalis" May 7 09:00:14 quercia01 slapd[22251]: conn=130 op=605 MOD attr=certificateRevocationList;binary May 7 09:00:14 quercia01 slapd[22251]: slap_queue_csn: queing 0x38f3980 20090507070014.234380Z#000000#000#000000 May 7 09:00:14 quercia01 slapd[22251]: slap_queue_csn: queing 0x59ad980 20090507070014.312708Z#000000#000#000000 May 7 09:00:14 quercia01 slapd[22251]: conn=567 op=445 RESULT tag=103 err=0 text= May 7 09:00:14 quercia01 slapd[22251]: conn=130 op=605 RESULT tag=103 err=0 text= May 7 09:00:14 quercia01 slapd[22251]: syncprov_sendresp: cookie=rid=002,csn=20090507070014.234380Z#000000#000#000000 May 7 09:00:14 quercia01 slapd[22251]: syncprov_sendresp: cookie=rid=002,csn=20090507070014.312708Z#000000#000#000000 May 7 09:00:14 quercia01 slapd[22251]: slap_graduate_commit_csn: removing 0x460d6410 20090507070014.234380Z#000000#000#000000 May 7 09:00:14 quercia01 slapd[22251]: conn=129 op=620 MOD dn="cn=CRL41,ou=Regione Siciliana Certification Authority Cittadini,o=Regione Siciliana,c=IT,dc=a ,dc=prod,dc=actalis" May 7 09:00:14 quercia01 slapd[22251]: slap_graduate_commit_csn: removing 0x97a6360 20090507070014.312708Z#000000#000#000000 and these from the replica: May 7 09:00:10 quercia02 slapd[13339]: do_syncrep2: cookie=rid=002,csn=20090507070009.855998Z#000000#000#000000 May 7 09:00:10 quercia02 slapd[13339]: syncrepl_entry: rid=002 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_MODIFY) May 7 09:00:10 quercia02 slapd[13339]: syncrepl_entry: rid=002 be_search (0) May 7 09:00:10 quercia02 slapd[13339]: syncrepl_entry: rid=002 cn=CRL24,ou=Regione Siciliana Certification Authority Cittadini,o=Regione Siciliana,c=IT,dc=a ,dc=prod,dc=actalis May 7 09:00:10 quercia02 slapd[13339]: slap_queue_csn: queing 0x548befa8 20090507070009.855998Z#000000#000#000000 May 7 09:00:10 quercia02 slapd[13339]: slap_graduate_commit_csn: removing 0x50067650 20090507070009.855998Z#000000#000#000000 May 7 09:00:10 quercia02 slapd[13339]: syncrepl_entry: rid=002 be_modify cn=CRL24,ou=Regione Siciliana Certification Authority Cittadini,o=Regione Siciliana ,c=IT,dc=a,dc=prod,dc=actalis (0) May 7 09:00:10 quercia02 slapd[13339]: slap_queue_csn: queing 0x548befa8 20090507070009.855998Z#000000#000#000000 May 7 09:00:
Date: Thu, 07 May 2009 15:17:11 +0200 From: Pierangelo Masarati <masarati@aero.polimi.it> To: hyc@symas.com CC: openldap-its@openldap.org Subject: Re: (ITS#6096) 2.4.16 replica segfault
hyc@symas.com wrote: > Luca Scamoni wrote: >> hyc@symas.com ha scritto: >>> Apparently the name of the entry in the consumer doesn't match the name of the >>> entry received from the provider. >>> >> Yes, but this is very strange. This is a migration from 2.3.37 to 2.4.16 >> done through slapcat/slapadd procedure on the master. >>> In frame 5, print *entry >>> >> (gdb) frame 5 >> #5 0x080f39f4 in syncrepl_entry (si=0x8fdebf8, op=0x380acf0, >> entry=0x54eba5f4, modlist=0x380aaf4, syncstate=2, syncUUID=0x380ab50, >> syncCSN=0x4d3e0388) >> at ../../../servers/slapd/syncrepl.c:2278 >> 2278 ../../../servers/slapd/syncrepl.c: No such file or directory. >> in ../../../servers/slapd/syncrepl.c >> (gdb) p *entry >> $1 = {e_id = 0, e_name = {bv_len = 0, bv_val = 0x4d3691c8 ""}, e_nname = >> {bv_len = 0, bv_val = 0x4d31cff8 ""}, e_attrs = 0x54a371fc, e_ocflags = >> 0, e_bv = { >> bv_len = 0, bv_val = 0x0}, e_private = 0x0} >> > Well, that's certainly odd looking. Did you have SYNC logging at the time, do > you have the log messages from just before this occurred? > > Can you print out the a_desc and values of all of the attributes in > entry->e_attrs ? Howard, what's odd is that, as far as I understand, entry->e_name is set after op->o_req_dn, inside syncrepl_message_to_entry(), which is just extracted and normalized from the message. What could perhaps happen is that dnPrettyNormal() fails (in fact its result is not checked). I'm adding a check and some logging, just in case. p.
Date: Thu, 07 May 2009 06:25:30 -0700 From: Howard Chu <hyc@symas.com> To: Pierangelo Masarati <masarati@aero.polimi.it> CC: openldap-its@openldap.org Subject: Re: (ITS#6096) 2.4.16 replica segfault
Pierangelo Masarati wrote: > hyc@symas.com wrote: >> Luca Scamoni wrote: >>> hyc@symas.com ha scritto: >>>> Apparently the name of the entry in the consumer doesn't match the name of the >>>> entry received from the provider. >>>> >>> Yes, but this is very strange. This is a migration from 2.3.37 to 2.4.16 >>> done through slapcat/slapadd procedure on the master. >>>> In frame 5, print *entry >>>> >>> (gdb) frame 5 >>> #5 0x080f39f4 in syncrepl_entry (si=0x8fdebf8, op=0x380acf0, >>> entry=0x54eba5f4, modlist=0x380aaf4, syncstate=2, syncUUID=0x380ab50, >>> syncCSN=0x4d3e0388) >>> at ../../../servers/slapd/syncrepl.c:2278 >>> 2278 ../../../servers/slapd/syncrepl.c: No such file or directory. >>> in ../../../servers/slapd/syncrepl.c >>> (gdb) p *entry >>> $1 = {e_id = 0, e_name = {bv_len = 0, bv_val = 0x4d3691c8 ""}, e_nname = >>> {bv_len = 0, bv_val = 0x4d31cff8 ""}, e_attrs = 0x54a371fc, e_ocflags = >>> 0, e_bv = { >>> bv_len = 0, bv_val = 0x0}, e_private = 0x0} >>> >> Well, that's certainly odd looking. Did you have SYNC logging at the time, do >> you have the log messages from just before this occurred? >> >> Can you print out the a_desc and values of all of the attributes in >> entry->e_attrs ? > > Howard, > > what's odd is that, as far as I understand, entry->e_name is set after > op->o_req_dn, inside syncrepl_message_to_entry(), which is just > extracted and normalized from the message. What could perhaps happen is > that dnPrettyNormal() fails (in fact its result is not checked). I'm > adding a check and some logging, just in case. Good idea. Also, I think the original LDAP message should still be intact, in frame 6 "msg" - perhaps you can extract the DN that was actually received and figure out why it had a problem. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Date: Thu, 07 May 2009 15:28:44 +0200 From: Pierangelo Masarati <masarati@aero.polimi.it> To: hyc@symas.com CC: openldap-its@openldap.org, Luca Scamoni <luca.scamoni@sys-net.it> Subject: Re: (ITS#6096) 2.4.16 replica segfault
hyc@symas.com wrote: > Pierangelo Masarati wrote: >> hyc@symas.com wrote: >>> Luca Scamoni wrote: >>>> hyc@symas.com ha scritto: >>>>> Apparently the name of the entry in the consumer doesn't match the name of the >>>>> entry received from the provider. >>>>> >>>> Yes, but this is very strange. This is a migration from 2.3.37 to 2.4.16 >>>> done through slapcat/slapadd procedure on the master. >>>>> In frame 5, print *entry >>>>> >>>> (gdb) frame 5 >>>> #5 0x080f39f4 in syncrepl_entry (si=0x8fdebf8, op=0x380acf0, >>>> entry=0x54eba5f4, modlist=0x380aaf4, syncstate=2, syncUUID=0x380ab50, >>>> syncCSN=0x4d3e0388) >>>> at ../../../servers/slapd/syncrepl.c:2278 >>>> 2278 ../../../servers/slapd/syncrepl.c: No such file or directory. >>>> in ../../../servers/slapd/syncrepl.c >>>> (gdb) p *entry >>>> $1 = {e_id = 0, e_name = {bv_len = 0, bv_val = 0x4d3691c8 ""}, e_nname = >>>> {bv_len = 0, bv_val = 0x4d31cff8 ""}, e_attrs = 0x54a371fc, e_ocflags = >>>> 0, e_bv = { >>>> bv_len = 0, bv_val = 0x0}, e_private = 0x0} >>>> >>> Well, that's certainly odd looking. Did you have SYNC logging at the time, do >>> you have the log messages from just before this occurred? >>> >>> Can you print out the a_desc and values of all of the attributes in >>> entry->e_attrs ? >> Howard, >> >> what's odd is that, as far as I understand, entry->e_name is set after >> op->o_req_dn, inside syncrepl_message_to_entry(), which is just >> extracted and normalized from the message. What could perhaps happen is >> that dnPrettyNormal() fails (in fact its result is not checked). I'm >> adding a check and some logging, just in case. > > Good idea. > > Also, I think the original LDAP message should still be intact, in frame 6 > "msg" - perhaps you can extract the DN that was actually received and figure > out why it had a problem. ... except for '\0' at the end of each berval... Luca, make sure you look at the full contents of the message (I fear one of the values is a CRL, which could be relatively large). p.
Date: Thu, 07 May 2009 15:36:28 +0200 From: Luca Scamoni <luca.scamoni@sys-net.it> To: hyc@symas.com CC: openldap-its@openldap.org Subject: Re: (ITS#6096) 2.4.16 replica segfault
hyc@symas.com ha scritto: > Can you print out the a_desc and values of all of the attributes in > entry->e_attrs ? > Don't know if this is the "right" way to do it, but here it is... (gdb) p *(entry->e_attrs->a_desc) $10 = {ad_next = 0x0, ad_type = 0x8f08d70, ad_cname = {bv_len = 9, bv_val = 0x8f08cb0 "entryUUID"}, ad_tags = {bv_len = 0, bv_val = 0x0}, ad_flags = 0} (gdb) p *(entry->e_attrs->a_vals) $11 = {bv_len = 36, bv_val = 0x4d36f498 "6a0ba116-b291-11da-8006-87f6e679f1bd"} (gdb) p *(entry->e_attrs->a_nvals) $12 = {bv_len = 16, bv_val = 0x45631550 "j\v..\026..\221\021..\200\006\207....y...."} p (struct Attribute) *0x54a2de9c $13 = {a_desc = 0x8f07d88, a_vals = 0x4d3e1dd0, a_nvals = 0x4d3e1dd0, a_numvals = 2, a_flags = 0, a_next = 0x54a3c41c} p (AttributeDescription) *0x8f07d88 $14 = {ad_next = 0x0, ad_type = 0x8f07cb0, ad_cname = {bv_len = 11, bv_val = 0x8f07c28 "objectClass"}, ad_tags = {bv_len = 0, bv_val = 0x0}, ad_flags = 0} (gdb) p (struct berval) *0x4d3e1dd0 $15 = {bv_len = 20, bv_val = 0x4d3f84d8 "cRLDistributionPoint"} (gdb) p (struct Attribute) *0x54a3c41c $16 = {a_desc = 0x8f0ce90, a_vals = 0x45665718, a_nvals = 0x4d366d98, a_numvals = 1, a_flags = 0, a_next = 0x54a41ec4} (gdb) p (AttributeDescription) *0x8f0ce90 $17 = {ad_next = 0x0, ad_type = 0x8f0cd70, ad_cname = {bv_len = 2, bv_val = 0x8f0ccf8 "cn"}, ad_tags = {bv_len = 0, bv_val = 0x0}, ad_flags = 0} (gdb) p (struct berval) *0x45665718 $18 = {bv_len = 5, bv_val = 0x45662320 "CRL19"} (gdb) p (struct berval) *0x4d366d98 $19 = {bv_len = 5, bv_val = 0x45666fc8 "crl19"} (gdb) p (struct Attribute) *0x54a41ec4 $20 = {a_desc = 0x8f08508, a_vals = 0x4d366d80, a_nvals = 0x4d3f9cf8, a_numvals = 1, a_flags = 0, a_next = 0x54a47d44} (gdb) p (AttributeDescription) *0x8f08508 $21 = {ad_next = 0x0, ad_type = 0x8f08528, ad_cname = {bv_len = 12, bv_val = 0x8f08460 "creatorsName"}, ad_tags = {bv_len = 0, bv_val = 0x0}, ad_flags = 0} (gdb) p (struct berval) *0x4d366d80 $22 = {bv_len = 20, bv_val = 0x4d301108 "cn=directory manager"} (gdb) p (struct berval) *0x4d3f9cf8 $23 = {bv_len = 20, bv_val = 0x45603f68 "cn=directory manager"} (gdb) p (struct Attribute) *0x54a47d44 $24 = {a_desc = 0x8f08178, a_vals = 0x45631538, a_nvals = 0x4d31b2b8, a_numvals = 1, a_flags = 0, a_next = 0x54a47f3c} (gdb) p (AttributeDescription) *0x8f08178 $25 = {ad_next = 0x0, ad_type = 0x8f08198, ad_cname = {bv_len = 15, bv_val = 0x8f08098 "createTimestamp"}, ad_tags = {bv_len = 0, bv_val = 0x0}, ad_flags = 0} $26 = {a_desc = 0xf, a_vals = 0x4d36d8c0, a_nvals = 0x0, a_numvals = 0, a_flags = 0, a_next = 0x11} (gdb) p (struct berval) *0x45631538 $27 = {bv_len = 15, bv_val = 0x4d31b2a0 "20060313130120Z"} (gdb) p (struct berval) *0x4d31b2b8 $28 = {bv_len = 15, bv_val = 0x4d36d8c0 "20060313130120Z"} (gdb) p (struct Attribute) *0x54a47f3c $29 = {a_desc = 0x8f07f10, a_vals = 0x4d36d8d8, a_nvals = 0x4d36d8d8, a_numvals = 1, a_flags = 0, a_next = 0x54a39c74} (gdb) p (AttributeDescription) *0x8f07f10 $30 = {ad_next = 0x0, ad_type = 0x8f07f30, ad_cname = {bv_len = 21, bv_val = 0x8f07e50 "structuralObjectClass"}, ad_tags = {bv_len = 0, bv_val = 0x0}, ad_flags = 0} (gdb) p (struct berval) *0x4d36d8d8 $31 = {bv_len = 20, bv_val = 0x4d3650a0 "cRLDistributionPoint"} (gdb) p (struct berval) *0x4d36d8d8 $32 = {bv_len = 20, bv_val = 0x4d3650a0 "cRLDistributionPoint"} (gdb) p (struct Attribute) *0x54a39c74 $33 = {a_desc = 0x905aa98, a_vals = 0x4d3650c0, a_nvals = 0x4d3650c0, a_numvals = 1, a_flags = 0, a_next = 0x54a38d8c} (gdb) p (AttributeDescription) *0x905aa98 $34 = {ad_next = 0x0, ad_type = 0x8f24f48, ad_cname = {bv_len = 32, bv_val = 0x905aab4 "certificateRevocationList;binary"}, ad_tags = {bv_len = 0, bv_val = 0x6769666e ""}, ad_flags = 1} (gdb) p (struct berval) *0x4d3650c0 $35 = {bv_len = 558, bv_val = 0x4d303a58 "0\202\002*0\202\001\022\002\001\0010\r\006\t*\206H\206..\r\001\001\005\005"} (gdb) p (struct Attribute) *0x54a38d8c $36 = {a_desc = 0x8f08f10, a_vals = 0x4d34c588, a_nvals = 0x4565ce58, a_numvals = 1, a_flags = 0, a_next = 0x54a38ce4} (gdb) p (AttributeDescription) *0x8f08f10 $37 = {ad_next = 0x0, ad_type = 0x8f08f30, ad_cname = {bv_len = 8, bv_val = 0x8f08e50 "entryCSN"}, ad_tags = {bv_len = 0, bv_val = 0x0}, ad_flags = 0} (gdb) p (struct berval) *0x4d34c588 $38 = {bv_len = 40, bv_val = 0x4d303c90 "20090507070014.234380Z#000000#000#000000"} (gdb) p (struct berval) *0x4565ce58 $39 = {bv_len = 40, bv_val = 0x4d3fb340 "20090507070014.234380Z#000000#000#000000"} (gdb) p (struct Attribute) *0x54a38ce4 $40 = {a_desc = 0x8f086b8, a_vals = 0x4565ce70, a_nvals = 0x456197b0, a_numvals = 1, a_flags = 0, a_next = 0x54a480a4} (gdb) p (AttributeDescription) *0x8f086b8 $41 = {ad_next = 0x0, ad_type = 0x8f086d8, ad_cname = {bv_len = 13, bv_val = 0x8f08608 "modifiersName"}, ad_tags = {bv_len = 0, bv_val = 0x0}, ad_flags = 0} (gdb) p (struct berval) *0x4565ce70 $42 = {bv_len = 34, bv_val = 0x456076d8 "cn=manager,dc=a,dc=prod,dc=actalis"} (gdb) p (struct berval) *0
Date: Thu, 07 May 2009 06:48:23 -0700 From: Howard Chu <hyc@symas.com> To: Luca Scamoni <luca.scamoni@sys-net.it> CC: openldap-its@openldap.org Subject: Re: (ITS#6096) 2.4.16 replica segfault
Luca Scamoni wrote: > hyc@symas.com ha scritto: >> Can you print out the a_desc and values of all of the attributes in >> entry->e_attrs ? >> > Don't know if this is the "right" way to do it, but here it is... Everything looks normal here. (I generally would do: p *entry->e_attrs p *entry->e_attrs->a_desc p *entry->e_attrs->a_vals p *entry->e_attrs->a_next p *entry->e_attrs->a_next->a_desc p *entry->e_attrs->a_next->a_vals ... Obviously it's easier with command history/editing...) Judging from the provider log, there's nothing special about the DN either. Can't imagine that it would get corrupted in the consumer, but we'll need to see what turns up in the LDAPMessage. > (gdb) p *(entry->e_attrs->a_desc) > $10 = {ad_next = 0x0, ad_type = 0x8f08d70, ad_cname = {bv_len = 9, > bv_val = 0x8f08cb0 "entryUUID"}, ad_tags = {bv_len = 0, bv_val = 0x0}, > ad_flags = 0} > (gdb) p *(entry->e_attrs->a_vals) > $11 = {bv_len = 36, bv_val = 0x4d36f498 > "6a0ba116-b291-11da-8006-87f6e679f1bd"} > (gdb) p *(entry->e_attrs->a_nvals) > $12 = {bv_len = 16, bv_val = 0x45631550 > "j\v..\026..\221\021..\200\006\207....y...."} > p (struct Attribute) *0x54a2de9c > $13 = {a_desc = 0x8f07d88, a_vals = 0x4d3e1dd0, a_nvals = 0x4d3e1dd0, > a_numvals = 2, a_flags = 0, a_next = 0x54a3c41c} > p (AttributeDescription) *0x8f07d88 > $14 = {ad_next = 0x0, ad_type = 0x8f07cb0, ad_cname = {bv_len = 11, > bv_val = 0x8f07c28 "objectClass"}, ad_tags = {bv_len = 0, bv_val = 0x0}, > ad_flags = 0} > (gdb) p (struct berval) *0x4d3e1dd0 > $15 = {bv_len = 20, bv_val = 0x4d3f84d8 "cRLDistributionPoint"} > (gdb) p (struct Attribute) *0x54a3c41c > $16 = {a_desc = 0x8f0ce90, a_vals = 0x45665718, a_nvals = 0x4d366d98, > a_numvals = 1, a_flags = 0, a_next = 0x54a41ec4} > (gdb) p (AttributeDescription) *0x8f0ce90 > $17 = {ad_next = 0x0, ad_type = 0x8f0cd70, ad_cname = {bv_len = 2, > bv_val = 0x8f0ccf8 "cn"}, ad_tags = {bv_len = 0, bv_val = 0x0}, ad_flags > = 0} > (gdb) p (struct berval) *0x45665718 > $18 = {bv_len = 5, bv_val = 0x45662320 "CRL19"} > (gdb) p (struct berval) *0x4d366d98 > $19 = {bv_len = 5, bv_val = 0x45666fc8 "crl19"} -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Date: Thu, 07 May 2009 16:02:24 +0200 From: Luca Scamoni <luca.scamoni@sys-net.it> To: Howard Chu <hyc@symas.com> CC: openldap-its@openldap.org Subject: Re: (ITS#6096) 2.4.16 replica segfault
Howard Chu ha scritto: > Luca Scamoni wrote: >> hyc@symas.com ha scritto: >>> Can you print out the a_desc and values of all of the attributes in >>> entry->e_attrs ? >>> >> Don't know if this is the "right" way to do it, but here it is... > > Everything looks normal here. > > (I generally would do: > p *entry->e_attrs > p *entry->e_attrs->a_desc > p *entry->e_attrs->a_vals > p *entry->e_attrs->a_next > p *entry->e_attrs->a_next->a_desc > p *entry->e_attrs->a_next->a_vals > ... > > Obviously it's easier with command history/editing...) > > Judging from the provider log, there's nothing special about the DN > either. Can't imagine that it would get corrupted in the consumer, but > we'll need to see what turns up in the LDAPMessage. > This one? (gdb) frame 6 #6 0x080eebcf in do_syncrep2 (op=0x380acf0, si=0x8fdebf8) at ../../../servers/slapd/syncrepl.c:892 892 ../../../servers/slapd/syncrepl.c: No such file or directory. in ../../../servers/slapd/syncrepl.c (gdb) p *msg $1 = {lm_msgid = 2, lm_msgtype = 100, lm_ber = 0x4d32d5d0, lm_chain = 0x0, lm_chain_tail = 0x4d3741f0, lm_next = 0x0, lm_time = 0} (gdb) p *msg->lm_ber $2 = {ber_opts = {lbo_valid = 2, lbo_options = 1, lbo_debug = 0}, ber_tag = 100, ber_len = 1194, ber_usertag = 0, ber_buf = 0x4d32c958 "\002\001\002d\202\0046\004", ber_ptr = 0x4d32c95b "d\202\0046\004", ber_end = 0x4d32ce02 "", ber_sos = 0x0, ber_rwptr = 0x0, ber_memctx = 0x0} Ing. Luca Scamoni Responsabile Ricerca e Sviluppo SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 0382 573859 (137) Fax: +39 0382 476497 Email: luca.scamoni@sys-net.it -----------------------------------
Date: Fri, 08 May 2009 16:33:49 +0200 From: Luca Scamoni <luca.scamoni@sys-net.it> To: hyc@symas.com CC: openldap-its@openldap.org Subject: Re: (ITS#6096) 2.4.16 replica segfault
hyc@symas.com ha scritto: > > Good idea. > > Also, I think the original LDAP message should still be intact, in frame 6 > "msg" - perhaps you can extract the DN that was actually received and figure > out why it had a problem. > This is the msg from frame 6 (gdb) p msg->lm_ber->ber_buf[0]@100 $4 = "\002\001\002d\202\0046\004\000\000\202\004003\004\tentryUUID\000&\004$6a0ba116-b291-11da-8006-87f6e679f1bd0*\004\vobjectClass\000\033\004\024cRLDistribution" (gdb) p msg->lm_ber->ber_buf[100]@100 $5 = "Point\004\003top0\r\004\002cn\000\a\004\005CRL190&\004\fcreatorsName\000\026\004\024cn=directory manager0$\004\017createTimestamp\000\021\004\017200603131301" (gdb) p msg->lm_ber->ber_buf[200]@100 $6 = "20Z0/\004\025structuralObjectClass\000\026\004\024cRLDistributionPoint0\202\002X\004 certificateRevocationList;binary\000\202\0022\004\202\002.0\202" (gdb) p msg->lm_ber->ber_buf[300]@100 $7 = "\002*0\202\001\022\002\001\0010\r\006\t*\206H\206..\r\001\001\005\005\0000\201\2101\v0\t\006\003U\004\006\023\002IT1\0270\025\006\003U\004\n\023\016Actalis S.p.A.1\"0 \006\003U\004\v\023\031Servizi di certificazion" (gdb) p msg->lm_ber->ber_buf[400]@100 $8 = "e1<0:\006\003U\004\003\0233Regione Siciliana Certification Authority Cittadini\027\r090507070003Z\027\r090508070003Z0\"0 \002\001\025" (gdb) p msg->lm_ber->ber_buf[500]@100 $9 = "\027\r060330073258Z0\f0\n\006\003U\035\025\004\003\n\001\001 10/0\f\006\003U\035\024\004\005\002\003\002\031(0\037\006\003U\035#\004\0300\026\200\024..\232..\027'..\214..\004)i ,x\"..<\226\210E0\r\006\t*\206H\206..\r\001\001\005\005\000\003\202\001\001" (gdb) p msg->lm_ber->ber_buf[600]@100 $10 = "E6......\023t\"..a\235Z....@(..(\222..G..'R!\234\\..\027..z..~l..z\032........q..\202::c......#\n2......+A..........#..^..\003..\030\235`..\032\027......v..O..\230..\233..\004K\201&\\r]..\233D..>]R" (gdb) p msg->lm_ber->ber_buf[700]@100 $11 = "4\213\t\a>X^..\224..]..\034#e..Q\215......zb....f..PC..\202....Z\177\024....%......8\022....<\234..Z..k\213..\b..Q....Q\205\232....\n3\212v\no..e+U\034..\212\207\215\231+\2374......N....\222\000..h..Y..+..8-" (gdb) p msg->lm_ber->ber_buf[800]@100 $12 = "....\234\214..8..a\177I....k..\001N\217~,..>..\217\1771......x..\206..\214..O5..%5..:..\206....\235..?\n..V....W\"\21606\004\bentryCSN\000*\004(20090507070014.234380Z#00000" (gdb) p msg->lm_ber->ber_buf[900]@100 $13 = "0#000#00000005\004\rmodifiersName\000$\004\"cn=manager,dc=a,dc=prod,dc=actalis0$\004\017modifyTimestamp\000\021\004\0172009050707" (gdb) p msg->lm_ber->ber_buf[1000]@100 $14 = "0014Z0\r\004\aentryDN\000\002\004\0000#\004\021subschemaSubentry\000\016\004\fcn=Subschema0\032\004\017hasSubordinates\000\a\004\005FALSE k0i\004\0301.3.6.1.4" (gdb) p msg->lm_ber->ber_buf[1100]@100 $15 = ".1.4203.1.9.1.2\004M0K\n\001\002\004\020j\v..\026..\221\021..\200\006\207....y....\0044rid=002,csn=20090507070014.234380Z#000000#000#000000\0000%\000\000" I fear the dn is already lost... :-( Ing. Luca Scamoni Responsabile Ricerca e Sviluppo SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 0382 573859 (137) Fax: +39 0382 476497 Email: luca.scamoni@sys-net.it -----------------------------------
Date: Fri, 08 May 2009 16:49:13 +0200 From: Pierangelo Masarati <masarati@aero.polimi.it> To: luca.scamoni@sys-net.it CC: openldap-its@openldap.org Subject: Re: (ITS#6096) 2.4.16 replica segfault
luca.scamoni@sys-net.it wrote: > hyc@symas.com ha scritto: >> Good idea. >> >> Also, I think the original LDAP message should still be intact, in frame 6 >> "msg" - perhaps you can extract the DN that was actually received and figure >> out why it had a problem. >> > This is the msg from frame 6 > > (gdb) p msg->lm_ber->ber_buf[0]@100 > $4 = > "\002\001\002d\202\0046\004\000\000\202\004003\004\tentryUUID\000&\004$6a0ba116-b291-11da-8006-87f6e679f1bd0*\004\vobjectClass\000\033\004\024cRLDistribution" The second '\000' after '\004' (octet string) was probably put by ber_scanf("m") to terminate the string, but the first one seems to be the length of the octet string! So apparently the message actually contained an empty DN, which makes little sense. Could the error be at the provider's side? p. > (gdb) p msg->lm_ber->ber_buf[100]@100 > $5 = > "Point\004\003top0\r\004\002cn\000\a\004\005CRL190&\004\fcreatorsName\000\026\004\024cn=directory > manager0$\004\017createTimestamp\000\021\004\017200603131301" > (gdb) p msg->lm_ber->ber_buf[200]@100 > $6 = > "20Z0/\004\025structuralObjectClass\000\026\004\024cRLDistributionPoint0\202\002X\004 > certificateRevocationList;binary\000\202\0022\004\202\002.0\202" > (gdb) p msg->lm_ber->ber_buf[300]@100 > $7 = > "\002*0\202\001\022\002\001\0010\r\006\t*\206H\206..\r\001\001\005\005\0000\201\2101\v0\t\006\003U\004\006\023\002IT1\0270\025\006\003U\004\n\023\016Actalis > S.p.A.1\"0 \006\003U\004\v\023\031Servizi di certificazion" > (gdb) p msg->lm_ber->ber_buf[400]@100 > $8 = "e1<0:\006\003U\004\003\0233Regione Siciliana Certification > Authority Cittadini\027\r090507070003Z\027\r090508070003Z0\"0 \002\001\025" > (gdb) p msg->lm_ber->ber_buf[500]@100 > $9 = > "\027\r060330073258Z0\f0\n\006\003U\035\025\004\003\n\001\001 10/0\f\006\003U\035\024\004\005\002\003\002\031(0\037\006\003U\035#\004\0300\026\200\024..\232..\027'..\214..\004)i > ,x\"..<\226\210E0\r\006\t*\206H\206..\r\001\001\005\005\000\003\202\001\001" > (gdb) p msg->lm_ber->ber_buf[600]@100 > $10 = > "E6......\023t\"..a\235Z....@(..(\222..G..'R!\234\\..\027..z..~l..z\032........q..\202::c......#\n2......+A..........#..^..\003..\030\235`..\032\027......v..O..\230..\233..\004K\201&\\r]..\233D..>]R" > (gdb) p msg->lm_ber->ber_buf[700]@100 > $11 = > "4\213\t\a>X^..\224..]..\034#e..Q\215......zb....f..PC..\202....Z\177\024....%......8\022....<\234..Z..k\213..\b..Q....Q\205\232....\n3\212v\no..e+U\034..\212\207\215\231+\2374......N....\222\000..h..Y..+..8-" > (gdb) p msg->lm_ber->ber_buf[800]@100 > $12 = > ". ..\234\214..8..a\177I....k..\001N\217~,..>..\217\1771......x..\206..\214..O5..%5..:..\206....\235..?\n..V....W\"\21606\004\bentryCSN\000*\004(20090507070014.234380Z#00000" > (gdb) p msg->lm_ber->ber_buf[900]@100 > $13 = > "0#000#00000005\004\rmodifiersName\000$\004\"cn=manager,dc=a,dc=prod,dc=actalis0$\004\017modifyTimestamp\000\021\004\0172009050707" > (gdb) p msg->lm_ber->ber_buf[1000]@100 > $14 = > "0014Z0\r\004\aentryDN\000\002\004\0000#\004\021subschemaSubentry\000\016\004\fcn=Subschema0\032\004\017hasSubordinates\000\a\004\005FALSE k0i\004\0301.3.6.1.4" > (gdb) p msg->lm_ber->ber_buf[1100]@100 > $15 = > ".1.4203.1.9.1.2\004M0K\n\001\002\004\020j\v..\026..\221\021..\200\006\207....y....\0044rid=002,csn=20090507070014.234380Z#000000#000#000000\0000%\000\000" > > I fear the dn is already lost... :-( > > > Ing. Luca Scamoni > Responsabile Ricerca e Sviluppo > > SysNet s.r.l. > via Dossi, 8 - 27100 Pavia - ITALIA > http://www.sys-net.it > ----------------------------------- > Office: +39 0382 573859 (137) > Fax: +39 0382 476497 > Email: luca.scamoni@sys-net.it > ----------------------------------- > > >
Date: Sat, 09 May 2009 01:51:17 -0700 From: Howard Chu <hyc@symas.com> To: masarati@aero.polimi.it CC: openldap-its@openldap.org Subject: Re: (ITS#6096) 2.4.16 replica segfault
masarati@aero.polimi.it wrote: > luca.scamoni@sys-net.it wrote: >> hyc@symas.com ha scritto: >>> Good idea. >>> >>> Also, I think the original LDAP message should still be intact, in frame 6 >>> "msg" - perhaps you can extract the DN that was actually received and figure >>> out why it had a problem. >>> >> This is the msg from frame 6 >> >> (gdb) p msg->lm_ber->ber_buf[0]@100 >> $4 = >> "\002\001\002d\202\0046\004\000\000\202\004003\004\tentryUUID\000&\004$6a0ba116-b291-11da-8006-87f6e679f1bd0*\004\vobjectClass\000\033\004\024cRLDistribution" > > The second '\000' after '\004' (octet string) was probably put by > ber_scanf("m") to terminate the string, but the first one seems to be > the length of the octet string! So apparently the message actually > contained an empty DN, which makes little sense. Could the error be at > the provider's side? It certainly looks that way. What version is the provider, what version is the consumer? You only said there were mixed versions before, you never specified which was which. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Date: Sat, 09 May 2009 13:13:04 +0200 From: Luca Scamoni <luca.scamoni@sys-net.it> To: hyc@symas.com CC: openldap-its@openldap.org Subject: Re: (ITS#6096) 2.4.16 replica segfault
hyc@symas.com ha scritto: > > It certainly looks that way. What version is the provider, what version is the > consumer? You only said there were mixed versions before, you never specified > which was which. > Both are same version: 2.4.16 + patches (looking at RELENG I simply anticipated Quanah in merging from HEAD). Ing. Luca Scamoni Responsabile Ricerca e Sviluppo SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 0382 573859 (137) Fax: +39 0382 476497 Email: luca.scamoni@sys-net.it -----------------------------------
______________ © Copyright 2013, OpenLDAP Foundation, info@OpenLDAP.org
