2

We updated a Laravel 5 project on a Ubuntu 14.04 server and now get an ERR_EMPTY_RESPONSE error when accessing it's main page.

Other PHP applications on the server work fine.

Using GDB we were able to generate the following :

root@server-3 /var/crash/apache # gdb apache2 -core CoreDump
GNU gdb (Ubuntu 7.7.1-0ubuntu5~14.04.2) 7.7.1
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from apache2...Reading symbols from /usr/lib/debug//usr/sbin/apache2...done.
done.
[New LWP 27190]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

warning: the debug information found in "/usr/lib/debug//usr/lib/php5/20121212/mysql.so" does not match "/usr/lib/php5/20121212/mysql.so" (CRC mismatch).


warning: the debug information found in "/usr/lib/debug/usr/lib/php5/20121212/mysql.so" does not match "/usr/lib/php5/20121212/mysql.so" (CRC mismatch).


warning: the debug information found in "/usr/lib/debug//usr/lib/php5/20121212/mysqli.so" does not match "/usr/lib/php5/20121212/mysqli.so" (CRC mismatch).


warning: the debug information found in "/usr/lib/debug/usr/lib/php5/20121212/mysqli.so" does not match "/usr/lib/php5/20121212/mysqli.so" (CRC mismatch).


warning: the debug information found in "/usr/lib/debug//usr/lib/php5/20121212/pdo_mysql.so" does not match "/usr/lib/php5/20121212/pdo_mysql.so" (CRC mismatch).


warning: the debug information found in "/usr/lib/debug/usr/lib/php5/20121212/pdo_mysql.so" does not match "/usr/lib/php5/20121212/pdo_mysql.so" (CRC mismatch).

