This is not a QuickForm-specific issue.  It's a general problem with APC when using certain types of complex class hierarchies and particular include orders.  QuickForm simply triggers this bug.

I've crafted a replication scenario that doesn't involve QuickForm.  The scenario is complex, so bear with me.  You'll need to create 5 files:

A.php
-----
<?
class A {
  function say_something() {
    print "Hello, World.<br />";
  }
}
?>

B.php
-----
<?
require_once "A.php";
class B extends A {
}
?>

Z.php
-----
<?
require_once "A.php";
class Z extends A {
}
?>

first.php
---------
<?
require_once "Z.php";
require_once "B.php";
?>

second.php
----------
<?
require_once "B.php";
$obj = new B();
$obj->say_something()
?>

SCENARIO ONE
------------
1) Restart your apache (or apc_clear_cache())
2) Load first.php in your browser
3) Load second.php in your browser
  EXPECTED: "Hello, World."
  ACTUAL: "Call to undefined method B::say_something()"

SCENARIO TWO
------------
1) Restart your apache (or apc_clear_cache())
2) Load second.php in your browser (no first.php)
  EXPECTED: "Hello, World."
  ACTUAL: "Hello, World."
3) Load first.php in your browser
4) Load second.php in your browser (no first.php)
  EXPECTED: "Hello, World."
  ACTUAL: "Hello, World."

There is something about calling first.php BEFORE second.php that causes the APC cache to get into a bad state.  As long as first.php is the first script loaded, ALL calls to second.php will fail until Apache is restarted or apc_clear_cache is called.  If second.php is loaded BEFORE first.php ever is, then both scripts work fine going forward.


VERSIONS
--------
PHP: 5.0.2
Apache: 1.3.29
APC: 3.0.8
OS: Linux 2.6.9

.

I've got an idea of how this bug happens - 

You hit first.php, it compiles B.php after class 'A'
is already compiled. Inhertiance there is based on
early binding - so it removes the FETCH_CLASS and all
that in the op_array.

But when you hit second.php after that, class 'A' is not
already in EG(class_table) because it will be added
only after the require_once in B.php will be executed.

I guess I need to do the opposite of zend_do_early_binding
in scenario #1. 

Thanks for giving such a clear bug report :)

This should be fixed in CVS now.  See http://news.php.net/php.pecl.cvs/4288

Please let me know if this fixes things for you.

I have tested the CVS version of APC with PHP 5.0.5. It fixes the test case in this bug, as well as bug #5314. I'll leave it running on my development server to see if any problems occur.

Ok Thanks.  Hopefully we can get a few more people to try it as well.  Of course, now that the problem is understood, it does suggest that you may want to fix the code that triggers this problem.  If you are running APC, you probably care about performance and running code that switches from early binding to dynamic inheritance is a bad idea.  Runtime inheritance adds at least 3 more hash lookups, if not more.

problem is gone using latest CVS code.
PHP 5.0.3 (SUSE Linux 9.3 AMD64) Apache apache2-prefork-2.0.53-9.7 gcc versi?n 3.3.5 20050117.

The bug is open for 3.0.10 / PHP 5.1.2 (or whatever is last PHP/APC I picked yesterday)

I'm still having this problem using cvs from April-5-2006,php 5.1.3-dev, and apache 1.3.27

Debian Sarge and LAMP packages from dotdeb
PHP Version 5.1.4
APC Version 3.0.10

Just to say that I have many problems when APC is enabled :(

Horde/IMP, Gallery2, custom apps don't work in some random way.

Hi there,

we have the same problem here with the actual stable eGroupware-version

our versions are:

Apache 2.0.58 (prefork)
PHP 5.1.4
APC 3.0.10
eGW 1.2.104

it's the same, it claims an undefined method, which is defined. Disabling APC solves this issue. The exact error message occurs if you change the tab when you make a new InfoLog entry. Message is: "Fatal error: Call to undefined method bolink::solink() in
[..]/htdocs/egroupware/phpgwapi/inc/class.bolink.inc.php on line 85" 

Okay, hope this helps. Thanks in advance :-)

This exact same bug exists in PHP 5.2.13 and APC 3.0.19 on 
RHEL5.