apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Orton <jor...@redhat.com>
Subject Re: possible apr_dbd_get_driver dso issue
Date Thu, 22 Mar 2007 16:40:25 GMT
On Thu, Mar 22, 2007 at 12:09:51PM -0400, Brian J. France wrote:
> I think there is a issue with the dso code for apr_dbd_get_driver.
> I was writing a milter using the APR and while reviewing the code and  
> the APR dbd code I noticed that I would have big problems if I built  
> the drivers as dso's.
> The problem is because I use a global pool to call apr_dbd_init, but  
> then call apr_dbd_get_driver using a child pool which is cleaned up  
> after a request. apr_dbd_get_driver will load a dso driver using the  
> child pool (calling init on the driver), but the memory will get  
> cleaned up when the pool get cleaned up at the end of the request.   
> This is bad because the driver will stay in the drivers hash, but  
> with bogus memory.

Ah... I thought about this before but forgot to follow through.  Thanks 
for the report.

It would be sufficient IMO to make it an API requirement that the pool 
passed to apr_dbd_get_driver is the same as the pool passed to 
apr_dbd_init().  But it looks like existing callers don't do that, so 
it's easy to just ignore the passed-in pool and DTRT:


It would probably be good to have apr_dbd_init() create a subpool and 
for apr_dbd_term() to destroy that subpool but that would be less 
pseudo-thread-safe than the current code....


View raw message