You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
phpredis should be able to open a connection more than once without segfaulting with the slots cache enabled
Actual behaviour
We are seeing a segfault occur on the second connection attempt. With php-cli we can reproduce by simply connecting twice to the same endpoint in a row ( see below ). With php-fpm behind nginx we see a SIGSEGV on the second http request to the same endpoint.
Setting other cluster distribution and connection persistence and pooling options appear to make no difference
Let me know if you need any more details.
I'm seeing this behaviour on
OS: Centos 7 - Linux 3.10.0-957.21.3.el7.x86_64 renameNx delivers false on success #1 SMP Tue Jun 18 16:35:19 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-114.el7
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty"for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/bin/php...Reading symbols from /usr/lib/debug/usr/bin/php.debug...done.
done.
(gdb) run cache_slots_testcase.php
Starting program: /usr/bin/php cache_slots_testcase.php
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
1
[Inferior 1 (process 92190) exited normally]
Missing separate debuginfos, use: debuginfo-install glibc-2.17-260.el7_6.6.x86_64
(gdb) run -d redis.clusters.cache_slots=1 cache_slots_testcase.php
Starting program: /usr/bin/php -d redis.clusters.cache_slots=1 cache_slots_testcase.php
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
1
Program received signal SIGSEGV, Segmentation fault.
0x00007fffdd6aa2df in cluster_disconnect (c=c@entry=0x7ffff38bc000, force=force@entry=0) at /usr/src/debug/php-pecl-redis5-5.0.0/NTS/cluster_library.c:1269
1269 ZEND_HASH_FOREACH_PTR(node->slaves, slave) {
(gdb) bt
#0 0x00007fffdd6aa2df in cluster_disconnect (c=c@entry=0x7ffff38bc000, force=force@entry=0) at /usr/src/debug/php-pecl-redis5-5.0.0/NTS/cluster_library.c:1269#1 0x00007fffdd6aa342 in cluster_free (c=c@entry=0x7ffff38bc000, free_ctx=free_ctx@entry=0) at /usr/src/debug/php-pecl-redis5-5.0.0/NTS/cluster_library.c:871#2 0x00007fffdd694b42 in free_cluster_context (object=0x7ffff38e05c0) at /usr/src/debug/php-pecl-redis5-5.0.0/NTS/redis_cluster.c:342#3 0x0000555555872fac in zend_objects_store_del (object=0x7ffff38e05c0) at /usr/src/debug/php-7.2.20/Zend/zend_objects_API.c:190#4 0x00005555558467b9 in _zend_hash_del_el_ex (prev=<optimized out>, p=<optimized out>, idx=<optimized out>, ht=<optimized out>) at /usr/src/debug/php-7.2.20/Zend/zend_hash.c:998#5 _zend_hash_del_el (p=0x7ffff385f200, idx=8, ht=0x555555c709d0 <executor_globals+304>) at /usr/src/debug/php-7.2.20/Zend/zend_hash.c:1021#6 zend_hash_reverse_apply (ht=ht@entry=0x555555c709d0 <executor_globals+304>, apply_func=apply_func@entry=0x5555558214c0 <zval_call_destructor>) at /usr/src/debug/php-7.2.20/Zend/zend_hash.c:1603#7 0x0000555555821985 in shutdown_destructors () at /usr/src/debug/php-7.2.20/Zend/zend_execute_API.c:238#8 0x0000555555833487 in zend_call_destructors () at /usr/src/debug/php-7.2.20/Zend/zend.c:1017#9 0x00005555557ccca5 in php_request_shutdown (dummy=dummy@entry=0x0) at /usr/src/debug/php-7.2.20/main/main.c:1851#10 0x00005555558e7603 in do_cli (argc=4, argv=0x555555c75ff0) at /usr/src/debug/php-7.2.20/sapi/cli/php_cli.c:1178#11 0x000055555563dd9b in main (argc=4, argv=0x555555c75ff0) at /usr/src/debug/php-7.2.20/sapi/cli/php_cli.c:1403
I've checked
[:heavy_check_mark:] There is no similar issue from other users
[:heavy_check_mark:] Issue isn't fixed in develop branch
Expected behaviour
phpredis should be able to open a connection more than once without segfaulting with the slots cache enabled
Actual behaviour
We are seeing a segfault occur on the second connection attempt. With php-cli we can reproduce by simply connecting twice to the same endpoint in a row ( see below ). With php-fpm behind nginx we see a SIGSEGV on the second http request to the same endpoint.
Setting other cluster distribution and connection persistence and pooling options appear to make no difference
Let me know if you need any more details.
I'm seeing this behaviour on
Steps to reproduce, backtrace or example script
Installed packages:
yum list installed | grep php newrelic-php5.x86_64 8.7.0.242-1 @newrelic newrelic-php5-common.noarch 8.7.0.242-1 @newrelic php-cli.x86_64 7.2.20-1.el7.remi @remi-php72 php-common.x86_64 7.2.20-1.el7.remi @remi-php72 php-debuginfo.x86_64 7.2.20-1.el7.remi @remi-php72-debuginfo php-fedora-autoloader.noarch 1.0.0-1.el7 @epel php-fpm.x86_64 7.2.20-1.el7.remi @remi-php72 php-intl.x86_64 7.2.20-1.el7.remi @remi-php72 php-json.x86_64 7.2.20-1.el7.remi @remi-php72 php-mbstring.x86_64 7.2.20-1.el7.remi @remi-php72 php-mysqlnd.x86_64 7.2.20-1.el7.remi @remi-php72 php-opcache.x86_64 7.2.20-1.el7.remi @remi-php72 php-pdo.x86_64 7.2.20-1.el7.remi @remi-php72 php-pear.noarch 1:1.10.9-3.el7.remi @remi-php72 php-pecl-apcu.x86_64 5.1.17-1.el7.remi.7.2 @remi-php72 php-pecl-apcu-debuginfo.x86_64 5.1.17-1.el7.remi.7.2 @remi-php72-debuginfo php-pecl-igbinary.x86_64 3.0.1-1.el7.remi.7.2 @remi-php72 php-pecl-igbinary-debuginfo.x86_64 3.0.1-1.el7.remi.7.2 @remi-php72-debuginfo php-pecl-imagick.x86_64 3.4.4-1.el7.remi.7.2 @remi-php72 php-pecl-imagick-debuginfo.x86_64 3.4.4-1.el7.remi.7.2 @remi-php72-debuginfo php-pecl-memcached.x86_64 3.1.3-1.el7.remi.7.2 @remi-php72 php-pecl-memcached-debuginfo.x86_64 3.1.3-1.el7.remi.7.2 @remi-php72-debuginfo php-pecl-msgpack.x86_64 2.0.3-1.el7.remi.7.2 @remi-php72 php-pecl-msgpack-debuginfo.x86_64 2.0.3-1.el7.remi.7.2 @remi-php72-debuginfo php-pecl-redis5.x86_64 5.0.0-1.el7.remi.7.2 @remi-php72 php-pecl-redis5-debuginfo.x86_64 5.0.0-1.el7.remi.7.2 @remi-php72-debuginfo php-pgsql.x86_64 7.2.20-1.el7.remi @remi-php72 php-php-gettext.noarch 1.0.12-1.el7 @epel php-process.x86_64 7.2.20-1.el7.remi @remi-php72 php-soap.x86_64 7.2.20-1.el7.remi @remi-php72 php-xml.x86_64 7.2.20-1.el7.remi @remi-php72 php72-php-common.x86_64 7.2.20-1.el7.remi @remi-safe php72-php-json.x86_64 7.2.20-1.el7.remi @remi-safe php72-php-pecl-igbinary.x86_64 3.0.1-1.el7.remi @remi-safe php72-php-pecl-msgpack.x86_64 2.0.3-1.el7.remi @remi-safe php72-runtime.x86_64 2.0-1.el7.remi @remi-safeTestcase:
Backtrace:
I've checked
developbranch