#20449 [Com]: sessions randomly fail

2002-12-02 Thread nbrandon 
 ID:   20449
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Session related
 Operating System: redhat 7.3
 PHP Version:  4.4.0-dev
 New Comment:

[General Message - Not Bug Specific]

In the past 12 months, I've raised a number of bugs relating to session
problems that could not be reproduced consistently with the standard
reply of 'its been fixed in CVS/Try CVS version'. I've tried the new
CVS version and problems still continue (but still erratically).

Over time, I've noticed a lot of developers problems (bugs) seem to be
related to the global $_SESSION variable and I personally feel that the
most stable session module is still in PHP version 4.0.6 before
introduction in the 4.1 series.

I'm not a hardened programmer, so this is a call to the current and
previous developers/maintainers to consider a complete design and code
walkthrough of the 'session related' code. Personally, I feel sessions
is one of the key feature areas of PHP and something that needs to be
highlighted to both Zend and the community to be made 'rock-solid'.

Thanks
Nick


Previous Comments:


[2002-11-25 18:22:39] [EMAIL PROTECTED]

After a good weekend we are having an incredible Monday.  My code in
place now uses serialize/unserialize.  I also convert my arrays to
strings with implode/explode before the serialization/unserialization
process.  I don't see any missing information anymore in my session
table.  

I really think the session serialize code is at fault for this bug. 
Specifically I think it simply doesn't handle arrays.  (perhaps objects
but my object simply had the array in it.  Removing the array from the
object and not using objects did not work)

This is an extremely serious bug that was costing us on average of
about 30-50 orders a day.  I am honestly not exaggerating on this
figure.  I tried the CVS version as late as 11-15-2002 and it still had
the bug in it.  Before that I was using the latest 4.2.3 version.

I'd like a little feedback from the developers to at least say they are
looking into it.  I will try to assist in any way I can.  However, as I
have said before, it was very random and I myself never saw my session
disappear.  Also important to note is that I do not rely on Session
Cookies so it is not related to cookies.  

Also, I tried doing the reset(arrayvar) after each session restoration
as suggested on one of the session man pages.  That too did not work. 

I hesitate to say but I really think it would be important to make note
to people that the session code is not reliable.  Perhaps in the man
pages.  I won't go to such length though as to warn them myself though
I feel some duty to do so.  Perhaps the bug only comes into play on
high traffic servers.  Either which way, not relying on the internal
session code has made a huge difference.  That in itself should prove
something.



[2002-11-25 11:46:34] [EMAIL PROTECTED]

This seems to be exactly the same problem we are having with one
particular visitor to one of my websites. He always has this problem,
every time he logs in his session expires. I have gone through his
client PC configuration very carefully, and cannot find anything
unusual. What's more odd is that he used to be able to use my site
without problems.

Would this problem manifest itself at random, or would it affect
specific PCs? I had assumed the problem was at his end until I read
this message thread, and it looked strangely familiar.

Jolyon



[2002-11-22 16:20:08] [EMAIL PROTECTED]

Just thought I'd add that we are having what - seems to be - the same
problem.
We are running on Solaris 8 and our sessions are being held in a tmpfs
mount that's balanced across 4 sun 220's.
PHP Version 4.2.2 and Apache 1.3.26 compiled staticly.

We've been moving the session store method around thinking I/O was the
issue but it hasn't helped. We've done NFS mounted share, local-only
share on 1 220 (limiting the load-balancing for one site to only that
box) and now tmpfs.

Our sessions are rather large (at least for me) normally around 11,316
bytes with objects and arrays w/ members that are serialized objects.
It's probably important to note that we are avoiding automatic
serialize/deserialize of objects by doing $_SESSION['someName'] =
serialize($Object) type stuff.

In almost all cases the sessions are there, but a couple values are
simply missing.

If you need anyother info please let me know.



[2002-11-21 21:52:36] [EMAIL PROTECTED]

Ok.  I think I have a really good idea as to what the bug is.

I am pretty sure there is a bug in the session serialization functions.
 (and perhaps the normal

#18031 [Fbk-Opn]: PHP engine runs user-based read and disconnect functions when open return false

2002-09-30 Thread nbrandon 

 ID:   18031
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   Open
 Bug Type: Session related
 Operating System: Win ME
 PHP Version:  4.1.2
 New Comment:

Will not be able to test the new snapshots until a couple of weeks
time.


Previous Comments:


[2002-09-29 13:46:06] [EMAIL PROTECTED]

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





[2002-06-28 06:01:13] [EMAIL PROTECTED]

Just looked at the code for php4/ext/session/session.c revision 1.310.

I'm no real coder but, I believe the area of code thats causing the
problem is

...
static void php_session_initialize(TSRMLS_D)
{
char *val;
int vallen;

/* Open session handler first */
if (PS(mod)-open(PS(mod_data), PS(save_path), PS(session_name)
TSRMLS_CC) == FAILURE) {
php_error(E_ERROR, Failed to initialize session module);
return;
}
...

I believe the return should read

return FAILURE;

I could be completely way-off - but thats my 2-cents.



[2002-06-27 19:51:50] [EMAIL PROTECTED]

I have created my own session handler using both a function and class
based approach. On both occasions, when the open function returns a
failure - return false;, PHP engine tries to run both the read and
disconnect functions. This causes a fatal error as shown below.

Fatal error: Call to undefined function: query() in
f:\cvs_dev\Neutec\website\www..co.uk\site\include\DBSession.class.inc
on line 139

Fatal error: Call to undefined function: disconnect() in
f:\cvs_dev\Neutec\website\www..co.uk\site\include\DBSession.class.inc
on line 109

On both lines, PHP is trying to connect to the database using a
database handler variable, and since the variable has not been
initialised (because the open function failed), these fatal errors
occur.

If the PHP engine could not open a session, then it should not try
and read or disconnect a session on exiting.

Full source code can be supplied on request.

Many Thanks
Nick







-- 
Edit this bug report at http://bugs.php.net/?id=18031edit=1