https://bugs.openldap.org/show_bug.cgi?id=10448
--- Comment #2 from KY kangyang126@gmail.com --- Thank you for taking the time to review this report. I appreciate your insight about tmpmemctx allocations—it helped me dig deeper into the slab allocator behavior.
You're absolutely right that sync_control is allocated via o_tmpcalloc with a valid tmpmemctx. After further investigation, I believe this is still a valid issue, though the root cause is more nuanced than my initial report suggested.
The core issue: op->o_controls[] entries are never explicitly freed.
While slap_free_ctrls() properly frees op->o_ctrls[] (the LDAPControl array), the overlay-specific data stored in op->o_controls[] has no corresponding cleanup path. The code relies on implicit slab reclamation.
Why does this become a leak?
This works under normal conditions. However, when the slab exhausts (complex requests with large filters, many attributes, or multiple controls), sl_malloc.c:385-390 falls back to ch_malloc(). Slab reset doesn't reclaim these overflow allocations—only explicit slap_sl_free() does.
Debug trace confirming the scenario:
DEBUG syncprov_parseCtrl: o_tmpmemctx=0x7badaf3f84a0 (valid, non-NULL) DEBUG sl_malloc: SLAB EXHAUSTED! size=80 ... avail=8 The proposed fix (cleanup callback) ensures explicit cleanup via op->o_tmpfree(), which handles both slab and overflow allocations correctly.
I hope this clarifies the issue. Please let me know if you have further questions or would like additional details.