• Joshua (unregistered)

    Brillant new error handling approach!

    do { LogError(); } while (true);

  • (cs)

    This kind of bug happens more often than we think. I've recently seen a similar bug, thought not in a infinite loop fashion.

  • Colin (unregistered)

    Hardly a WTF at all.  Slap a check for if not connected then log with error_log() or just bail.

    An oversight like this isn't a WTF, sheesh.

  • HopHead (unregistered) in reply to Colin

    >>An oversight like this isn't a WTF, sheesh.

    The WTF isn't the code. The WTF is that the previous maintenance developer didn't investigate and just rebooted the server any time there was an error that triggered the error trap infinite loop.

     

     

  • (cs)

    Yes, when the phonelines go dead, I quickly get on the phone to call the phone company to let them know.

    He must have left the position to move on to management.

  • Joshua (unregistered)

    The REAL WTF is the eventual stack overflow. That's what my do loop fixes!

  • (cs) in reply to Colin
    Anonymous:
    Hardly a WTF at all.  Slap a check for if not connected then log with error_log() or just bail.

    An oversight like this isn't a WTF, sheesh.


    Actually an oversight, leading to an infinite loop thereby crashing your entire program, sounds pretty much like the definition of a WTF.

    Not saying I have never done it, that I will at least admit it.
  • check that code again (unregistered) in reply to HopHead

    the code is also a WTF, because the query executed in the executeQuery function is using $sqlText to execute the query, not the parameter $string. Thus when the error occurs, it will continually execute the same query that caused the error instead of executing the error query.


  • (cs) in reply to Colin
    Anonymous:
    Hardly a WTF at all.  Slap a check for if not connected then log with error_log() or just bail.

    An oversight like this isn't a WTF, sheesh.

    You seem to have missed the point -- when the database goes down, how will you be able to write a log entry into a table in the very same database that just went down?

  • (cs) in reply to HopHead
    Anonymous:

    >>An oversight like this isn't a WTF, sheesh.

    The WTF isn't the code. The WTF is that the previous maintenance developer didn't investigate and just rebooted the server any time there was an error that triggered the error trap infinite loop.



    That is not a WTF - it is petty incompetence entrained into a support person by our Microsoft-PC environment.

    A WTF is when something is done that rises above the level of normal laziness, incompetence,  ignorance, attitude or a combination.

    This is not brillant, has no juice and isNotSortOfNull.

    In an era of Uncle-Bill-induced reboot-for-memory-leaks, it is the normal learned activity for anybody not supervized by a manager willing to slap the developer/support person/whoever/whatever for not investigating.

    Good people - the criteria for acceptance as a WTF is going south in a hurry.
  • (cs) in reply to Joshua

    I guess this was written by a programmer who knew he was going to be fired, and he wanted some closure.

  • Tim (unregistered) in reply to check that code again

    It also happens to be missing a single quote after the owner

  • Mike5 (unregistered) in reply to dhromed

    Keyboard not found! Press any key to continue...

  • 'hook (unregistered) in reply to tiro

    doesn't executeQuery() only take one argument anyway?

  • (cs) in reply to HopHead
    Anonymous:

    The WTF isn't the code. The WTF is that the previous maintenance developer didn't investigate and just rebooted the server any time there was an error that triggered the error trap infinite loop.

    He could have just coded the shutdown right in the error handling ... it would have been much easier that way and he would have had more time to adjust his fantasy baseball lineup.

  • (cs) in reply to tiro

    tiro:
    Anonymous:
    Hardly a WTF at all.  Slap a check for if not connected then log with error_log() or just bail.

    An oversight like this isn't a WTF, sheesh.


    Actually an oversight, leading to an infinite loop thereby crashing your entire program, sounds pretty much like the definition of a WTF.

    Not saying I have never done it, that I will at least admit it.

    Yeah I ran into one that had a CheckUser() function in the HandleError() (so you could insert the user name into the log).  Of course the CheckUser() function also had an error handler that led to the HandleError() function .... similar results.  Talk about a stack overflow

  • Zygo Blaxell (unregistered) in reply to check that code again
    Anonymous:
    the code is also a WTF, because the query executed in the executeQuery function is using $sqlText to execute the query, not the parameter $string. Thus when the error occurs, it will continually execute the same query that caused the error instead of executing the error query.




    Almost...it's the other way around.  Instead of executing the offending command, it executes some random sql query.  One of the possible sql queries it could be executing is the query that writes a log message.

    It's also odd that writeErrorToLog gives two arguments to executeQuery but executeQuery seems to need only one...
  • wkapri (unregistered)

     $sqlText =
    "INSERT INTO errorLog (ownerID,time,description,script) " .
    "VALUES ('" . $owner . ",Now(),'" . $description . "','" . $script . "')";

    isn't an apostrophe missing?

     "INSERT INTO errorLog (ownerID,time,description,script) " .
    "VALUES ('" . $owner . <FONT style="BACKGROUND-COLOR: #7fffd4">"<FONT color=#ff1493>'</FONT>,Now</FONT>(),'" . $description . "','" . $script . "')";

  • Hilarious (unregistered) in reply to Cooper
    Cooper:
    That is not a WTF - it is petty incompetence entrained into a support person by our Microsoft-PC environment.

    A WTF is when something is done that rises above the level of normal laziness, incompetence,  ignorance, attitude or a combination.

    This is not brillant, has no juice and isNotSortOfNull.


    I'll agree this is pretty much incompetence, and not really crazy enough.

    However, it was the first one in a long time that actually made me laugh out loud when I read the code.  (the truly brillant ones usually make me cry, rather than laugh)



  • AASoft (unregistered)

    hey, thats exactly what our system did untill not so long ago....and it was a web application too.

    lol, i dont even have an account here, but just had to comment on that.

  • (cs) in reply to Colin

    Anonymous:
    Hardly a WTF at all.  Slap a check for if not connected then log with error_log() or just bail.

    An oversight like this isn't a WTF, sheesh.

     

    You missed it.

     

    The code follows this logic:

    write data to database, if fail then call the write error to log routine, which calls the write data to database routine to write the error to the log.

     

    It's called an infinite loop.

  • (cs)
  • Arne (unregistered)

    How often does your MySQL server fail right in the middle of script execution? He could have added a different error handler for when mysql_connect() fails and with the above code he wants to log any queries that might fail for whatever reason.
    However, there must have been some error in copying this code for this thread, because mysql_query() will never execute something since the query is contained in $string and not $sqltext, thus it will always log an error.

  • (cs) in reply to It's a Feature

    ...or a recursive call...

    --Jim

  • (cs) in reply to loneprogrammer

    loneprogrammer:
    Anonymous:
    Hardly a WTF at all.  Slap a check for if not connected then log with error_log() or just bail.

    An oversight like this isn't a WTF, sheesh.

    You seem to have missed the point -- when the database goes down, how will you be able to write a log entry into a table in the very same database that just went down?

    You'd be surprised.  I have errors try to log to the database first before falling back, and occasionally I get an error *in the database log* saying the database is unavailable.  It's good for a laugh every now and then.

  • JudoPolecat (unregistered) in reply to wkapri
    Anonymous:

     $sqlText =
    "INSERT INTO errorLog (ownerID,time,description,script) " .
    "VALUES ('" . $owner . ",Now(),'" . $description . "','" . $script . "')";

    isn't an apostrophe missing?

     "INSERT INTO errorLog (ownerID,time,description,script) " .
    "VALUES ('" . $owner . <FONT style="BACKGROUND-COLOR: #7fffd4">"<FONT color=#ff1493>'</FONT>,Now</FONT>(),'" . $description . "','" . $script . "')";

    Actually, you're on to something...  executeQuery might fail for reasons other than connectivity, so it's not a WTF to log an error to the database.  The WTF is that the code that logged an error to the database was not well-tested, and not robust.  If anything should be robust, it should be your error-handling...
  • reverendryan (unregistered) in reply to Mike5
    Anonymous:
    Keyboard not found! Press any key to continue...


    Actually, that makes perfect sense. The BIOS is giving you an opportunity to plug a keyboard in (when it will still be recognized) before your OS boots and simply assumes that there is never going to be a keyboard.   Especially usefull back in the day when plugging in a keyboard would crash DOS/Windows.
  • (cs)

    Writing errors to a database, though? Seriously, there's nothing wrong with using plain text flat files for things like this.

    Or XML ducks

  • (cs) in reply to Shen

    function executeQuery($string)
    {
        return executeQueryHelper($string, 1);
    }

    function executeQueryIgnoringErrors($string)
    {
        return executeQueryHelper($string, 0);
    }

    function executeQueryHelper($string, $dieOnError)
    {
        GetDatabaseConnection();
        $result = mysql_query($sqlText)

        if ($dieOnError and not $result) {
            die(
                "Query failed " .
                writeErrorToLog(
                    $_SESSION['USERNAME'],
                    "Query Failed: " .$sqlText . " " . mysql_error()
                    ,$scriptName
                )
            );
        }

        return  $result;
    }

    function writeErrorToLog($owner,$description,$script)
    {
        $script = str_replace($_SERVER['DOCUMENT_ROOT'], "", $script);
        $sqlText =
            "INSERT INTO errorLog (ownerID,time,description,script) " .
            "VALUES ('" . $owner . ",Now(),'" . $description . "','" . $script . "')";
        executeQueryIgnoringErrors($sqlText, $_SERVER['PHP_SELF']);

        return "";
    }

  • (cs)

    Recursion is a Good Thing (TM).

  • HAWKEYES (unregistered)
    Is this what we call nth level recursive error-logging?
  • (cs) in reply to Shen

    XML ducks?

  • stjack1 (unregistered)

    Shouldn't php's maximum execution time kick in a stop the script from running? I don't get why he had to keep rebooting the server, unless he was dumb enough to set php to run sripts forever.

  • (cs) in reply to Oscar L

    You'd be surprised.  I have errors try to log to the database first before falling back, and occasionally I get an error *in the database log* saying the database is unavailable.  It's good for a laugh every now and then.

      My apps often open a second database connection when logging an error. So, if the first connection goes south, I can get that kind of error. This was fairly common back in the Win16 days when any other TCP/IP traffic had a good chance of FUBARing SQL Server connections if it happened while you were executing SQL. (Microsoft's "fix" was to go to the 32 bit client.)

  • nikolas (unregistered) in reply to X-Phile
    X-Phile:

    He must have left the position to move on to management.


    yes. you definitely know the business.
  • (cs)

    Infinite Recursion n. see loop

     

    Loop n. see Infinite Recursion

     

     

    Is there another word for "Thesaurus"?

  • (cs) in reply to GalacticCowboy

    GalacticCowboy:
    XML ducks?

    They walk in a row (according to a Schema).

  • (cs) in reply to GalacticCowboy

    Fat finger problem, the "D" is right next to the "S".

  • (cs) in reply to GalacticCowboy
    GalacticCowboy:
    XML ducks?


    My previous post was in response to this post.... The Real WTF (tm) is this forum software that doesn't allow editing posts.
  • Mark H (unregistered)

    I like how writeErrorToLog is executed as a side-effect of concatenating its return (a constant "" BTW) with the error message that gets printed out, which is conveniently also a really meaningful constant: "Query failed ".

  • KeyJ (unregistered)

    I can't help but quote Douglas Adams:

    Anything that happens happens, anything that in happening causes something else to happen causes something else to happen, and anything that in happening causes itself to happen again, happens again. Although not necessarily in chronological order.

  • (cs)

    We had a similar problem around here. Basically, if you hit any unhandled exception it would redirect you to an error page. But the error page was only available to logged in users. Attempting to access this page while not logged in would throw an exception which was not being handled. So any time unlogged in users got an error (i.e. on the public part of the site) or if you got an error while logging in, BAM! Stack overflow.

  • (cs) in reply to stannius

    I see a sql inyection, because the SQL is never quoted with mysql_real_quote or something alike. Or this guys will use some magic php feature that will aturdetect smoke?

  • Rico Chet (unregistered)

    you all oversee that this code might actually work given that the SQL server that failed was on another machine than the PHP / HTTP server. There might have been an extra database for logging installed on the PHP machine (well, it looks like this wasn't the case), and if it would be not down as well, it'd work.

  • Ed (unregistered) in reply to Rico Chet
    Anonymous:
    you all oversee that this code might actually work given that the SQL server that failed was on another machine than the PHP / HTTP server. There might have been an extra database for logging installed on the PHP machine (well, it looks like this wasn't the case), and if it would be not down as well, it'd work.


    There might be such an extra database.  Unfortunately, since executeQuery doesn't take a second argument, the extra database won't be targetted.  Further, as writeToErrorLog does not check to see if the error was in attempting to write to the error log, it still doesn't matter, because even if it could target the alternate database, a problem with that alternate database could still cause the problem - it just wouldn't happen quite so often.
  • Vicki (unregistered) in reply to HopHead

    >>The WTF is that the previous maintenance developer didn't investigate

    Reminds me a bit of Monday's SharkTank:



    ...a few weeks ago, the server started reporting errors on the screen. She then proudly stated that they would simply shut the power off and turn it back on, and it would work again for a day or two. This morning, it wouldn't come back - it just ran in an infinite reboot mode. Only then did they think to call us."

  • (cs) in reply to Cooper
    Cooper:
    Anonymous:

    >>An oversight like this isn't a WTF, sheesh.

    The WTF isn't the code. The WTF is that the previous maintenance developer didn't investigate and just rebooted the server any time there was an error that triggered the error trap infinite loop.



    That is not a WTF - it is petty incompetence entrained into a support person by our Microsoft-PC environment.

    A WTF is when something is done that rises above the level of normal laziness, incompetence,  ignorance, attitude or a combination.

    This is not brillant, has no juice and isNotSortOfNull.

    In an era of Uncle-Bill-induced reboot-for-memory-leaks, it is the normal learned activity for anybody not supervized by a manager willing to slap the developer/support person/whoever/whatever for not investigating.

    Good people - the criteria for acceptance as a WTF is going south in a hurry.


    I couldn't agree more.  Clearly, this is all Micro$oft's fault.  Very astute observation.
  • (cs)

    Unfortunately, I once did a similar thing on a website. The error page, like the others, tried to connect to the database server in order to show whether the user was logged in. Of course, if the reason for the error had been a MySQL server failure, trying to connect would just fail again, leading to the error page being included again, and so on.

    In my defence, I had been very tired, and removed it the next day before I got the opportunity to see what happened if the database failed...

  • Pyromancer (unregistered) in reply to Vicki

    Well, there is some hope that sooner or later(more likely much later)script will get a connection to DB thus stoping the infinite loop[:D]

  • (cs)

    I nearly did something like this once, too my lasting shame. Then I noticed how very silly it was and fixed it.

Leave a comment on “The Never Ending Error ”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article