SitePoint Sponsor

User Tag List

Results 1 to 13 of 13
  1. #1
    SitePoint Member
    Join Date
    Feb 2013
    Posts
    9
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Endless script hangs my session

    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?

  2. #2
    Hosting Team Leader silver trophybronze trophy
    cpradio's Avatar
    Join Date
    Jun 2002
    Location
    Ohio
    Posts
    5,058
    Mentioned
    152 Post(s)
    Tagged
    0 Thread(s)
    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.
    Be sure to congratulate Patche on earning July's Member of the Month
    Go ahead and blame me, I still won't lose any sleep over it
    My Blog | My Technical Notes

  3. #3
    SitePoint Member
    Join Date
    Feb 2013
    Posts
    9
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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?

  4. #4
    SitePoint Addict bronze trophy vectorialpx's Avatar
    Join Date
    Dec 2012
    Location
    Bucharest
    Posts
    247
    Mentioned
    8 Post(s)
    Tagged
    0 Thread(s)
    On a problem like this, you need to create your own debug. In the problem-zone try something like this

    PHP Code:
    <?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.

  5. #5
    SitePoint Member
    Join Date
    Feb 2013
    Posts
    9
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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...'. :-(

  6. #6
    SitePoint Addict bronze trophy vectorialpx's Avatar
    Join Date
    Dec 2012
    Location
    Bucharest
    Posts
    247
    Mentioned
    8 Post(s)
    Tagged
    0 Thread(s)
    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.

  7. #7
    SitePoint Member
    Join Date
    Feb 2013
    Posts
    9
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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?

  8. #8
    Hosting Team Leader silver trophybronze trophy
    cpradio's Avatar
    Join Date
    Jun 2002
    Location
    Ohio
    Posts
    5,058
    Mentioned
    152 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by rv0987 View Post
    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?
    Be sure to congratulate Patche on earning July's Member of the Month
    Go ahead and blame me, I still won't lose any sleep over it
    My Blog | My Technical Notes

  9. #9
    SitePoint Member
    Join Date
    Feb 2013
    Posts
    9
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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

  10. #10
    Hosting Team Leader silver trophybronze trophy
    cpradio's Avatar
    Join Date
    Jun 2002
    Location
    Ohio
    Posts
    5,058
    Mentioned
    152 Post(s)
    Tagged
    0 Thread(s)
    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.
    Be sure to congratulate Patche on earning July's Member of the Month
    Go ahead and blame me, I still won't lose any sleep over it
    My Blog | My Technical Notes

  11. #11
    SitePoint Addict bronze trophy vectorialpx's Avatar
    Join Date
    Dec 2012
    Location
    Bucharest
    Posts
    247
    Mentioned
    8 Post(s)
    Tagged
    0 Thread(s)
    Code:
    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)

  12. #12
    SitePoint Member
    Join Date
    Feb 2013
    Posts
    9
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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.

  13. #13
    SitePoint Guru
    Join Date
    Nov 2004
    Location
    England
    Posts
    698
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    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


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •