[Date Prev][Date Next]
Re: (ITS#4477) Realloc memory leak during temporary memory shortage
slapd(8) traditionally uses ch_realloc() which, instead of returning
NULL on allocation failure, causes slapd(8) to immediately exit
(or abort). Use of SLAP_REALLOC(), a rather new macro, is suppose
to be limited to cases where the code gracefully handles the
allocation failure. Of course, gracefully handling allocation
failures in slapd(8) can be quite difficult if not infeasible.
The bug here is simply that ch_realloc() should have been used
as the code obviously doesn't handle memory allocation failures
gracefully. I committed corrective changes to HEAD.
It is noted that there is a general feature request (see the
todo list) to add more graceful memory allocation handling to
I note that I only reviewed SLAP_REALLOC use. There may be
cases where SLAP_MALLOC and friends are used instead of
ch_malloc and friends.
At 04:10 PM 4/5/2006, firstname.lastname@example.org wrote:
>Full_Name: Sean Burford
>Submission from: (NULL) (220.127.116.11)
>When realloc(ptr, size) fails, ptr is still valid. When used like this:
> ptr = realloc(ptr, size)
>the original valid ptr is discarded if realloc fails. This causes a memory leak
>when there is a temporary memory shortage. This was previously discussed, in
>different circumstances, in issue 2126.
>I'm looking into malloc/realloc fails we seem to be experiencing during
>value_add() for modifications of large groups (servers/slapd/value.c). the
>realloc in value_add() will leak memory as described above. A temporary
>variable should be used to check the return value of realloc.
>I have verified this in CVS openldap HEAD.
>A quick grep reveals v2ref() in servers/slapd/result.c uses the same poor form