https://bugs.openldap.org/show_bug.cgi?id=10448
--- Comment #2 from KY <[email protected]> --- 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. -- You are receiving this mail because: You are on the CC list for the issue.
