Anything abnormal in the server logs? Also, would it be possible for you to test with 5.3.20? Please also try to test with a small snippet - if it not suffer the same fate you can try to extract the reproduce code from your app.

Thank you for your answer!
Really I do not know how to use APC. While running WordPress-es and looking at apc.php I noticed no Hits. I know WP uses APC but it is a production server, so I got frightened and reverted back to 3.1.13

I have the same problem on Ubuntu 12.04.01 LTS (php 5.3.10). There were only few 
hits and a lot of cache misses. Nothing peculiar in server logs, no errors 
during build time. make test gives:

FAILED TEST SUMMARY
---------------------------------------------------------------------
APC: classes with namespaces (php 5.3) [tests/apc53_001.phpt]
APC: global spaces (php 5.3) [tests/apc53_002.phpt]
APC: closures (php 5.3) [tests/apc53_004.phpt]
APC: apc_store/fetch with objects [tests/apc_002.phpt]
APC: apc_store/fetch with objects (php 5.3) [tests/apc_003b.phpt]
APC: apc_delete_file test [tests/apc_009.phpt]
APC: bindump file cache part 1 [tests/apc_bin_002.phpt]
Bug #62757 (php-fpm carshed when used apc_bin_dumpfile with apc.serializer) 
[tests/bug62757.phpt]
Bug #62765 (apc_bin_dumpfile report Fatal error when there is "goto" in 
function) [tests/bug62765.phpt]
APC: APCIterator formats [tests/iterator_006.phpt]
=====================================================================

You may have found a problem in PHP.

I'm having the same problem. Upgraded from 3.1.13 to 3.1.13 via pecl install apc-3.1.14 on Ubuntu 12.04 LTS x64 official repository.

I've used the same options when compiling 3.1.14 and all I got was cache misses on the apc.php stat page.

Tested on a server with WordPress 3.5.

Reverted back to 3.1.13 and the problems were gone.

What are your apc.stat and apc.include_once_override settings?

apc.include_once_override	0
apc.stat	0

Also, if tests are failing, please look at the failures and see if there is a 
common cause. eg. if tests/apc53_001.phpt failed, look at tests/apc53_001.diff

Will the diff files help? Below are first two diff files. Anything I can do to 
help?

apc53_001.diff:
001+ 
001- object(Foo\Bar\Baz)#1 (3) {
002-   ["i"]=>
003-   int(1)
004-   ["f":protected]=>
005-   float(3.14)
006-   ["s":"Foo\Bar\Baz":private]=>
007-   string(11) "hello world"
008- }
009- ===DONE===


apc53_002.diff:
001+ 
001- array(4) {
002-   [0]=>
003-   int(1)
004-   [1]=>
005-   int(2)
006-   [2]=>
007-   int(3)
008-   [3]=>
009-   int(4)
010- }
011- array(4) {
012-   [0]=>
013-   int(1)
014-   [1]=>
015-   int(2)
016-   [2]=>
017-   int(3)
018-   [3]=>
019-   int(4)
020- }
021- string(8) "IT WORKS"
022- ===DONE===

Maybe it is config-related somehow. I tried a bunch of different PHP versions 
with APC 3.1.14 today and they all worked. But all my configs were close to 
this:

extension = apc.so
apc.enabled = 1
apc.shm_segments = 1
apc.optimization = 0
apc.shm_size = 384M
apc.ttl = 7200
apc.user_ttl = 7200
apc.num_files_hint = 1024
apc.mmap_file_mask = /tmp/apc.XXXXXX
apc.enable_cli = 1
apc.cache_by_default = 1
apc.include_once_override = 1
apc.stat = 1
apc.stat_ctime = 1

My config:
;[APC]
extension=apc.so
apc.shm_size = 160M
apc.max_file_size = 16M
apc.file_update_protection = 5
apc.slam_defense = 0
; apc.write_lock = 1

build config:
./configure --enable-apc-mmap --enable-apc --with-php-config=/usr/bin/php-config

This is the second time I write this comment, first time dunno what happened but I lost all the comment when submitting...

Ok let's begin.

I have two server installations. Production server and testing server, both have the same webserver configuration (nginx + php5-fpm + apc + memcache + varnish 3 + drupal 7).

Production server runs a Debian Squeeze and testing server runs a Debian Sid/Wheezy. Monday the 7th production server had PHP5.3 (from dotdeb.org repository) and testing server had PHP5.4 (from debian repository).

I saw the 3.1.14, I compiled in my testing env, all tests ok, I compiled in prod server, I obtained the same errors Jan Slusarczyk obtained. 

