php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #57203 Inheritance problems with 3.0.11
Submitted: 2006-08-29 16:29 UTC Modified: 2006-09-02 09:23 UTC
From: jason at xc dot net Assigned:
Status: Closed Package: APC (PECL)
PHP Version: 4.3.10 OS: Debian 3.1 (Sarge)
Private report: No CVE-ID: None
View Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
If you reported this bug, you can edit this bug over here.
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: jason at xc dot net
New email:
PHP Version: OS:

 

 [2006-08-29 16:29 UTC] jason at xc dot net 
Description:
------------
After upgrading to 3.0.11, I noticed that changes to certain class files were not being reflected on subsequent page loads (Apache had to be restarted).

apc.stat seemed the likely culprit, but I verified that APC IS noticing changes, and some changes go into effect immediately while others only go into effect after Apache has been restarted.  In addition to editing the file in
place, I've tried overwriting the file with a new file and the results are the same.

The problem does not occur with 3.0.8 or 3.0.10.

php.ini settings:
apc.shm_segments=3
apc.stat=1

To test, use the three files below.  Access main.php three times:

1st time: Use the files below
2nd time: Change A_Base::getString() to:
        function getString()
        {
                return 'test';
        }
3rd time: Edit class_base.php and add a syntax error

APC notices the syntax error, but does not pick up on the change to A_Base::getString().

Using require_once with full paths gives the same results.

Reproduce code:
---------------
class_base.php
--------------
<?php

class A_Base
{
        var $string;

        function A()
        {
                $this->setString('one');
        }

        function setString($value)
        {
                $this->string = $value;
                return True;
        }

        function getString()
        {
                return $this->string;
        }
}

?>

class.php
---------
<?php

class A extends A_Base
{
        function doSomething()
        {
                $a = 1 + 1;
                return $a;
        }
}

?>

main.php
--------
<?php

require_once "class_base.php";
require_once "class.php";

$a = new A;
echo $a->getString();

?>

Expected result:
----------------
1st time: 'one'
2nd time: 'test'
3rd time: Syntax Error

Actual result:
--------------
1st time: 'one'
2nd time: 'one'
3rd time: Syntax Error

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2006-08-29 20:12 UTC] gopalv82 at yahoo dot com 
APC takes ~2 seconds before it will a cache a file to deal with people scp'ing files into production machines.

Maybe you're not waiting 2 seconds before your attempt #2 after editing the file ?

Can you set apc.file_update_protection to 0 and then try the same ?
 [2006-08-30 11:28 UTC] jason at xc dot net 
I get the same results with apc.file_update_protection=0.

Note that test #2 is repeatable.  After I make the changes to A_Base::getString() to return 'test', if I reload main.php 10 seconds after making the change, 10 minutes after making the change, and an hour after making the change, it will still return 'one'.  Only restarting Apache makes it return 'test'.
 [2006-08-30 16:15 UTC] jason at xc dot net 
I did some more testing and found that the problem was not introduced with 3.0.11 as I had thought.  I tested 3.0.7-3.0.11 with apc.file_update_protection=0 and apc.file_update_protection=2.  The testing procedure was:

- Install APC using 'make install'
- Change apc.file_update_protection setting
- Reset getString() to default
- Restart Apache
- Access main.php #1
- Change getString() to return 'test'
- Wait 20 seconds. Access main.php #2

Here were the results I got.  "Yes" means the problem existed and access #2 returned 'one'.  "No" means access #2 returned 'test' as expected.

Version  up=0  up=2
3.0.7    Yes   Yes
3.0.8    Yes   No
3.0.9    Yes   Yes
3.0.10   Yes   Yes
3.0.11   Yes   Yes

So it seems the only version that works as expected is 3.0.8 with apc.file_update_protection=2.  I ran through the entire list twice and triple-checked the 3.0.8 results, and the results appear to be always reproducible.  I used wget to test with so that browser cache was not an issue.

php.ini settings
----------------
apc.shm_segments=3
apc.stat=1
apc.file_update_protection=X (X = 0 or 2)
 [2006-08-30 16:18 UTC] rasmus@php.net 
Yes, I made a half-assed attempt at fixing this in 3.0.8 but all you have to do to break that fix is to go one level deeper in your inhertitance tree, so I reverted it.  3.0.11 should be detecting this case and not actually caching in this case.  I'll let Gopal figure out why his check is not working in this example.
 [2006-08-31 05:42 UTC] gopalv82 at yahoo dot com 
Something overlooked for all these months... But here's a 
quick patch to fix it up for you.

http://t3.dotgnu.info/code/apc-php4-inhclean.patch

It doesn't have nearly enough testing, I'll commit it after I'm done testing.
 [2006-09-02 09:23 UTC] gopalv82 at yahoo dot com 
Fixed in CVS on Sept 2nd 2006.

apc_compile.c,3.55 apc_main.c,3.81

Tested with php 4.3.11,apache2.
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved. 		Last updated: Wed Nov 05 15:00:01 2025 UTC