#20449 [Com]: sessions randomly fail

From: Date: Tue, 06 May 2003 08:38:53 +0000
Subject: #20449 [Com]: sessions randomly fail
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-39145@lists.php.net to get a copy of this message
ID: 20449 Comment by: php dot bugs dot krishaven at spamgourmet dot com Reported By: josh at zebotech dot com Status: Open Bug Type: Session related Operating System: redhat 7.3 PHP Version: 4.4.0-dev New Comment: One of our sites has this problem. A phpinfo() page for them is at: http://www.myibt.vic.edu.au/help.php It's runnning Redhat 7.3, PHP Version 4.3.0 and Apache/1.3.27 Note: This is a production system and may get downgraded in the next few days if we can't resolve this problem. We have a page that sets eight associative arrays as session variables. It *always* falls over (apache segfaults) when you set all eight. The session corrupts and no other page ever loads until you kill the session or manage to unset the arrays. Sometimes if you only set one or two associative arrays, it survives. However, if you set only enumerated arrays (mysql_fetch_row instead of mysql_fetch_array) you can set as many as you want (we've tested up to 40 copies on just that page) and it never fails. When you look at the session info in /tmp it appears to be complete, so it's as if there's a problem reading associative arrays back from session variables. I have also set the associative arrays, then gone to a page that doesn't depend on a valid session to work, just displays the raw $_SESSION contents. Each refresh comes up slighly different, but sometimes it comes back perfectly, indicating again that it's probably a read problem not a write one. We have some major portions of a wide circulated web system that have been written expecting associative arrays to survive session registration. Major things like student enrolment. While it appears that we could re-write everything to only use enumerated arrays, we simply do not have enough days until the next enrolment period to manage this. By the same token we have some sites that specifically do not want to downgrade their installations. Previous Comments: ------------------------------------------------------------------------ [2003-03-13 17:08:29] dave at flitsservice dot nl * PHP Version 4.2.2 (and 4.1.1) * Apache 2.0.40 (and 1.3.23) * Windows NT 5.1 build 2600 (Windows XP sp1) Allright, I experience this problem also! (thnx Google). It drives me mad, I already did a downgrade to PHP v4.1.1 without succes. I experience the same situation as jpmarray, the page looks like it loads, I get some HTML code and a part of my page is displayed... Suddenly it breaks off the output showing some unfinished HTML code and a "Page cannot be displayed" occurs. And I'm talking of the well known phpinfo.php now! The strange thing which someone else mentioned also here, is that it works perfectly well with all non-IE related browsers. I tested it for example with Mozilla 1.0 and everything is working fine. And now comes the strange part. I have another server here, running exactly the same OS (Windows NT 5.1 build 2600) and exactly the same installation and php.ini file (version 4.1.1) and that is working perfectly well. The only difference is the Apache server version; 1.3.23 And I don't want to downgrade Apache unless I have too... Oh and another thing, I tried to run phpinfo.php on different machines, all resulting with the same problem. No go with IE and Mozilla and Opera 7 everything looks OK... But while I test this when I'm writing this now, I see that it isn't OK either with other browsers... It does not result in a "page cannot be found" error but it just unfinishes the page ending. This looks like it's doing it at random... Sometimes stopping earlier and sometimes near the end of the output... Very strange! Nothing is wrong with my php maximum execution time or something. Remember that I have two different servers with exactly the same PHP installation... Maybe I'll try an Apache downgrade to exclude some things out tomorrow... First I'll get some sleep, luckily this is less critical than the problem of Josh... Dave Lolkes de Beer The Netherlands ------------------------------------------------------------------------ [2003-01-31 14:57:30] jpmurray at hxti dot com Hello all, * PHP Version 4.2.3 * Apache 1.3.27 * Linux * config: ./configure' '--with-apxs' '--with-oci8=/usr/local/oracle/m01/app/oracle/product/8.1.7/' '--with-openssl' '--with-curl' '--with-mysql' I'm having this problem every day, and can reproduce at will. Extremely frustrating. For me it only occurs upon (successful) login to my site. Instead of going to the php index, I get a "Page cannot be displayed". I'm using non-cookie sessions managed by an Oracle database. Once I am in, past the login, the error never occurs however. It seems only to be a problem when the session is first initialized via session_start(). After this, I pass the sid via the URL, and its subsequently checked by the target script against the oracle db for authenticity- No problems at all there. Does anybody else see this problem occur only upon doing things such as logging in? Thanks, J. Murray HX Technologies ------------------------------------------------------------------------ [2003-01-08 11:45:20] phpBug20449 at rehner dot net Further testing shows that on Windows 2000 Server with Identical Configurations as the Windows 2000 Pro (I did diffs to be sure) reveals: Win2000Server 2 Processor- 2 failues in an estimates 300,000 tests. Win2000Server 4 processor - 0 failures in 1000 tests (Just started running this one.) Basically I had everyone in the office run the test against the 2 Processor system at the same time. Only 2 failures in that many requests I can live with. So is it more of an issue on less capable systems? ------------------------------------------------------------------------ [2003-01-08 01:52:58] josh at zebotech dot com interesting. However, I switched my session manager to a dbase function and it still died. How would file locking effect that? I'm interested in the fact though that you can actually witness the bug first hand. I only saw that it was happening. However, I could never get the thing to happen to me. Also, since I have gone to my own session code without using php's built in sessions, I don't have problems at all anymore. Josh ------------------------------------------------------------------------ [2003-01-08 01:19:06] bug20449 at rehner dot net My script will fail in as short as 1 request or over 1000 requests. I did set session.gc_probability = 0 but still fails. -Ryan ------------------------------------------------------------------------ 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/20449 -- Edit this bug report at http://bugs.php.net/?id=20449&edit=1

« previous php.bugs (#39145) next »