[Date Prev][Date Next]
Re: Kurt's reply (Was: change submission)
comming back to your bug-report.
I do not see what the problem is. ldbm_datum_free() is defined three times
in ldbm.c . Once for Berkeley-DB, once for GDBM (in both cases the dptr
element of the data structure is free´ed as the only action), and once for
NDBM, where it is a simple return. So calling the function with Berkeley
DB will free the memory allocated after a key/data retrieval, or any other
allocation of memeory for that pointer.
However, the free() is unconditional, and some calls to ldbm_datum_free()
were not captured by appropriate tests for non-NULL pointers in
slapd/tools/ldbmcat, ldbmtest and sizecount. I have fixed that in my local
copy of -devel. As soon as Kurt has build the release, I could commit the
changes. Nevertheless, I had no problem with the umich code as is for more
than half a year in production, both in DB 1.85 compatibility and DB 2.x
mode, as well as the OpenLDAP code during some inmitial tests.
BUT, we MAY have a problem with ldbm_datum_free(), if someone uses flag
DB_DBT_USERMEM with DB 2.x, avoiding memory allocation by DB itself,
instead using a self-provided storage (pointed to in (Datum).dptr, with
size in (Datum).ulen). If this storage is a static buffer, free() indeed
may fail. However, In the DB 2.x code I provided in ldbm.c, DB_DBT_MALLOC
together with a self-provided ldbm_malloc() function is used.
On Tue, 29 Dec 1998, Hallvard B Furuseth wrote:
> Date: Tue, 29 Dec 1998 09:28:27 +0100 (MET)
> From: Hallvard B Furuseth <email@example.com>
> To: Kurt Spanier <firstname.lastname@example.org>
> Cc: email@example.com
> Subject: Re: Kurt's reply (Was: change submission)
> Kurt Spanier writes:
> > I will look for integration of Sleepycat´s latest (BETA) code of Berkeley
> > DB (i.e., 2.6.4).
> Maybe you could pick up this report too?
> Hallvard B Furuseth writes:
> > From: Hallvard B Furuseth <firstname.lastname@example.org>
> > To: email@example.com
> > Subject: malloc bugs
> > Date: Mon, 23 Nov 1998 08:26:35 +0100 (MET)
> > Message-ID: <HBF.firstname.lastname@example.org>
> > (...)
> > Somebody who knows db-1.85 and Sleepycat should check this:
> > Files: include/ldbm.h, libraries/libldbm/ldbm.c.
> > All ldbm functions except some versions of ldbm_<first/next>_key
> > appear to return newly allocated data which the caller should free.
> > (If the underlying database doesn't malloc the data, then ldbm does it
> > for you - and ldbm_datum_free reflects whether or not the underlying
> > service does malloc). So, ldbm_datum_free() should probably only be
> > used on data from ldbm_<first/next>key; other data should be plain
> > free()d. Today, ldbm_datum_free is used on all kinds of Datum values.
Kurt Spanier, Zentrum fuer Datenverarbeitung, +49 7071 29-70334
Universitaet Tuebingen, DE
email@example.com +49 7071 29-5912
Dr. Kurt Spanier, Zentrum fuer Datenverarbeitung,
Universitaet Tuebingen, Waechterstrasse 76, D-72074 Tuebingen
finger "Kurt Spanier"@x500.uni-tuebingen.de