Just noting that one way to reproduce this assert reliably is to bind to an existing entry, through the relay, with an incorrect password.

The important part of the config is:

database mdb suffix dc=example,dc=com [...]

overlay ppolicy

database relay suffix o=example

overlay rwm rwm-suffixmassage o=example dc=example,dc=com

overlay ppolicy

Then, binding through the relay:

$ ldapwhoami -x -D uid=test,o=example -w zzz -e ppolicy

slapd: ppolicy.c:912: ctrls_cleanup: Assertion `rs->sr_ctrls != ((void *)0)' failed.

Same as when someone accidentally attaches two ppolicy instances to a single database. Not totally sure, but I suspect it's wrong here too: I don't see what the ppolicy attached to the relay is supposed to add in this case. I guess in theory they could have different configuration? wrt. e.g. ppolicy_use_lockout, or even pwdLockout/pwdMustChange via a different ppolicy_default...

Wondering if it would make sense for add_passcontrol to look for a ppolicy control already existing on the op, and try to fail gracefully if so, instead of hitting this on the way out.

Binding to the same entry with the correct password...

$ ldapwhoami -x -D uid=test,o=example -w test -e ppolicy

currently hits the same segfault reported in ITS#7966.