Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:97902
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain lerdorf.com designates 74.125.82.169 as permitted sender)
MIME-Version: 1.0
References: <CACXBjuiCfGt+eoX_rmCBQw3b9ns8J--R8+LCtp1cekKGghdD9Q@mail.gmail.com>
 <CAF+90c-pER=1Q-4UcQjWtGXB0PneCfM_5Kw5EquxVw_181yjMg@mail.gmail.com>
In-Reply-To: <CAF+90c-pER=1Q-4UcQjWtGXB0PneCfM_5Kw5EquxVw_181yjMg@mail.gmail.com>
Date: Fri, 20 Jan 2017 21:08:43 +0000
Message-ID: <CACXBjuhY3Srkj=jgTVT8uTdFDqC66ybUuorarH9NNcsEfXZ_CQ@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a113e1fe4a3f57905468d0e48
Subject: Re: [PHP-DEV] pdo_sqlite fd leak
From: rasmus@lerdorf.com (Rasmus Lerdorf)

--001a113e1fe4a3f57905468d0e48
Content-Type: text/plain; charset=UTF-8

On Fri, Jan 20, 2017 at 12:58 Nikita Popov <nikita.ppv@gmail.com> wrote:

>
> From the docs for sqlite3_close():
>
> > If the database connection is associated with unfinalized prepared
>
> statements or unfinished sqlite3_backup objects then sqlite3_close()
>
> will leave the database connection open and return SQLITE_BUSY
> <http://www.sqlite.org/rescode.html#busy>.
>
> If sqlite3_close_v2() is called with unfinalized prepared statements
>
> and/or unfinished sqlite3_backups, then the database connection becomes
>
> an unusable "zombie" which will automatically be deallocated when the
>
> last prepared statement is finalized or the last sqlite3_backup is
>
> finished. The sqlite3_close_v2() interface is intended for use with
>
> host languages that are garbage collected, and where the order in which
>
> destructors are called is arbitrary.
>
>
>
>
> That sounds like it could be the source of the issue.
>
Ah, that makes more sense that 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.

-Rasmus

--001a113e1fe4a3f57905468d0e48--