On Thu, Mar 30, 2017 at 12:30:09PM -0700, Paul B. Henson wrote:

...

From: Ond=C5=99ej Kuzn=C3=ADk Sent: Monday, March 27, 2017 8:10 AM =20 I've had a look whether I could reproduce the issue somehow and there =

is

...

a potential crasher if the accesslog entry contained "reqmod: eduPersonAffiliation:+". Can you confirm whether you have entries like this in your logdb?

=20 There aren't currently any entries like that in the log, although the l=

ast

crash was a week or two ago. I will check again right after the next cr=

ash.

However, here is one of the log entries that appeared to correlate with=

what

was being processed in the backtrace of one of the crashes: =20 [...] =20 And it does not appear to have that signature.

Hi Paul, "modify: replace" entries should result in modify_replace_values being called instead, where modify_add_values is called when the mod is LDAP_MOD_ADD (set up from reqMod values starting "attr:+").

Not sure if there is a way to reset the LDAPResult *msg in syncrepl_message_to_op to retrieve the entry from there but that would be the place I'd look when you get a another crash.

Regards,

--=20 Ond=C5=99ej Kuzn=C3=ADk Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP