Cannot dublicate the crash using latest PHP snapshot. If you still experience the problem could you please provide a backtrace.

Sorry, but your problem does not imply a bug in PHP itself.  For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. 

Thank you for your interest in PHP.

On aftger analysis of the bug I must conclude it is a bug in libxml2 (possibly old version of it) and not a bug in PHP.

It almost certainly is a PHP bug, according to Daniel Veillard, author of libxml2.

It is an incompatibility with libxml2 version  libxml2-2.4.30 or better, maybe earlier too. Ilia only tested with libxml2-2.4.25. 

Daniel has analyzed the backtrace, which follows, with comments:

> Here is some more gdb output that might help.
>
> (gdb) info stack
> #0  xmlStrEqual (str1=0x3 <Address 0x3 out of bounds>,
>      str2=0x401632e0 "-//W3C//DTD XHTML 1.0 Strict//EN") at parser.c:1293
> #1  0x4010d834 in xmlIsXHTML (systemID=0x4015e9c0 "text",
>      publicID=0x3 <Address 0x3 out of bounds>) at tree.c:6728
> #2  0x4010d586 in xmlNodeDumpOutput (buf=0x81eadf8, doc=0x81f78a8,
>      cur=0x81f78a8, level=0, format=0, encoding=0x0) at tree.c:6599
> #3  0x4010cc72 in xmlNodeDump (buf=0x81eeaa0, doc=0x81f78a8, cur=0x81f78a8,
>      level=0, format=0) at tree.c:6164
> #4  0x080706ab in zif_domxml_dump_node (ht=1, return_value=0x81f584c,
>      this_ptr=0x81f3104, return_value_used=1)
>      at
> /home/greg/new/php4-STABLE-200301070230/ext/domxml/php_domxml.c:3697 #5 
> 0x0815576f in execute (op_array=0x81f27ac)
>      at /home/greg/new/php4-STABLE-200301070230/Zend/zend_execute.c:1596
> #6  0x08145756 in zend_execute_scripts (type=8, retval=0x0, file_count=3)
>      at /home/greg/new/php4-STABLE-200301070230/Zend/zend.c:864
> #7  0x08115afd in php_execute_script (primary_file=0xbffff880)
>      at /home/greg/new/php4-STABLE-200301070230/main/main.c:1573
> #8  0x0815b134 in main (argc=3, argv=0xbffff924)
>      at /home/greg/new/php4-STABLE-200301070230/sapi/cli/php_cli.c:746
> #9  0x401a0507 in __libc_start_main (main=0x815a83c <main>, argc=3,
>      ubp_av=0xbffff924, init=0x8061588 <_init>, fini=0x815b7d0 <_fini>,
>      rtld_fini=0x4000dc14 <_dl_fini>, stack_end=0xbffff91c)
>      at ../sysdeps/generic/libc-start.c:129
> (gdb)
>
>

Daniel said:

  The DTD node for the document was not properly initialized. The call
made by xmlNodeDumpOutput is :
  is_xhtml = xmlIsXHTML(dtd->SystemID, dtd->ExternalID);

  the DTD is looked for based on the document passed to xmlNodeDumpOutput().
And the pointer stored in the DTD for the system ID is invalid. Go back
to the PHP maintainer and ask him to fix the code making that xmlDtdPtr node.
That DTD node was not generated by libxml2 as part of the parsed document
since there is NO DOCTYPE entries in the parsed examples. I have no idea
what the PHP code looks like but getting an invalid DTD node for a document
which did not contained any initially doesn't give me a good opinion of
that code quality honnestly. I have no idea of what's going on there, but
this doesn't sound good, really.

Daniel
----
On Wed, Jan 08, 2003 at 10:42:54AM -0800, gk wrote:
> I don't understand why, if this is a PHP issue, the bug is not reproducible 
> with the same version of PHP and different versions of libxml2. I will go 
> back to the same version of libxml2 that Ilia tested with and see if I can 
> reproduce it on my machine, with same PHP and sample code.

  I'm very sorry, but I do not have the time to fix the PHP code.
Your documents from your example did NOT have any DOCTYPE. The doc
xmlDocPtr passed to the serialization routine had an xmlDtdNode.
That xmlDtdNode will NOT be generated by libxml2 (any version) when
passing the sample examples your provided within your PHP. Moreover
that xmlDtdNode is buggy because one of the pointers is 0x3 which
leads to the crash. I don't have the time to find in the PHP code
  - what code generated that xmlDtdNode.
  - why it has buggy pointers
  - why it's passed to the serialization routine while
    obviously the document asked for serialization should NOT
    have an xmlDtdNode

 Again I can't debug this. This sounds completely broken to stay polite.
The fact that the bug doesn't show up with other versions is simply that
earlier version don't have the XHTML1 detection code looking for the 
DTD System ID in order to adjust the serializations accordingly.

Daniel
-----
On Wed, Jan 08, 2003 at 11:48:07AM -0800, gk wrote:
> I have never debugged PHP sources either but looking in 
> <php_source>/ext/domxml.c I found this:
> The "FIX ME" comment seems to suggest a problem :--)
> 
>                  /* FIXME: nodes of type XML_DTD_NODE used to be 
> domxmldtd_class_entry.
>                   * but the DOM Standard doesn't have a DomDtd class. The 
> DocumentType
>                   * class seems to be want we need and the libxml dtd 
> functions are
>                   * very much like the methods of DocumentType. I wonder 
> what exactly
>                   * is the difference between XML_DTD_NODE and 
> XML_DOCUMENT_TYPE_NODE.

   Libxml2 generates only XML_DTD_NODE whcih are xmlDtdPtr. 
 XML_DOCUMENT_TYPE_NODE enum is here from DOM early cut'n paste but
never used. A DOCTYPE declaration is associated an xmlDtdPtr kept as
child of the xmlDocPtr (and also recoded in it with a direct pointer).
  But this can't explain why such a node was "magically" created,
why it has bad pointers in it, why it has an XHTML1 strict public ID.

 to me this does not make sense, at all !

Daniel
----

Re-opening this bug. I'd be happy to work on it if some dom xml developers could give me a start.

modified bug title to be more specific

The error is here:

$nodeContent =$root->dump_node($root); 

$root has to be a DOM_DOCUMENT and in your case it's DOM_ELEMENT.

I'll fix the code, so it will throw an error, if it's not a DOM_DOCUMENT

chregu

Thanks for identifying the problem, chregu.
But your comment didn't specify WHICH $root in the sample code was causing the problem.
Here's an example:
     <?php
     $xml=<<<eot
     <node attr="test"><test>hi</test>
     </node>
     eot;
     $doc = domxml_open_mem($xml);
     $root=$doc->document_element();
     //This won't work:
     //$nodeDump =$doc->dump_node($doc);  
     //This crashes:
     //$nodeDump =$root->dump_node($root);  
     //This works:
     $nodeDump =$doc->dump_node($root); 
     echo htmlentities($nodeDump);
     ?>

I have re-opened the bug for integrity of the bug database:
a bug is not 'Bogus' if PHP crashes due to scripting errors.
For the sake of others who get bitten, this should stay open until fixed, then set it to 'Closed'.

You're not in position to decide what is bogus and what is not. This is bogus.

This is a valid bug, by initial conclusion as to the nature of this bug was wrong.

This bug has been fixed in CVS.

In case this was a PHP problem, 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/.
 
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.

In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
 
Thank you for the report, and for helping us make PHP better.

And fixed in CVS PHP_4_3 as well.