#15983 [Fbk->Opn]: session variables lost between pages

From: Date: Tue, 10 Sep 2002 15:28:17 +0000
Subject: #15983 [Fbk->Opn]: session variables lost between pages
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-18943@lists.php.net to get a copy of this message
 ID:               15983
 User updated by:  sl@scrooge.dk
 Reported By:      sl@scrooge.dk
-Status:           Feedback
+Status:           Open
 Bug Type:         Session related
 Operating System: Debian/Linux mips platform
 PHP Version:      4.1.2 and 4.2.0
 New Comment:

Nope, the patch still failes on MIPS.

I'll see if I can get my patch to work.

Regards,

Søren


Previous Comments:
------------------------------------------------------------------------

[2002-09-10 07:35:12] kalowsky@php.net

Please try using this CVS snapshot:

  http://snaps.php.net/php4-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-latest.zip

In 4.2.3, there is no more PREAD functionality.  Please try that and
see if these problems continue.

I took out the PREAD functionality in cvs HEAD, but sascha has
re-added.  He has also placed some further tests to ensure that it
works.... so try that as well, so we can see if thats stable.  

My local test box doesn't support it, so...

------------------------------------------------------------------------

[2002-09-10 07:06:08] sl@scrooge.dk

Tried the patch it did not work.

I have worked on a patch my self but it is not ready yet.

It goes something like this:
if( OS == linux ) && (arch == 'mips') 
disable_pread

One should be able to include other arch if needed.

Regards,

Søren

------------------------------------------------------------------------

[2002-09-09 18:23:40] pratesi@telug.it

I have downloaded the snapshot php4-200209091500;
when I run the configure on Debian Woody PPC, I read:

[...]
Configuring extensions
[...]
checking for pread... yes
checking for pwrite... yes
checking whether pwrite works... yes
checking whether pread works... yes
[...]

but maybe you want that instead, on this platform,
the check returns "no" for
"checking whether pwrite works..."
and for
"checking whether pread works..."
don't you?

------------------------------------------------------------------------

[2002-09-04 08:43:43] kalowsky@php.net

There is now a patch submitted to CVS, test the latest out and see if
it works better for you. 

------------------------------------------------------------------------

[2002-09-03 13:39:32] pratesi@telug.it

I have found some messages that could reply to our issue;
the second is a reply written by Linus Torvalds:

http://www.cs.helsinki.fi/linux/linux-kernel/2002-30/0486.html
http://www.cs.helsinki.fi/linux/linux-kernel/2002-30/0493.html

In practice, for what I'm able to understand of these messages,
it seems that, on non-i386 platforms, glibc and the linux kernel
could "disagree" about the implementation of pread() and then
that the use of pread() on linux + glibc can fail on non-i386
platforms.

Some other messages about this topic:

http://www.cs.helsinki.fi/linux/linux-kernel/2002-30/0411.html
        
                                                                 
http://www.cs.helsinki.fi/linux/linux-kernel/2002-30/0439.html
        
                                                                 
http://www.cs.helsinki.fi/linux/linux-kernel/2002-30/0469.html

And finally:

http://www.cs.helsinki.fi/linux/linux-kernel/2002-30/0559.html

where it is written that it is a glibc bug, fixed in the CVS.

I suppose that future Linux distributions will not be affected 
by this problem, but, IMVVVHO, for safety reasons, currently
the use of pread() should be avoided on non-i386 Linux platforms,
and this should solve this issue.

------------------------------------------------------------------------

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



Thread (46 messages)

« previous php.bugs (#18943) next »