apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick Kew <n...@webthing.com>
Subject Lifetime of apr_dbd_get_entry return values
Date Sun, 21 Dec 2008 03:22:04 GMT
PR#46421 reports a bug in mod_authz_dbd: it fails to copy return
values from apr_dbd_get_entry before they go out of scope.
Evidently the user has a DBD driver that re-uses memory.
https://issues.apache.org/bugzilla/show_bug.cgi?id=46421

I've just checked the drivers.  Most of them return each
apr_dbd_get_entry in new memory, and I think we can reasonably
harmonise on that.  Here's my take:


FreeTDS - return value is in a re-used buffer!
MySQL - memory is allocated by MySQL lib functions.
    Looks as if it shouldn't need copying for mod_authz_dbd,
    but likely unsafe in the general case.
ODBC - allocates pool memory.
Oracle - allocates pool memory.
PostgreSQL - returns memory with the lifetime of the PQresult.
SQLite2 - looks like everything is in memory tied to the query.
SQLite3 - appears to copy everything to pool in
    dbd_sqlite3_select_internal.

I've asked the reporter what driver he's using, and I'm guessing
FreeTDS (he's on Windows).  If he confirms that, we can deliver a
fix by ensuring all drivers return memory that'll remain for the
lifetime of a pool.  But that may lose efficiency in some drivers,
pgsql in sequential/async mode being a case in point where the
copy is likely unnecessary in many/most apps.  Would it be too
complicated to provide users a switch?

Or we could beat this by returning buckets, but not in a release
anytime soon.

Thoughts?

-- 
Nick Kew

Mime
View raw message