Hi,

Thanks for the patch, however it looks like the problem is still there.

On Tue, May 5, 2009 at 1:01 PM, Howard Chu <hyc@symas.com> wrote:
Sean Burford wrote:
On Tue, May 5, 2009 at 12:52 PM, Howard Chu <hyc@symas.com
<mailto:hyc@symas.com>> wrote:

   Sean Burford wrote:

       slapcat shows no problems with the entry on the 2.4.16 host.

       Since the database looks fine I wonder if this is just a logging
       issue.
       Should this Debug statement in syncrepl.c actually use
       op->ora_e->e_name.bv_val or some other attribute?


   Looks like a side-effect of ITS#5326. And no, you can't use
   op->ora_e because the backend may free it before returning
   (back-bdb/hdb definitely do).


Do you agree that this looks like a logging issue rather than a database
issue?

Yes, and it is fixed now in HEAD.

I've got three 2.4.16 servers running with the patched add.c from head.  They are replicating from the 2.3.43 server.  One of them logged this today (the other two logged the correct DN) indicating that this is still an issue:

May  6 12:10:27 ldapserver slapd[29037]: syncrepl_message_to_op: rid=100 be_add µ-ESCxxxxxxxxxx,ou=people,dc=example,dc=com (0)

4 characters were lost (uid=) under the µ-ESC.  xxxxxxxxxx masks the uid.

For reference I've attached the patch I used.

--
Thanks,
Sean Burford