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)