|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #59007 Memory leak in APC results with a crash
Submitted: 2009-12-24 08:19 UTC Modified: 2016-08-31 15:23 UTC
From: rubi at metacafe dot com Assigned: cmb (profile)
Status: Wont fix Package: APC (PECL)
PHP Version: 5.3.0 OS: GNU/Linux
Private report: No CVE-ID: None
View Add Comment Developer Edit
Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know!
Just going to say 'Me too!'? Don't clutter the database with that please — but make sure to vote on the bug!
Your email address:
Solve the problem:
18 - 3 = ?
Subscribe to this entry?

 [2009-12-24 08:19 UTC] rubi at metacafe dot com
A web server crashes erratically due to a segmentation fault.
When analyzing a GDB backtrace we see it happens inside APC code:

#0  0x0000002a96fe57fe in apc_request_shutdown () at /path_to_src/APC-3.1.3p1/apc_main.c:871
871                 for (i = 0; cache_entry->data.file.classes[i].class_entry != NULL; i++) {

(gdb) print ((apc_cache_entry_t*) apc_globals.cache_stack).data
$17 = {file = {filename = 0xa86200 "?\222F\227*", op_array = 0x7700000140, functions = 0x0, classes = 0x31, 
    halt_offset = 7598807758542366034}, user = {info = 0xa86200 "?\222F\227*", info_len = 320, val = 0x0, ttl = 49}}

(gdb) print *((apc_cache_entry_t*) apc_globals.cache_stack).data.file.classes
Cannot access memory at address 0x31

There's no PHP backtrace once this error happens (e.g zbacktrace produces an empty output), e.g the script execution has finished or never began.

We will be happy to supply any additional required information.

We do see cases in which CacheFullCount is starting to grow infinitely. Once it happens the server becomes significantly slow, and we get from apc_cache_info() an empty cache_list, but deleted_list contains all the PHP source files. Since we are not sure both problems are related, we will report about it in a different bug report.

Reproduce code:
This error is being reproduced in many different pages in the site. Since the GDB doesn't contain a PHP backtrace we assume that it doesn't related to PHP code.

Actual result:
(gdb) where
#0  0x0000002a96fe57fe in apc_request_shutdown () at /path_to_src/APC-3.1.3p1/apc_main.c:871
#1  0x0000002a96fdb8fc in zm_deactivate_apc (type=9061616, module_number=1) at /path_to_src/APC-3.1.3p1/php_apc.c:320
#2  0x0000002a95fb1d33 in module_registry_cleanup (module=Variable "module" is not available.
) at /path_to_src/php-5.3.0/Zend/zend_API.c:2150
#3  0x0000002a95fb9e43 in zend_hash_reverse_apply (ht=0x2a967b8c40, apply_func=0x2a95fb1d10 <module_registry_cleanup>)
    at /path_to_src/php-5.3.0/Zend/zend_hash.c:755
#4  0x0000002a95fac578 in zend_deactivate_modules () at /path_to_src/php-5.3.0/Zend/zend.c:866
#5  0x0000002a95f5ac88 in php_request_shutdown (dummy=Variable "dummy" is not available.
) at /path_to_src/php-5.3.0/main/main.c:1550
#6  0x0000002a96033b2d in php_handler (r=0xa3ca78) at /path_to_src/php-5.3.0/sapi/apache2handler/sapi_apache2.c:488
#7  0x000000000043cbd3 in ap_run_handler (r=0xa3ca78) at config.c:157
#8  0x000000000043d071 in ap_invoke_handler (r=0xa3ca78) at config.c:372
#9  0x000000000046a2e0 in ap_process_request (r=0xa3ca78) at http_request.c:282
#10 0x00000000004679fd in ap_process_http_connection (c=0xa309f8) at http_core.c:190
#11 0x0000000000443693 in ap_run_process_connection (c=0xa309f8) at connection.c:43
#12 0x0000000000484870 in child_main (child_num_arg=Variable "child_num_arg" is not available.
) at prefork.c:662
#13 0x0000000000484ac4 in make_child (s=0x5d9990, slot=4) at prefork.c:758
#14 0x0000000000485649 in ap_mpm_run (_pconf=Variable "_pconf" is not available.
) at prefork.c:893
#15 0x000000000042a5b5 in main (argc=Variable "argc" is not available.
) at main.c:740


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2010-01-07 08:48 UTC] rubi at metacafe dot com
This issue has been partly resolved.

Basically it happened due to a massive fragmentation caused by short-period caching of files. By avoiding the caching of them in 
APC, the problem ceased to exist.

Nevertheless, it would be great if:
1. APC will not crash in such cases (e.g the memory leak described will be taken care of)
2. APC will trigger an error whenever the fragmentation of it's memory is reaching to risky levels which results with bad 
 [2016-08-31 15:23 UTC]
-Status: Open +Status: Wont fix -Assigned To: +Assigned To: cmb
 [2016-08-31 15:23 UTC]
According to <>, APC support has been
discontinued in favor of OPcache, APCu, the session upload
progress API and WinCache. Therefore this issue won't get fixed.
PHP Copyright © 2001-2021 The PHP Group
All rights reserved.
Last updated: Wed Mar 03 19:01:25 2021 UTC