[Date Prev][Date Next]
Re: (ITS#6660) paged result searches fail to deallocate memory until slapd shutdown
I may have another data point w.r.t this ITS. I tried replicating
this ITS by: setting up a slapd based on test003-search config plus
100,000 additional entries similar to the other OpenLDAPperson
test entries. running 20+ simultaneous instances of the test003
search tests I see a definite memory growth in the server.
After the test run, according to libumem transaction logs there is about
600k lost memory in leaks (in my case). BUT the leaks are not lost
cache entries or other obvious malloc/free errors.
According to libumem the "leaks" are all 4k - 16k chunks of MMAP
memory allocated to thread stacks associated with threads 11 - 14.
I plan to investigate further. libumem may be reporting that there
are no leaks, but instead that certain threads have significant thread
stack growth under heavy activity. Alternately the threads may be
terminating, resulting in loss of thread stack memory and later
being restarted multiple times resulting in multiple thread stack leaks.
(I am not sure yet which situation is the correct one).
Either situation may produce an unaccounted for memory growth
that may not be exposed via normal debugging malloc techniques
because the memory loss does not seem to be heap related.
At the end of my test threads 11-14 were not terminated. I
believe this may imply significant thread stack growth not 'leakage'.
I will provide more info as I get it. I hope this helps in resolving