php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #58380 Apache crashes
Submitted: 2008-10-16 02:53 UTC Modified: 2009-04-05 23:27 UTC
From: komanek at natur dot cuni dot cz Assigned:
Status: No Feedback Package: APC (PECL)
PHP Version: 5.2.6 OS: Debian 4.0
Private report: No CVE-ID: None
 [2008-10-16 02:53 UTC] komanek at natur dot cuni dot cz
Description:
------------
Apache crashes a few times per week. After this happens,
Apache is still running but is servong no further requests
until restarted.

Apache is 2.2.9, PHP 5.2.6 (nearest in the dropdown above is
5.2.5, 5.2.6 is not in the list unfortunately).


Expected result:
----------------
APC should work well, i.e. without crashes. If there is a
problem, instead of crash there should be some assresrtion
or whatever to recover from that.

Actual result:
--------------
Program terminated with signal 11, Segmentation fault.
#0  0xb6c396f3 in prevent_garbage_collection
(entry=0xb4b08a18) at /tmp/pear/temp/APC/apc_cache.c:211
211	/tmp/pear/temp/APC/apc_cache.c: No such file or
directory.
	in /tmp/pear/temp/APC/apc_cache.c
(gdb) backtrace
#0  0xb6c396f3 in prevent_garbage_collection
(entry=0xb4b08a18) at /tmp/pear/temp/APC/apc_cache.c:211
#1  0xb6c3a924 in apc_cache_find_slot (cache=0x86177d0, key=
      {data = {file = {device = 2049, inode = 1132012}, user
= {identifier = 0x801 <Address 0x801 out of bounds>,
identifier_len = 0}, fpfile = {fullpath = 0x801 <Address
0x801 out of bounds>, fullpath_len = 0}}, mtime =
1201181595, type = 1 '\001'}, t=1224111093) at
/tmp/pear/temp/APC/apc_cache.c:537
#2  0xb6c3aaa7 in apc_cache_find (cache=0x86177d0, key=
      {data = {file = {device = 2049, inode = 1132012}, user
= {identifier = 0x801 <Address 0x801 out of bounds>,
identifier_len = 0}, fpfile = {fullpath = 0x801 <Address
0x801 out of bounds>, fullpath_len = 0}}, mtime =
1201181595, type = 1 '\001'}, t=1224111093) at
/tmp/pear/temp/APC/apc_cache.c:568
#3  0xb6c3f32d in my_compile_file (h=0xbfdfc1f0, type=8) at
/tmp/pear/temp/APC/apc_main.c:343
#4  0xb7656197 in ZEND_INCLUDE_OR_EVAL_SPEC_CONST_HANDLER
(execute_data=0xbfdfd3e0) at
/scratch/install/php-5.2.6/Zend/zend_vm_execute.h:1991
#5  0xb6c4139b in apc_op_ZEND_INCLUDE_OR_EVAL
(execute_data=0xbfdfd3e0) at
/tmp/pear/temp/APC/apc_zend.c:216
#6  0xb76538e8 in execute (op_array=0xb6c54a30) at
/scratch/install/php-5.2.6/Zend/zend_vm_execute.h:92
#7  0xb7635304 in zend_execute_scripts (type=8,
retval=<value optimized out>, file_count=3) at
/scratch/install/php-5.2.6/Zend/zend.c:1134
#8  0xb75f4e30 in php_execute_script
(primary_file=0xbfdff688) at
/scratch/install/php-5.2.6/main/main.c:2005
#9  0xb76b1051 in php_handler (r=0x862c010) at
/scratch/install/php-5.2.6/sapi/apache2handler/sapi_apache2.
#10 0x0807afa7 in ap_run_handler (r=0x862c010) at
config.c:157
#11 0x0807e097 in ap_invoke_handler (r=0x862c010) at
config.c:372
#12 0x0809ce68 in ap_process_request (r=0x862c010) at
http_request.c:258
#13 0x0809a0be in ap_process_http_connection (c=0x8619f18)
at http_core.c:190
#14 0x08081f57 in ap_run_process_connection (c=0x8619f18) at
connection.c:43
#15 0x080a140d in child_main (child_num_arg=<value optimized
out>) at prefork.c:650
#16 0x080a16da in make_child (s=0x80cfca8, slot=7) at
prefork.c:746
#17 0x080a200e in ap_mpm_run (_pconf=0x80cb0a8,
plog=0x8101180, s=0x80cfca8) at prefork.c:881
#18 0x080689ff in main (argc=135041184, argv=0x8617d38) at
main.c:730


Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2008-10-20 03:10 UTC] komanek at natur dot cuni dot cz
new crash dump:
Program terminated with signal 11, Segmentation fault.
#0  0xb6bb08d5 in apc_cache_find_slot (cache=0x860ff60, key=
      {data = {file = {device = 2049, inode = 13402295}, user = {identifier = 0x801 <Address 0x801 out of bounds>, identifier_len = 0}, fpfile = {fullpath = 0x801 <Address 0x801 out of bounds>, fullpath_len = 0}}, mtime = 1154696068, type = 1 '\001'}, t=1224392929) at /tmp/pear/temp/APC/apc_cache.c:525
