Edit report at https://bugs.php.net/bug.php?id=79270&edit=1
ID: 79270
Patch added by: cmb@php.net
Reported by: martin dot aschenbrenner at erwinmueller dot de
Summary: segfault in libodbc.so.2.0.0 with
ReflectionFunction($functio)->getParameters()
Status: Assigned
Type: Bug
Package: PDO ODBC
Operating System: Linux Ubuntu 18.04 x86_64
PHP Version: 7.3.14
Assigned To: cmb
Block user comment: N
Private report: N
New Comment:
The following patch has been added/updated:
Patch Name: bug79270.patch
Revision: 1604576850
URL: https://bugs.php.net/patch-display.php?bug=79270&patch=bug79270.patch&revision=1604576850
Previous Comments:
------------------------------------------------------------------------
[2020-11-05 11:38:50] cmb@php.net
> [â¦] supposed to call the free_object handlers of the objects in> reverse order of their creation [â¦]
I just learned that this is not true. I'll have a closer look.
------------------------------------------------------------------------
[2020-11-05 11:20:28] cmb@php.net
Thanks for the valgrind report. I've moved the full report to a
Gist[1] to keep this ticket more lucid. I'm ignoring the
Conditional jump or move depends on uninitialised value(s) in
zend_string_equal_val() , because these only occur under valgrind
and might be false positives. So the first relevant items are:
==2860== Conditional jump or move depends on uninitialised value(s)
==2860== at 0x9440B70: my_SQLFreeStmtExtended (in /usr/lib/x86_64-linux-gnu/odbc/libmyodbc8w.so)
==2860== by 0x9441014: my_SQLFreeStmt (in /usr/lib/x86_64-linux-gnu/odbc/libmyodbc8w.so)
==2860== by 0x9433993: free_connection_stmts (in /usr/lib/x86_64-linux-gnu/odbc/libmyodbc8w.so)
==2860== by 0x94339B0: SQLDisconnect (in /usr/lib/x86_64-linux-gnu/odbc/libmyodbc8w.so)
==2860== by 0x58703D9: SQLDisconnect (in /usr/lib/x86_64-linux-gnu/libodbc.so.2.0.0)
==2860== by 0x504AF1: odbc_handle_closer (odbc_driver.c:131)
==2860== by 0x4F6B68: dbh_free (pdo_dbh.c:1515)
==2860== by 0x6FDBC1: zend_objects_store_free_object_storage (zend_objects_API.c:104)
==2860== by 0x6B8054: shutdown_executor (zend_execute_API.c:342)
==2860== by 0x6C7992: zend_deactivate (zend.c:1198)
==2860== by 0x665D6A: php_request_shutdown (main.c:1921)
==2860== by 0x751453: do_cli (php_cli.c:1132)
==2860==
==2860== Invalid read of size 4
==2860== at 0x589BE37: ??? (in /usr/lib/x86_64-linux-gnu/libodbc.so.2.0.0)
==2860== by 0x58769F7: ??? (in /usr/lib/x86_64-linux-gnu/libodbc.so.2.0.0)
==2860== by 0x5069F1: odbc_stmt_dtor (odbc_stmt.c:148)
==2860== by 0x5005CC: php_pdo_free_statement (pdo_stmt.c:2272)
==2860== by 0x6FDBC1: zend_objects_store_free_object_storage (zend_objects_API.c:104)
==2860== by 0x6B8054: shutdown_executor (zend_execute_API.c:342)
==2860== by 0x6C7992: zend_deactivate (zend.c:1198)
==2860== by 0x665D6A: php_request_shutdown (main.c:1921)
==2860== by 0x751453: do_cli (php_cli.c:1132)
==2860== by 0x358697: main (php_cli.c:1359)
That shows that the issue happens during shutdown, namely in
zend_objects_store_free_object_storage() which is supposed to call
the free_object handlers of the objects in reverse order of their
creation, i.e. first the statement and then the database handle.
For some reason, in your case dbh_free() is called before
php_pdo_free_statement(), though, causing a crash.
[1] <https://gist.github.com/cmb69/337c02a21d6d7a9fd29f8d725f052945>
------------------------------------------------------------------------
[2020-10-20 11:09:43] cmb@php.net
Thanks for the stack backtrace! Apparently, there is a serious
issue when the statement handle is freed during shutdown[1]. I
still cannot reproduce this, and from looking at the
implementation, I cannot find anything obviously wrong. Maybe an
ODBC trace of running the script can bring some insights. On the
other hand, the fact that this would be related to constructing a
ReflectionFunction, hints at a more general memory management
issue. This might be debuggable using valgrind; you can find a
description in the phpinternalsbook[2] (just ignore the C code
snippets and respective details).
[1] <https://github.com/php/php-src/blob/php-7.4.11/ext/pdo_odbc/odbc_stmt.c#L148>
[2] <http://www.phpinternalsbook.com/php7/memory_management/memory_debugging.html#before-starting>
------------------------------------------------------------------------
[2020-10-19 16:10:19] alexander dot stix at erwinmueller dot de
#0 0x00007f36ff9e2a50 in ?? () from /lib/x86_64-linux-gnu/libodbc.so.2
#1 0x000056403f7559f2 in odbc_stmt_dtor (stmt=<optimized out>) at
/tmp/php-7.4.11/ext/pdo_odbc/odbc_stmt.c:148
#2 0x000056403f74f5cd in php_pdo_free_statement (stmt=0x7f36fcc98300) at
/tmp/php-7.4.11/ext/pdo/pdo_stmt.c:2272
#3 0x000056403f94cbc2 in zend_objects_store_free_object_storage
(objects=objects@entry=0x5640407820e8 <executor_globals+840>,
fast_shutdown=fast_shutdown@entry=1 '\001') at /tmp/php-7.4.11/Zend/zend_objects_API.c:104
#4 0x000056403f907055 in shutdown_executor () at /tmp/php-7.4.11/Zend/zend_execute_API.c:342
#5 0x000056403f916993 in zend_deactivate () at /tmp/php-7.4.11/Zend/zend.c:1198
#6 0x000056403f8b4d6b in php_request_shutdown (dummy=<optimized out>) at
/tmp/php-7.4.11/main/main.c:1921
#7 0x000056403f9a0454 in do_cli (argc=2, argv=0x5640415f1910) at
/tmp/php-7.4.11/sapi/cli/php_cli.c:1132
#8 0x000056403f5a7698 in main (argc=2, argv=0x5640415f1910) at
/tmp/php-7.4.11/sapi/cli/php_cli.c:1359
------------------------------------------------------------------------
[2020-10-19 07:50:50] cmb@php.net
I cannot reproduce the reported behavior with a non debug build.
Could you please provide a stack backtrace[1], so we have at least
some idea what might be wrong there?
[1] <https://bugs.php.net/bugs-generating-backtrace.php>
------------------------------------------------------------------------
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=79270
--
Edit this bug report at https://bugs.php.net/bug.php?id=79270&edit=1