8000 rediscluster crashed when using as session handler · Issue #618 · phpredis/phpredis · GitHub
[go: up one dir, main page]

Skip to content

rediscluster crashed when using as session handler #618

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
nailding1 opened this issue Jun 18, 2015 · 7 comments
Closed

rediscluster crashed when using as session handler #618

nailding1 opened this issue Jun 18, 2015 · 7 comments

Comments

@nailding1
Copy link

Hi,

it's great to find that redis cluster is supported for session handler which I searched for a long time. But it crashed for my first run after I compiled your latest version on dev branch. The following is my config:

session.save_handler = rediscluster
session.save_path = "seed[]=10.206.212.14:6382&seed[]=10.206.212.15:6382&seed[]=10.206.212.17:6386&seed[]=10.206.212.18:6386&timeout=3&read_time=3&prefix=sess"

==== error log ====
[18-Jun-2015 21:23:02] WARNING: [pool www] child 30732 exited on signal 11 (SIGSEGV) after 177.730814 seconds from start
[18-Jun-2015 21:23:02] NOTICE: [pool www] child 31187 started

would you please advise if this is a known issue or caused by my incorrect configuration since my project is eager for the feature?

Moreover, when would the cluster supported session handler be released?

Thanks
Daniel

@michael-grunder
Copy link
Member

Hey,

Thanks for the report!

I just pushed this last night and it's not well tested yet. All I did was run a few little test scripts and didn't see any crashing on my end. That being said, I'm running the tests via php-cli (not fpm), so that could be a difference.

I'll try to semi-replicate the way you're calling it and see if I can get lucky and crash it!

If I can't get it to break, I'll do the work to run it via fpm and if it still doesn't break might bother you for a call stack. :octocat:

Cheers
Mike

@michael-grunder
Copy link
Member

I tested it with settings similar to what you provided (just changed the IPs to 127.0.0.1), and didn't have any problems. I also ran it through valgrind without any warnings.

Are the scripts you're using to run it simple enough to paste (or even just a simple script where you can get it to crash?)

For example, if you put these three scripts into a directory and run php ses-in.php and then php ses-out.php from the command line do you still get a SIGSEGV?

ses-std.php:

<?php
ini_se
8000
t('session.save_handler', 'rediscluster');
ini_set('session.save_path', 'seed[]=127.0.0.1:7000&seed[]=127.0.0.1:7001&seed[]=127.0.0.1:7002&timeout=3&read_time=3&prefix=sess');
session_id('my_session_id');
?>

ses-in.php:

<?php
require_once('ses-std.php');

session_start();

for ($i = 0; $i < 100; $i++) {
    $_SESSION['var-'.$i] = 'my_special_value:' . $i . (isset($argv[1]) ? '-c' : '');
}
?>

ses-out.php:

<?php
require_once('ses-std.php');

session_start();

for ($i = 0; $i < 100; $i++) {
    var_dump($_SESSION['var-'.$i]);
}
?>

@nailding1
Copy link
Author

Hi, Mike,

Thanks a lot for your quick turnaround and I tried your excerpt but it still crashed. I pasted the stacktrace and hope that might help:


Reading symbols from /home/admin/fpm-php/lib/php/extensions/no-debug-non-zts-20100525/yaf.so...done.
Loaded symbols for /home/admin/fpm-php/lib/php/extensions/no-debug-non-zts-20100525/yaf.so
Reading symbols from /home/admin/fpm-php/lib/php/extensions/no-debug-non-zts-20100525/xhprof.so...done.
Loaded symbols for /home/admin/fpm-php/lib/php/extensions/no-debug-non-zts-20100525/xhprof.so
Reading symbols from /home/admin/fpm-php/lib/php/extensions/no-debug-non-zts-20100525/redis.so...done.
Loaded symbols for /home/admin/fpm-php/lib/php/extensions/no-debug-non-zts-20100525/redis.so
Core was generated by `/home/admin/fpm-php/bin/php ses-in.php'.
Program terminated with signal 11, Segmentation fault.
#0 0x0000000000563365 in ps_srlzr_decode_php ()
(gdb) bt
#0 0x0000000000563365 in ps_srlzr_decode_php ()
#1 0x000000000055ed3a in php_session_decode ()
#2 0x0000000000560973 in php_session_initialize ()
#3 0x00000000005610d9 in php_session_start ()
#4 0x00000000005618a9 in zif_session_start ()
#5 0x00000000006afbc5 in zend_do_fcall_common_helper_SPEC ()
#6 0x00000000006b5880 in execute ()
#7 0x0000000000680f8f in zend_execute_scripts ()
#8 0x0000000000624148 in php_execute_script ()
#9 0x00000000007290e8 in do_cli ()
#10 0x0000000000729818 in main ()

(gdb)

since it seems mattering with the encoding stuff ( I am from China and not sure whether timezone or locale settings caused the problem), I pasted my locale as follows:
LANG=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=

btw, my php uses yaf and not sure whether it conflicts with redis.

Just let me know if you need further info for troubleshooting.

Thanks again
Daniel

@nailding1
Copy link
Author

More comes: I commented out the yaf in php.ini just in case and crash still happens. So yaf should not be the problem.

@michael-grunder
Copy link
Member

Hey, thanks for the update.

What version of php are you running? Sometimes these things come down to specific differences between them.

Also I have a couple of questions. First, have you tried this same script using the standard 'redis' session handler? I'm curious to see if that also causes a crash, which would tend to rule out the cluster functionality specifically.

The callstack in question doesn't contain any of the phpredis routines, but it still could be the module (in the case where I'm corrupting memory somehow in initialization).

One thing that's always a good thing to do is run a full make clean && phpize && ./configure && make && sudo make install if you're building from source, because sometimes the compiler can produce bad code if there are cached object files which it (incorrectly) thinks don't need updating.

If that doesn't solve the problem, you could also run the script I posted through valgrind which should report any place where phpredis might be performing invalid read/write operations or operating on uninitialized values.

Also there are other people who are going to be testing this functionality very soon, so if they have issues that might help narrow down the issue.

Cheers,
Mike

@nailding1
Copy link
Author

Hi,

I made a quick double-check as you mentioned:

  1. php version:
    $ /home/admin/fpm-php/bin/php --version
    PHP 5.4.13 (cli) (built: Jun 25 2014 18:36:36)
    Copyright (c) 1997-2013 The PHP Group
    Zend Engine v2.4.0, Copyright (c) 1998-2013 Zend Technologies
  2. work with standard redis
    I updated the ses-std.php as follows and it worked without crash. In fact , the redis version has been working for months stably.
  3. for building stuff, since I just downloaded the code and unzip and phpize and ..., so the code base should be clean enough.
  4. I would download php code and build a debug version to run your code for further clues and please drop me a message if other guys have clues.

Thanks a lot for your nice help :-)
Daniel

@nailding1
Copy link
Author

Just an update:

It seems the core only occurs to php 5.4.xx (I used the version php-5.4.42 for the testing). For php 5.6.xx, everything goes well. Would you please take a look at this since I am a fresh man for php source code?

Thanks
Daniel

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants
0