525	/tmp/pear/temp/APC/apc_cache.c: No such file or directory.
	in /tmp/pear/temp/APC/apc_cache.c
(gdb) backtrace
#0  0xb6bb08d5 in apc_cache_find_slot (cache=0x860ff60, key=
      {data = {file = {device = 2049, inode = 13402295}, user = {identifier = 0x801 <Address 0x801 out of bounds>, identifier_len = 0}, fpfile = {fullpath = 0x801 <Address 0x801 out of bounds>, fullpath_len = 0}}, mtime = 1154696068, type = 1 '\001'}, t=1224392929) at /tmp/pear/temp/APC/apc_cache.c:525
#1  0xb6bb0aa7 in apc_cache_find (cache=0x860ff60, key=
      {data = {file = {device = 2049, inode = 13402295}, user = {identifier = 0x801 <Address 0x801 out of bounds>, identifier_len = 0}, fpfile = {fullpath = 0x801 <Address 0x801 out of bounds>, fullpath_len = 0}}, mtime = 1154696068, type = 1 '\001'}, t=1224392929) at /tmp/pear/temp/APC/apc_cache.c:568
#2  0xb6bb532d in my_compile_file (h=0xbf90d5f0, type=8) at /tmp/pear/temp/APC/apc_main.c:343
#3  0xb75cd703 in ZEND_INCLUDE_OR_EVAL_SPEC_TMP_HANDLER (execute_data=0xbf90ed00) at /scratch/install/php-5.2.6/Zend/zend_vm_execute.h:4566
#4  0xb6bb739b in apc_op_ZEND_INCLUDE_OR_EVAL (execute_data=0xbf90ed00) at /tmp/pear/temp/APC/apc_zend.c:216
#5  0xb75c98e8 in execute (op_array=0xb6bd5bb0) at /scratch/install/php-5.2.6/Zend/zend_vm_execute.h:92
#6  0xb75cbf80 in ZEND_INCLUDE_OR_EVAL_SPEC_CONST_HANDLER (execute_data=0xbf910ee0) at /scratch/install/php-5.2.6/Zend/zend_vm_execute.h:2037
#7  0xb6bb739b in apc_op_ZEND_INCLUDE_OR_EVAL (execute_data=0xbf910ee0) at /tmp/pear/temp/APC/apc_zend.c:216
#8  0xb75c98e8 in execute (op_array=0xb6bcae70) at /scratch/install/php-5.2.6/Zend/zend_vm_execute.h:92
#9  0xb75ab304 in zend_execute_scripts (type=8, retval=<value optimized out>, file_count=3) at /scratch/install/php-5.2.6/Zend/zend.c:1134
#10 0xb756ae30 in php_execute_script (primary_file=0xbf913188) at /scratch/install/php-5.2.6/main/main.c:2005
#11 0xb7627051 in php_handler (r=0x86267a8) at /scratch/install/php-5.2.6/sapi/apache2handler/sapi_apache2.c:629
#12 0x0807b277 in ap_run_handler (r=0x86267a8) at config.c:157
#13 0x0807e367 in ap_invoke_handler (r=0x86267a8) at config.c:372
#14 0x0809c8a8 in ap_process_request (r=0x86267a8) at http_request.c:258
#15 0x08099afe in ap_process_http_connection (c=0x86126a8) at http_core.c:190
#16 0x08082227 in ap_run_process_connection (c=0x86126a8) at connection.c:43
#17 0x080a0e4d in child_main (child_num_arg=<value optimized out>) at prefork.c:650
#18 0x080a111a in make_child (s=0x80cfca8, slot=11) at prefork.c:746
#19 0x080a1a4e in ap_mpm_run (_pconf=0x80cb0a8, plog=0x8101180, s=0x80cfca8) at prefork.c:881
#20 0x08068cbf in main (argc=135041184, argv=0x86104c8) at main.c:740



