How can a bog-standard WordPress install break PHP? – Problems with loading a website are often blamed on the Internet connection, but even the most perfectly set up network cannot help if there is no service to reply at your destination. One of the most popular HTTP servers used for this task is Apache2. Much of Apache’s popularity can be attributed to its easy installation and use, but never the less it is possible to run into problems with even the easiest of the software. If you’ve encountered an issue loading your web page, follow these simple troubleshooting methods outlined in this guide to attempt to get your web server back up and working again. Below are some tips in manage your apache2 server when you find problem about apache-2.2, ubuntu, wordpress, php5, segmentation-fault.
I’m trying to host a WordPress site on the root of a standard Apache setup on Ubuntu 14.04. The main page of the site loads fine, but any other page causes a “no data received” message in the browser, and a segfault in the apache log:
[Wed Sep 17 09:47:57.278168 2014] [core:notice] [pid 26097] AH00051: child pid 26123 exit signal Segmentation fault (11), possible coredump in /etc/apache2
I can use gdb to attach to the process, try to load a linked page, and this is what I see:
Program received signal SIGSEGV, Segmentation fault.
_zend_mm_free_int (heap=0x7f7370b94920, p=0x7f735c138880) at /build/buildd/php5-5.5.9+dfsg/Zend/zend_alloc.c:2104
2104 /build/buildd/php5-5.5.9+dfsg/Zend/zend_alloc.c: No such file or directory.
I’ve loaded the debug symbols for Apache2 and PHP5, and this is the backtrace:
#0 _zend_mm_free_int (heap=0x7f7370b94920, p=0x7f735c138880) at /build/buildd/php5-5.5.9+dfsg/Zend/zend_alloc.c:2104 #1 0x00007f736b4b7d55 in i_zval_ptr_dtor (zval_ptr=0x7f735c138880) at /build/buildd/php5-5.5.9+dfsg/Zend/zend_execute.h:82 #2 zend_do_fcall_common_helper_SPEC (execute_data=<optimized out>) at /build/buildd/php5-5.5.9+dfsg/Zend/zend_vm_execute.h:633 #3 0x00007f736b4319e8 in execute_ex (execute_data=0x7f7370108af0) at /build/buildd/php5-5.5.9+dfsg/Zend/zend_vm_execute.h:363 #4 0x00007f736b3f7b59 in dtrace_execute_ex (execute_data=<optimized out>) at /build/buildd/php5-5.5.9+dfsg/Zend/zend_dtrace.c:73 #5 0x00007f736b4b8300 in zend_do_fcall_common_helper_SPEC (execute_data=0x7f7370108960) at /build/buildd/php5-5.5.9+dfsg/Zend/zend_vm_execute.h:584 #6 0x00007f736b4319e8 in execute_ex (execute_data=0x7f7370108960) at /build/buildd/php5-5.5.9+dfsg/Zend/zend_vm_execute.h:363 #7 0x00007f736b3f7b59 in dtrace_execute_ex (execute_data=<optimized out>) at /build/buildd/php5-5.5.9+dfsg/Zend/zend_dtrace.c:73 #8 0x00007f736b4b8300 in zend_do_fcall_common_helper_SPEC (execute_data=0x7f7370108828) at /build/buildd/php5-5.5.9+dfsg/Zend/zend_vm_execute.h:584 #9 0x00007f736b4319e8 in execute_ex (execute_data=0x7f7370108828) at /build/buildd/php5-5.5.9+dfsg/Zend/zend_vm_execute.h:363 #10 0x00007f736b3f7b59 in dtrace_execute_ex (execute_data=<optimized out>) at /build/buildd/php5-5.5.9+dfsg/Zend/zend_dtrace.c:73 #11 0x00007f736b4b8300 in zend_do_fcall_common_helper_SPEC (execute_data=0x7f7370108710) at /build/buildd/php5-5.5.9+dfsg/Zend/zend_vm_execute.h:584 #12 0x00007f736b4319e8 in execute_ex (execute_data=0x7f7370108710) at /build/buildd/php5-5.5.9+dfsg/Zend/zend_vm_execute.h:363 #13 0x00007f736b3f7b59 in dtrace_execute_ex (execute_data=<optimized out>) at /build/buildd/php5-5.5.9+dfsg/Zend/zend_dtrace.c:73 #14 0x00007f736b4b658c in ZEND_INCLUDE_OR_EVAL_SPEC_CV_HANDLER (execute_data=0x7f7370108600) at /build/buildd/php5-5.5.9+dfsg/Zend/zend_vm_execute.h:30964 #15 0x00007f736b4319e8 in execute_ex (execute_data=0x7f7370108600) at /build/buildd/php5-5.5.9+dfsg/Zend/zend_vm_execute.h:363 #16 0x00007f736b3f7b59 in dtrace_execute_ex (execute_data=<optimized out>) at /build/buildd/php5-5.5.9+dfsg/Zend/zend_dtrace.c:73 #17 0x00007f736b4b8300 in zend_do_fcall_common_helper_SPEC (execute_data=0x7f7370108480) at /build/buildd/php5-5.5.9+dfsg/Zend/zend_vm_execute.h:584 #18 0x00007f736b4319e8 in execute_ex (execute_data=0x7f7370108480) at /build/buildd/php5-5.5.9+dfsg/Zend/zend_vm_execute.h:363 #19 0x00007f736b3f7b59 in dtrace_execute_ex (execute_data=<optimized out>) at /build/buildd/php5-5.5.9+dfsg/Zend/zend_dtrace.c:73 #20 0x00007f736b4b8300 in zend_do_fcall_common_helper_SPEC (execute_data=0x7f7370108370) at /build/buildd/php5-5.5.9+dfsg/Zend/zend_vm_execute.h:584 #21 0x00007f736b4319e8 in execute_ex (execute_data=0x7f7370108370) at /build/buildd/php5-5.5.9+dfsg/Zend/zend_vm_execute.h:363 #22 0x00007f736b3f7b59 in dtrace_execute_ex (execute_data=<optimized out>) at /build/buildd/php5-5.5.9+dfsg/Zend/zend_dtrace.c:73 #23 0x00007f736b4b658c in ZEND_INCLUDE_OR_EVAL_SPEC_CV_HANDLER (execute_data=0x7f7370108288) at /build/buildd/php5-5.5.9+dfsg/Zend/zend_vm_execute.h:30964 #24 0x00007f736b4319e8 in execute_ex (execute_data=0x7f7370108288) at /build/buildd/php5-5.5.9+dfsg/Zend/zend_vm_execute.h:363 #25 0x00007f736b3f7b59 in dtrace_execute_ex (execute_data=<optimized out>) at /build/buildd/php5-5.5.9+dfsg/Zend/zend_dtrace.c:73 #26 0x00007f736b4b7241 in ZEND_INCLUDE_OR_EVAL_SPEC_TMP_HANDLER (execute_data=0x7f73701081a0) at /build/buildd/php5-5.5.9+dfsg/Zend/zend_vm_execute.h:8053 #27 0x00007f736b4319e8 in execute_ex (execute_data=0x7f73701081a0) at /build/buildd/php5-5.5.9+dfsg/Zend/zend_vm_execute.h:363 #28 0x00007f736b3f7b59 in dtrace_execute_ex (execute_data=<optimized out>) at /build/buildd/php5-5.5.9+dfsg/Zend/zend_dtrace.c:73 #29 0x00007f736b4b7241 in ZEND_INCLUDE_OR_EVAL_SPEC_TMP_HANDLER (execute_data=0x7f73701080a0) at /build/buildd/php5-5.5.9+dfsg/Zend/zend_vm_execute.h:8053 #30 0x00007f736b4319e8 in execute_ex (execute_data=0x7f73701080a0) at /build/buildd/php5-5.5.9+dfsg/Zend/zend_vm_execute.h:363 #31 0x00007f736b3f7b59 in dtrace_execute_ex (execute_data=<optimized out>) at /build/buildd/php5-5.5.9+dfsg/Zend/zend_dtrace.c:73 #32 0x00007f736b4095e0 in zend_execute_scripts (type=type@entry=8, retval=retval@entry=0x0, file_count=file_count@entry=3) at /build/buildd/php5-5.5.9+dfsg/Zend/zend.c:1316 #33 0x00007f736b3a94c5 in php_execute_script (primary_file=primary_file@entry=0x7ffff71b7b40) at /build/buildd/php5-5.5.9+dfsg/main/main.c:2506 #34 0x00007f736b4b993a in php_handler (r=<optimized out>) at /build/buildd/php5-5.5.9+dfsg/sapi/apache2handler/sapi_apache2.c:667 #35 0x00007f7370269680 in ap_run_handler (r=0x7f7370093130) at config.c:169 #36 0x00007f7370269bc9 in ap_invoke_handler (r=r@entry=0x7f7370093130) at config.c:439 #37 0x00007f737027ec2c in ap_internal_redirect (new_uri=<optimized out>, r=<optimized out>) at http_request.c:644 #38 0x00007f7369abdcfc in handler_redirect (r=0x7f73700990a0) at mod_rewrite.c:5063 #39 0x00007f7370269680 in ap_run_handler (r=0x7f73700990a0) at config.c:169 #40 0x00007f7370269bc9 in ap_invoke_handler (r=r@entry=0x7f73700990a0) at config.c:439 #41 0x00007f737027f16a in ap_process_async_request (r=0x7f73700990a0) at http_request.c:317 #42 0x00007f737027f444 in ap_process_request (r=r@entry=0x7f73700990a0) at http_request.c:363 #43 0x00007f737027bf02 in ap_process_http_sync_connection (c=0x7f737009f290) at http_core.c:190 #44 ap_process_http_connection (c=0x7f737009f290) at http_core.c:231 #45 0x00007f7370272cc0 in ap_run_process_connection (c=0x7f737009f290) at connection.c:41 #46 0x00007f73702730a8 in ap_process_connection (c=c@entry=0x7f737009f290, csd=<optimized out>) at connection.c:202 #47 0x00007f736caaa767 in child_main (child_num_arg=child_num_arg@entry=5) at prefork.c:704 #48 0x00007f736caaa9a6 in make_child (s=0x7f73701d8de0, slot=5) at prefork.c:800 #49 0x00007f736caab60e in perform_idle_server_maintenance (p=<optimized out>) at prefork.c:902 #50 prefork_run (_pconf=<optimized out>, plog=<optimized out>, s=<optimized out>) at prefork.c:1090 #51 0x00007f737025069e in ap_run_mpm (pconf=0x7f7370206028, plog=0x7f73701d4028, s=0x7f73701d8de0) at mpm_common.c:96 #52 0x00007f7370249e36 in main (argc=3, argv=0x7ffff71b82e8) at main.c:777
For one thing, why is Zend involved at all? I’m guessing that’s just the way PHP is built. I’ve uncommented the one line in php5.ini that references it, but that didn’t change anything.
It seems reasonably clear that a call to load a linked page in the WordPress site is going through mod_rewrite (as it should), gets handed off to PHP, then gets lost in a bunch of sub-calls to
zend_vm_execute where it ultimately seems to be looking for a source file that’s not installed. Do I need to install some other part of Zend on my installation? It doesn’t seem like I should have to install non-free software for this.
Have I just found a bug? It doesn’t seem like something as simple as a stock WordPress install would uncover a latent problem.
The only other piece of the puzzle is that I’ve moved this site in from a shared host to a dedicated server. I used https://github.com/interconnectit/Search-Replace-DB to sort out the change in the URL. It was working when I set it up and used it a week ago, and now it’s not. I’ve looked through all of the logs from the intervening week, and there’s nothing but a handful of status messages. I haven’t installed anything or changed anything since this was working. I went to update the site this morning, and found it broken.
Since the default page and the dashboard are working, I used the wp-admin page to change the permalink configuration back to the default, and moved the stock .htaccess file out of the way. Another backtrace showed that mod_rewrite is now out of the loop, but the problem persists.
I founded the same error in a Drupal installation (Ubuntu 14, PHP-5.5.9) with a quite heavy theme.
Obviously the first suspect in these cases is the PHP code. But gdb did not give any hint about the custom code, and pointed to zend_alloc.c, as in your case.
Ok, it seems that some (ignored) conditions make the Zend engine to crash.
I started then to play with OPCache configuration and finally I was able to find the cause.
In my case, the installation had several vhosts, with OPCache initially enabled, and then disabled in some of the vhosts… particularly in the one that gave the segmentation fault.
Simply enabling OPCache for that particular vhost, or just disable OPCache for the overall installation, and the segmentation faults went away.
It seems that a different OPcache-configuration between vhosts, plus some (ignored) PHP conditions, both cause the problem, although it should not be.
Some light on this would be really apprciated…