|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #33299 php:function no longer handles returned dom objects
Submitted: 2005-06-10 16:13 UTC Modified: 2005-06-22 22:02 UTC
Avg. Score:4.0 ± 1.0
Reproduced:2 of 2 (100.0%)
Same Version:2 (100.0%)
Same OS:1 (50.0%)
From: clicknmix at gmail dot com Assigned:
Status: Closed Package: XSLT related
PHP Version: 5.0.4 OS: Linux
Private report: No CVE-ID:
 [2005-06-10 16:13 UTC] clicknmix at gmail dot com
When using a function with XSLTProcessor->registerPHPFunctions() to return a dom object, it no longer handles it as XML, and produces an error.

Reproduce code:
Function is:
function myxml ($Value="default")
        $dom = new domdocument();
        $dom->loadXML("<root>this is from an external DomDocument - $Value</root>");
        return $dom;

and XSLT call is:
<xsl:value-of select="php:function('myxml','Hello World')/root" />

Full scripts at:

Expected result:
In previous versions you could access the tree of the returned XML and print the output. (As if you were including a flat XML file)

Actual result:
Warning: XSLTProcessor::transformToXml() [function.transformToXml]: A PHP Object can not be converted to a XPath-string in /controlpanel/hosts/design/htdocs/test/collection.php on line 22

Warning: Invalid type in /controlpanel/hosts/design/htdocs/test/collection.php on line 22

Warning: runtime error: file /controlpanel/hosts/design/htdocs/test/collection.xsl element value-of in /controlpanel/hosts/design/htdocs/test/collection.php on line 22

Warning: xsltValueOf: text copy failed in /controlpanel/hosts/design/htdocs/test/collection.php on line 22


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2005-06-11 10:25 UTC]
Works for me just fine. 

Which libxml2/libxslt versions are you using?

 [2005-06-13 10:30 UTC] Ritch at Bugsoftware dot co dot uk
I have exactley the problem described. Linux/Apache2/PHP5.0.4 with libxml 2.6.16 & libxslt 1.1.11.
 [2005-06-13 19:17 UTC] clicknmix at gmail dot com
The above comment didnt make it very clear, but Ritch is running on the same platform as me:
Linux running Apache2 with PHP 5.0.4
libxml2: 2.6.16
libxslt: 1.1.11.

The scripts do work on a previous platform: 
Linux running Apache1 with PHP 5.0.1
libxml2: 2.6.8
libxslt: 1.0.19

Additional it's might be worth mentioning using the php:function to simply return a value works fine. It's only when returning an object it errors.
 [2005-06-14 08:59 UTC]
You changed 3 components at once, bad for pointing the error 
at something...

As it works for me (with your combination, but on OSX, not 
Linux), would it be possible for you to use the old libxml/
libxslt configuration and test that with php 5.0.4. Or use 
thenew libxml/libxslt configuration with php 5.0.1? I have 
no idea, what's going wrong here, but as I use that 
functionality from a day-to-day basis, I can tell you, it 
works for me (and I never heard of that problem before from 
others using my software)
 [2005-06-14 19:13 UTC] Ritch at Bugsoftware dot co dot uk

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 @;

This implies that there is something that has changed between these two versions that upsets this feature. At least in certain circumstances.

 [2005-06-15 17:28 UTC] 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-15 17:37 UTC]
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-17 17:41 UTC] 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(''));


    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-19 16:38 UTC] 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-19 16:54 UTC] jon at dsvr dot co dot uk
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.
 [2005-06-19 23:19 UTC] jon at dsvr dot co dot uk
On a hunch, I patched the .spec file from the Redhat-provided RPM to build XSL and DOM support statically, instead of as a shared library, and this test fragment of code works.  

I hope the debugging I've done gives someone with a bit more knowledge of this code enough information to get this cracked.
 [2005-06-21 14:39 UTC]
Rob asked me to look at this...

it looks like the variables are not declared properly in ext/dom/xml_common.h.

#define PHP_DOM_EXPORT(__type) PHPAPI __type
PHP_DOM_EXPORT(zend_class_entry *) dom_node_class_entry;

results in
zend_class_entry *dom_class_entry;

rather than the desired

extern zend_class_entry *dom_class_entry;

when included by xsltprocessor.c.  The former just defines a new global variable in the BSS which is not going to work at all.  I'm testing a patch.

 [2005-06-22 22:02 UTC]
This bug has been fixed in CVS.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
Thank you for the report, and for helping us make PHP better.

PHP Copyright © 2001-2016 The PHP Group
All rights reserved.
Last updated: Thu Feb 11 04:01:45 2016 UTC