Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:97903
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain lerdorf.com designates 209.85.218.50 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CACXBjuhY3Srkj=jgTVT8uTdFDqC66ybUuorarH9NNcsEfXZ_CQ@mail.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>
Date: Fri, 20 Jan 2017 13:41:06 -0800
Message-ID: <CACXBjuiK6=h+wqzGeWzxfR0EucToFENC28f_BNoG=UUBi1d+1A@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a1141b2664a81c505468d84d1
Subject: Re: [PHP-DEV] pdo_sqlite fd leak
From: rasmus@lerdorf.com (Rasmus Lerdorf)

--001a1141b2664a81c505468d84d1
Content-Type: text/plain; charset=UTF-8

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. There still must be some path where on
a timeout we don't call pdo_sqlite_stmt_dtor() which does the finalize on
the statement.

-Rasmus

--001a1141b2664a81c505468d84d1--