Re: 2.4.44 + ITS 8432 patch segfault in modify_add_values

["Paul B. Henson" <henson@acm.org>]

On Thu, Feb 16, 2017 at 03:53:40PM -0800, Quanah Gibson-Mount wrote:

> It appears to be crashing while writing the change to the accesslog 
> database.  It's odd that the value for the attribute is NULL.  Do we know 
> for sure what the client doing the write op to the server is sending?

The code is in perl, and looks like this:

	$entry->replace(eduPersonAffiliation => \@eduPersonAffiliation);

In this case, the array @eduPersonAffiliation is empty, effectively
deleting the attribute. I'm not 100% sure what this generates on the
wire, I'd have to debug it. I can say it's the same code that's been
running for a decade or so with no issues.

> Yeah, so this is the operation that actually failed... It'd be interesting 
> to know if it succeeded in the primary DB, but failed when writing to the 
> accesslog DB

I already reran that operation to fix the expiration, but the next time
it crashes I'll take a look at the primary and secondaries first to see
if they're out of sync.

> Hm, so I guess my question would be is it doing the op like this:

Hmm, the expiration code when removing an expiration looks like:

	$entry->delete('cppEduPersonExpiration');

So it should be a delete on the wire for removing the attribute. You
think it crashed on the expiration operating, even though the backtrace
shows the segfault having the eduPersonAffiliation accesslog reqStart
id?

> dn: ...
> changetype: modify
> replace: csupomonaEduPersonExpiration
> csupomonaEduPersonExpiration:
> 
> Or is it doing it like this:
> 
> dn: ...
> changetype: modify
> delete: csupomonaEduPersonExpiration
> 
> Because the NULL value seems to imply the former.