[2004-08-24 03:34 UTC] xuefer at 21cn dot com
Description:
------------
1. load test.php in browser (via apache+php+apc)
2. update "in p2" to "in p2**" (*** is random text)
3. reload test.php, nothing changed (even with ctrl+f5 in ie, reload with nocache)
4. uncomment class p3::set
5. do 1-3, message is updated
Reproduce code:
---------------
test.php:
require("./p12.php");
require("./p3.php");
$p3 = new p3();
$p3->set();
p12.php
class p1
{
function set()
{
echo "in p1<br>";
}
}
class p2 extends p3
{
function set()
{
echo "in p2<br>";
return parent::set();
}
}
p3.php
class p3 extends p2
{
/* if this exists, no error
function set()
{
echo "in p3<br>";
return parent::set();
}
*/
}
Comments
[2004-09-07 04:16 UTC] rasmus
This example doesn't work without APC either. Did you really mean to have p3 extend p2 and p2 extend p3 here?
[2004-09-07 08:38 UTC] xuefer at 21cn dot com
sorry, it's my typo while reporting this bug
class p3 extends p2
class p2 extends p1 (not p3)
p1 and p2 in same file(p12.php), while p3 is alone(p3.php)
update code in class p2::set() (file p12.php)
no errors/warnnings, but result it wrong
may times i have to re-update the file or clear apc cache
[2004-09-07 16:42 UTC] rasmus
I still can't reproduce this with the current CVS version of APC.
With set() in p3 commented I see:
in p2
in p1
And when I uncomment it I see:
in p3
in p2
in p1
consistently.
Could you try building the current CVS code and make sure you are still seeing this problem?
[2004-09-07 17:19 UTC] xuefer at 21cn dot com
updated summary.
verified with lastest apc
i think my mistake make u ignored my "reproduce steps"
step 1-3 is required to reproduce the bug
without p3::set, compare result of 3 to 1, result is(but shouldn't be) same until i `touch p3.php`, this is the bug.
u may try steps2-3 more times
step 4-5 is an exception of the bug(i.e.: not a bug)
i've once trace apc optimizer, and noticed some function opcode is optimized twice.
(the following notes is just my guessing, hope it help to explain this bug)
situtation 1: without p3::set
it seems apc copied all methods from p2 (p2::set) to class p3, once p2 is updated, p3 is not, this is the bug
situtation 1: with p3::set
p3 has it's own p3::set thus won't copy p2::set to p3::set, thus not triggering this bug
[2004-09-07 17:43 UTC] rasmus
I did follow your steps. But I don't have the optimizer enabled. Can you verify that this problem disappears when you disable the optimizer?
[2004-09-12 06:39 UTC] xuefer at 21cn dot com
my config is:
extension = apc.so
apc.enabled = 1
apc.optimization = 1
apc.ttl = 3600
verified with:
apc.enabled = 1
apc.optimization = 0
ok with:
apc.enabled = 0
apc.optimization = 0
[2004-09-19 07:30 UTC] rasmus
Ok, I did reproduce this now.
My guess is that there is a check on a function HashTable somewhere that terminates a loop that otherwise would have climbed the dependency tree if class p3 hadn't been empty. Didn't see it though skimming through apc_compile.c. Having a property in the p3 class doesn't help. Only a method clears this one up.