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(a)symas.com> wrote:
Sean Burford wrote:
> On Tue, May 5, 2009 at 12:52 PM, Howard Chu <hyc(a)symas.com
> <mailto:firstname.lastname@example.org>> 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
> 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
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
May 6 12:10:27 ldapserver slapd: 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.