Are you using the latest pecl/apc from svn?

I downloaded APC with "pecl download APC". Version 3.1.9 was downloaded. 
Now, after your question, I downloaded with:

svn co http://svn.php.net/repository/pecl/apc/trunk/ apc-trunk

This seems to be the very same version, though. In phpinfo() it says "Revision 308812".

Nevertheless I compiled the SVN version as well just to be sure and it also crashes frequently. As a workaround, for now, I set

apc.cache_by_default=off

At least I can now use APC's variable store facilities. Though the missing cache, of course, still remains a big performance problem.

Are you using a thread-safe build? Please, provide your PHP's configure line.

Thanks!

APC: pecl/svn - trunk (Revision 322504)
PHP: 5_4, svn - PHP 5.4.0RC7-dev
Static build: ./configure --enable-apc --disable-apc-pthreadmutex --enable-maintainer-zts --enable-debug

NOTE: I'm showing traces from a patched PHP/APC, line numbers may differ slightly, my copy has some additional php_printf()'s in it.



Some thoughts on this. I am able to reproduce the issue. It takes nothing but a thread-safe/ZTS PHP build with APC support on CLI:

  valgrind sapi/cli/php -d apc.enable_cli=1 -r 'echo 123;'

And there's our crash/invalid free:

==22448== Invalid free() / delete / delete[]
==22448==    at 0x40282A3: free (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==22448==    by 0x8431BB0: zend_hash_destroy (zend_hash.c:560)
==22448==    by 0x84202D4: zend_shutdown (zend.c:819)
==22448==    by 0x83889FB: php_module_shutdown (main.c:2349)
==22448==    by 0x8568679: main (php_cli.c:1371)
==22448==  Address 0x48b0e64 is 568,660 bytes inside a block of size 4,194,304 alloc'd
==22448==    at 0x81A7E67: apc_sma_malloc_ex (apc_sma.c:467)
==22448==    by 0x81A82F7: apc_sma_malloc (apc_sma.c:517)
==22448==    by 0x81B1930: apc_interned_strings_init (apc_string.c:218)
==22448==    by 0x81A6881: apc_module_init (apc_main.c:846)
==22448==    by 0x81967AC: zm_startup_apc (php_apc.c:347)
==22448==    by 0x842806F: zend_startup_module_ex (zend_API.c:1653)
==22448==    by 0x843220E: zend_hash_apply (zend_hash.c:716)
==22448==    by 0x8428578: zend_startup_modules (zend_API.c:1780)
==22448==    by 0x8388615: php_module_startup (main.c:2194)
==22448==    by 0x8565EC7: php_cli_startup (php_cli.c:414)
==22448==    by 0x85684CA: main (php_cli.c:1336)
==22448== 
==22448== Invalid free() / delete / delete[]
==22448==    at 0x40282A3: free (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==22448==    by 0x8431BB0: zend_hash_destroy (zend_hash.c:560)
==22448==    by 0x8413C54: destroy_zend_class (zend_opcode.c:327)
==22448==    by 0x8431BB0: zend_hash_destroy (zend_hash.c:560)
==22448==    by 0x84202D4: zend_shutdown (zend.c:819)
==22448==    by 0x83889FB: php_module_shutdown (main.c:2349)
==22448==    by 0x8568679: main (php_cli.c:1371)
==22448==  Address 0x48b1238 is 569,640 bytes inside a block of size 4,194,304 alloc'd
==22448==    at 0x81A7E67: apc_sma_malloc_ex (apc_sma.c:467)
==22448==    by 0x81A82F7: apc_sma_malloc (apc_sma.c:517)
==22448==    by 0x81B1930: apc_interned_strings_init (apc_string.c:218)
==22448==    by 0x81A6881: apc_module_init (apc_main.c:846)
==22448==    by 0x81967AC: zm_startup_apc (php_apc.c:347)
==22448==    by 0x842806F: zend_startup_module_ex (zend_API.c:1653)
==22448==    by 0x843220E: zend_hash_apply (zend_hash.c:716)
==22448==    by 0x8428578: zend_startup_modules (zend_API.c:1780)
==22448==    by 0x8388615: php_module_startup (main.c:2194)
==22448==    by 0x8565EC7: php_cli_startup (php_cli.c:414)
==22448==    by 0x85684CA: main (php_cli.c:1336)


The invalid delete happens after apc_interned_strings_shutdown(TSRMLS_D) from apc_string.c, http://lxr.php.net/opengrok/xref/PECL/apc/apc_string.c#227:

    227 void apc_interned_strings_shutdown(TSRMLS_D)
    228 {
    229     zend_hash_clean(CG(function_table));
    230     zend_hash_clean(CG(class_table));
    231     zend_hash_clean(EG(zend_constants));
    232 
    233     CG(interned_strings_start) = old_interned_strings_start;
    234     CG(interned_strings_end) = old_interned_strings_end;
    235     zend_new_interned_string = old_new_interned_string;
    236     zend_interned_strings_snapshot = old_interned_strings_snapshot;
    237     zend_interned_strings_restore = old_interned_strings_restore;
    238 
    239     DESTROY_LOCK(APCSG(lock));
    240 }

APC cleans some compile/executor global hash tables, among them CG(class_table). The trace shows that the invalid delete happens after:

  ==22448==    by 0x84202D4: zend_shutdown (zend.c:819)

http://lxr.php.net/opengrok/xref/PHP_5_4/Zend/zend.c#819 shows:

    807 void zend_shutdown(TSRMLS_D) /* {{{ */
    808 {
    809 #ifdef ZEND_SIGNALS
    810 	zend_signal_shutdown(TSRMLS_C);
    811 #endif
    812 #ifdef ZEND_WIN32
    813 	zend_shutdown_timeout_thread();
    814 #endif
    815 	zend_destroy_rsrc_list(&EG(persistent_list) TSRMLS_CC);
    816 	zend_destroy_modules();
    817 
    818 	zend_hash_destroy(GLOBAL_FUNCTION_TABLE);
    819 	zend_hash_destroy(GLOBAL_CLASS_TABLE);
    820 

Thus, one can see there is an issue with the class table. This, I think, is matched by other reports. My trace:

==22448==  Address 0x48b1238 is 569,640 bytes inside a block of size 4,194,304 alloc'd
==22448==    at 0x81A7E67: apc_sma_malloc_ex (apc_sma.c:467)
==22448==    by 0x81A82F7: apc_sma_malloc (apc_sma.c:517)
==22448==    by 0x81B1930: apc_interned_strings_init (apc_string.c:218)

Makes me assume, its about freeing an interned string from APC. At this point, I wondered what APC's zend_hash_clean() call is about: 

    230     zend_hash_clean(CG(class_table));

... which is then followed by Zend's shutdown activity:

    819 	zend_hash_destroy(GLOBAL_CLASS_TABLE);

I wondered why it reads differently and checked if there is a difference between CG(class_table) and GLOBAL_CLASS_TABLE. The two can be different, depending whether ZTS is used or not, http://lxr.php.net/opengrok/xref/PHP_5_3/Zend/zend.c#33: 

     33 #ifdef ZTS
     34 # define GLOBAL_FUNCTION_TABLE		global_function_table
     35 # define GLOBAL_CLASS_TABLE			global_class_table
     36 # define GLOBAL_CONSTANTS_TABLE		global_constants_table
     37 # define GLOBAL_AUTO_GLOBALS_TABLE	global_auto_globals_table
     38 #else
     39 # define GLOBAL_FUNCTION_TABLE		CG(function_table)
     40 # define GLOBAL_CLASS_TABLE			CG(class_table)
     41 # define GLOBAL_AUTO_GLOBALS_TABLE	CG(auto_globals)
     42 # define GLOBAL_CONSTANTS_TABLE		EG(zend_constants)
     43 #endif

If ZTS is used, the class table hash destroyed by Zend during shutdown is not CG(class_table) but global_class_table. global_class_table is a static variable from zend.c, http://lxr.php.net/opengrok/xref/PHP_5_3/Zend/zend.c#100:

    100 #ifdef ZTS
    101 ZEND_API int compiler_globals_id;
    102 ZEND_API int executor_globals_id;
    103 static HashTable *global_function_table = NULL;
    104 static HashTable *global_class_table = NULL;
    105 static HashTable *global_constants_table = NULL;
    106 static HashTable *global_auto_globals_table = NULL;
    107 static HashTable *global_persistent_list = NULL;
    108 #endif

This made me wonder what would happen, if I compiled PHP without ZTS. Guess what: no crash on my box if not using APC with ZTS....

Ulf

In case this still helps: My configure line according to phpinfo():

	'./configure' '--prefix=/usr' '--datadir=/usr/share/php' '--mandir=/usr/share/man' '--bindir=/usr/bin' '--libdir=/usr/share' '--includedir=/usr/include' '--sysconfdir=/etc' '--with-libdir=lib64' '--with-config-file-path=/etc' '--with-exec-dir=/usr/lib/php/bin' '--disable-debug' '--enable-inline-optimization' '--enable-magic-quotes' '--enable-safe-mode' '--enable-sigchild' '--enable-ctype' '--enable-cli' '--with-openssl' '--with-t1lib' '--with-apxs2=/usr/bin/apxs2' 

I see nothing there about ZTS, though.

This bug has been fixed in SVN.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.

 For Windows:

http://windows.php.net/snapshots/
 
Thank you for the report, and for helping us make PHP better.

This bug has been fixed in trunk, see #61238