|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #56545 APC breaks class inheritance in certain situations
Submitted: 2005-09-14 10:45 UTC Modified: 2006-02-27 07:34 UTC
From: nick dot locking at gmail dot com Assigned:
Status: Closed Package: APC (PECL)
PHP Version: 5.0.3 OS: Trustix
Private report: No CVE-ID: None
 [2005-09-14 10:45 UTC] nick dot locking at gmail dot com
When APC is turned on, QuickForm breaks and produces an error:

Fatal error: Call to undefined method HTML_QuickForm_hidden::HTML_QuickForm_element() in /usr/lib/php/HTML/QuickForm/input.php on line 50

Obviously this method is not undefined. When APC is turned off, it works perfectly. Strangely, manually including "HTML/QuickForm/element.php" before the code fixes the problem.

PHP Version: 5.0.4
QuickForm Version: 3.2.5
APC Version: 3.0.8

Operating System: Trustix 2.2

Reproduce code:
php_flag apc.enabled on


// Include QuickForm

// This line, uncommented, fixes the problem
// require_once "HTML/QuickForm/element.php";

// Create a form
$form = new HTML_QuickForm('frmUser', 'post');
// This line produces the error
$form->addElement('hidden', 'id');

Expected result:
I expect a form to be created with a hidden element.

Actual result:
Fatal error: Call to undefined method HTML_QuickForm_hidden::HTML_QuickForm_element() in /usr/lib/php/HTML/QuickForm/input.php on line 50


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2005-10-13 21:06 UTC] jascha at bluestatedigital dot com
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:

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

require_once "A.php";
class B extends A {

require_once "A.php";
class Z extends A {

require_once "Z.php";
require_once "B.php";

require_once "B.php";
$obj = new B();

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()"

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.

PHP: 5.0.2
Apache: 1.3.29
APC: 3.0.8
OS: Linux 2.6.9
 [2005-10-14 05:44 UTC] nick dot locking at gmail dot com
 [2005-10-18 05:54 UTC] gopalv82 at yahoo dot com
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 :)
 [2005-10-26 23:44 UTC]
This should be fixed in CVS now.  See

Please let me know if this fixes things for you.
 [2005-10-27 10:55 UTC] kloor at bgsu dot edu
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.
 [2005-10-27 11:11 UTC]
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.
 [2005-10-27 18:10 UTC] soporte at onfocus dot cl
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.
 [2006-03-21 11:43 UTC] ilia at manual dot ru
The bug is open for 3.0.10 / PHP 5.1.2 (or whatever is last PHP/APC I picked yesterday)
 [2006-04-05 15:10 UTC] zedic1 at yahoo dot com
I'm still having this problem using cvs from April-5-2006,php 5.1.3-dev, and apache 1.3.27
 [2006-05-08 18:31 UTC] redfox at redfoxcenter dot org
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.
 [2006-07-26 06:29 UTC] robin at 2-com dot de
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/ on line 85" 

Okay, hope this helps. Thanks in advance :-)
 [2010-12-14 12:49 UTC] gil at squidoo dot com
This exact same bug exists in PHP 5.2.13 and APC 3.0.19 on 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Sun May 26 12:01:29 2024 UTC