Bug #71088 [Nab]: Session gets corrupted using custom session handler, unicode chars + 2 pg_conn

Edit report at https://bugs.php.net/bug.php?id=71088&edit=1 ID: 71088 Updated by: yohgaki@php.net Reported by: cdutary at grupocti dot com Summary: Session gets corrupted using custom session handler, unicode chars + 2 pg_conn Status: Not a bug Type: Bug Package: Session related Operating System: Windows 2008 PHP Version: 7.0.0 Assigned To: yohgaki Block user comment: N Private report: N New Comment: @cdutary I updated the sample code pg_esacpe_bytea() https://gist.github.com/yohgaki/a7b130bc93b2f9467ccc to use database connection. libpq's code use connection version ID for proper escape method. This will fix your issue. Previous Comments: ------------------------------------------------------------------------ [2015-12-15 00:31:57] yohgaki@php.net Some kind of BYTEA escape/unescape issue. ------------------------------------------------------------------------ [2015-12-15 00:30:57] yohgaki@php.net @cdutary I briefly checked PostgreSQL 8.4 and 9.x libpq code. PostgreSQL 8.4's PQunescapeBytea() does not have support new escape method, but it seems 9.x code has older escape support. I'm not sure why you get errors. Since I'm a pgsql module maintainer, I may investigate what's wrong. Please open new pgsql module bug report, if you think your problem is some kind of bug. I'll close this bug. ------------------------------------------------------------------------ [2015-12-14 22:56:39] cdutary at grupocti dot com Well, the seccond connection is made to a older version of postgres, session management is made on the same version (9.4.4) both client and server so I guess this is the one that should matter. My guess is that PHP, in order to be compatible with the seccond conection is using old "techniques" against the new server as well. I was expecting for php to handle both connections separately but I guess that is just not possible. FIRST SERVER (session storage): PostgreSQL 9.4.4 on x86_64-unknown-linux-gnu, compiled by gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-11), 64-bit SECCOND SERVER: PostgreSQL 8.4.20 on x86_64-redhat-linux-gnu, compiled by GCC gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-11), 64-bit CLIENT(php): PostgreSQL(libpq) Version 9.4.4 ------------------------------------------------------------------------ [2015-12-14 22:08:20] yohgaki@php.net I don't get suspicious error. --- modified test codes ---- ob_start(); session_start(); isset($_SESSION['aaa']) ? : 'Setting value' . $_SESSION['aaa'] = 'áéíóú'; //added unicode chars to our session data. $_SESSION['cnt']++; var_dump($_SESSION); $pg_conn = pg_connect("host=localhost port=5432 dbname=yohgaki user=yohgaki"); ------------------------------ 1st access ------------------------------ Notice: Undefined index: cnt in /home/yohgaki/workspace/ext/git/oss/php.net/php-src/t3.php on line 156 array(2) { ["aaa"]=> string(10) "áéíóú" ["cnt"]=> int(1) } ------------------------------- 2nd access ------------------------------- array(2) { ["aaa"]=> string(10) "áéíóú" ["cnt"]=> int(2) } ------------------------------- It seems you are having problem with BYTEA escaping. What is your PostgreSQL version, both client library(libpq) and server? Does client library (libpq) and server version match? Check phpinfo() output for client library version. Do "SELECT version()" for server version. BYTEA escaping has been changed for better performance. It seems your environment has version mismatch problem. If client library and server version matches, it should work. ------------------------------------------------------------------------ [2015-12-14 18:41:12] cdutary at grupocti dot com I took your code and added the last 2 ingredients to make PHP fail and it did: ob_start(); session_start(); echo isset($_SESSION['aaa']) ? : 'Setting value' . $_SESSION['aaa'] = 'áéíóú'; //added unicode chars to our session data. var_dump($_SESSION['cnt'] ++); $pg_conn = pg_connect("host=´host2 port=5432 dbname=database2 user=user2 password=pass2"); //added a seccond pg_conn which somehow makes session unreadable The output is: PHP Warning: session_start(): Failed to decode session object. Session has been destroyed in sesions.php on line 179 PHP Notice: Undefined index: cnt in sesions.php on line 183 For now the workaround I found is to wrap up the session info in base64() before saving it into php_session and unwrap it at read. This works with both session save handlers, your's and mine. The original problem still remains and I can't find a reason for it yet. ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=71088 -- Edit this bug report at https://bugs.php.net/bug.php?id=71088&edit=1