Magento – Fun with Debugging the Magento Compiler

Home / Blog / Magento / Magento – Fun with Debugging the Magento Compiler

I was recently debugging an issue with the Magento compiler that only seemed to occur when our Full Page Cache was enabled.  Drove me nuts for a good part of the day!  Basically when ever accessing the cart or one page checkout you would get a blank screen, just a white blank screen.

So when starting to look into this I did what I normally do and checked out the errors logs.  But what did I find … absolutely nothing!  Nothing in Magento’s, PHP-FPM‘s, or Nginx‘s log files. I even checked the syslog just in case.  I went back and checked all my log settings.   Everything was fine but the blank screen persisted without generating any errors in the logs.  So I decided to turn on PHP’s display_errors setting as there obviously had to be an error of some sort causing this.  And it doesn’t get any easier than just displaying errors in the browser, right?  Nope still nothing, just a white blank screen…

So where to go from here?  I decided to checkout xdebug’s documentation in case there was something there to force a stack trace or something. I first found this and decided to give it a try:

xdebug.show_exception_trace

Type: integer, Default value: 0

When this setting is set to 1, Xdebug will show a stack trace whenever an exception is raised – even if this exception is actually caught.

I figured that should show something so I enabled it… but still nothing!  So went back searching through the documentation tried a few other things and then buy yasmin 28 online finally found this:

xdebug.scream

Type: boolean, Default value: 0, Introduced in Xdebug 2.1

If this setting is 1, then Xdebug will disable the @ (shut-up) operator so that notices, warnings and errors are no longer hidden.

And then finally something!

FPC Compiler Exception

So as it turns out Xdebug’s scream setting can be really useful when you are at your wits end trying to find some error message that is hidden for what ever reason.  I found this to be an odd error at first but at least it’s something to work with.

What ended up causing the error in the first place and why was that exception displayed?  Well long story short Varien_Autoloader::registerScope was hiding all error messages on an include_once AWESOME!

    static public function registerScope($code)
    {
        self::$_scope = $code;
        if (defined('COMPILER_INCLUDE_PATH')) {
            @include_once self::SCOPE_FILE_PREFIX.$code.'.php';
        }
    }

But why the redeclare?  It’s kind of an odd exception to get.  Well, we were hooking into Magento’s controller_action_predispatch event, loading some classes, and doing a few checks.  However controller_action_predispatch occurs before Magento registers the current scope which in this case was “checkout”.  The Magento compiler uses this scope concept to combine known required classes into a single file to cut down on the number of include_once that are needed.  Less file access is needed so it should make IO on the disk a little lighter.

Since Mage_Directory_Model_Currency is defined in Mage_Directory_Model_Currency.php and __checkout.php and we needed the class before the auto loader registered the scope we ended up with a redeclared class.   So that was my fun with debugging the Magento compiler.

Comments
  • Sarthak

    After Spending several long hours split over several days trying to figure out what was the problem I finaaly located the problem thanks to your blog.

    Thanx Thanx Thanx!!!

Leave a Comment