session_start() Never Returns!

[magicdanw]

I'm trying to help out a friend who has a website based on PhpProBid.  The login page works sometimes, but quite often it hangs on a white page, and then every page on the site does the exact same thing.  I've traced it all down to the line session_start() at the top of each page.  If I'm not mistaken, this is a core PHP function that loads a session based on the ID found in the local cookie.  Clearing the cookie fixes access to the website temporarily, but the problem reoccurs.

 

Now, what could cause this core PHP function to hang forever and never return or give any error?  Could anything wrong in the website's source code corrupt the PHP session data that much?  Or should I assume that it is a server problem (he is on a very cheap, unreliable server) and recommend that he switch servers?  If there is a chance that PHP code could corrupt the session data to the point where it can't be loaded.....well, it's a big site, and I don't know where I would begin debugging this.

 

By the way, is there any way to view the raw contents of the PHP session data?  I can't SSH into the server, I only have CPanel access (I really wish my friend would switch to a decent hosting company )  I just don't understand, if session data is only written to by reliable core PHP functions, how can this happen?

[btherl]

The session handler can be replaced by another back end, such as one that stores the data in a database.  http://sg2.php.net/manual/en/session.customhandler.php

 

Apart from that, the core session handler might hang if it can't create or read the session file, I would imagine.

 

We had similar issues before, but it was with a custom session handler holding a lock on session data, preventing any other requests from the same session from running.

[PFMaBiSmAd]

Add the following three lines of debugging code immediately after the first opening <?php tag and before the session_start() statement and see if there are in fact any php detected errors -

 

ini_set("display_startup_errors", "1");
ini_set("display_errors", "1");
error_reporting(E_ALL);

[magicdanw]

Oh god...I don't think I've seen so many warnings on one page.  Whatever guy my friend said he hired to modify his website previously......I don't even want to know what he was thinking.

 

Anyway.  There are tons and tons of warnings on each page, mostly about undefined variables and stuff, but no errors.  The site does seem to work though...until you try to log in about 50% of the time.  In this case, as I stated, session_start() never returns, so obviously the page is never loaded, meaning that if there are any errors or warnings, I don't get to see them.

 

My friend said that he never had the problem logging in, so either it's computer/browser related (?) or he just hasn't logged in and out as many times as I have (likely, since I'm the one working on the code).  Still, I'll go try it out on another computer, see how it goes.

[PFMaBiSmAd]

Have you checked the web server error log for any related errors?

 

What does a "view source" in the browser show for the resulting white page?

 

How did you determine that the problem was related to the session_start and that the session_start was not returning to the code? We only see the information you provide in your post, and well, how you determined this and what other symptoms you have observed could tell someone what the problem is.

 

If the symptom only shows up for you, it might be due to the URL's that you are using to reach the page(s). Perhaps the host part of the URL is being changed (www. vs no www.) on different pages and the session cookie settings don't cause the session cookie to match.

[magicdanw]

I tried another computer, and it seems to work okay, so maybe it is just something odd with my setup...

 

There is no source code, nothing at all is sent from the server, and session_start() hangs because nothing after it is executed (echos, etc.), and when I set a limit on script execution time, it finally stops with a blank page.

 

There's nothing wrong with the URL scheme, because www.domain.org automatically redirects the user to domain.org.  The site is configured to never use www.domain.org for anything links.

 

The error log....oh boy.  There are soooo many warnings about undefined variables and such.  But one problem that looks like it may be somewhat related is that every so often, a PhpProBid cron job tried to run session_start() itself and fails, because a session has already been loaded.  However, this cron job is completely PhpProBid code, nothing has been modified.  Does this suggest anything?

[PFMaBiSmAd]

There is no practical reason for a script being rung by cron to do a session_start() and if that results in an error (posting the actual error message would help narrow down what is happening) that there was already an existing session start, that would indicate the script is doing something unexpected.

 

If the script being run by cron is cycling through all the sessions for some purpose (a really bad design idea), it could cause a problem due to the session data file locking.

 

The overall symptom sounds like file locking when a page has frames or images that all attempt to start the same session as the main page.

 

In the case where you have set the execution time limit and have the lines that set error_reporting/display_errors, did you get any php errors?

 

Also, what php version? php5.2.5 (if I remember correctly) had a bug where if output buffering was turned on in php.ini, that fatal errors were not output even when the error_reporting/display_errors settings should have causes them to be output.

[magicdanw]

The error doesn't seem to have occurred again recently, so I can't see what exactly it said.  You got the gist of it though.  However, the login problem is still occurring even without the errors around.

 

As far as I can tell, the cron job is indeed cycling through the sessions for a general cleanup.  God only knows why, but it doesn't seem to be the (sole) cause, since the lockup occurs even when the job isn't running.

 

Apparently now, setting the execution time limit doesn't manage to stop session_start().  That could mean that the problem lies in a system call that doesn't return, right?  The one time I did get it to stop with a time limit, there were no errors displayed.

 

The php version is 5.2.8.

[PFMaBiSmAd]

That you can clear the problem by deleting the session cookie, means that the server itself is not experiencing a fatal problem. That leaves something the script is doing to or with the sessions or something specific to the computer/browser that you were using.

 

Do you know for a fact that the script has not replaced the built-in file session save handler with a custom one that is using a database? That would be about the only reasonable way that the cron executed script could be cycling through anything to do with cleaning up sessions. What does that code look like?

 

Also, if this is on a shared web server, has the session.save_path been set to a private folder within the account's folder tree? If the session save path is still the default shared folder, something that a completely different account is doing to the session data files could be causing the problem.

 

Related to the above, is the code for the rest of the site doing anything with any of the session settings, such as setting a short session.gc_maxlifetime setting (in a misguided attempt to limit the length of a log in.) Is the code for the rest of the site using $_SESSION variables that could be in conflict with the $_SESSION variables that the PhpProBid script is also using?

[magicdanw]

I'm 99% sure that the session save handler being used is the one build into PHP.  Granted, I'm not 100% sure, since PhpBidPro seems to have no available documentation Here's the cron code (after a session_start()):

## suspend users in account mode that have their credit limit exceeded.

$remove_session = suspend_debit_users();

if ($remove_session)

{

$session->unregister('membersarea');

}

 

It is on a shared web server, and the session save path is "N;/path".  I'm not sure if that means that it is within the account or at the root of the web server...but wouldn't a web host prevent one user's sessions from overwriting another's by default?

 

PhpBidPro is currently the entire site, so the session should be entirely under its control.

[btherl]

I would try changing the session save path.  It's worth a try.

 

I wouldn't worry about the E_ALL warnings.  Code that's quite solid can produce a lot of "notices", which will show up with E_ALL, and getting rid of them can often make the code less readable.

[magicdanw]

I've changed the path, but it didn't help I think it may just be some weird quirk specific to my setup.