Bug #72294 [Opn->Csd]: Segmentation fault/invalid pointer in connection with pgsql_stmt_dtor

From: Date: Wed, 01 Jun 2016 09:58:01 +0000
Subject: Bug #72294 [Opn->Csd]: Segmentation fault/invalid pointer in connection with pgsql_stmt_dtor
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-201384@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=72294&edit=1

 ID:                 72294
 Updated by:         ab@php.net
 Reported by:        jesse dot hallam at gmail dot com
 Summary:            Segmentation fault/invalid pointer in connection
                     with pgsql_stmt_dtor
-Status:             Open
+Status:             Closed
 Type:               Bug
 Package:            PDO PgSQL
 Operating System:   CentOS release 6.5 (Final)
 PHP Version:        7.0.7
 Block user comment: N
 Private report:     N

 New Comment:

Automatic comment on behalf of ab
Revision: http://git.php.net/?p=php-src.git;a=commit;h=af8fa8e937418756dfc18c59475ca348f8af654e
Log: Fixed bug #72294 Segmentation fault/invalid pointer in connection with pgsql_stmt_dtor


Previous Comments:
------------------------------------------------------------------------
[2016-05-30 19:21:01] jesse dot hallam at gmail dot com

Description:
------------
Our regression test suite against PHP7 has been throwing segmentation faults since at least PHP
7.0.2 up to the latest PHP 7.0.7 in connection with pgsql_stmt_dtor. It was difficult to recreate a
minimal reproduction step since it only occurred in connection with PHPUnit executing the tests, but
the self-contained (modulo the required Postgres server), 146-line PHP script below represents our
best attempt at that. It's a hodge podge of hacked-up PHPUnit code, the basic tests that
trigger the behaviour, and an empty if statement that triggers some exception handling similar to
PHPUnit that appeared to be required to reproduce the issue.

The exact failure semantics will vary wildly if small, unrelated parts of the code are changed (e.g.
removing a test case that would pass). The behaviour observed at the present time using the above
script is captured below.

Test script:
---------------
https://gist.github.com/lieut-data/71eda10bab6e2ccec4e3b11251b2d0a2

Expected result:
----------------
No segmentation fault.

Actual result:
--------------
*** glibc detected *** /bin/php: realloc(): invalid pointer: 0x00007ffff7cb2000 ***
======= Backtrace: =========
/lib64/libc.so.6[0x3b8b276166]
/lib64/libc.so.6(realloc+0x2e2)[0x3b8b27bfd2]
/usr/pgsql-9.2/lib/libpq.so.5(enlargePQExpBuffer+0xb2)[0x7ffff11257d2]
/usr/pgsql-9.2/lib/libpq.so.5(printfPQExpBuffer+0x103)[0x7ffff1125c03]
/usr/pgsql-9.2/lib/libpq.so.5(+0x116e1)[0x7ffff111a6e1]
/usr/pgsql-9.2/lib/libpq.so.5(PQsendQuery+0x11)[0x7ffff111aef1]
/usr/pgsql-9.2/lib/libpq.so.5(PQexec+0x3b)[0x7ffff111d4fb]
/usr/lib64/php/modules/pdo_pgsql.so(+0x6727)[0x7ffff133d727]
/usr/lib64/php/modules/pdo.so(php_pdo_free_statement+0x79)[0x7ffff154e119]
/bin/php(zend_objects_store_del+0x297)[0x61ee17]
/bin/php(zend_array_destroy+0x175)[0x5f6615]
/bin/php(zend_object_std_dtor+0x92)[0x61a452]
/bin/php(zend_objects_store_free_object_storage+0x50)[0x61ea80]
/bin/php[0x5d68c3]
/bin/php(zend_deactivate+0x57)[0x5e3897]
/bin/php(php_request_shutdown+0x202)[0x5858d2]
/bin/php[0x6799cf]
/bin/php[0x67ad9a]
/lib64/libc.so.6(__libc_start_main+0xfd)[0x3b8b21ed1d]
/bin/php[0x429371]

Valgrind reports:
==3482== Memcheck, a memory error detector
==3482== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==3482== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
==3482== Command: /bin/php -c /home/jesse.hallam/tmp/php.ini bug.php
==3482== Parent PID: 2762
==3482== 
==3482== Invalid read of size 8
==3482==    at 0xCC37719: pgsql_stmt_dtor (pgsql_statement.c:78)
==3482==    by 0xCA25118: php_pdo_free_statement (pdo_stmt.c:2323)
==3482==    by 0x61EE16: zend_objects_store_del (zend_objects_API.c:178)
==3482==    by 0x5F6614: zend_array_destroy (zend_variables.h:58)
==3482==    by 0x61A451: zend_object_std_dtor (zend_variables.h:58)
==3482==    by 0x61EA7F: zend_objects_store_free_object_storage (zend_objects_API.c:99)
==3482==    by 0x5D68C2: shutdown_executor (zend_execute_API.c:357)
==3482==    by 0x5E3896: zend_deactivate (zend.c:967)
==3482==    by 0x5858D1: php_request_shutdown (main.c:1833)
==3482==    by 0x6799CE: do_cli (php_cli.c:1141)
==3482==    by 0x67AD99: main (php_cli.c:1344)
==3482==  Address 0xfd0c840 is 0 bytes inside a block of size 56 free'd
==3482==    at 0x4A063F0: free (vg_replace_malloc.c:446)
==3482==    by 0xCC34EAF: pgsql_handle_closer (pgsql_driver.c:226)
==3482==    by 0xCA1EDFA: dbh_free (pdo_dbh.c:1516)
==3482==    by 0x61EA7F: zend_objects_store_free_object_storage (zend_objects_API.c:99)
==3482==    by 0x5D68C2: shutdown_executor (zend_execute_API.c:357)
==3482==    by 0x5E3896: zend_deactivate (zend.c:967)
==3482==    by 0x5858D1: php_request_shutdown (main.c:1833)
==3482==    by 0x6799CE: do_cli (php_cli.c:1141)
==3482==    by 0x67AD99: main (php_cli.c:1344)
==3482== 
==3482== 
==3482== HEAP SUMMARY:
==3482==     in use at exit: 78,376 bytes in 302 blocks
==3482==   total heap usage: 30,360 allocs, 30,058 frees, 4,530,852 bytes allocated
==3482== 
==3482== LEAK SUMMARY:
==3482==    definitely lost: 152 bytes in 1 blocks
==3482==    indirectly lost: 0 bytes in 0 blocks
==3482==      possibly lost: 0 bytes in 0 blocks
==3482==    still reachable: 78,224 bytes in 301 blocks
==3482==         suppressed: 0 bytes in 0 blocks
==3482== Rerun with --leak-check=full to see details of leaked memory
==3482== 
==3482== For counts of detected and suppressed errors, rerun with: -v
==3482== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 132 from 9)


------------------------------------------------------------------------



--
Edit this bug report at https://bugs.php.net/bug.php?id=72294&edit=1


Thread (2 messages)

« previous php.bugs (#201384) next »