On Sun, Mar 30, 2003 at 04:34:36PM -0500, Rob Richards wrote: > My questions for the other day seem a lot off. After going through modules > much more, I need someone to either confirm or explain a little more on how > resources within a module are destroyed. What I am seeing stepping through > the code is the following: > > a module loaded from the ini file destroys its resources in the reverse > order that they are created via the script. > > a module loaded from a dl command destroys resources in the order that they > are registered in the PHP_MINIT_FUNCTION via > zend_register_list_destructors_ex. > > The memory leaks I seem to be seeing then would be due to the fact that > there are some dependencies on the resource destructions, which would mean > that the destructors would need to be defined in the order they should be > destroyed in (to support loading via dl). > > Is correct? If not can someone shed a little more light on this?
using dl() is generally not as "good" as loading extensions via php.ini. > > The problem I am stepping through is in the domxml. php_free_xml_doc is the > first destructor registered, so when the extension is loaded via the dl > command, php_free_xml_doc is the first destructor called, leaving the other > resources (node references, etc..) which were created in the script to crash > when they get called to be destroyed since xmlFreeDoc was already called. i was the guy that requested the destructors to be called in reverse order of creation, but i have never invstigated what happens if extensions are loaded via dl(). > > Any info on how the destructors work in the 2 different scenarios would be > greatly helpful. they shouldn't IMHO. if you could prepare a patch that fixes this i'm sure it'll be discussed here. but as not too many ppls actually think that dl() is a GoodFunction(tm) don't expect that anyone will "jump on" you problem just 'cause you reported it. so - my advice: a) include domxml in your php-build -or- b) load the shared lib via php.ini. if you _have_ to use dl() during your script (which will always be waaay slower than a or b) you will have to either c) fix the problem yourself and propose a patch or d) find someone who does that for you. my 2c, tc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php