[Date Prev][Date Next]
Re: Memory leak in liblunicode (ITS#2126)
Fixed in HEAD. Please test.
At 01:59 AM 2002-10-08, email@example.com wrote:
>Full_Name: Timofey B. Nickonov
>Submission from: (NULL) (220.127.116.11)
>slapd process grows permanently when doing massive searches (searches returning
>more than 1000 records).
>I have located where problem comes from, but patch referenced is only
>making opelnlap-2.1.x usable in environments like mine...
>actually liblunicode needs slightly more fixing/redesigning, because
>like "*out = (unsigned long *) realloc(*out, size * sizeof(**out))"
>(ucdata.c from 2.1.4, line 918) can not be considered correct.
>Imagine we have temporary lack of free memory on server. then realloc returns
>NULL _without_freeing_ original *out... we leak that block at this time...
>also, uccanoncompatdecomp (and uccanondecomp, stubbing to it) returns -1
>in several error conditions, but in UTF8bvnormalize we call uccanondecomp
>(ucstr.c from 2.1.4, line 215) without checking return code...
>Anyway, the patch solves main problem - server no longer eats giant amounts
>of memory (at least if solaris libc is patched to -30, but this is a different
>story). debugging performed on version 2.1.4, and patch made against it,
>but i notice that ucstr.c is same in current cvs at moment i write this,
>so i think in 2.1.5 it same too.