Re: pdo_sqlite fd leak
| From: | Christoph M. Becker | Date: | Sun, 22 Jan 2017 00:47:02 +0000 |
| Subject: | Re: pdo_sqlite fd leak | ||
| References: | 1 2 3 4 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-97918@lists.php.net to get a copy of this message | ||
On 20.01.2017 at 22:41, Rasmus Lerdorf wrote:
> On Fri, Jan 20, 2017 at 1:08 PM, Rasmus Lerdorf <rasmus@lerdorf.com> wrote:
>
>> On Fri, Jan 20, 2017 at 12:58 Nikita Popov <nikita.ppv@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