php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #57304 APC causes core dump after a few days of running
Submitted: 2006-10-18 23:02 UTC Modified: 2007-12-26 17:59 UTC
From: bob at norcalttora dot com Assigned:
Status: Closed Package: APC (PECL)
PHP Version: 5.1.2 OS: FreeBSD 5.3-Stable
Private report: No CVE-ID: None
View Developer Edit
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: bob at norcalttora dot com
New email:
PHP Version: OS:

 

 [2006-10-18 23:02 UTC] bob at norcalttora dot com 
Description:
------------
After running for at least ~1 day Apache will start to dump 
core. I have a feeling that not all of the core files are 
referring to the same problem but this is the first one I've 
opened up in gdb. The problem does not occur if APC is 
disabled.


Reproduce code:
---------------
Using APC 3.0.12p2

My apc vars from php.ini
apc.enabled="1"                                                                 
apc.mmap_file_mask="/tmp/apc/apc.XXXXXX"                                                  
apc.shm_size="30"                                                               
auto_globals_jit = Off                                                          
apc.filters="horde,class_bbcode_alt.php,wiki,administrator"                     
apc.ttl=3600                                                                    
apc.user_ttl = 1800 

My site runs vBulletin 3.0x, MediaWiki and is fairly well traveled bringing in 1 million hits to 10GB of HTTP traffic a day.

I filed bug 7547 a while back though I don't think that's actually relevant.

Actual result:
--------------
The backtrace from the core file:
#0  0x28dde3cd in sma_allocate () from /usr/local/lib/php/
20050922/apc.so
(gdb) bt
#0  0x28dde3cd in sma_allocate () from /usr/local/lib/php/
20050922/apc.so
#1  0x28dde7a7 in apc_sma_malloc () from /usr/local/lib/php/
20050922/apc.so
#2  0x28dd8b3c in apc_copy_op_array () from /usr/local/lib/
php/20050922/apc.so
#3  0x28dd7bb5 in my_copy_function () from /usr/local/lib/
php/20050922/apc.so
#4  0x28dd90b9 in apc_copy_new_functions ()
   from /usr/local/lib/php/20050922/apc.so
#5  0x28ddb540 in my_compile_file () from /usr/local/lib/
php/20050922/apc.so
#6  0x28635248 in ?? () from /usr/local/libexec/apache2/
libphp5.so
#7  0xbfbf58d0 in ?? ()
#8  0x00000008 in ?? ()
#9  0x00000002 in ?? ()
#10 0x2862f45c in ?? () from /usr/local/libexec/apache2/
libphp5.so
#11 0x08559210 in ?? ()
#12 0x2a5ae8ec in ?? ()
#13 0x083a32c0 in ?? ()
#14 0x2a5af648 in ?? ()
#15 0x0000000b in ?? ()
#16 0x2a4c8888 in ?? ()
#17 0xbfbf5908 in ?? ()
#18 0x0060c4dc in ?? ()
#19 0x00000000 in ?? ()
#20 0xbfbf9d84 in ?? ()
#21 0x00000000 in ?? ()
#22 0x00000001 in ?? ()
#23 0x2a4c8805 in ?? ()
#24 0x2a4c8a00 in ?? ()
#25 0x0836a10c in ?? ()
#26 0x08491a0c in ?? ()
#27 0x285f14ec in ?? () from /usr/local/libexec/apache2/
libphp5.so
#28 0x285e2d84 in ?? () from /usr/local/libexec/apache2/
libphp5.so
#29 0x285e2d98 in ?? () from /usr/local/libexec/apache2/
libphp5.so
#30 0x00000000 in ?? ()
#31 0xbfbf9900 in ?? ()
#32 0xbfbf5a88 in ?? ()
#33 0x2a5aea1c in ?? ()
#34 0x2a5ae9d0 in ?? ()
#35 0xbfbf99c0 in ?? ()
#36 0xbfbf99c0 in ?? ()
#37 0xbfbf5928 in ?? ()
#38 0x28667f13 in ?? () from /usr/local/libexec/apache2/
libphp5.so
#39 0x2a4c8888 in ?? ()
#40 0x0000000a in ?? ()
#41 0xbfbf5a88 in ?? ()
#42 0x00000000 in ?? ()
#43 0x0835660c in ?? ()
#44 0xbfbf99c0 in ?? ()
#45 0xbfbf9a18 in ?? ()
#46 0x2862ea99 in ?? () from /usr/local/libexec/apache2/
libphp5.so
#47 0xbfbf99c0 in ?? ()
#48 0x284af3d1 in ?? () from /usr/local/libexec/apache2/
mod_rewrite.so
#49 0x00000001 in ?? ()
#50 0x28321272 in apr_palloc () from /usr/local/lib/apache2/
libapr-0.so.9
Previous frame inner to this frame (corrupt stack?)

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2006-10-27 13:07 UTC] bob at norcalttora dot com 
Here's a different backtrace:

