0

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.

  • A quick google shows this crash issue to be quite a common occurrence...it looks like a bug. I'd file a bug with PHP to see what they say. – Nathan C Sep 17 '14 at 14:42
  • 1
    Zend is the execution engine in PHP - you can't disable it. This does appear to be a bug in the PHP interpreter/compiler/runtime (it souldn't be possible to trigger a segmentation fault from your PHP code). – symcbean Sep 17 '14 at 14:51
  • I opened a bug report with the PHP guys (bugs.php.net/bug.php?id=68038), but finally figured out that the theme I was using was breaking the site. (It was "Mystique," which I've seen in a few places, so it's not like it's obscure.) How? I have no idea. It still shouldn't cause a segfault in PHP. – David Krider Sep 20 '14 at 21:59
0

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...

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

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