magespecialist/m1-MSP_DevTools

Undefined offset -1 on AbstractOpsRegistry line 74

Closed this issue ยท 11 comments

I am on a fresh installation of Magento 1.9.2.4 and I correctly enabled the module. After I set 127.0.0.1 in the authorized IP address config, everypage I load will throw this error:

Notice: Undefined offset: -1 in /var/www/magento_test_1924/vendor/msp/devtools-m1/app/code/community/MSP/DevTools/Model/AbstractOpsRegistry.php on line 74

0 /var/www/magento_test_1924/vendor/msp/devtools-m1/app/code/community/MSP/DevTools/Model/AbstractOpsRegistry.php(74): mageCoreErrorHandler(8, 'Undefined offse...', '/var/www/magent...', 74, Array)

1 /var/www/magento_test_1924/vendor/msp/devtools-m1/app/code/community/Varien/Profiler.php(159): MSP_DevTools_Model_AbstractOpsRegistry->stop('http_response_s...', Array)

2 /var/www/magento_test_1924/vendor/msp/devtools-m1/app/code/community/Varien/Profiler.php(199): Varien_Profiler::pause('DISPATCH EVENT:...')

3 /var/www/magento_test_1924/magento/app/Mage.php(457): Varien_Profiler::stop('DISPATCH EVENT:...')

4 /var/www/magento_test_1924/magento/app/code/core/Mage/Core/Controller/Response/Http.php(83): Mage::dispatchEvent('http_response_s...', Array)

5 /var/www/magento_test_1924/magento/app/code/core/Mage/Core/Controller/Varien/Front.php(184): Mage_Core_Controller_Response_Http->sendResponse()

6 /var/www/magento_test_1924/magento/app/code/core/Mage/Core/Model/App.php(365): Mage_Core_Controller_Varien_Front->dispatch()

7 /var/www/magento_test_1924/magento/app/Mage.php(692): Mage_Core_Model_App->run(Array)

8 /var/www/magento_test_1924/magento/index.php(83): Mage::run('', 'store')

9 {main}

I debugged it and the error occur when $opName is 'http_response_send_before'. I noticed that you override Varien/Profiler, but ::enable() is never called in my installation.

Hello LucaGallinari,
we tried to reproduce this issue on a Magento 1.9.2.4 fresh install with no success.

The lines you are reporting do not match with the very last version. What is the module version you are using?

Hi @phoenix128!
I have a similar problem on a 1.9.2.1 magento installation.
I find this rows in system.log:
2016-09-05T14:41:57+00:00 ERR (3): Notice: Undefined index: time in /<project root>/app/code/community/MSP/DevTools/Model/AbstractOpsRegistry.php on line 138 2016-09-05T14:41:57+00:00 ERR (3): Notice: Undefined index: name in /<project root>/app/code/community/MSP/DevTools/Model/AbstractOpsRegistry.php on line 142 2016-09-05T14:41:57+00:00 ERR (3): Notice: Undefined offset: -1 in /<project root>/app/code/community/MSP/DevTools/Model/AbstractOpsRegistry.php on line 71

This may depends on invalid Profiler nesting. We can add a control on the array bounds, but you could have a wrong profiler count. Any 3rd party module installed?

Hi @phoenix128!
Yes, third party modules on Magento installation are ever more than I like.... 0! :)

Ok, we will run some more test. Did you upgrade to the very last version? We had a similar bug closed in the last release.

Hi @phoenix128!
Hi have the 0.1.8 version :)

My bad for the lines that don't correspond to the last version, cause I added some debug lines before the line that throw the error. My version is by the way the v0.1.8.
Maybe tonight I'll update with some more debug information.

Since we are not able to reproduce it, can you please try the following patch?

MSP_DevTools_Model_AbstractOpsRegistry at line 71 (t the very beginning of method stop):

...
if (count($this->stackOps) < 1) {
  return $this;
}
...

@phoenix128 your fix resolves the problem but i debugged it (for interests =P) and found that this happen:

  • All starts when the system dispatch the 'http_response_send_before' event (Mage_Core_Controller_Response_Http.php line 83)
  • This will call the dispatchEvent() function in the Mage.php that do this:
        Varien_Profiler::start('DISPATCH EVENT:'.$name);
        $result = self::app()->dispatchEvent($name, $data);
        Varien_Profiler::stop('DISPATCH EVENT:'.$name);
  • The first line will end up putting the 'http_response_send_before' in the stackOps, the second line will dispatch the event that is catched by your Observer and at line 110 (of the Observer) it will call a stop() for the event profiler so it will end up popping (removing) the opName from the stackOps. The third line will try to do what the second line already did, but failing.

I don't know if i explained that good, but that's it.

It probably depends on the anti-recursion control we added some times ago.
Tomorrow morning we will try tro reproduce and fix it.

Hi @LucaGallinari,
I confirm it was caused by our anti-recusrsion code.

The patch I provided should work without problems, we just added it to version 0.1.9.

Thank you for your help.