hyc(a)symas.com wrote:
> Pierangelo Masarati wrote:
>> hyc(a)symas.com wrote:
>>> Luca Scamoni wrote:
>>>> hyc(a)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.