OpenLDAP
Up to top level
Build   Contrib   Development   Documentation   Historical   Incoming   Software Bugs   Software Enhancements   Web  

Logged in as guest

Viewing Incoming/6096
Full headers

From: luca@openldap.org
Subject: 2.4.16 replica segfault
Compose comment
Download message
State:
0 replies:
14 followups: 1 2 3 4 5 6 7 8 9 10 11 12 13 14

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

Message of length 16371 truncated

Followup 1

Download message
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

Message of length 18174 truncated


Followup 2

Download message
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
-----------------------------------



Followup 3

Download message
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/



Followup 4

Download message
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:

Message of length 12303 truncated


Followup 5

Download message
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.



Followup 6

Download message
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/



Followup 7

Download message
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.



Followup 8

Download message
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

Message of length 5920 truncated


Followup 9

Download message
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/



Followup 10

Download message
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
-----------------------------------



Followup 11

Download message
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
-----------------------------------



Followup 12

Download message
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
> -----------------------------------
> 
> 
> 



Followup 13

Download message
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/



Followup 14

Download message
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
-----------------------------------


Up to top level
Build   Contrib   Development   Documentation   Historical   Incoming   Software Bugs   Software Enhancements   Web  

Logged in as guest


The OpenLDAP Issue Tracking System uses a hacked version of JitterBug

______________
© Copyright 2013, OpenLDAP Foundation, info@OpenLDAP.org