Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:97918
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmx.de designates 212.227.17.22 as permitted sender)
To: Rasmus Lerdorf <rasmus@lerdorf.com>, Nikita Popov <nikita.ppv@gmail.com>
References: <CACXBjuiCfGt+eoX_rmCBQw3b9ns8J--R8+LCtp1cekKGghdD9Q@mail.gmail.com>
 <CAF+90c-pER=1Q-4UcQjWtGXB0PneCfM_5Kw5EquxVw_181yjMg@mail.gmail.com>
 <CACXBjuhY3Srkj=jgTVT8uTdFDqC66ybUuorarH9NNcsEfXZ_CQ@mail.gmail.com>
 <CACXBjuiK6=h+wqzGeWzxfR0EucToFENC28f_BNoG=UUBi1d+1A@mail.gmail.com>
Cc: PHP internals <internals@lists.php.net>
Message-ID: <4bc04e8d-d546-a671-6c88-cb44af2e0529@gmx.de>
Date: Sun, 22 Jan 2017 01:47:02 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101
 Thunderbird/45.6.0
MIME-Version: 1.0
In-Reply-To: <CACXBjuiK6=h+wqzGeWzxfR0EucToFENC28f_BNoG=UUBi1d+1A@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] pdo_sqlite fd leak
From: cmbecker69@gmx.de ("Christoph M. Becker")

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