--On August 26, 2010 3:44:02 AM +0000 masarati@aero.polimi.it wrote:

...

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (129.72.175.5) Submitted by: ando

REP_CTRLS_MUSTBEFREED is only honored by send_ldap_response(); when response controls are attached to slap_send_search_entry() it is not honored. This does not surface because controls must be malloc'ed on the slab; however, it clearly appears when built with SLAP_NO_SL_MALLOC.

Interesting -- I'm seeing an issue where I can get slapd to consume all available memory on the system by using paged results. It takes a while to do so (depending on how much memory is available), but it's 100% repeatable. The more mixes of paged and non paged results there are with large result sets, the more quickly it happens.

pagedResults only sends a control response with the searchResultDone response, which uses send_ldap_response() and thus clears the controls; moreover, we are talking about few bytes, so I don't think this is the issue. There might be something else related to slab allocation that runs out of slab memory and starts using the heap without freeing it.

The present issue might affect syncrepl, since in that case a control is attached to each entry/intermediate response (afaik).

It might even be intentional; in fact, often when a control is attached to an entry in a searchResultEntry the same control needs to be applied to many entries returned by the same operation. However, in this case we should probably define a specific API for slap_add_ctrls() that does not set the REP_CTRLS_MUSTBEFREED, or something like that.

However, I do not build with SLAP_NO_SL_MALLOC (or at least, not intentionally ;) ).

I occasionally do (you only need to recompile slapd/sl_malloc.c) to trace possible leaks when developing something. Since we make an intensive use of slab mallocs, usual minimal tests with valgrind do not show leaks otherwise.

p.