ID: 22237
User updated by: peter at globalvision dot com dot au
Reported By: peter at globalvision dot com dot au
Status: Verified
Bug Type: Zend Engine 2 problem
Operating System: All
PHP Version: 5CVS-2003-02-15 (dev)
New Comment:
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?
Previous Comments:
------------------------------------------------------------------------
[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] [EMAIL PROTECTED]
No crash with PHP 4.3.1-dev, does crash with PHP 5-dev.
------------------------------------------------------------------------
[2003-02-15 19:06:29] peter at globalvision dot com dot au
<?php
class myClass
{
var $foo = "hi";
var $bar = "foo";
function test()
{
echo $this->$bar; //line 1
//echo $this->foo; //line 2
}
}
?>
commenting out line 1 (and optionally including line 2) cause it to run
normally. The crash occurs as soon as you
include $this->$<something>.
----------------
>From a dos command line on Windows XP Pro SP1 (build 2600):
>php c:\temp\t.php
I get
PHP Script Interpreter has encountered a problem and
needs to close (pop up).
I'm using the windows build from the snaps page. I've had this error
over the past few days of snaps too.
>php -m
[PHP Modules]
bcmath
calendar
com
ctype
ftp
mysql
odbc
pcre
rpc
session
standard
tokenizer
wddx
xml
zlib
[Zend Modules]
The crash details are:
AppName: php.exe
AppVer: 5.0.0.0
ModName: php4ts.dll
ModVer: 5.0.0.0
Offset: 000b3bdc
Exception Information:
Code: 0xc0000005 Flags: 0x00000000
Record: 0x000000000000000 Address: 0x000000000100b3bdc
------------------------------------------------------------------------
--
Edit this bug report at http://bugs.php.net/?id=22237&edit=1