Core was generated by `/usr/sbin/apache2 -k start'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  zend_parse_parameters (num_args=1, type_spec=type_spec@entry=0x7f8b02987f9a "H") at /build/php5-RpYHCf/php5-5.5.9+dfsg/Zend/zend_API.c:924
924 /build/php5-RpYHCf/php5-5.5.9+dfsg/Zend/zend_API.c: No such file or directory.

And after typing backtrace:

#0  zend_parse_parameters (num_args=1, type_spec=type_spec@entry=0x7f8b02987f9a "H") at /build/php5-RpYHCf/php5-5.5.9+dfsg/Zend/zend_API.c:924
#1  0x00007f8b024440bf in zif_end (ht=<optimized out>, return_value=0x7f8b09329c60, return_value_ptr=<optimized out>, this_ptr=<optimized out>, return_value_used=1)
    at /build/php5-RpYHCf/php5-5.5.9+dfsg/ext/standard/array.c:822
#2  0x00007f8b0251700b in dtrace_execute_internal (execute_data_ptr=<optimized out>, fci=<optimized out>, return_value_used=<optimized out>) at /build/php5-RpYHCf/php5-5.5.9+dfsg/Zend/zend_dtrace.c:97
#3  0x00007f8b025d7075 in zend_do_fcall_common_helper_SPEC (execute_data=<optimized out>) at /build/php5-RpYHCf/php5-5.5.9+dfsg/Zend/zend_vm_execute.h:552
#4  0x00007f8b02550da8 in execute_ex (execute_data=0x7f8b09317418) at /build/php5-RpYHCf/php5-5.5.9+dfsg/Zend/zend_vm_execute.h:363
#5  0x00007f8b02516f09 in dtrace_execute_ex (execute_data=<optimized out>) at /build/php5-RpYHCf/php5-5.5.9+dfsg/Zend/zend_dtrace.c:73
#6  0x00007f8b025d76c0 in zend_do_fcall_common_helper_SPEC (execute_data=0x7f8b093172c8) at /build/php5-RpYHCf/php5-5.5.9+dfsg/Zend/zend_vm_execute.h:584
#7  0x00007f8b02550da8 in execute_ex (execute_data=0x7f8b093172c8) at /build/php5-RpYHCf/php5-5.5.9+dfsg/Zend/zend_vm_execute.h:363
#8  0x00007f8b02516f09 in dtrace_execute_ex (execute_data=<optimized out>) at /build/php5-RpYHCf/php5-5.5.9+dfsg/Zend/zend_dtrace.c:73
#9  0x00007f8b025d76c0 in zend_do_fcall_common_helper_SPEC (execute_data=0x7f8b09317158) at /build/php5-RpYHCf/php5-5.5.9+dfsg/Zend/zend_vm_execute.h:584
#10 0x00007f8b02550da8 in execute_ex (execute_data=0x7f8b09317158) at /build/php5-RpYHCf/php5-5.5.9+dfsg/Zend/zend_vm_execute.h:363
#11 0x00007f8b02516f09 in dtrace_execute_ex (execute_data=<optimized out>) at /build/php5-RpYHCf/php5-5.5.9+dfsg/Zend/zend_dtrace.c:73
#12 0x00007f8b025d76c0 in zend_do_fcall_common_helper_SPEC (execute_data=0x7f8b09317020) at /build/php5-RpYHCf/php5-5.5.9+dfsg/Zend/zend_vm_execute.h:584
#13 0x00007f8b02550da8 in execute_ex (execute_data=0x7f8b09317020) at /build/php5-RpYHCf/php5-5.5.9+dfsg/Zend/zend_vm_execute.h:363
#14 0x00007f8b02516f09 in dtrace_execute_ex (execute_data=<optimized out>) at /build/php5-RpYHCf/php5-5.5.9+dfsg/Zend/zend_dtrace.c:73
#15 0x00007f8b025d76c0 in zend_do_fcall_common_helper_SPEC (execute_data=0x7f8b09316f20) at /build/php5-RpYHCf/php5-5.5.9+dfsg/Zend/zend_vm_execute.h:584
#16 0x00007f8b02550da8 in execute_ex (execute_data=0x7f8b09316f20) at /build/php5-RpYHCf/php5-5.5.9+dfsg/Zend/zend_vm_execute.h:363
#17 0x00007f8b02516f09 in dtrace_execute_ex (execute_data=<optimized out>) at /build/php5-RpYHCf/php5-5.5.9+dfsg/Zend/zend_dtrace.c:73
#18 0x00007f8b02519241 in zend_call_function (fci=fci@entry=0x7fffc06b8a50, fci_cache=<optimized out>, fci_cache@entry=0x7fffc06b8a20) at /build/php5-RpYHCf/php5-5.5.9+dfsg/Zend/zend_execute_API.c:939
#19 0x00007f8b0253e1e5 in zend_call_method (object_pp=object_pp@entry=0x7fffc06b8b08, obj_ce=<optimized out>, obj_ce@entry=0x7f8b08bae380, fn_proxy=fn_proxy@entry=0x0, 
    function_name=function_name@entry=0x7f8b02973648 "offsetget", function_name_len=function_name_len@entry=9, retval_ptr_ptr=retval_ptr_ptr@entry=0x7fffc06b8b18, param_count=param_count@entry=1, 
    arg1=arg1@entry=0x7f8b09329c10, arg2=arg2@entry=0x0) at /build/php5-RpYHCf/php5-5.5.9+dfsg/Zend/zend_interfaces.c:97
#20 0x00007f8b02549725 in zend_std_read_dimension (object=0x7f8b08b270d0, offset=0x7f8b09329c10, type=<optimized out>) at /build/php5-RpYHCf/php5-5.5.9+dfsg/Zend/zend_object_handlers.c:646
#21 0x00007f8b025ad250 in zend_fetch_dimension_address_read (result=0x7f8b09316e10, container=0x7f8b08b270d0, dim=<optimized out>, dim_type=dim_type@entry=1, type=type@entry=0)
    at /build/php5-RpYHCf/php5-5.5.9+dfsg/Zend/zend_execute.c:1332
#22 0x00007f8b025ae66c in ZEND_FETCH_DIM_R_SPEC_CV_CONST_HANDLER (execute_data=0x7f8b09316e30) at /build/php5-RpYHCf/php5-5.5.9+dfsg/Zend/zend_vm_execute.h:32192
#23 0x00007f8b02550da8 in execute_ex (execute_data=0x7f8b09316e30) at /build/php5-RpYHCf/php5-5.5.9+dfsg/Zend/zend_vm_execute.h:363
#24 0x00007f8b02516f09 in dtrace_execute_ex (execute_data=<optimized out>) at /build/php5-RpYHCf/php5-5.5.9+dfsg/Zend/zend_dtrace.c:73
#25 0x00007f8b02519241 in zend_call_function (fci=fci@entry=0x7fffc06b8e40, fci_cache=<optimized out>, fci_cache@entry=0x7fffc06b8e10) at /build/php5-RpYHCf/php5-5.5.9+dfsg/Zend/zend_execute_API.c:939
#26 0x00007f8b0244c729 in zif_call_user_func (ht=<optimized out>, return_value=0x7f8b09329a80, return_value_ptr=<optimized out>, this_ptr=<optimized out>, return_value_used=<optimized out>)
    at /build/php5-RpYHCf/php5-5.5.9+dfsg/ext/standard/basic_functions.c:4781
#27 0x00007f8b0251700b in dtrace_execute_internal (execute_data_ptr=<optimized out>, fci=<optimized out>, return_value_used=<optimized out>) at /build/php5-RpYHCf/php5-5.5.9+dfsg/Zend/zend_dtrace.c:97

and so on...

How can this be fixed / further debugged? Google did not bring up any specific PHP bugs for this, maybe also I do not really know what to search for.

Is there a way to find the vomitive line in the PHP code?

Alex
  • 32,506
  • 16
  • 106
  • 171
  • 1
    Does laravel app have high memory usage? Look here https://www.digitalocean.com/community/questions/apache2-crashing-segmentation-fault – Bogdan Burym Sep 23 '15 at 14:27
  • It shouldn't... It is a pretty simple app. And I would expect it to run into the memory_limit of PHP? Also system has plenty of free memory (1G) and swap is on and has 16G free. – Alex Sep 23 '15 at 14:29
  • And what if try this http://stackoverflow.com/questions/24971824/laravel-default-page-not-loading-error-324-err-empty-response – Bogdan Burym Sep 23 '15 at 14:35
  • You could isolate the problem by removing everything from `public/index.php` then adding it back piece-wise. You can then drill down into `bootstrap/start.php` and do the same process and so on. – bernie Sep 23 '15 at 17:45

1 Answers1

2

With some git bisect magic I was able to identify a commit which contained a call to url() in a config file (config subfolder). This caused a recursion.

On my dev machine I get a error Maximum function nesting level of '100' reached, aborting!. On the bespoken server I just get this PHP crash.

I am able to reproduce the PHP crash with such a recursion:

<?php

function foo() {
    foo();
}
foo();

I was not aware, that the message "Maximum function nesting level of '100' reached, aborting!" come from XDEBUG, which is of course not enabled on the server.

So it is normal behaviour, that PHP crashes on a recursion.

Alex
  • 32,506
  • 16
  • 106
  • 171