#15983 [Com]: session variables lost between pages

From: Date: Tue, 27 Aug 2002 15:33:22 +0000
Subject: #15983 [Com]: session variables lost between pages
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-17941@lists.php.net to get a copy of this message
ID: 15983 Comment by: niimai@tiscali.it Reported By: sl@scrooge.dk Status: Open Bug Type: Session related Operating System: Debian/Linux mips platform PHP Version: 4.1.2 and 4.2.0 New Comment: It seems that also on WinXP, when I do redirects between pages, I experience the same problem, using header("Location: URL");. Previous Comments: ------------------------------------------------------------------------ [2002-08-22 06:33:37] pratesi@telug.it The following patch seems to workaround the problem for me, on Debian Woody PPC: --- ext/session/mod_files.c.orig Tue Apr 23 20:10:49 2002 +++ ext/session/mod_files.c Thu Aug 22 11:41:05 2002 @@ -255,12 +255,16 @@ data->st_size = *vallen = sbuf.st_size; *val = emalloc(sbuf.st_size); +/* #ifdef HAVE_PREAD n = pread(data->fd, *val, sbuf.st_size, 0); #else +*/ lseek(data->fd, 0, SEEK_SET); n = read(data->fd, *val, sbuf.st_size); +/* #endif +*/ if (n != sbuf.st_size) { efree(*val); return FAILURE; I.e., use of the read instead of pread seems to fix the problem. I wonder if this is a PHP bug (maybe endianess?) or a glibc bug. ------------------------------------------------------------------------ [2002-08-21 07:48:37] pratesi@telug.it I am affected by just the same problem on Debian Woody PPC with PHP 4.1.2. I also get a sigsegv: gdb /usr/sbin/apache [...] (gdb) run -X [...] Program received signal SIGSEGV, Segmentation fault. 0x0f3e61d8 in zend_hash_get_current_key_ex () from /usr/lib/apache/1.3/libphp4.so It seems that this sigsegv does not occur with PHP 4.2.2. Using session.save_path = mm seems to workaround with PHP 4.1.2, but I would prefer to avoid using libmm, which now is a dead project; moreover, this workaround is rather awkful, as sessions get lost if Apache is restarted (e.g. to let it reread httpd.conf after some changes). BTW, which other options are available apart from session.save_path = files and session.save_path = mm ? I fear that this will force me to downgrade to PHP 4.0.6, but I cannot keep the server outdated for too much months :-( ------------------------------------------------------------------------ [2002-05-29 15:59:12] foosnb@nc.rr.com I'm working with win version 4.1.2, and while the very first example's code worked find for me (printed 'Hello world' as expected), the test script from sniper@php.net did not. From my testing, it appears as though using $_SESSION just doesn't register a value with the session, although it maintains any changes to a variable once it has been registered with the session. If instead of, <?php if(!isset($_SESSION['test'])) { $_SESSION['test'] = 0; } echo $_SESSION['test']++; ?> you use, <?php if(!isset($_SESSION['test'])) { $test = 0; session_register('test'); } echo $_SESSION['test']++; ?> the script will increment the variable just fine. But because $_SESSION['test'] = 0; doesn't set/register the variable the first time, each time you refresh you will find yourself stuck in the if statement, and the value still stuck at 0. -- foos ------------------------------------------------------------------------ [2002-04-30 13:47:37] herrington@topiksolutions.com This bug is killing me. Anyone tried 4.1.2 RC4 ? Otherwise, I am rolling back to 4.06. Don't really have time to do the workarounds.... ------------------------------------------------------------------------ [2002-04-28 07:31:44] sl@scrooge.dk Tried the latest snapshort and I have started to debug the code myself using to computers a i386 as reference and the MIPS. We will see how much I can debug of this. Regards, Søren, ------------------------------------------------------------------------ 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 http://bugs.php.net/15983 -- Edit this bug report at http://bugs.php.net/?id=15983&edit=1

« previous php.bugs (#17941) next »