[Date Prev][Date Next] [Chronological] [Thread] [Top]

RE: (ITS#8609) segfault in mods.c - modify_add_values

> From: Ond=F8ej Kuzn=EDk
> Sent: Monday, March 27, 2017 8:10 AM
> I've had a look whether I could reproduce the issue somehow and there =
> a potential crasher if the accesslog entry contained "reqmod:
> eduPersonAffiliation:+". Can you confirm whether you have entries like
> this in your logdb?

There aren't currently any entries like that in the log, although the =
crash was a week or two ago. I will check again right after the next =
However, here is one of the log entries that appeared to correlate with =
was being processed in the backtrace of one of the crashes:

dn: reqStart=3D20170214120013.000001Z,cn=3Daccesslog

objectClass: auditModify

structuralObjectClass: auditModify

reqStart: 20170214120013.000001Z

reqEnd: 20170214120013.000002Z

reqType: modify

reqSession: 37859

reqAuthzID: cn=3Didmgmt,ou=3Duser,ou=3Dservice,dc=3Dcsupomona,dc=3Dedu

reqDN: uid=3Dvntruong,ou=3Duser,dc=3Dcsupomona,dc=3Dedu

reqResult: 0

reqMod: eduPersonAffiliation:=3D

reqMod: eduPersonPrimaryAffiliation:=3D

reqMod: csupomonaEduPersonAffiliation:=3D

reqMod: entryCSN:=3D 20170214120013.628665Z#000000#000#000000

reqMod: modifiersName:=3D =

reqMod: modifyTimestamp:=3D 20170214120013Z

reqEntryUUID: bd5ba51c-7a1b-4bdb-8bf3-fe90552f5909

entryCSN: 20170214120013.628665Z#000000#000#000000

entryUUID: 4737c48c-e46e-45a4-ba4b-2eb61540b27b

creatorsName: cn=3Daccesslog

createTimestamp: 20170214120013Z

modifiersName: cn=3Daccesslog

modifyTimestamp: 20170214120013Z

And it does not appear to have that signature.