A crash occurred in the odbc_handle_closer function

[matyhtf]

There is an issue with the order of resource release that needs to be corrected by modifying the code.

• swoole pdo mdb错误 swoole/swoole-src#5956

php-src/ext/pdo_odbc/odbc_driver.c

Line 138 in 833120e

SQLFreeHandle(SQL_HANDLE_ENV, H->env);

The correct code might be:

static void odbc_handle_closer(pdo_dbh_t *dbh) {
    pdo_odbc_db_handle *H = (pdo_odbc_db_handle *) dbh->driver_data;

    SQLFreeHandle(SQL_HANDLE_ENV, H->env);
    H->env = NULL;

    if (H->dbc != SQL_NULL_HANDLE) {
        SQLEndTran(SQL_HANDLE_DBC, H->dbc, SQL_ROLLBACK);
        SQLDisconnect(H->dbc);
        SQLFreeHandle(SQL_HANDLE_DBC, H->dbc);
        H->dbc = NULL;
    }

    pefree(H, dbh->is_persistent);
    dbh->driver_data = NULL;
}

I don't quite understand the logic of the ODBC PDO driver, please review the code above.

==45879== Invalid read of size 8
==45879==    at 0x1185F941: ??? (in /usr/lib/libodbccr.so.2.0.0)
==45879==    by 0x734F411: ??? (in /usr/lib/libodbc.so.2.0.0)
==45879==    by 0x7351182: ??? (in /usr/lib/libodbc.so.2.0.0)
==45879==    by 0x7359691: ??? (in /usr/lib/libodbc.so.2.0.0)
==45879==    by 0x7B01E10: odbc_handle_closer (odbc_driver.c:139)
==45879==    by 0x73F800E: ??? (in /usr/lib/php84/modules/pdo.so)
==45879==    by 0x5CE98E: zend_objects_store_del (in /usr/bin/php84)
==45879==    by 0x586F32: ??? (in /usr/bin/php84)
==45879==    by 0x534247: execute_ex (in /usr/bin/php84)
==45879==    by 0x52D64B: zend_call_function (in /usr/bin/php84)
==45879==    by 0x799996A: swoole::PHPCoroutine::main_func(void*) (swoole_coroutine.cc:773)
==45879==    by 0x7A2B6C7: operator() (std_function.h:591)
==45879==    by 0x7A2B6C7: swoole::coroutine::Context::context_func(transfer_t) (context.cc:149)
==45879==  Address 0x11079928 is 2,344 bytes inside a block of size 5,256 free'd
==45879==    at 0x48B2ECF: free (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==45879==    by 0x73788CA: ??? (in /usr/lib/libodbc.so.2.0.0)
==45879==    by 0x73597E7: ??? (in /usr/lib/libodbc.so.2.0.0)
==45879==    by 0x7B01DFB: odbc_handle_closer (odbc_driver.c:136)
==45879==    by 0x73F800E: ??? (in /usr/lib/php84/modules/pdo.so)
==45879==    by 0x5CE98E: zend_objects_store_del (in /usr/bin/php84)
==45879==    by 0x586F32: ??? (in /usr/bin/php84)
==45879==    by 0x534247: execute_ex (in /usr/bin/php84)
==45879==    by 0x52D64B: zend_call_function (in /usr/bin/php84)
==45879==    by 0x799996A: swoole::PHPCoroutine::main_func(void*) (swoole_coroutine.cc:773)
==45879==    by 0x7A2B6C7: operator() (std_function.h:591)
==45879==    by 0x7A2B6C7: swoole::coroutine::Context::context_func(transfer_t) (context.cc:149)
==45879==    by 0x7B1F70E: swoole_make_fcontext (make_x86_64_sysv_elf_gas.S:135)
==45879==  Block was alloc'd at
==45879==    at 0x48B640A: calloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==45879==    by 0x7378711: ??? (in /usr/lib/libodbc.so.2.0.0)
==45879==    by 0x734A3EE: ??? (in /usr/lib/libodbc.so.2.0.0)
==45879==    by 0x7B022FE: pdo_odbc_handle_factory (odbc_driver.c:498)
==45879==    by 0x73F2A2D: php_pdo_internal_construct_driver (in /usr/lib/php84/modules/pdo.so)
==45879==    by 0x552BD0: ??? (in /usr/bin/php84)
==45879==    by 0x534247: execute_ex (in /usr/bin/php84)
==45879==    by 0x52D64B: zend_call_function (in /usr/bin/php84)
==45879==    by 0x799996A: swoole::PHPCoroutine::main_func(void*) (swoole_coroutine.cc:773)
==45879==    by 0x7A2B6C7: operator() (std_function.h:591)
==45879==    by 0x7A2B6C7: swoole::coroutine::Context::context_func(transfer_t) (context.cc:149)
==45879==    by 0x7B1F70E: swoole_make_fcontext (make_x86_64_sysv_elf_gas.S:135)

[ndossche]

The handle is used when creating the DBC handle:

php-src/ext/pdo_odbc/odbc_driver.c

Lines 507 to 511 in 06ea0e5

	rc = SQLAllocHandle(SQL_HANDLE_DBC, H->env, &H->dbc);
	if (rc != SQL_SUCCESS && rc != SQL_SUCCESS_WITH_INFO) {
	pdo_odbc_drv_error("SQLAllocHandle: DBC");
	goto fail;
	}

So I think that the env must be destroyed after destroying the DBC. But that's what the current code already does.
Without a reproducer this is gonna be difficult.

cc @NattyNarwhal

[NattyNarwhal]

Yeah, the environment handle should always be freed last, since the DBC is derived from the ENV. (The way the handles are structured makes me think it might be possible to just make one in module state and share it across multiple connections, but that's something else.)

I'm guessing you were able to reproduce it on your own, since the linked issue's reproducer seems simple. Does it reproduce outside of Swoole?

[NattyNarwhal]

Can reproduce on master without Swoole (on ppc64, since that's the system I had on hand, and running Gentoo, so unixODBC symbols are easy):

(gdb) run
Starting program: /home/calvin/php-src/sapi/cli/php ../mdbtools.php
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib64/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
0x00003ffff6da238c in CLDisconnect (connection_handle=0x102272b00) at /usr/src/debug/dev-db/unixODBC-2.3.12-r2/unixODBC-2.3.12/cur/SQLConnect.c:428
428	            connection -> functions[ i ] =
(gdb) bt
#0  0x00003ffff6da238c in CLDisconnect (connection_handle=0x102272b00) at /usr/src/debug/dev-db/unixODBC-2.3.12-r2/unixODBC-2.3.12/cur/SQLConnect.c:428
#1  0x00003ffff79dd1f4 in close_pooled_connection (ptr=ptr@entry=0x10228a160)
    at /usr/src/debug/dev-db/unixODBC-2.3.12-r2/unixODBC-2.3.12/DriverManager/SQLConnect.c:2916
#2  0x00003ffff79dfb40 in __strip_from_pool (env=env@entry=0x10225c710)
    at /usr/src/debug/dev-db/unixODBC-2.3.12-r2/unixODBC-2.3.12/DriverManager/SQLConnect.c:3101
#3  0x00003ffff79eba38 in __SQLFreeHandle (handle_type=<optimized out>, handle=0x10225c710)
    at /usr/src/debug/dev-db/unixODBC-2.3.12-r2/unixODBC-2.3.12/DriverManager/SQLFreeHandle.c:283
#4  0x00003ffff79ec010 in SQLFreeHandle (handle_type=<optimized out>, handle=<optimized out>)
    at /usr/src/debug/dev-db/unixODBC-2.3.12-r2/unixODBC-2.3.12/DriverManager/SQLFreeHandle.c:662
#5  0x00000001005e0c74 in odbc_handle_closer (dbh=0x3ffff745c240) at /home/calvin/php-src/ext/pdo_odbc/odbc_driver.c:138
#6  0x00000001005ce234 in dbh_free (dbh=0x3ffff745c240, free_persistent=false) at /home/calvin/php-src/ext/pdo/pdo_dbh.c:1562
#7  0x00000001005ce6a0 in pdo_dbh_free_storage (std=0x3ffff74951e8) at /home/calvin/php-src/ext/pdo/pdo_dbh.c:1611
#8  0x0000000100bd9784 in zend_objects_store_del (object=0x3ffff74951e8) at /home/calvin/php-src/Zend/zend_objects_API.c:196
#9  0x0000000100c06bdc in rc_dtor_func (p=0x3ffff74951e8) at /home/calvin/php-src/Zend/zend_variables.c:57
#10 0x0000000100c06afc in i_zval_ptr_dtor (zval_ptr=0x3fffffffb098) at /home/calvin/php-src/Zend/zend_variables.h:45
#11 0x0000000100c06e5c in zval_ptr_dtor (zval_ptr=0x3fffffffb098) at /home/calvin/php-src/Zend/zend_variables.c:84
#12 0x0000000100b4620c in _zend_hash_del_el_ex (ht=0x101fb4c00, idx=9, p=0x3ffff745d320, prev=0x0) at /home/calvin/php-src/Zend/zend_hash.c:1500
#13 0x0000000100b46370 in _zend_hash_del_el (ht=0x101fb4c00, idx=9, p=0x3ffff745d320) at /home/calvin/php-src/Zend/zend_hash.c:1527
#14 0x0000000100b491f8 in zend_hash_reverse_apply (ht=0x101fb4c00, apply_func=@0x101e66d08: 0x100a4ceb8 <zval_call_destructor>)
    at /home/calvin/php-src/Zend/zend_hash.c:2243
#15 0x0000000100a4d230 in shutdown_destructors () at /home/calvin/php-src/Zend/zend_execute_API.c:262
#16 0x0000000100c16588 in zend_call_destructors () at /home/calvin/php-src/Zend/zend.c:1342
#17 0x00000001008e9234 in php_request_shutdown (dummy=0x0) at /home/calvin/php-src/main/main.c:1985
#18 0x0000000100c1e028 in do_cli (argc=2, argv=0x101fb1540) at /home/calvin/php-src/sapi/cli/php_cli.c:1158
#19 0x0000000100c1e6d4 in main (argc=2, argv=0x101fb1540) at /home/calvin/php-src/sapi/cli/php_cli.c:1362

Code is (random mdb file from https://github.com/mdbtools/mdbtestdata/blob/master/data/nwind.mdb to placate it):

<?php
$file = "/home/calvin/nwind.mdb";
$dsn = "odbc:Driver=MDBTools;DBQ=$file";
$pdo = new \PDO($dsn);

(edit: unixODBC trace shows the crash in the freeing of the environment handle)

[NattyNarwhal]

What version of unixODBC are you using? The crash is occurring somewhere with the cursor library, and I noticed 2.3.13/2.3.14 seem to fix some bugs related to (de)init and the cursor library. Indeed, switching my system from 2.3.12 to 2.3.14 seems to allegedly shift the crash somewhere else instead:

(gdb) bt
#0  0x00003ffff79e0fc0 in return_to_pool (connection=connection@entry=0x10225d6b0)
    at /usr/src/debug/dev-db/unixODBC-2.3.14/unixODBC-2.3.14/DriverManager/SQLConnect.c:3957
#1  0x00003ffff79e486c in SQLDisconnect (connection_handle=0x10225d6b0)
    at /usr/src/debug/dev-db/unixODBC-2.3.14/unixODBC-2.3.14/DriverManager/SQLDisconnect.c:293
#2  0x00000001005e0c38 in odbc_handle_closer (dbh=0x3ffff745c240) at /home/calvin/php-src/ext/pdo_odbc/odbc_driver.c:134
#3  0x00000001005ce234 in dbh_free (dbh=0x3ffff745c240, free_persistent=false) at /home/calvin/php-src/ext/pdo/pdo_dbh.c:1562
#4  0x00000001005ce6a0 in pdo_dbh_free_storage (std=0x3ffff74951e8) at /home/calvin/php-src/ext/pdo/pdo_dbh.c:1611
#5  0x0000000100bd9784 in zend_objects_store_del (object=0x3ffff74951e8) at /home/calvin/php-src/Zend/zend_objects_API.c:196
#6  0x0000000100c06bdc in rc_dtor_func (p=0x3ffff74951e8) at /home/calvin/php-src/Zend/zend_variables.c:57
#7  0x0000000100c06afc in i_zval_ptr_dtor (zval_ptr=0x3fffffffb098) at /home/calvin/php-src/Zend/zend_variables.h:45
#8  0x0000000100c06e5c in zval_ptr_dtor (zval_ptr=0x3fffffffb098) at /home/calvin/php-src/Zend/zend_variables.c:84
#9  0x0000000100b4620c in _zend_hash_del_el_ex (ht=0x101fb4c00, idx=9, p=0x3ffff745d320, prev=0x0) at /home/calvin/php-src/Zend/zend_hash.c:1500
#10 0x0000000100b46370 in _zend_hash_del_el (ht=0x101fb4c00, idx=9, p=0x3ffff745d320) at /home/calvin/php-src/Zend/zend_hash.c:1527
#11 0x0000000100b491f8 in zend_hash_reverse_apply (ht=0x101fb4c00, apply_func=@0x101e66d08: 0x100a4ceb8 <zval_call_destructor>)
    at /home/calvin/php-src/Zend/zend_hash.c:2243
#12 0x0000000100a4d230 in shutdown_destructors () at /home/calvin/php-src/Zend/zend_execute_API.c:262
#13 0x0000000100c16588 in zend_call_destructors () at /home/calvin/php-src/Zend/zend.c:1342
#14 0x00000001008e9234 in php_request_shutdown (dummy=0x0) at /home/calvin/php-src/main/main.c:1985
#15 0x0000000100c1e028 in do_cli (argc=2, argv=0x101fb1540) at /home/calvin/php-src/sapi/cli/php_cli.c:1158
#16 0x0000000100c1e6d4 in main (argc=2, argv=0x101fb1540) at /home/calvin/php-src/sapi/cli/php_cli.c:1362

I'm not entirely sure if this is more of an MDBTools/unixODBC bug and PHP is just the messenger being shot here too.

[NattyNarwhal]

I think this is an interaction between mdbtools and unixODBC's connection pooling:

calvin@php-ci-ppc64be ~/php-src $ sapi/cli/php -d pdo_odbc.connection_pooling=off ~/mdbtools.php 
calvin@php-ci-ppc64be ~/php-src $ sapi/cli/php ~/mdbtools.php 
Segmentation fault         (core dumped) sapi/cli/php ~/mdbtools.php

I also can't reproduce this with another ODBC driver (i.e. MySQL's).

[matyhtf]

Version:

3c732aa18f85:/work# php -v
PHP 8.4.14 (cli) (built: Oct 24 2025 20:05:56) (NTS)
Copyright (c) The PHP Group
Zend Engine v4.4.14, Copyright (c) Zend Technologies
    with Zend OPcache v8.4.14, Copyright (c), by Zend Technologies
3c732aa18f85:/work# odbc_config --longodbcversion
3.52
3c732aa18f85:/work# odbc_config --version
2.3.12
3c732aa18f85:/work# apk info unixodbc
unixodbc-2.3.12-r0 description:
ODBC is an open specification to access Data Sources

unixodbc-2.3.12-r0 webpage:
https://www.unixodbc.org/

unixodbc-2.3.12-r0 installed size:
655 KiB

[NattyNarwhal]

What happens if you turn off connection pooling (either via the PHP INI option, or via the unixODBC odbcinst.ini option CPTimeout = 0 on the driver)?

I really suspect this is some interaction with MDBTools and unixODBC, based on the connection pool behaviour and lack of problems with other drivers. I'm trying to reproduce this outside of PHP to test that, but haven't had much luck.