php.net |  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
Description:
------------
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:
---------------
HTAccess:
php_flag apc.enabled on

Whatever.php:

// Include QuickForm
require_once("HTML/QuickForm.php");

// 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

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

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:

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
 [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] rasmus@php.net
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.
 [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] rasmus@php.net
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/class.bolink.inc.php 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 
RHEL5.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Fri Mar 29 15:01:28 2024 UTC