php.ini settings:

[apc]
apc.enabled = 1
apc.shm_size = 100
apc.shm_segments = 4
apc.ttl = 3600
apc.user_ttl = 3600
apc.gc_ttl = 3600
apc.cache_by_default = 1
apc.file_update_protection = 2
apc.enable_cli = 0
apc.max_file_size = 4M
apc.stat = 1
apc.write_lock = 1
apc.report_autofilter = 0
apc.include_once_override = 1
apc.localcache = 0


3 crashes in the previous week, so I am forced to disable APC on my site untill resolved.
 [2008-10-20 13:29 UTC] shire@php.net
Your configuration is setup to use 4 segments, can you attempt to use one 400MB segment instead of 4 x 100MB segments?

Can you also verify that you're not exceeding your cache size by regularly checking the apc.php script (comes with the APC source code)?

Can you also verify which APC version you're running, I assume it's 3.0.19 correct?
 [2008-10-20 14:44 UTC] komanek at natur dot cuni dot cz
Either the APC is not using segments 2,3,4 at all or the web interface does not display them, I see only the first segments wich seems to be nearly full (but I suppose it is APC's responsibility to stay within reserved memory bounds, isn't it ? I have more than 2GB of free memory, so 400MB does not seem to be much. But the server is heavily used by various PHP apps, so the cache has to do many work.

I am using 3.0.19 - the latest stable version I found - already for some time, my does not seem to be related to the last upgrade.

I will try to use one 400MB segment instead of four smaller, hopefully my boss would not fire me at the next webserver crash.

Interrestingly the crash means the main httpd process produces a core dump, but the other processess are still in memory, although they are serving nothing more.
 [2008-10-31 04:00 UTC] komanek at natur dot cuni dot cz
After running in the recently advised configuration for some time, it seems, the crashes are over. So, in my case, 4x100MB segments produces crashes, 1x400MB seems to work fine. I don't know if the source code line apc_cache.c:211 is somehow connected to multiple memory segment handling, but I hope you do.
 [2009-01-28 04:33 UTC] gsirin at gmail dot com
APC Version	3.0.19
PHP Version	5.2.0-8+etch13
Debian 4.0

Discovering similar Problems.
1 Segment with 128MB.

Running only the file cache works "fine" 
Turning on the heavily used user cache Seg Faults (11) Apache when the Cache is full.
 [2009-02-18 13:50 UTC] shire@php.net
Can you try with the latest CVS of APC.  There's been a handful of changes that might have affected this.

Also, I assume that if you increase your cache size this doesn't happen, or is at least delayed?
 [2009-04-05 23:27 UTC] shire@php.net
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.


 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Fri Nov 08 05:01:28 2024 UTC