#22237 [Ver->Csd]: PHP crashes when class references property using variable variable

From: Date: Sun, 20 Apr 2003 01:06:17 +0000
Subject: #22237 [Ver->Csd]: PHP crashes when class references property using variable variable
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-37915@lists.php.net to get a copy of this message
ID: 22237 User updated by: peter at globalvision dot com dot au Reported By: peter at globalvision dot com dot au -Status: Verified +Status: Closed Bug Type: Zend Engine 2 problem Operating System: All PHP Version: 5CVS-2003-02-15 (dev) New Comment: Yup.. confirmed that the latest CVS no longer crashes... Previous Comments: ------------------------------------------------------------------------ [2003-04-18 18:14:16] thekid at thekid dot de No crash here. In line 1, I assume you're expecting "hi" as an output. This will of course not work as $bar is not set. Modify line 1 to read: echo $this->{$this->bar} and you will have your expected output. Note that with error_reporting(E_ALL) you would notice such kinds of mistakes. Also, var_dump() helps a lot, you can actually see type information instead of just nothing appearing:) thekid@friebes:~ > cat | php5 <?php class myClass { var $foo = "hi"; var $bar = "foo"; function test() { var_dump($this->{$this->bar}); var_dump($this->foo); } } $c= new myClass(); $c->test(); ?> string(2) "hi" string(2) "hi" ------------------------------------------------------------------------ [2003-03-23 06:46:27] peter at globalvision dot com dot au Well... I have not had the time to solve it, but I now know pretty well why it is caused. **can someone please have a crack at fixing this**? In zend_language_parser.y, the rule for object_property is either an object_dim_list (which can be a T_STRING) or it is a "variable_without_ibjects". object_dim_list works for $this->foo, but $this->$foo is matched by variable_without_objects. HOWEVER, variable_without_objects is the match for vanilla variables, so it consumes one '$' before it dereferences. in other words, $this->$foo sends the $foo part off to the standard variable compiler area which does not recognise that $foo is a reference. I experimented by placing a couple of rules in the lex scanner as follows: <ST_LOOKING_FOR_PROPERTY>"$" { fprintf(stderr,"xxx"); yy_push_state(ST_TEST) return '$'; } and <ST_TEST>";" { fprintf(stderr,"yyy"); yy_pop_state(TSRMLS_C); return ';'; } <ST_TEST>{LABEL} { fprintf(stderr,"zzz"); zendlval->value.str.val = (char *)estrndup(yytext,yyleng); zendlval->value.str.len = yyleng; zendlval->type = IS_STRING; return T_VARIABLE; } and suddenly, it all seems to parse, however I'm clearly missing something - it still does not display the forrect output for echo $this->$foo; What am I doing wrong? ------------------------------------------------------------------------ [2003-02-22 17:08:49] peter at globalvision dot com dot au I'm assuming all OSes b/c my original report was MS Windows but a subsequent dup report was for Linux. I've narrowed it down a bit by running with debug mode on the ZE2 I'm 99% sure it is due to the way zend treats "$this" as special. I don't think it's putting all the required data on the stack. Specifically, when it processes the base_variable_without_objects bison rule after reading T_OBJECT_OPERATOR (ie -> ) it sets yyval.u.EA.type (see case 363 in zend_language_parser.c) but yyval.u is zero at that time when the LH operand is $this. Not sure why yet... EG the following modification causes no crash: <?php class myClass { var $foo = "hi"; var $bar = "foo"; function test() { $t = &$this; echo $t->$bar; //echo $this->foo; } } ?> ------------------------------------------------------------------------ [2003-02-19 06:26:45] root at kitten dot net This is pretty serious... it prevents pear from working. Can someone please take a look at it? Thanks ------------------------------------------------------------------------ [2003-02-15 19:15:01] sniper@php.net No crash with PHP 4.3.1-dev, does crash with PHP 5-dev. ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/22237 -- Edit this bug report at http://bugs.php.net/?id=22237&edit=1

« previous php.bugs (#37915) next »