Bug #62111 [Ver->Csd]: MySQL PDO memory leaks, when used own result row class

Edit report at https://bugs.php.net/bug.php?id=62111&edit=1 ID: 62111 Updated by: nikic@php.net Reported by: hosiplan at gmail dot com Summary: MySQL PDO memory leaks, when used own result row class -Status: Verified +Status: Closed Type: Bug Package: PDO MySQL Operating System: Linux PHP Version: 5.4.4RC1 -Assigned To: +Assigned To: nikic Block user comment: N Private report: N New Comment: No longer reproduces on 7.3 at least, don't have older versions to test. Various GC issues in PDO have been fixed in the meantime. Previous Comments: ------------------------------------------------------------------------ [2020-03-10 15:26:07] cmb@php.net I can confirm that we're still leaking the pdo_stmt_t objects: ==32703== 3,680 bytes in 10 blocks are definitely lost in loss record 1 of 1 ==32703== at 0x4C2BBAF: malloc (vg_replace_malloc.c:299) ==32703== by 0x4D52B6: __zend_malloc (zend_alloc.c:2976) ==32703== by 0x4D423A: _malloc_custom (zend_alloc.c:2417) ==32703== by 0x4D4368: _emalloc (zend_alloc.c:2536) ==32703== by 0x3291C1: zend_object_alloc (zend_objects_API.h:91) ==32703== by 0x331151: pdo_dbstmt_new (pdo_stmt.c:2314) ==32703== by 0x511762: _object_and_properties_init (zend_API.c:1417) ==32703== by 0x5117D3: object_init_ex (zend_API.c:1431) ==32703== by 0x323948: pdo_stmt_instantiate (pdo_dbh.c:412) ==32703== by 0x324290: zim_PDO_prepare (pdo_dbh.c:522) ==32703== by 0x5781A9: ZEND_DO_FCALL_SPEC_RETVAL_USED_HANDLER (zend_vm_execute.h:1730) ==32703== by 0x5D6FF6: execute_ex (zend_vm_execute.h:53821) ------------------------------------------------------------------------ [2012-12-15 20:35:10] enumag at gmail dot com Try this one instead. It does not matter whether you use MySQL or SQLlite. The problem is that if you add some arguments for the constructor, it consumes more and more memory without any reason. --------- class pdo_row { public function __construct() { } } $pdo = new PDO('mysql:host=127.0.0.1;dbname=information_schema', 'root', ''); $pdo->exec("DROP TABLE test"); $pdo->exec("CREATE TABLE test(id INT, col VARCHAR(200))"); for ($i = 0; $i < 100; $i++) { $pdo->exec(sprintf("INSERT INTO test(id, col) VALUES (1, '012345678901234567890123456789012345678901234567890123456789-%d')", $i)); } printf("With ctor argument (memory usage increase):"); for ($i = 0; $i < 10; $i++) { $stmt = $pdo->prepare("SELECT col FROM test"); $stmt->setFetchMode(PDO::FETCH_CLASS, 'pdo_row', array($stmt)); $stmt->execute(); $rows = $stmt->fetchAll(); printf("emalloc %d kB, malloc %d kB\n", memory_get_usage() / 1024, memory_get_usage(true) / 1024); } printf("Without ctor argument (no memory usage increase):"); for ($i = 0; $i < 10; $i++) { $stmt = $pdo->prepare("SELECT col FROM test"); $stmt->setFetchMode(PDO::FETCH_CLASS, 'pdo_row'); $stmt->execute(); $rows = $stmt->fetchAll(); printf("emalloc %d kB, malloc %d kB\n", memory_get_usage() / 1024, memory_get_usage(true) / 1024); } ------------------------------------------------------------------------ [2012-06-13 15:10:15] uw@php.net It matters a whole lot what the cause is. It is not a leak. First, it helps to have some clean test code, such as this: class pdo_row { public function __construct($stmt) { $stmt = NULL; } } /* $pdo = new PDO("mysql:dbname=test;unix_socket=/var/run/mysql/mysql.sock", "root", ""); */ $pdo = new PDO("sqlite::memory:"); $pdo->exec("DROP TABLE test"); $pdo->exec("CREATE TABLE test(id INT, col VARCHAR(200))"); for ($i = 0; $i < 100; $i++) { $pdo->exec(sprintf("INSERT INTO test(id, col) VALUES (1, '012345678901234567890123456789012345678901234567890123456789-%d')", $i)); } for ($i = 0; $i < 10; $i++) { $stmt = $pdo->prepare("SELECT col FROM test"); $stmt->execute(); $stmt->setFetchMode(PDO::FETCH_CLASS, 'pdo_row', array($stmt)); $rows = $stmt->fetchAll(); printf("emalloc %d kB, malloc %d kB\n", memory_get_usage() / 1024, memory_get_usage(true) / 1024); } Running the above for SQLlite gives me: emalloc 205 kB, malloc 256 kB emalloc 206 kB, malloc 512 kB emalloc 207 kB, malloc 512 kB emalloc 208 kB, malloc 512 kB emalloc 209 kB, malloc 512 kB emalloc 210 kB, malloc 512 kB emalloc 211 kB, malloc 512 kB emalloc 212 kB, malloc 512 kB emalloc 213 kB, malloc 512 kB emalloc 214 kB, malloc 512 kB Running the above for MySQL gives me: emalloc 221 kB, malloc 256 kB emalloc 231 kB, malloc 512 kB emalloc 240 kB, malloc 512 kB emalloc 250 kB, malloc 512 kB emalloc 259 kB, malloc 512 kB emalloc 269 kB, malloc 512 kB emalloc 278 kB, malloc 512 kB emalloc 288 kB, malloc 512 kB emalloc 297 kB, malloc 512 kB emalloc 307 kB, malloc 512 kB Second, it helps to understand the matter. In both cases emalloc() figures increase, which is to be expected. PHP objects are created, the extensions allocate memory using the PHP internal e*alloc() function family and the figures increase. And, in both cases malloc() figures are the same. No difference between MySQL and SQLite. ------------------------------------------------------------------------ [2012-06-12 16:18:47] hosiplan at gmail dot com I don't really care what you name it. It's a real problem and its eating my memory and it shouldn't! ------------------------------------------------------------------------ [2012-06-12 13:33:16] uw@php.net There is no leak with MySQL. Memory usage increases, that's it. ==6216== LEAK SUMMARY: ==6216== definitely lost: 0 bytes in 0 blocks ==6216== indirectly lost: 0 bytes in 0 blocks ==6216== possibly lost: 0 bytes in 0 blocks ==6216== still reachable: 54 bytes in 2 blocks ==6216== suppressed: 0 bytes in 0 blocks ==6216== Rerun with --leak-check=full to see details of leaked memory ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=62111 -- Edit this bug report at https://bugs.php.net/bug.php?id=62111&edit=1