php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #16888 domXML causes Segfault, when you create to many Nodes
Submitted: 2002-04-28 15:37 UTC Modified: 2002-05-18 08:37 UTC
Votes:4
Avg. Score:4.0 ± 0.7
Reproduced:4 of 4 (100.0%)
Same Version:2 (50.0%)
Same OS:4 (100.0%)
From: cb at designassembly dot de Assigned:
Status: Closed Package: DOM XML related
PHP Version: 4.2.0 OS: Windows XP
Private report: No CVE-ID: None
View Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
If you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: cb at designassembly dot de
New email:
PHP Version: OS:

 

 [2002-04-28 15:37 UTC] cb at designassembly dot de 
System: Apache/1.3.24 PHP running as SAPI-module (Binary from php.net)

simple script, which causes segfault 
<?
	$doc = new_xmldoc( "1.0" );
	$root = $doc->add_root("document");
	for($i = 1; $i < 1000; $i++){
		$element = $doc->create_element("element");
		$element->set_content("content ".$i);
		$root->append_child($element);
	}
	$xml = $doc->dumpmem();
	echo htmlspecialchars($xml);
?>

Description:
the content is shown shortly in the browser, but apache causes a segfault in module php4ts.dll at offset  00096057  and finally a 404 page is displayed.

This code causes no problems with PHP 4.1.2. When you try to create only 100 elements in this loop, it runs without any seg-faults. For complex xmldocuments this bug makes it impossible to use domxml with php 4.2.

Modules:
php_domxml, php_xslt, php_gd und mysql

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2002-04-28 17:37 UTC] chregu@php.net 
Seems to be an OS-specific problem. It is not reproducable under linux. Even with adding 100'000 nodes :) Can someone with access to windows please check that?

chregu
 [2002-05-09 18:00 UTC] lrargerich at yahoo dot com 
Checked under Win98 and crashes if too many nodes are created. This is confirmed.
 [2002-05-14 17:03 UTC] cb at designassembly dot de 
Same error still occurs with PHP 4.2.1 Version
 [2002-05-15 08:57 UTC] chregu@php.net 