(gdb) bt
#0  0x28dd6472 in apc_cache_expunge () from /usr/local/lib/
php/20050922/apc.so
#1  0x28ddb4f6 in my_compile_file () from /usr/local/lib/
php/20050922/apc.so
#2  0x285fe7a2 in ?? () from /usr/local/libexec/apache2/
libphp5.so
#3  0xbfbf5500 in ?? ()
#4  0x00000002 in ?? ()
#5  0x0844121c in ?? ()
#6  0x00002800 in ?? ()
#7  0xbfbf5620 in ?? ()
#8  0xbfbf56a0 in ?? ()
#9  0x00000000 in ?? ()
#10 0x285ef378 in ?? () from /usr/local/libexec/apache2/
libphp5.so
#11 0x0000a000 in ?? ()
#12 0x00002800 in ?? ()
#13 0x00000000 in ?? ()
#14 0x00000000 in ?? ()
#15 0x00000005 in ?? ()
#16 0x084cb74c in ?? ()
#17 0x087fe40c in ?? ()
#18 0x087eaa0c in ?? ()
#19 0x285f14ec in ?? () from /usr/local/libexec/apache2/
libphp5.so
#20 0x285e2d84 in ?? () from /usr/local/libexec/apache2/
libphp5.so
#21 0x285e2d98 in ?? () from /usr/local/libexec/apache2/
libphp5.so
#22 0x00000000 in ?? ()
#23 0x00000000 in ?? ()
#24 0x00000000 in ?? ()
#25 0x00000001 in ?? ()
#26 0xbfbf5624 in ?? ()
#27 0xbfbf5620 in ?? ()
#28 0xbfbf56a0 in ?? ()
#29 0xbfbf5558 in ?? ()
#30 0x00000000 in ?? ()
#31 0x087ef874 in ?? ()
#32 0x087ef858 in ?? ()
#33 0xbfbf55e8 in ?? ()
#34 0x286352ab in ?? () from /usr/local/libexec/apache2/
libphp5.so
#35 0x00000002 in ?? ()
#36 0x087ef874 in ?? ()
#37 0xbfbf55b8 in ?? ()
#38 0x2862f0c1 in ?? () from /usr/local/libexec/apache2/
libphp5.so
#39 0xbfbf5624 in ?? ()
#40 0x0000004f in ?? ()
#41 0xbfbf55b8 in ?? ()
#42 0x087ef858 in ?? ()
#43 0x087f6000 in ?? ()
#44 0x00002000 in ?? ()
#45 0x00000000 in ?? ()
#46 0x0041b9cc in ?? ()
#47 0x00000000 in ?? ()
---Type <return> to continue, or q <return> to quit--- 
#48 0xbfbf6504 in ?? ()
#49 0x00000000 in ?? ()
#50 0x283af006 in ldexp () from /lib/libc.so.5
Previous frame inner to this frame (corrupt stack?)
 [2006-10-27 13:55 UTC] shire@php.net 
Can you verify (using apc.php) that you are not running out of memory?  It looks like you're shared memory size is 30, can you state how much of this is consumed?  (you may need to watch this over a period to see if it's slowly consuming the entire shared memory segment).
 [2006-10-27 13:57 UTC] bob at norcalttora dot com 
I shutdown and restarted (term, not hup) apache about an hour 
ago. I'm at 100% utilization of the cache right now.

Is that bad? I figured you'd just round robin over the memory, 
purging the LRU stuff.

I can spare more memory, should I double to 60mb?
 [2006-10-27 14:04 UTC] shire@php.net 
The cache will attempt to remove entries when at capacity based upon their ttl value (if not set it will expunge the entire cache).  This of course is not optimal, so if you can spare the extra memory, I would recomend doing so until your cache has at least a little extra space.  Please try this and let us know if it at least solves the segfault problem.
 [2006-10-27 14:27 UTC] bob at norcalttora dot com 
Ok, I've set it to 100MB. The cache is filling relatively 
quickly (21MB at the moment). If I don't post for a week or 
two I think we're in good shape. I'll try to follow up 
regardless of what I find (or don't find).
 [2006-10-27 14:30 UTC] shire@php.net 
Thank you, it would be helpful if you could post back here to let us know your status.
 [2006-11-07 12:17 UTC] bob at norcalttora dot com 
I set the cache size to 100MB and APC is currently, after 10 
days, using 35MB. I'm willing to say that this workaround is 
working for me, however, I still think there's a bug here.
 [2006-11-07 12:39 UTC] gopalv82 at yahoo dot com 
I'm aware that there is a bug in the high-load, cache full scenarios.

But the problem is reproducing it to test out every fix attempt made ("few days").
 [2007-12-26 17:59 UTC] rasmus@php.net 
We believe this is fixed now.  Please try APC-3.0.16
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved. 		Last updated: Sun Oct 26 06:00:02 2025 UTC