[OpenSER-Devel] RFC: memory management in database modules

Henning Westerholt henning.westerholt at 1und1.de
Tue Feb 5 16:38:00 UTC 2008


On Tuesday 05 February 2008, Daniel-Constantin Mierla wrote:
> > [..]
> > At the moment there existing two different styles:
> >
> > mysql, unixodbc don't allocate new memory and just assign the string
> > pointer of the result set to the internal OpenSER representation. The
> > modules that needs to use this results needs to copy them, because there
> > are not available after a call to the DB specific result free function.
> >
> > postgres, db_berkeley allocate new memory and copy all string values from
> > the database to the internal representation. Modules that uses this
> > driver don't need to copy there values, even after the freeing of the
> > result set.
>
> quite strange, if the copy is not freed with free_result(), when it
> happens? At first thought, seems exposed to memory leak.

The copy is eventual freed with free_result(). The difference is only the copy 
operation that takes place.

> db_berkely seems constructed on dbtext structure. In dbtext, the result
> is duplicated in private memory, as the tables are stored in shared
> memory, and making direct references will be exposed to race.

Ok, i don't thought that much about this issues with dbtext yet..

> I think that the driver modules should not duplicate the result unless
> there is some race in reading/writing values in the result. Each module
> that uses the driver decides whether it needs values after free_result()
> and does a copy -- this is how should be now, at least did so.

Well, ok. Perhaps we can introduce a flag in the db_val or db_row type, that 
indicates that STR, STRING and BLOB values are copied, and thus needs to be 
freed? This would make it possible to use the same free function for the 
different databases, without changing that much of the internal logic of the 
driver.

Henning



More information about the Devel mailing list