ID: 15983
Comment by: pratesi@telug.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:
RH 7.3 on i386???
Noooo.... do you have enabled cookies? :-)
Apart from joking, the problem we are mentioning
seems to be strictly related to non-i386 platforms,
while I do not have any problem on both Debian Woody
and RH 7.3, both with PHP 4.1 and 4.2.
I have problems only on PPC (I still haven't had time
to test on Debian Sparc, I should try in september),
but the workaround that I have mentioned seems to be
correctly working since from many days on my new server :-)
BTW, the workaround that I'm using corresponds to using
the same code that it was used in PHP 4.0 and that worked
for me also on Debian Sparc and on Linux PPC.
Previous Comments:
------------------------------------------------------------------------
[2002-08-28 13:07:51] kt@mconline.dk
Im using RH7.3 - PHP 4.1.2 and i have all the mentioned symptoms.
When using header for redir i seem to loose the session vars.
I seem to be stuck here
Looking forward to hear any suggestions :)
Regards,
Kristian
------------------------------------------------------------------------
[2002-08-27 11:33:21] niimai@tiscali.it
It seems that also on WinXP, when I do redirects between pages, I
experience the same problem, using header("Location: URL");.
------------------------------------------------------------------------
[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
------------------------------------------------------------------------
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