I have 2 different patches that fix this specific issue, but am not sure if they are actually correct - as there may be a lower level issue, or even which one would be correct. One patch is on the Zend engine which will go through the destructor list in reverse within zend_clean_module_rsrc_dtors. The other is directly in domxml by just moving the php_free_xml_doc call to the end of the registered destructor list.
Which is actually correct, I have no idea. There is no documentation on which order destructors should be defined within a module, so dont know if there is a standard already in place. As you note it is most likely due to dl() not being a good function and few modules probably have a dependency issue like this. Although it is not an ideal way to load extensions, the function does exist. The real issue comes down to why when coming from the ini file, things are destroyed in reverse from how they were created within a php script, while if loaded from dl(), they are destroyed based on the order the destructors are defined within the module. Is this really a lower level issue and I am just seeing the surface of it? This is one sure fire way to dive into the engine piece I can tell you. On 31 Mar 2003, Thies C. Arntzen wrote: > > 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. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