I would blame libxml2 :) Do you have the latest libxml2 dll? (available anywhere from http://www.xmlsoft.org). Can you check with that?

chregu
 [2002-05-15 12:23 UTC] flying at dom dot natm dot ru 
Confirmed under windows 2000 server running as CGI with following combinations:

PHP 4.1.1 + libxml2 2.4.21 - works well
PHP 4.2.0 + libxml2 2.4.21 - crash
PHP 4.2.1 + libxml2 2.4.9  - crash
 
 Unfortunatelly latest PHP version - 4.2.1 have been build with libxml2 compiled as static library, so i can't test it with latest libxml2.

 So it is not a problem of libxml2, but something into DOM XML module itself.

 PHP crashes into final stage, when script execution itself is completed (and even function, registered as shutdown function have been executed).
 [2002-05-15 12:28 UTC] flying at dom dot natm dot ru 
One more interesting remark - DOM XML module crashes if more then 128 elements are created. Less then 128 elements are created without problems. Maybe it will help you somehow?
 [2002-05-15 16:15 UTC] cb at designassembly dot de 
I  tried the newest xml-lib build from http://www.fh-frankfurt.de/~igor/projects/libxml/ (Version 2.4.21) and apache still crashes. 

I also can confirm the barrier with 128 elements.
 [2002-05-15 17:50 UTC] jtate@php.net 
FWIW, the sample script works ok using the latest HEAD under IIS in debug mode...well, works is an approximation.  It doesn't crash until the Zend tries to clean up memory, and then crashes in _zval_ptr_dtor.  Not feeling like a Zend guru today, I don't feel like attacking it.  I'll try Apache though to see if I can narrow this bug down.
 [2002-05-16 09:07 UTC] chregu@php.net 
Edin created a new php_domxml.dll with libxml2-2.4.21 compile d in. It's available at http://ftp.proventum.net/pub/php/win32/php_domxml.zip

Can you check that. But i fear, it doesn't help solve the problem :( Please be aware, that append_child changed the meaning in 4.2.1. The former append_child is now append_sibling, and append_child behaves like the w3c likes it. But appending a sibling to the root node, doesn't make really sense, but it souldn't crash PHP, either :)

I would be very glad, if someone with windows programming experience could hunt down the problem.

chregu
 [2002-05-16 11:06 UTC] jtate@php.net 
I'm looking into it.  No guarantees though.  I tried it with IIS, and it seemed to work ok (Well the domxml part), it just crashed later.

I'm installing Apache to see if I can reproduce the problem/fix it.
 [2002-05-16 13:03 UTC] cb at designassembly dot de 
even with the new php_domxml.dll it still crashes 

also when you use the correct new function 
append_sibling() it still crashes, even worser when you forget to add content to your nodes as in the example above apache crashes in a loop until the timeout is reached and no output reaches the browser.

<?
$doc = domxml_new_doc("1.0");
$root = $doc->create_element("HTML");
$root = $doc->append_child($root);
$body = $doc->create_element("element");
$body = $root->append_child($body);
//$body->set_content("content");

for($i = 1; $i < 130; $i++){
   $element = $doc->create_element("element");
   //$element->set_content("content ".$i);
  $body->append_sibling($element);
}

echo htmlentities($doc->dump_mem(true));
?>
 [2002-05-16 13:29 UTC] chregu@php.net 
To narrow down the problem. Does it also crash, when you don't use append_sibling, but append_child in the for-loop?

chregu
 [2002-05-16 14:05 UTC] cb at designassembly dot de 
The crash occurs weather you use append_sibling or append_child
 [2002-05-16 15:59 UTC] jtate@php.net 
Ahh,  Now I'm understanding the original poster.  I never got the 404 page.  Must have been a browser specific issue.  The error occurs in the cleanup routines on both iis and apache.  The stack trace is as follows:

_zval_ptr_dtor(_zval_struct * * 0x00e2f568, char * 0x10023020 `string', unsigned int 0x000001f8) line 272 + 5 bytes
node_wrapper_dtor(_xmlNode * 0x005cb9c8) line 504 + 26 bytes
node_list_wrapper_dtor(_xmlNode * 0x005cb9c8) line 531 + 9 bytes
node_list_wrapper_dtor(_xmlNode * 0x005c3c18) line 521 + 12 bytes
php_free_xml_doc(_zend_rsrc_list_entry * 0x00e38e18, void * * * 0x00afe7a8) line 563 + 12 bytes
list_entry_destructor(void * 0x00e38e18) line 177 + 16 bytes
zend_hash_apply_deleter(_hashtable * 0x00b2cac4, bucket * 0x00e38db8) line 596 + 15 bytes
zend_hash_graceful_reverse_destroy(_hashtable * 0x00b2cac4) line 662 + 13 bytes
zend_destroy_rsrc_list(_hashtable * 0x00b2cac4, void * * * 0x00afe7a8) line 233 + 9 bytes
shutdown_executor(void * * * 0x00afe7a8) line 196 + 30 bytes
zend_deactivate(void * * * 0x00afe7a8) line 596 + 9 bytes
php_request_shutdown(void * 0x00000000) line 787 + 9 bytes
apache_php_module_main(request_rec * 0x00afc798, int 0x00000000, void * * * 0x00afe7a8) line 96 + 8 bytes
send_php(request_rec * 0x00afc798, int 0x00000000, char * 0x00afd248) line 575 + 17 bytes
send_parsed_php(request_rec * 0x00afc798) line 590 + 13 bytes
ap_invoke_handler(request_rec * 0x00afc798) line 517 + 10 bytes
process_request_internal(request_rec * 0x00afc798) line 1308 + 9 bytes
ap_process_request(request_rec * 0x00afc798) line 1324 + 9 bytes
child_sub_main(int 0x00000000) line 5881
 [2002-05-16 19:04 UTC] jtate@php.net 
I seem to have found the problem.  Nodes are being freed twice: once in a call to php_free_xml_node, and once in a call to node_wrapper_dtor.  I've made two changes, one i've replaced the "free" code in php_free_xml_node with a call to the static inline function node_wrapper_dtor, and then call dom_object_set_data to clear the data (a check should be put here to make sure that the refcount is 0 before doing this, but I don't have time right now).  I'll post the patch to the php-dev list so that people can look it over, and make sure that it doesn't introduce any memory leaks.  I'll mark the bug fixed when I commit my change.
 [2002-05-16 19:17 UTC] jtate@php.net 
Oh, and I've tested it to work with 70,000 elements...
 [2002-05-17 07:44 UTC] chregu@php.net 
Ok, i did some tests on linux and indeed

There is a big f**king memory hole in domxml with append_child/append_sibling :( even with Josephs patch.

I will investigate further today...
 [2002-05-17 11:44 UTC] chregu@php.net 
Other people sit at the lake and enjoy the stupid hot weather here, i hunt memory leaks... what a pleasure... But i found it. Nodes which had no parents were not freed. i have a fix, but it's not perfect yet. expect a patch soon.
 [2002-05-17 13:10 UTC] chregu@php.net 
My patch is available at
http://trash.chregu.tv/domxml-memleak.diff
(for CVS-HEAD, but should be applyable to PHP_4_2_0 branch as well)

The big memory hole is certainly fixed with that, don't know about windows and the little memleaks...

Would be great, if someone could test it.
 [2002-05-18 08:37 UTC] chregu@php.net 
There is a stable snapshot available with (hopefully) the memleak-fixes. You can get it at http://snaps.php.net/win32/php4-win32-STABLE-latest.zip

Please report, if it works on Windows now.
 [2002-05-22 05:49 UTC] barrypalmer at ntlworld dot com 
GREAT !

I was sufferring (the same ) bug using the latest PHP binaries with:

$dom = domxml_open_file("tests/huge.xml");
$array = $dom->get_elements_by_tagname('document');
foreach($array as $e) {
echo "<br>" . $e->get_attribute("id");
}

using 'php4-win32-STABLE-latest.zip' its works !!

many thanks
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved. 		Last updated: Sat Nov 08 22:00:01 2025 UTC