apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From r..@covalent.net
Subject Re: cvs commit: apr-util/src/dbm apr_dbm.c
Date Sat, 09 Dec 2000 17:35:26 GMT

> > > > note absurdity of apr_dbm_freedatum in a pool-managed implementation
> > > 
> > > The returned data is not always located in a pool. Specifically, GDBM's
> > > return data is malloc'd. SDBM's return data is from a shared block of
> > > memory. [hmm. sdbm's behavior should be clarified in the docs]
> > 
> > Of course not, but it should be.
> No way. No no no. You could pull several hundred Kbytes of data from a GDBM
> record. We cannot and should not copy that into a pool. Take a page from
> Ryan's book and attach a cleanup to the pool to free() the block at pool
> cleanup time.
> Hell, we use the cleanup function (rather than pool allocation) all over the
> place in the bucket code.
> There is no reason to take the hit of a memory copy when a simple
> registration is sufficient.

Actually, that's not true.  I have added SDBM support to a couple modules
recently, and while everything just works on Linux and FrreBSD, it blows
up on all Solaris machines.  Basically, on solaris just referencing the
data in a datum returned by sdbm_fetch will cause a SIGBUS.  This is
easily reproducable, and is solved by memcpy'ing the data before trying to
reference it.

Ryan Bloom                        	rbb@apache.org
406 29th St.
San Francisco, CA 94131

View raw message