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