Persistent connections in the session handler are not documented and wrong string causing segfaults

[samm-git]

I found that there is a possibility to use persistent connections in memcached session handler. However, i cant find any reference on it. From the code i found that it expects PERSISTENT= in the save_path string. I tried PERSISTENT=host:port and got segfault. Could you please tell if this functionality is complete or not and how to use it? Thank you.

[samm-git]

Ok, found it, works correctly with:

PERSISTENT=1 localhost:11211

So probably it needs to be documented + segfault for paths like PERSISTENT=host:port needs to be resolved

[mkoppanen]

Are you able to create a backtrace out of the segfault?

[samm-git]

@mkoppanen interesting, i am able to reproduce segfault on my OSX machine, but when i am trying to reproduce this on Linux - it works correctly:

[Thu Nov 12 19:31:50 2015] [error] [client 37.48.44.175] PHP Warning:  Unknown: Failed to write session data (memcached). Please verify that the current setting of session.save_path is correct (PERSISTENT=127.0.0.1:11211) in Unknown on line 0

I will try to debug segfault on osx and will let you know.

[samm-git]

I been able to get some debug with lldb:

This is message after crash;

* thread #1: tid = 0x172e31, 0x0000000110a996b3 memcached.so`ps_write_memcached(mod_data=<unavailable>, key=0x00000001151e5388, val=0x0000000115124660, vallen=0) + 163 at php_memcached_session.c:357, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
    frame #0: 0x0000000110a996b3 memcached.so`ps_write_memcached(mod_data=<unavailable>, key=0x00000001151e5388, val=0x0000000115124660, vallen=0) + 163 at php_memcached_session.c:357
   354
   355      /* Set the number of write retry attempts to the number of replicas times the number of attempts to remove a server plus the initial write */
   356      if (MEMC_G(sess_remove_failed_enabled)) {
-> 357          write_try_attempts = 1 + MEMC_G(sess_number_of_replicas) * ( memcached_behavior_get(memc_sess->memc_sess, MEMCACHED_BEHAVIOR_SERVER_FAILURE_LIMIT) + 1);
   358      }
   359
   360      do {

And this is backtrace:

(lldb) bt all
* thread #1: tid = 0x172e31, 0x0000000110a996b3 memcached.so`ps_write_memcached(mod_data=<unavailable>, key=0x00000001151e5388, val=0x0000000115124660, vallen=0) + 163 at php_memcached_session.c:357, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
  * frame #0: 0x0000000110a996b3 memcached.so`ps_write_memcached(mod_data=<unavailable>, key=0x00000001151e5388, val=0x0000000115124660, vallen=0) + 163 at php_memcached_session.c:357
    frame #1: 0x000000010fa502a2 php-fpm`zim_SessionHandler_write + 97
    frame #2: 0x000000010fbbc8b1 php-fpm`dtrace_execute_internal + 126
    frame #3: 0x000000010fc35bc6 php-fpm`zend_do_fcall_common_helper_SPEC + 1339
    frame #4: 0x000000010fbf2d86 php-fpm`execute_ex + 93
    frame #5: 0x000000010fbbc7ed php-fpm`dtrace_execute_ex + 226
    frame #6: 0x000000010fbbe061 php-fpm`zend_call_function + 2008
    frame #7: 0x000000010fbbd789 php-fpm`call_user_function + 154
    frame #8: 0x000000010fa57bd7 php-fpm`ps_call_handler + 95
    frame #9: 0x000000010fa57943 php-fpm`ps_write_user + 191
    frame #10: 0x000000010fa5565a php-fpm`php_session_flush + 145
    frame #11: 0x000000010fa53867 php-fpm`zm_deactivate_session + 76
    frame #12: 0x000000010fbd15a4 php-fpm`zend_deactivate_modules + 152
    frame #13: 0x000000010fb71637 php-fpm`php_request_shutdown + 333
    frame #14: 0x000000010fc5eae5 php-fpm`main + 6321
    frame #15: 0x00007fff97e955c9 libdyld.dylib`start + 1

[samm-git]

i think that problem is that PS_WRITE_FUNC is called when PS_OPEN_FUNC returns FAILURE and this causing access to non-allocated data (memc_sess).

[mkoppanen]

I wonder why it's getting called. Almost sounds like incorrect behaviour.

Does changing PS_WRITE_FUNC to following fix the issue:

       memcached_sess *memc_sess = PS_GET_MOD_DATA();
    if (!memc_sess) {
        return FAILURE;
    }

[samm-git]

@mkoppanen i fixed this issue and i think that i know the reason - its called because default (file) handler failed, probably because of permissions. Anyway, i think it is good idea to check that pointer is correct before doing any operations on data. I sent PR for that.

[mkoppanen]

Merged both of them. Thanks for your contribution!

[samm-git]

Thank you!