On 20.01.2017 at 22:41, Rasmus Lerdorf wrote: > On Fri, Jan 20, 2017 at 1:08 PM, Rasmus Lerdorf <ras...@lerdorf.com> wrote: > >> On Fri, Jan 20, 2017 at 12:58 Nikita Popov <nikita....@gmail.com> wrote: >> >>> That sounds like it could be the source of the issue. >> >> Ah, that makes more sense than it never hitting that close call because I >> couldn't find any scenario where we wouldn't get there eventually. So it >> sounds like we should be calling sqlite3_close_v2() there instead. > > Of course, something must be causing the unfinalized prepared statement in > the first place so moving to the v2 close likely wouldn't fix it, just move > it from an unclosed db handle to an unclosed "unusable zombie" handle, > whatever that means. I also noticed that ext/sqlite3 uses > sqlite3_prepare_v2() while pdo_sqlite uses sqlite3_prepare(). The > differences in those two don't seem like they would affect whether the > prepare is finalized or not though.
Anyhow, the SQLite3 documentation states[1]: | The sqlite3_prepare_v2() and sqlite3_prepare16_v2() interfaces are | recommended for all new programs. The two older interfaces are | retained for backwards compatibility, but their use is discouraged. Isn't that reason enough to switch to sqlite3_prepare_v2() ASAP? Note that this is documented at least for more than nine years[2]! [1] <https://sqlite.org/c3ref/prepare.html> [2] <http://web.archive.org/web/20070701000000*/https://sqlite.org/c3ref/prepare.html> -- Christoph M. Becker -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
