Hi,
I have a php script that for some reason sometimes either goes into an endless loop or it just fails & ends. Eitherway, the session is not released which causes other requests from the same session to wait endlessly.
What could cause this? How can my script run endlessly OR fail without releasing the lock on the session?
If the script goes into an endless loop it looks like it does so when I do a quite simple sql-query.
Any hints?
Can you post code? If not, I’d focus on getting xDebug installed and running a profile. You may have to abruptly killing the process to stop the endless loop, but then you could review the profile report and see directly where the endless loop is located.
Thank you. Problem with xdebug will be that the problem only happens now and then. While we must let xdebug run all the time.
I have the feeling that ist is the PDO/Mysql driver that is crashing without properly closing the script and handling the error. Have any one seen this before with PDO?
On a problem like this, you need to create your own debug. In the problem-zone try something like this
<?php
if( !isset($_SESSION['_passed_']) ) {
$_SESSION['_passed_'] = 0;
} $_SESSION['_passed_']++;
echo $_SESSION['_passed_'];
?>
This will check if you are into a loop.
Now, about the PDO, make sure you use a try-catch so when things will stop you’ll know the reason.
The problem is, there is a ‘global/catch-all’ try-catch but it does not catch anything.
So either I am in an endless loop, or php crashes without being able to handle the exception. And all this I expect to happen somewhere in PDO because the problem area seems to be a rather simple ‘select * from table where…’. 
If you have crack that does not appear in logs it might be a require stuff or some memory crash.
To debug you just have to add die(“here and there”); over some key places so you’ll see when it blows.
A simple PDO error will not crash you PHP, will just send you a warning.
I have been able to trace down the a bit further. What I now see is that some queries take (exactly) 930 sec. to complete. These are normal queries over the unique index. Nothing special.
Could this be some issue in PDO or mysql?
I’ve yet to run into such a problem with PDO or MySQL, are you sure your query is good? And that the query itself isn’t running a long running query? Or maybe you are stuck executing the query in an endless loop? Maybe a networking issue is happening? Memory limit?
I don’t believe my eyes either. But here is an extract from the logs:
DEBUG –> 930.808… row-count: 0 ; select * from tblUserDevice where deviceId = ? order by 1… tO/lbqCtVxr
DEBUG –> 931.006… row-count: 0 ; select * from tblUserDevice where deviceId = ? order by 1… tO/lbqCtVxr
DEBUG –> 931.223… row-count: 0 ; select * from tblUserDevice where deviceId = ? order by 1… tO/lbqCtVxr
DEBUG –> 931.283… row-count: 1 ; select * from tblUserDesktop where UserID = ? order by 1… 75
DEBUG –> 930.922… row-count: 1 ; select * from tblUser where id = ?.. 75
DEBUG –> 930.805… row-count: 3 ; select * from tblUserPersonalDesktop where UserId = ? order by 1… 75
These are al simple indexed queries on table with less then 500 rows. The 930.xxx is the execution time of the query.
Very 
Is anything locking the query? An Update, Insert, Delete, Transaction of some sort? A transaction that was never committed or rolled back could be a candidate for these sporadic issues.
select * from tblUserDevice where deviceId = ?
The ? is what matters 
so you canot be sure that those 500 rows are matched unless you know the ?
If you can, try to trigger an echo OR add the value into the SQL (just for debug)
It turned out that we were using pdo-persistent connections and they broke it. We are now running for 2 weeks on non-persistent connections and no more problems.
I’ve read so many times that persistent connections are bad! In some cases I’ve seen people say that they’ve been forced to use them, but so many people have had some really difficult problems to find, and they’ve ended up being as a result of persistent connections. Personally, I never use them unless specifically required