ID: 16888 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Analyzed Bug Type: DOM XML related Operating System: Windows XP PHP Version: 4.2.0 New Comment:
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. Previous Comments: ------------------------------------------------------------------------ [2002-05-17 11:44:09] [EMAIL PROTECTED] 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 07:44:01] [EMAIL PROTECTED] 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-16 19:17:32] [EMAIL PROTECTED] Oh, and I've tested it to work with 70,000 elements... ------------------------------------------------------------------------ [2002-05-16 19:04:25] [EMAIL PROTECTED] 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 15:59:08] [EMAIL PROTECTED] 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 ------------------------------------------------------------------------ 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/16888 -- Edit this bug report at http://bugs.php.net/?id=16888&edit=1
