Works for me just fine. 

Which libxml2/libxslt versions are you using?

chregu

I have exactley the problem described. Linux/Apache2/PHP5.0.4 with libxml 2.6.16 & libxslt 1.1.11.

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.

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)

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.

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.

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.

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.

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.

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.

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.

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.

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
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.