Re: (ITS#6096) 2.4.16 replica segfault

[masarati@aero.polimi.it]

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.