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
