Session problem View as Markdown

When an extension is loaded from a script rather than the ini file, the
resources are being destroyed incorrectly.
When I change zend_list and zend_hash to the following, the resources are
now destroyed in the same order as they are when the extension is loaded
from the ini file and no more memory issues (tested under windows).

It seems zend_clean_module_rsrc_dtors should be changed to something along
the lines of:

zend_list.c
void zend_clean_module_rsrc_dtors(int module_number TSRMLS_DC)
{
zend_hash_apply_reverse_with_argument(&list_destructors, (apply_func_arg_t)
zend_clean_module_rsrc_dtors_cb, (void *) &module_number TSRMLS_CC);
}

zend_hash.c
ZEND_API void zend_hash_apply_reverse_with_argument(HashTable *ht,
apply_func_arg_t apply_func, void *argument TSRMLS_DC)
{
Bucket *p;

IS_CONSISTENT(ht);

HASH_PROTECT_RECURSION(ht);
p = ht->pListTail;
while (p != NULL) {
if (apply_func(p->pData, argument TSRMLS_CC)) {
p = zend_hash_apply_deleter(ht, p);
} else {
p = ht->pListTail;
}
}
HASH_UNPROTECT_RECURSION(ht);
}

does this seem to be correct? Basically the only change is that it traverses
the hash table in reverse. didnt make a diff as not sure wether this is
correct logic or if there is a functions already there which would do the
same aszend_hash_apply_reverse_with_argument.

Thanks,

Rob

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