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.