2

This problem has me beyond stumped. A little background:

  • Red Hat Enterprise Linux 6
  • PHP 5.3.3
  • Magento 1.7.0.2
  • Hacked Core
  • Compilation is disabled
  • Ioncube Loader Zend Extension Included

Installed Third Party Modules:

  • Aitoc Aitinstall
  • Aitoc Aitsys
  • Anaraky Gdrt
  • Aoe Scheduler
  • Devinc License
  • Devinc Multipledeals
  • Displaze MyProductType
  • Dull Uploader
  • Listrak Remarketing
  • Magemaven OrderComment
  • Magestore Bannerslider
  • OlegKoval ProductReviewCaptcha
  • Phoenix VarnishCache
  • AW All
  • AW Core
  • AW Kbase
  • Aitoc Aitgroupedoptions
  • Amasty Base
  • Amasty Conf
  • Amasty Coupons
  • Amasty Oaction
  • Amasty Promo
  • Amasty ShippingPerItem
  • Amasty Shiprestriction
  • Amasty Shiprules
  • Bazaarvoice Connector
  • Bizrate Buyersurvey
  • CommerceExtensions Productimportexport
  • GoDataFeed Services
  • Humsayaa AbsolutePricing
  • ME Base
  • ME DataFlowAdvanced
  • ME ProductInParent
  • ME Shipping
  • ME UrlMapper
  • Magestore Imageoption
  • Magestore Magenotification
  • Mirasvit FeedExport
  • Mirasvit MstCore
  • RapidCommerce Browserupgrade
  • SOAP ShoppingAnalytics

PHP Include Path:

/home/xxx/htdocs/app/code/local:/home/xxx/htdocs/app/code/community:/home/xxx/htdocs/app/code/core:/home/xxx/htdocs/lib:.:/usr/share/pear:/usr/share/php

The Problem

On approximately 1% of all requests, I'm seeing an issue where the Varien auto-loader fails to include a core file: app/code/core/Mage/Core/Model/Layout.php

Tracing this down to the autoload($class) method inside the lib/varien/Autoload.php file, I am able to confirm that include $classFile is returning FALSE approximately 1% of the time. This indicates that the file could not be found and/or opened. This seems to be the only file that fails to be loaded.

It's currently my theory that something is locking the file...but I am at a loss as to what the most efficient next debugging step should be. Has anyone had any experience with third party modules doing some funky file locking during the Magento bootstrapping process?

How the devil should one go about finding the root cause of this?

*Edit 1:

I've modified the autoload function as follows:

public function autoload($class)
{
    if ($this->_collectClasses) {
        $this->_arrLoadedClasses[self::$_scope][] = $class;
    }
    if ($this->_isIncludePathDefined) {
        $classFile =  COMPILER_INCLUDE_PATH . DIRECTORY_SEPARATOR . $class;
    } else {
        $classFile = str_replace(' ', DIRECTORY_SEPARATOR, ucwords(str_replace('_', ' ', $class)));
    }
    $classFile.= '.php';

    $includeResult = include($classFile);

    /// Whoa something is very wrong here!
    if(!$includeResult) {
        error_reporting(E_ALL);
        ini_set('display_errors', '1');
        $handle = fopen('/home/xxx/htdocs/app/code/core/Mage/Core/Model/Layout.php');
        $wb = false;
        if(!flock($handle, LOCK_EX|LOCK_NB, $wb)) {
            if($wb) {
                die('Something has the darn thing locked...');
            } else {
                /// Nothing has the darn thing locked!
                $includeResult = include($classFile);
                if(!$includeResult) {
                    die('....something just does not make sense here.');
                } else {
                    die('Included the file this time.......');
                }
            }
        } else {
            die('Was able to lock the file successfully...');
        }
    }
    return $includeResult;

}

The result is as follows: ....something just does not make sense here.

This indicates that nothing has a lock on the file. This also indicates that no warnings are emitted from the include construct.

*Edit 2 - Reading from the PHP language specification (https://github.com/php/php-langspec/blob/master/spec/10-expressions.md#the-include-operator), it appears that if an included file cannot be opened or read, then a warning is emitted. Additionally, the value FALSE is returned.

FALSE is definitely being returned by the inclusion, however no warning is being emitted. This leads me to believe that this is likely an internal PHP issue.

2

Finally - a break in this case. I was able to grep a few warnings from the Ioncube zend_extension.

Apparently (not suprisingly) - the Ioncube product hacks up how the Zend Interpreter works. As a result, the Zend interpreter did not emit the proper warnings.

As it turns out, the number of file descriptors available to PHP-FPM was too low. I've cranked this number up and the problem is now alleviated.

Yet another reason never to use software that requires the use of the broken Ioncube product.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.