RE: Thread-local malloc discussion summary

[Luke Howard <lukeh@PADL.COM>]

>> The only way we can fix this without breaking API signatures is to
>> change the semantics of the computed attribute search rewriter so
>> that the front-end, rather than the plugin, is responsible for
>> freeing the original search filter. Obviously this is problematic
>> because only one plugin can rewrite the search filter without
>> leaking memory.
>>
>> Another alternative would be to disable the thread-local malloc
>> entirely if SLAPI was enabled. We would prefer this. Comments?
>
>I've modified ch_free (and ch_realloc) to test the pointer argument and pass
>it off to sl_free (and sl_realloc) if necessary. This gives some freedom from
>mismatch problems, and with the new ldap_pvt_thread_pool_context() function
>this solution doesn't cost much. So I'm going to revert the SLAPI filter
>patches to slapd/search.c, I think it should be safe.

So, my plugin resets the filter to one that is slapi_ch_malloc()'d, this
is set to op->ors_filter in doSearchRewriteFNs(), and eventually this 
filter is freed with filter_free_x().

filter_free_x() then calls op->o_tmpfree(), on memory that has been 
allocated using ch_malloc()... things will blow up, surely?

You could make slapi_ch_malloc() use sl_malloc().

-- Luke
--
Luke Howard | PADL Software Pty Ltd | www.padl.com