Simpler test case:

wp.php: https://gist.github.com/1949801
wpdb.php: https://gist.github.com/1949797

call localhost/wp.php 1st call works, 2nd called will fail (some methods unknown)

Just debugged that with CGI and current APC trunk with valgrind, the following 
infos seem to be relevant:


first call:

==15012== 
==15012== Conditional jump or move depends on uninitialised value(s)
==15012==    at 0x4DC7BC1: apc_new_interned_string (apc_string.c:82)
==15012==    by 0x4DC7FCE: apc_copy_internal_strings (apc_string.c:190)
==15012==    by 0x4DC825E: apc_interned_strings_init (apc_string.c:224)
==15012==    by 0x4DBC95D: apc_module_init (apc_main.c:845)
==15012==    by 0x4DAC38D: zm_startup_apc (php_apc.c:347)
==15012==    by 0x8495FF3: zend_startup_module_ex (zend_API.c:1657)
==15012==    by 0x84A076D: zend_hash_apply (zend_hash.c:716)
==15012==    by 0x849656C: zend_startup_modules (zend_API.c:1784)
==15012==    by 0x83E9B5B: php_module_startup (main.c:2191)
==15012==    by 0x85E15E6: php_cgi_startup (cgi_main.c:931)
==15012==    by 0x85E43EC: main (cgi_main.c:1882)
==15012== 
==15012== Conditional jump or move depends on uninitialised value(s)
==15012==    at 0x4DC7C9D: apc_new_interned_string (apc_string.c:109)
==15012==    by 0x4DC7FCE: apc_copy_internal_strings (apc_string.c:190)
==15012==    by 0x4DC825E: apc_interned_strings_init (apc_string.c:224)
==15012==    by 0x4DBC95D: apc_module_init (apc_main.c:845)
==15012==    by 0x4DAC38D: zm_startup_apc (php_apc.c:347)
==15012==    by 0x8495FF3: zend_startup_module_ex (zend_API.c:1657)
==15012==    by 0x84A076D: zend_hash_apply (zend_hash.c:716)
==15012==    by 0x849656C: zend_startup_modules (zend_API.c:1784)
==15012==    by 0x83E9B5B: php_module_startup (main.c:2191)
==15012==    by 0x85E15E6: php_cgi_startup (cgi_main.c:931)
==15012==    by 0x85E43EC: main (cgi_main.c:1882)


second call:

==15613== 
==15613== Invalid read of size 1
==15613==    at 0x4026979: memcpy (mc_replace_strmem.c:497)
==15613==    by 0x4DC18EF: apc_pmemcpy (apc_pool.c:493)
==15613==    by 0x4DB6FDE: my_copy_hashtable_ex (apc_compile.c:902)
==15613==    by 0x4DB94B2: apc_copy_class_entry_for_execution 
(apc_compile.c:1745)
==15613==    by 0x4DBA3C3: install_class (apc_main.c:176)
==15613==    by 0x4DBAAE7: cached_compile (apc_main.c:357)
==15613==    by 0x4DBB77B: my_compile_file (apc_main.c:552)
==15613==    by 0x821E4ED: phar_compile_file (phar.c:3391)
==15613==    by 0x84D8D99: ZEND_INCLUDE_OR_EVAL_SPEC_CONST_HANDLER 
(zend_vm_execute.h:2572)
==15613==    by 0x84CE51B: execute (zend_vm_execute.h:410)
==15613==    by 0x848F69B: zend_execute_scripts (zend.c:1272)
==15613==    by 0x83EA537: php_execute_script (main.c:2473)
==15613==  Address 0x585bf77 is 6,871 bytes inside a block of size 8,208 alloc'd
==15613==    at 0x4DBE227: apc_sma_malloc_ex (apc_sma.c:467)
==15613==    by 0x4DBE5BB: apc_sma_malloc (apc_sma.c:517)
==15613==    by 0x4DC1373: create_pool_block (apc_pool.c:217)
==15613==    by 0x4DC14EE: apc_realpool_alloc (apc_pool.c:274)
==15613==    by 0x4DB7863: apc_copy_op_array (apc_compile.c:1109)
==15613==    by 0x4DB5FC4: my_copy_function (apc_compile.c:470)
==15613==    by 0x4DB708D: my_copy_hashtable_ex (apc_compile.c:924)
==15613==    by 0x4DB674C: my_copy_class_entry (apc_compile.c:666)
==15613==    by 0x4DB89D3: apc_copy_new_classes (apc_compile.c:1434)
==15613==    by 0x4DBB04C: apc_compile_cache_entry (apc_main.c:457)
==15613==    by 0x4DBBBAB: my_compile_file (apc_main.c:610)
==15613==    by 0x821E4ED: phar_compile_file (phar.c:3391)

