ID: 33299
Comment by: jon at dsvr dot co dot uk
Reported By: clicknmix at gmail dot com
Status: Feedback
Bug Type: XSLT related
Operating System: Linux
PHP Version: 5.0.4
New Comment:
In fact, something quite strange appears to be happening.
instanceof_function is called from xsltprocessor.c:281. At this point
dom_node_class_entry is not null.
At a breakpoint in instanceof_function (zend_operators.c:1581),
instance_ce and ce are equal (we can see therefore that this test
should go on to succeed).
instanceof_function calls instanceof_function_ex. At a breakpoint in
this function, (zend_operators.c:1560), instance_ce has apparently been
passed correctly, but ce is now null, and the function goes on to return
0.
Looks like there could be some stack breakage going on here. Any
suggestions welcome.
Previous Comments:
------------------------------------------------------------------------
[2005-06-19 16:38:56] jon at dsvr dot co dot uk
I've done a bit more digging and poking with gdb.
It looks to be the case that when instanceof_function is called from
xsltprocessor.c:281, zend_class_entry *ce is NULL, and so the
instanceof test fails. Something seems wrong with
dom_node_class_entry.
------------------------------------------------------------------------
[2005-06-17 17:41:46] jon at dsvr dot co dot uk
The following code:
function myxml ($Value="default")
{
$dom = new domdocument();
$dom->loadXML("<root>this is from an external
DomDocument - $Value</root>");
return $dom;
}
print debug_zval_dump(myxml(''));
yields:
object(DOMDocument)#1 (0) refcount(1){
}
I haven't yet managed to get gdb attached happily to this build of PHP;
having trouble with loadable modules.
It's worth noting that the stock PHP 5.0.4 that comes with Fedora Core
4 demonstrates this problem, if anyone's looking for basic install to
test with.
------------------------------------------------------------------------
[2005-06-15 17:37:56] [EMAIL PROTECTED]
Taking XSL out of the equation, what is returned directly from the
calling the myxml function? I cant reproduce this either (tested on
linux and windows). If the myxml function works, try building in debug
mode and set a breakpoint in the xsl extension to find out what type of
object it thinks is being returned there.
------------------------------------------------------------------------
[2005-06-15 17:28:58] jon at dsvr dot co dot uk
I've been working with Ritch on this one. He says the same code works
with 5.0.3 but not with 5.0.4, so I've compared the two source files
for the location of the bug, and nothing other than the "{{{ proto"
lines in ext/xsl/xsltprocessor.c seems to be different.
The warnings come about when you return a DOMDocument (rather than a
string) from the php:function, and this causes retval->type ==
IS_OBJECT to be true.
Now, I'm not that familiar with this code, but it seems to me that
maybe the test on line 281 should be true if the object you're
returning is a DOMDocument, and that this equality is true under 5.0.3
but false under 5.0.4, causing the equality on line 295 to be true and
thus generating the first warning as reported above.
------------------------------------------------------------------------
[2005-06-14 19:13:58] Ritch at Bugsoftware dot co dot uk
Ok,
I've spent all day recompiling php and eventualy got the script running
(clicknmix's fom above). The only way to do it was to go back a php
version... to 5.0.3.... Everything else stayed the same including the
configure command used to compile PHP and the libxml/libxslt versions;
libxml 2.6.19
libxslt 1.1.11
I'm running FC3 and clicknmix is running centos so it is a problem
across linux platforms.
I've sent my phpinfo results for both builds to clicknmix so he can
post them @;
http://home.protocol80.co.uk/php5/phpinfo.5.0.3.php.html
http://home.protocol80.co.uk/php5/phpinfo.5.0.4.php.html
This implies that there is something that has changed between these two
versions that upsets this feature. At least in certain circumstances.
Cheers,
Ritch.
------------------------------------------------------------------------
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/33299
--
Edit this bug report at http://bugs.php.net/?id=33299&edit=1
