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
