#2202 inherit method is not updated when parent class file updated
Submitted: 2004-08-24 03:34 UTC
From: xuefer at 21cn dot com Assigned:
Status: Open Package:
PHP Version: 4.3.3 OS: linux
Roadmaps: (Not assigned)    
Subscription  
Comments Add Comment Add patch


Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know! Just going to say 'Me too!'? Don't clutter the database with that please !
Your email address:
MUST BE VALID
Solve the problem : 31 - 27 = ?

 
 [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.