Bug #71569 [Csd]: #70389 fix causes segmentation fault

From: Date: Sat, 13 Feb 2016 14:28:06 +0000
Subject: Bug #71569 [Csd]: #70389 fix causes segmentation fault
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-199193@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=71569&edit=1 ID: 71569 Updated by: nikic@php.net Reported by: pavel2000 at ngs dot ru Summary: #70389 fix causes segmentation fault Status: Closed Type: Bug Package: PDO related PHP Version: 5.6.18 -Assigned To: +Assigned To: nikic Block user comment: N Private report: N New Comment: @pavel: Thanks for the investigation. As you correctly deduced the bug was caused by efreeing an interned string. I've fixed this by using an interned string compatible freeing function instead. Previous Comments: ------------------------------------------------------------------------ [2016-02-13 14:22:39] nikic@php.net Automatic comment on behalf of nikic Revision: http://git.php.net/?p=php-src.git;a=commit;h=bc419fee5c9704eb4ce338acacbc2380c6f4427d Log: FIx bug #71569 ------------------------------------------------------------------------ [2016-02-13 12:17:30] pavel2000 at ngs dot ru Hi! We continued to discover this issue. Our crashes caused by attribute MYSQL_ATTR_READ_DEFAULT_GROUP with NULL value and many other conditions. When Z_TYPE is 0 (IS_NULL) then convert_to_string() returns value obtained from STR_EMPTY_ALLOC(). In turn, STR_EMPTY_ALLOC() returns a value of CG(interned_empty_string). I don't think what doing efree() on this value later (like ext/pdo_mysql/mysql_driver.c:685) is a good idea. Unless ef1bd8f0e6f88b1d123cea1c0b5079cfde7f90df applied, there was no efree() on this value due to estrndup() call, but now it is. This needs to be fixed, see proposed patch attached. ------------------------------------------------------------------------ [2016-02-11 11:58:20] pavel2000 at ngs dot ru bt full 2 #0 _zend_mm_free_int (heap=0xdc7c30, p=0x7ffff7ea4058) at /home/t/php-5.6.17/Zend/zend_alloc.c:2104 mm_block = 0x7ffff7ea4048 next_block = 0xffffefdd3c68 size = 140737353284640 #1 0x00007fffe6543c05 in pdo_mysql_handle_factory (dbh=0x25cbd00, driver_options=0x22e5d68) at /home/t/php-5.6.17/ext/pdo_mysql/mysql_driver.c:685 connect_timeout = 30 default_file = <optimized out> ssl_capath = 0x0 init_cmd = <optimized out> default_group = <optimized out> ssl_key = 0x0 ssl_cert = 0x0 ssl_cipher = 0x0 compress = 0 ssl_ca = 0x0 H = 0x25a6300 i = <optimized out> ret = 0 host = 0x0 unix_socket = 0x0 port = 3306 dbname = <optimized out> vars = {{optname = 0x7fffe6546045 "charset", optval = 0x25c5b70 "UTF8", freeme = 1}, {optname = 0x7fffe654604d "dbname", optval = 0x25c5be8 "test2", freeme = 1}, {optname = 0x7fffe6546059 "host", optval = 0x25bc2d0 "127.0.0.1", freeme = 1}, { optname = 0x7fffe654605e "port", optval = 0x7fffe6546063 "3306", freeme = 0}, {optname = 0x7fffe6546068 "unix_socket", optval = 0x25c2388 "/var/run/mysqld/mysqld.sock", freeme = 1}} connect_opts = 196608 ------------------------------------------------------------------------ [2016-02-11 11:56:09] pavel2000 at ngs dot ru Description: ------------ Hi! We began to get segfaults after updating 5.6.7 up to 5.6.17 on our Debian 7 box. While searching for the causes of this, we found that resolution of https://bugs.php.net/bug.php?id=70389 (http://git.php.net/?p=php-src.git;a=commit;h=ef1bd8f0e6f88b1d123cea1c0b5079cfde7f90df) introduces regression. Please look into the backtrace we get: Program received signal SIGSEGV, Segmentation fault. _zend_mm_free_int (heap=0xdc7c30, p=0x7ffff7ea4058) at /home/t/php-5.6.17/Zend/zend_alloc.c:2104 2104 /home/t/php-5.6.17/Zend/zend_alloc.c: No such file or directory. (gdb) bt #0 _zend_mm_free_int (heap=0xdc7c30, p=0x7ffff7ea4058) at /home/t/php-5.6.17/Zend/zend_alloc.c:2104 #1 0x00007fffe6543c05 in pdo_mysql_handle_factory (dbh=0x25cbd00, driver_options=0x22e5d68) at /home/t/php-5.6.17/ext/pdo_mysql/mysql_driver.c:685 #2 0x00007ffff5d2f1ba in zim_PDO_dbh_constructor () at /build/php5-5.6.17+dfsg/ext/pdo/pdo_dbh.c:389 #3 0x00000000006e5cd2 in zend_do_fcall_common_helper_SPEC (execute_data=0x7ffff7fac858) at /home/t/php-5.6.17/Zend/zend_vm_execute.h:558 #4 0x00000000006aa728 in execute_ex (execute_data=0x7ffff7fac858) at /home/t/php-5.6.17/Zend/zend_vm_execute.h:363 #5 0x0000000000642a89 in zend_execute_scripts (type=type@entry=8, retval=retval@entry=0x0, file_count=file_count@entry=3) at /home/t/php-5.6.17/Zend/zend.c:1341 #6 0x00000000005df042 in php_execute_script (primary_file=primary_file@entry=0x7fffffffd290) at /home/t/php-5.6.17/main/main.c:2597 #7 0x00000000006e8f79 in do_cli (argc=6, argv=0xdc7890) at /home/t/php-5.6.17/sapi/cli/php_cli.c:994 #8 0x0000000000427a1d in main (argc=6, argv=0xdc7890) at /home/t/php-5.6.17/sapi/cli/php_cli.c:1378 mysql_driver.c has following lines of this process: 687: default_group= pdo_attr_strval(driver_options, PDO_MYSQL_ATTR_READ_DEFAULT_GROUP, NULL TSRMLS_CC); ... 685: efree(default_group) <--- crashed here Fix #70389 changes pdo_attr_strval() implementation. After replacing pdo_mysql.so to file from 5.6.7 problem disappears (and #70389 comes back). All indicates that the reason for crashes we got is #70389 regression. Please note, what we use MYSQL_ATTR_READ_DEFAULT_GROUP flag in our code, it was set it to string value: PDO::MYSQL_ATTR_READ_DEFAULT_GROUP => 'client-section' Sorry, I'm unable to provide more info such as test PHP script or a patch, as I'm not PHP or C qualified developer. But I think my ticket and backtrace can be useful point of start to review #70389 / ef1bd8f0e6f88b1d123cea1c0b5079cfde7f90df again. Thanks. ------------------------------------------------------------------------ -- Edit this bug report at https://bugs.php.net/bug.php?id=71569&edit=1

« previous php.bugs (#199193) next »