Same problem here. I'd like to add that it started when I upgraded to Apache 2.4 and recompiled PHP for it. It might be related.

After the shutdown crash was fixed in #61238 it gives a couple of other errors 
on 
startup:

==12900== 4 bytes in 1 blocks are definitely lost in loss record 2 of 86
==12900==    at 0x4024F20: malloc (vg_replace_malloc.c:236)
==12900==    by 0x4DBD3E1: apc_pthreadmutex_create (apc_pthreadmutex.c:30)
==12900==    by 0x4DB1161: apc_cache_create (apc_cache.c:301)
==12900==    by 0x4DBC70A: apc_module_init (apc_main.c:809)
==12900==    by 0x4DAC38D: zm_startup_apc (php_apc.c:347)
==12900==    by 0x84960CF: zend_startup_module_ex (zend_API.c:1657)
==12900==    by 0x84A0849: zend_hash_apply (zend_hash.c:716)
==12900==    by 0x8496648: zend_startup_modules (zend_API.c:1784)
==12900==    by 0x83E9B5B: php_module_startup (main.c:2191)
==12900==    by 0x85DFF0B: php_cli_startup (php_cli.c:414)
==12900==    by 0x85E24CB: main (php_cli.c:1336)


==12900== 4,194,304 bytes in 1 blocks are definitely lost in loss record 86 of 
86
==12900==    at 0x4DBE227: apc_sma_malloc_ex (apc_sma.c:467)
==12900==    by 0x4DBE5BB: apc_sma_malloc (apc_sma.c:517)
==12900==    by 0x4DC80BB: apc_interned_strings_init (apc_string.c:201)
==12900==    by 0x4DBC961: apc_module_init (apc_main.c:845)
==12900==    by 0x4DAC38D: zm_startup_apc (php_apc.c:347)
==12900==    by 0x84960CF: zend_startup_module_ex (zend_API.c:1657)
==12900==    by 0x84A0849: zend_hash_apply (zend_hash.c:716)
==12900==    by 0x8496648: zend_startup_modules (zend_API.c:1784)
==12900==    by 0x83E9B5B: php_module_startup (main.c:2191)
==12900==    by 0x85DFF0B: php_cli_startup (php_cli.c:414)
==12900==    by 0x85E24CB: main (php_cli.c:1336)

A simpler reproduce code;

<?php

$there = 'world';

class hello
{
    function __construct($p)
    {   
        $this->testme($p);
    }   

    function testme($p)
    {   
        echo "testme $p <br>";
    }   
}

$h = new hello($there);

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.

Tested and reproduced:  Apache 2.4.2, php-5.4.4 and APC 3.1.9.  

Is this supposed to be fixed in the current stable versions?

Not meaning to just say me too, but sorry for ignorance of php bug tracking, patch merging, etc..., just not sure if this is a regression or what versions of php/apc it is slated to be included in.  I believe PHP 5.4.4 / APC 3.1.9 were both release after the closing of this bug. If this wasn't slated to be released yet, is there a good way to tell well it is slated to be included?

As expected, if I comment out extension=apc.so in php.ini, all is fine.

Sorry for clutter.  APC 3.1.10 (beta) resolves the issue.  I was mistaken, 3.1.9 was released prior.

I don't believe this issue should be closed. As of 3.1.13 and trunk (against PHP 5.4.7), I am still getting this error.

I should have mentioned in my previous bug that it happens under 50+ requests/second load, inconsistently, and only on classes that are attached to $GLOBALS.

I am experiencing this issue with PHP 5.4.36 and APC 3.1.15