go to bug id or search bugs for
while migrating a project which was using PDO->MSSQL (https://docs.microsoft.com/it-it/sql/connect/php/microsoft-php-driver-for-sql-server) to PDO->PostgreSQL, I found a strange behavior in how memory is retained by PHP when prepared statements are 'prepared' with the
\PDO::ATTR_CURSOR => \PDO::CURSOR_SCROLL
option, at least on Microsoft Windows.
By using the test script attached, it looks like memory used during the result set object retrieval is never de-allocated, leading to an abnormal memory consumption and ultimately to a httpd.exe crash on 32 bit systems due to memory allocation limitations.
I'm using a x64 build of PHP 7.1.10 with Apache 2.4.28 on a Windows 10 x64 PRO and I've also tested the following with PHP 5.4 32 bit and with PHP 7.0 32bit.
The behavior looks to be the same, each time the script is ran the memory used by httpd.exe increments by almost 800KB and it never get released.
We saw processes keeping up to 1.5Gb of RAM on 32bit OSs.
By simply changing the prepared statement 'prepare' option to:
\PDO::ATTR_CURSOR => \PDO::CURSOR_FWDONLY
memory is allocated and de-allocated correctly.
You can see here:
how quickly memory is being allocated and never released.
Initially I thought it was some kind of caching mechanism of PHP/PDO/PGSQL but memory allocation seems to be simply increasing with no limit.
This does not happen with the CURSOR_FWDONLY option.
Please find a sample test script below.
SQL Table creation script:
SQL Dummy data insert script:
PHP test script:
Add a Patch
Add a Pull Request
Automatic comment on behalf of ab
Log: Fixed bug #75402 Possible Memory Leak using PDO::CURSOR_SCROLL option