|
|
php.net | support | documentation | report a bug | advanced search | search howto | statistics | random bug | login |
[2016-01-16 08:37 UTC] bugs dot php dot net at ss dot st dot tc
Description: ------------ Tested in 7.0.0, 7.0.1 and 7.0.2. The problem doesn't happen when PHP is compiled with --enable-debug option, so here's all we've got: #0 0x00000000007482aa in php_mysqlnd_rowp_read_text_protocol_aux () #1 0x00000000007508b2 in ?? () #2 0x00000000007517c5 in ?? () #3 0x00000000007520f6 in ?? () #4 0x00000000005d2618 in zif_mysqli_fetch_all () #5 0x000000000089027b in ?? () #6 0x000000000084a55b in execute_ex () #7 0x00000000008beb9e in zend_execute () #8 0x00000000007e6d5a in zend_execute_scripts () #9 0x0000000000765858 in php_execute_script () #10 0x00000000008c0e24 in ?? () #11 0x000000000046bf09 in main () We figured segfault happens on this line: https://github.com/php/php-src/blob/php-7.0.2/ext/mysqlnd/mysqlnd_wireprotocol.c#L1670 but didn't dig deeper. After we removed as much as possible from our php script, we managed to narrow the problem down to just one query that was performed in a loop: select id, f1, f2 from table where id>{$some_id} and f1 is not null order by id limit 100 The script always segfaults after a certain amount of queries done. As soon as we change something in that query (add or remove field, change limit to 99 or 101), the number of performed queries before segfault changes (yet keeps steady as long as we don't touch the query anymore). For instance, with limit 100 it constantly takes 35 queries to segfault. With limit 101 we need 93 iterations. Without field "f2" it takes 83 iterations. With limit=102 segfault doesn't happen at all. And so on. We've also tried to add more mysql queries to another server/tables/databases, this also affects on the moment segfault happens, but it always keeps steady until we change something else. Could be a stack corruption, or something like that. PatchesPull RequestsHistoryAllCommentsChangesGit/SVN commits
|
|||||||||||||||||||||||||||||||||||||
Copyright © 2001-2024 The PHP GroupAll rights reserved. |
Last updated: Sat Dec 21 16:01:28 2024 UTC |
Not sure if it would help, but f1 is varbinary(32000). And if we select concat(f1, f1) instead of just f1, segfault does not happen. It also does not happen if we include something like: $x = str_repeat('XXXXXXXXXXXXXXXXXXXXXXX', 1000); echo strlen($x); // without echo segfault still happens into the loop. So any minor change to the code which affects memory may change the picture.Not 100% sure it's related, but I've run into an issue in the same function. PHP 7.0.8-0ubuntu0.16.04.3 (cli) ( NTS ) Copyright (c) 1997-2016 The PHP Group Zend Engine v3.0.0, Copyright (c) 1998-2016 Zend Technologies with Zend OPcache v7.0.8-0ubuntu0.16.04.3, Copyright (c) 1999-2016, by Zend Technologies The first time I ran valgrind, I got this: ==16316== Process terminating with default action of signal 11 (SIGSEGV) ==16316== at 0x682D2A9: raise (pt-raise.c:35) ==16316== by 0x17174A2E: nr_signal_reraise (util_signals.c:40) ==16316== by 0x682D3CF: ??? (in /lib/x86_64-linux-gnu/libpthread-2.23.so) ==16316== by 0x343C43: _emalloc (in /usr/bin/php7.0) ==16316== by 0x9A55F26: php_mysqlnd_rowp_read_text_protocol_aux (in /usr/lib/php/20151012/mysqlnd.so) ==16316== by 0x9A5D3F0: ??? (in /usr/lib/php/20151012/mysqlnd.so) ==16316== by 0x9A5D8A4: ??? (in /usr/lib/php/20151012/mysqlnd.so) ==16316== by 0x16F0FE73: php_mysqli_fetch_into_hash (in /usr/lib/php/20151012/mysqli.so) ==16316== by 0x356C99: dtrace_execute_internal (in /usr/bin/php7.0) ==16316== by 0x3EB93F: ??? (in /usr/bin/php7.0) ==16316== by 0x3A6F8A: execute_ex (in /usr/bin/php7.0) ==16316== by 0x356B30: dtrace_execute_ex (in /usr/bin/php7.0) One of the next times, after futzing with the code to try and get more information, I got this one: ==3636== Process terminating with default action of signal 11 (SIGSEGV) ==3636== at 0x682D2A9: raise (pt-raise.c:35) ==3636== by 0x17174A2E: nr_signal_reraise (util_signals.c:40) ==3636== by 0x682D3CF: ??? (in /lib/x86_64-linux-gnu/libpthread-2.23.so) ==3636== by 0x343C43: _emalloc (in /usr/bin/php7.0) ==3636== by 0x343EC0: _ecalloc (in /usr/bin/php7.0) ==3636== by 0x215D12: timelib_get_time_zone_info (in /usr/bin/php7.0) ==3636== by 0x217C35: timelib_set_timezone (in /usr/bin/php7.0) ==3636== by 0x217157: timelib_update_ts (in /usr/bin/php7.0) ==3636== by 0x1F2B43: zif_strtotime (in /usr/bin/php7.0) ==3636== by 0x356C99: dtrace_execute_internal (in /usr/bin/php7.0) ==3636== by 0x3EB93F: ??? (in /usr/bin/php7.0) ==3636== by 0x3A6F8A: execute_ex (in /usr/bin/php7.0) These both happen in a loop of several hundred queries. So far I've failed to make a reduced test case.