ID: 14529 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Critical Bug Type: Output Control Operating System: Linux RH 7.2 PHP Version: 4.3.0-dev New Comment:
I did the same thing a while back and things appeared to work again. My screens were not getting cut off on every page load. But apache still crashed on almost every page viewed. Somehow, IE was able to display the page (I'm thinking though cache but it caught some of the newer info - but not always) but Netscape, Opera and some linux browsers simply displayed an error that they could not connect and eventually even in IE the pages started getting cut off again. It's as if apache crashed anyways for me only crashed sooner if the session read function returned false instead of an empty string. I've cut my program very small and eliminated all include/require statements thinking I'd add them until the problem occured, only as a base program (still fairly complex) the problem still occurs. Yet I've written some very simple pages and they don't crash. It's almost like it's a combination of tasks that cause it. Previous Comments: ------------------------------------------------------------------------ [2002-03-26 18:22:30] [EMAIL PROTECTED] YEAH! IT WORKS! I've solved my problem! It was related to my session_handling and the session_read function. When I forced the function to ALWAYS return a string, even if it was an empty one apache stopped crashing! return (string)$value; Previously I sometimes returned other values such as the boolean false. This didn't make apache crash with 4.0.6 but it does with the later versions. *happy happy happy* The page works like a charm again! No cut off pages! No messed up posted forms! No more weird sessions that doesn't register! I LOVE IT! ------------------------------------------------------------------------ [2002-03-20 06:18:03] [EMAIL PROTECTED] http://www.php.net/manual/en/function.session-set-save-handler.php On this page are a lot of comments, one of them was striking: <quote> 04-Mar-2002 02:57 I just want to mention, that it's critical to return a string value with the read function, because there can be strange errors if - for example - the return value is null. In my case the php program stopped in the middle of an "echo" command, so it was really hard to find, that the real problem was with that session read callback function. The easyest way to handle this, that you should cast the return value before return. For example: function read ($id) { /* code here to produce $retval */ return (string)$retval; } </quote> Weird, isn't it, but maybe it helps getting more close to solving the problem. ps: we've got php4.1.2 now installed as a CGI, session.save_handler=files, still using the session_set_save_handler function (although it doesn't say so in the tutorial -explicitly- it does override the 'files'-setting, see one of the other comments) and I don't have any problems anymore. At least, not until now, fingers crossed. ------------------------------------------------------------------------ [2002-03-19 16:28:14] [EMAIL PROTECTED] Responding to albert. My system also needed to have session.save_handler set to user for load balancing. However, I tried using files instead and at first I thought it worked fine but it turned out it still crashed, only less often and at different points. (Previously code output always stopped at specific spots when it crashed and only on some pages, this just changed the point at which it would crash and other pages that before had no problems didn't appear correctly. Some have suggested they removed sessions all together and still had the problem and others claim the problems stop if sessions are not used. (Maybe there is two completely different bugs causing similar problems). It seems as if this bug has nothing that anyone has been able to narrow down as what causes the problem. Besides apache crashing (Segmentation fault)I have noticed that other small things don't opperate properly since version 4.0.6 that should. Here are two other things I've seen give problems and confirmed through test scripts. 4.2.x (or 4.3.x) unserialize() does not recognizing values set by serialize() in PHP 4.0.x. My system stores arrays using the serialize() function into a database (such as a color scheme). When I upgrade to 4.2.x or new snaps, when those strings are pulled from the database, the unserialize() function will gives an error that it couldn't read the string (this is not a magic_quote issue as settings are the same). Session variable values getting corrupted: For example at one point I had a transparent graphic shim.gif used on a page to keep columns widths in line. That graphic was moved to a new location but a php's script was not updated from <img src="shim.gif> to <img src="/images/shim.gif">. This meant the HTML that PHP returned to the visitors browser had a simple invalid link in it and the page should load normally with just an empty placeholder where the image shim.gif was to be. However, even though this did happen it also did mess up session variable values. A simple test created that had the HTML code with the invalid location for shim.gif in the image tag along with the lines: echo $HTTP_SERVER_VARS['PHP_SELF'].'<br>'; $HTTP_SESSION_VAR['lastpage']=$HTTP_SERVER_VARS['PHP_SELF']; echo $HTTP_SERVER_VARS['PHP_SELF'].'<br>'; would output correctly: pagename.php pagename.php BUT the session $HTTP_SESSION_VAR['lastpage'] upon the next page load would be equal to 'shim.gif' and not 'pagename.php' like you'd expect. So even though $HTTP_SERVER_VARS['PHP_SELF'] returned (and must have set the correct value), setting it into a session changed the value of it. These problems did not happen in version 4.0.6 or older, so they may have something to do with the bug of shutting down apache but I don't know enough of how PHP is written to really know. Hope this helps. ------------------------------------------------------------------------ [2002-03-19 10:03:48] [EMAIL PROTECTED] Check out bug-report #15940, talking about propably the same problems there ------------------------------------------------------------------------ [2002-03-19 10:00:27] [EMAIL PROTECTED] Read the whole thread, concluded that I've got the same problems as described by jay1 First we thought that it maybe was an Apacheproblem, so we installed an older version than 1.3.23, namely 1.3.20 This didn't help, same bugs appeared. Fiddled around with fopen, nothing there. Read this thread and came to the idea to set session.save_handler to files instead of user (wich setting actually IS necesary, because we loadbalance our site with three mirrored servers). And since then, no problems at all. My question now is to jay1: how is session.save_handler in your php-config? ------------------------------------------------------------------------ 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/14529 -- Edit this bug report at http://bugs.php.net/?id=14529&edit=1