as PHP5.3 was a little old, I upgraded prod server to "PHP5.4.10-1~dotdeb.0" I checked tests all succeeded and now I blame myself for not testing better, yeps I was too lazy, my fault. And testing server to "PHP5.4.4-11" (yeps i'm using deb repository, but is because Squeeze was frozen without php5-fpm, that's the reason to use dotdeb repository).

Some hours later I started to have 502 Bad Gateway in some random pages,I have 4 full drupal 7 + modules obviously updated,  finally in nginx logs I obtained this:
2013/01/09 09:01:27 [error] 15489#0: *53 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: 192.168.1.3, server: xxx.xxx, request: "GET /content/wysiwyg-html5-contrib-commit HTTP/1.1", upstream: "fastcgi://unix:/var/run/php5-fpm.sock:", host: "xxx.xxx", referrer: "http://xxx.xxx/"

The most weird thing is now I have 3.1.13 version which never failed in test with PHP5.3 but now in prod server tests:
=====================================================================
FAILED TEST SUMMARY
---------------------------------------------------------------------
APC: Bug #62456 Incorrect description of notice variation 1 (php 5.4 nts) [tests/apc54_004.phpt]
APC: APCIterater basic test on file (php 5.4) [tests/apc54_020.phpt]
APC: Bug #62699 Wrong behavior with traits (variant 2) [tests/apc54_bug62699_2.phpt]
=====================================================================

And in testing server I obtained this:
=====================================================================
FAILED TEST SUMMARY
---------------------------------------------------------------------
APC: Bug #62456 Incorrect description of notice variation 1 (php 5.4 nts) [tests/apc54_004.phpt]
APC: Bug #59938 APCIterator fails with large user cache [tests/apc54_018.phpt]
=====================================================================

But both seem to be more stable, and during last 12 hours I didn't obtained errors nor visible nor in logs.

My apc.ini config (very simple):

extension=apc.so
apc.enabled=1
apc.shm_size=128M
apc.ttl=7200
apc.user_ttl=7200
apc.cache_by_default = 1
apc.filters = "apc\.php$,memcache\.php$"
apc.stat = 0
apc.mmap_file_mask = "/tmp/apc.XXXXXX"

I have tested all version from 3.1.9 to 3.1.13 with default compile options.

Also 3.1.13 is working for me

I do have the same problem here in one of my test servers, 3.1.13 works as expected whereas 3.1.14 does cache much less. I still see that some caching is done using apc_cache_info(), but the amount of cached files is much less than with the previous version.

The test environment consists of

CentOS 5.8
PHP 5.3.21 (FPM)
APC 3.1.14
compiled using GCC 4.1.2 and --enable-apc-mmap --enable-apc

While building 3.1.14 'make test' produces the same FAILs as reported by Jan. The APC config options used are:

apc.enabled=1
apc.shm_segments=1
apc.shm_size=128M
apc.ttl=7200
apc.user_ttl=7200
apc.num_files_hint=1024
apc.mmap_file_mask=/tmp/apc53.XXXXXXXX
apc.enable_cli=1

I already tested the options apc.include_once_override and apc.stat_ctime, but they do not change anything.

Hi,
we have the same problem. We used APC v3.1.9 so far, but got affected by bug #52144 which should be fixed in 3.1.14. The bug itself does not come up anymore, but now we are not caching as many files as before.

With version 3.1.9 (which is active on 66% of our cluster) we cache about 60 MB of opcode. With version 3.1.14 we cache only 20kb. The user cache itself is not affected.

We are using the following apc.ini settings (for both APC versions):
"""
extension=apc.so
apc.enabled=1
apc.include_once_override=false
apc.mmap_file_mask=/tmp/apc.XXXXXX
apc.rfc1867=On
apc.shm_segments=1
apc.shm_size=1024M
apc.max_file_size=512M
apc.stat=1
apc.optimization=4
apc.ttl=7200
apc.user_ttl=7200
apc.lazy_classes=0
apc.lazy_functions=0
apc.num_files_hint=0
"""

We are using Ubuntu 12.04 LTS with stock apache and mod_php5.

Hi,
are there any news on this bug or any workarounds known? We would really like to use version 3.1.14.

Hello,

I bumped into this issue, tracked it down to this in the git repo:

Before and including commit
88f76c3d7957b14afaa774b77d457d8e8b65220d

OK, we have hits

from (including) commit
7f57ec6aefda67a348e5053363e02f7f493870ce

No more hits...

Debian Squeeze 6.0.8, php5 5.3.3-7+squeeze18 , and apc compiled locally with the same stuff, but using the git repo to compile it.

APC is no longer supported in favor of opcache that comes bundled with PHP, if you wish to use the user cache, then look at PECL/APCu.