https://bugs.openldap.org/show_bug.cgi?id=10290
--- Comment #5 from Ondřej Kuzník ondra@mistotebe.net --- On Mon, Dec 09, 2024 at 06:41:00PM +0000, openldap-its@openldap.org wrote:
On Mon, Dec 09, 2024 at 02:34:43PM +0000, openldap-its@openldap.org wrote:
ch_free() will correctly free either.
On the contrary, objects allocated from inside op->o_tmpmemctx are not safe to free by anyone else (and ch_malloc()'d pointers can be freed by anyone so long as they share the same free() fallback). And slap_mods_free can't use it because it's not been passed enough information.
NONSENSE.
https://git.openldap.org/openldap/openldap/-/blob/master/servers/slapd/ch_ma...
Ok, that's not even *hinted at* anywhere else. And it took a while to trace down the mechanisms of whether the thread context might be set correctly when needed in this case because syncrepl manages its own Operations.
Regardless, syncrepl_op_modify created modifications cannot be safely passed to slap_mods_free (I tried that), it might be that the `#define free ch_free` in proto-slap.h somehow doesn't actually work, or down to something I did, I didn't investigate further. And even if it was all fine and something else I did was at fault, rwm still needs to call `slap_mods_free( x, 1 )` which definitely isn't compatible with the ones coming from syncrepl_op_modify.