Sunday, March 10, 2013

Getting to the bottom of Bus Errors

Last week I ran into a fatal PHP error which Apache reported as a Bus Error (7).  I've been working in PHP and Apache now for over 10 years and I have never seen PHP just die and report a Bus Error.  So through some research I found out what this bizarre error means and how you can find out what is causing it.  You're going to need to have a dedicated box to make all this happen.

First Bus Error = Core Dump.  This was annoying because had I known it was a core dump from PHP I would have known where to start.  When you google Bus Error 7 you get a lot of bug reports and other garbage but not a lot of information on where to go to figure this issue out.   The key here is that you need the version of PHP and Apache with the debugging symbols in it.  Thats not the out of the box package.

PHP Website talks about recompiling PHP and Apache to get the debugging turned on but I was able to find a better solution.

CentOS has a debugging repo so we found packages here .  You'll need the Apache ones as well.  Once you get these installed you're ready to figure out what is causing your headache.

What you're going to want to do is follow the instructions over on the PHP website. This will get PHP configured and setup to generate the core dumps.

Once you have them then it's time to work some magic.

You'll start up GDB just like it shows on the PHP link above and run the "bt" command.  I got this out of the output.

#0  lex_scan (zendlval=0x7ffff7fcce08) at Zend/zend_language_scanner.c:2117
#1  0x00007fa0a14d0aa0 in zendlex (zendlval=0x7ffff7fcce00) at /usr/src/debug/php-5.3.3/Zend/zend_compile.c:4942
#2  0x00007fa0a14bb2e7 in zendparse () at /usr/src/debug/php-5.3.3/Zend/zend_language_parser.c:3282
#3  0x00007fa0a14c5f32 in compile_file (file_handle=0x7ffff7fcd130, type=) at Zend/zend_language_scanner.l:354
#4  0x00007fa09b0cc721 in phar_compile_file (file_handle=0x7ffff7fcd130, type=2) at /usr/src/debug/php-5.3.3/ext/phar/phar.c:3393
#5  0x00007fa09f13bda6 in ?? () from /usr/lib64/php/modules/
#6  0x00007fa0a14c57de in compile_filename (type=2, filename=0x7fa0aef2aa78) at Zend/zend_language_scanner.l:397
#7  0x00007fa0a15159d8 in ZEND_INCLUDE_OR_EVAL_SPEC_CV_HANDLER (execute_data=0x7fa0acccfa58) at /usr/src/debug/php-5.3.3/Zend/zend_vm_execute.h:22432
#8  0x00007fa0a150f400 in execute (op_array=0x7fa0acc6b898) at /usr/src/debug/php-5.3.3/Zend/zend_vm_execute.h:107
#9  0x00007fa0a14e0285 in zend_call_function (fci=0x7ffff7fcd4e0, fci_cache=) at /usr/src/debug/php-5.3.3/Zend/zend_execute_API.c:963
#10 0x00007fa0a15003f7 in zend_call_method (object_pp=0x7fa0acd948a0, obj_ce=, fn_proxy=0x7fa0acd94898, 
    function_name=0x7fa0acca8f98 "aitoc_aitsys_model_rewriter_autoload::autoload\005", function_name_len=, retval_ptr_ptr=0x7ffff7fcd648, param_count=1, 
    arg1=0x7fa0ad68eaa8, arg2=0x0) at /usr/src/debug/php-5.3.3/Zend/zend_interfaces.c:97
#11 0x00007fa0a14044d6 in zif_spl_autoload_call (ht=, return_value=, return_value_ptr=, this_ptr=, 
    return_value_used=) at /usr/src/debug/php-5.3.3/ext/spl/php_spl.c:406
#12 0x00007fa0a14e032e in zend_call_function (fci=0x7ffff7fcd890, fci_cache=) at /usr/src/debug/php-5.3.3/Zend/zend_execute_API.c:985
#13 0x00007fa0a14e094e in zend_lookup_class_ex (name=0x7fa0aee5b9e0 "XXX_Catalog_Model_Inventory_Stock_Item", name_length=38, use_autoload=1, ce=0x7ffff7fcd9b0)
    at /usr/src/debug/php-5.3.3/Zend/zend_execute_API.c:1120
#14 0x00007fa0a14fb4b0 in zif_class_exists (ht=, return_value=0x7fa0aee1a470, return_value_ptr=, this_ptr=, 
    return_value_used=) at /usr/src/debug/php-5.3.3/Zend/zend_builtin_functions.c:1217

Now while this may look like complete garbage it actually tells you quite a bit.

First, it's clear it died in lex_scan which at this point you know something other than "Bus Error".  The key here though was what came at line 10.  "aitoc_aitsys_model_rewriter_autoload" here was the problem.  Something in this was causing the issue.   This module uses some derived code from the Ioncube loader.

Now while I don't have a solution for this piece of code I know what at least was causing the problem and where.  If you look at line #13 you'll see the Magento module where this was being called.   So again we at least know where this issue is happening.

Standard debugging here would be normal where you can isolate the issue.  What we knew going into this is that Aitoc has serious licensing issues.  When developers in Magento use their modules there are constant complains about Aitoc and their licensing.  I found from personal experience their 24 hour once a day response to your email is not worth it.  I wouldn't use their software if I didn't have to.

The point of this whole post is simply to give you some hope when you run into this Bus Error with Apache and PHP.  You can get to the bottom of it with these simple tools.  I was not able to find a way to get to the bottom of the Bus Error without a lot of research on the internet.  This post should now help someone else quickly get to the bottom of a bus error without having to research for hours like I did.


Unknown said...
This comment has been removed by a blog administrator.
Unknown said...
This comment has been removed by a blog administrator.
Best Multimedia said...
This comment has been removed by a blog administrator.
Nandhini said...
This comment has been removed by a blog administrator.