# Session problem - Thread: https://externals.io/message/85 - Original archive: https://news-web.php.net/php.internals/85 - Started by michel 'ziobudda' morelli on 2003-03-18T15:31:39+00:00 - Messages: 15 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #85 — michel 'ziobudda' morelli — 2003-03-18T15:31:39+00:00 URL: https://externals.io/message/85#85 Any news about this bug http://bugs.php.net/bug.php?id=22175 ? Tnx -- michel 'ziobudda' morelli Today I tried to run PHP-GTK with ZE2 changes against current CVS and it >segfaulted. I traced it to the fact that >PG(http_globals)[TRACK_SERVER_VARS] is no longer available if $_SERVER >is not present in the PHP code, due to the changes Zeev (I think) made >in order to improve efficiency. I don't quite agree with the way it >works right now. Well, it works well though :) All you have to do is hint PHP that you're going to touch it, and it will be available for you immediately. To do that, simply call: zend_is_auto_global("_SERVER", sizeof("_SERVER")-1 TSRMLS_CC); and you're done. ext/standard/info.c already makes use of this. Zeev ----- Original Message ----- From: "michel 'ziobudda' morelli" To: "php-dev" Sent: Tuesday, March 18, 2003 4:31 PM Subject: [PHP-DEV] Session problem > Any news about this bug > > http://bugs.php.net/bug.php?id=22175 > > ? > > Tnx > > -- > michel 'ziobudda' morelli I am trying to do a win 32 build from the latest cvs source. After 842 > errors I am trying to go through them to figure out what the problems are > that I am having. > > The largest source of errors seems to be a change made in February to the > use of winsock2. > winsock.h is getting pulled in first from /arpa/inet.h from the win32build > tools (via the php.h include). > This is causing many redefinition; different linkage errors. > In order to get rid of the errors and allow the the problem files to be > created I include the winsock2.h file prior to including the php.h file. > > Does any know wether this may o may not cause any unexpected problems? > > The files I found the problems in were: > > main/fopen_wrappers.c > main/mergesort.c > extc/ftp/ftp.c > ext/standard/dns.c > ext/standard/ftp_fopen_wrapper.c > ext/standard/http_fopen_wrapper.c > ext/mysql/php_mysql.c > ext/odbc/php_odbc.c > win32/sendmail.c > > Rob --- ## #200 — Rob Richards — 2003-03-23T18:53:45+00:00 URL: https://externals.io/message/85#200 · In reply to: #197 Thanks, working much better now Rob ----- Original Message ----- From: "Wez Furlong" To: "Rob Richards" Cc: "php-dev" Sent: Sunday, March 23, 2003 1:10 PM Subject: Re: [PHP-DEV] Win 32 Build problem > You are most likely building from the wrong branch. > > for PHP5: > co php5 > > for PHP 4.3.x > co -r PHP_4_3 php4 > > checking out HEAD from php4 will not work. > > --Wez. --- ## #451 — Rob Richards — 2003-03-29T10:34:53+00:00 URL: https://externals.io/message/85#451 · In reply to: #197 I am getting some serious memory leaks due to the difference between a module loaded via the ini file and one loaded via a dl call in a script. When loaded via the ini file, the memory is fine as the resources are killed in the correct order via the zend_hash_graceful_reverse_destroy call. When a module is loaded via dl call, the module is removed via the modules_destructor which kills off the resources in the order they were created in a script (at least looking at the stack while debugging this is what it shows is happening). Is this behavior by design or is it incorrect as some extensions rely on the reverse destruction on the resources. I would assume this is incorrect as it now no longer consistent execution of an extension if one were to load the extension using dl rather than from the ini file. Running some of them under Windows, php completely dies due to memory access violations. Thanks, Rob --- ## #468 — Rob Richards — 2003-03-29T14:17:46+00:00 URL: https://externals.io/message/85#468 · In reply to: #451 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 --- ## #517 — Rob Richards — 2003-03-30T21:34:36+00:00 URL: https://externals.io/message/85#517 · In reply to: #197 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? 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. Any info on how the destructors work in the 2 different scenarios would be greatly helpful. Thanks, Rob --- ## #546 — Thies C. Arntzen — 2003-03-31T18:18:25+00:00 URL: https://externals.io/message/85#546 · In reply to: #517 > 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 --- ## #550 — Rob Richards — 2003-03-31T19:03:51+00:00 URL: https://externals.io/message/85#550 · In reply to: #546 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. > > using `dl()` is generally not as "good" as loading extensions via > php.ini. > > > […] the > > […] other > > […] crash > > […] 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()`. > > > […] be > > […] > > 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. --- ## #597 — Rob Richards — 2003-04-02T10:24:03+00:00 URL: https://externals.io/message/85#597 · In reply to: #550 This patch fixes Bug #22774 PHP crashes when exiting. All it does is move the registration of the php_free_xml_doc destructor to the end of the list, so it is called after destroying nodes and attributes in the instances where the domxml extension is loaded via a `dl()` call. It seems the only time that the order of destructors matters is in the event of being loaded by `dl()`. Thanks, Rob --- ## #598 — Rob Richards — 2003-04-02T10:26:16+00:00 URL: https://externals.io/message/85#598 · In reply to: #546 Patch didnt get attached in last message. It can be found here: http://www.digarc.com/php_domxml.c.diff --- ## #599 — Christian Stocker — 2003-04-02T10:40:21+00:00 URL: https://externals.io/message/85#599 · In reply to: #598 > Patch didnt get attached in last message. > > It can be found here: http://www.digarc.com/php_domxml.c.diff applied. thanks chregu --- ## #630 — Rob Richards — 2003-04-03T09:31:43+00:00 URL: https://externals.io/message/85#630 · In reply to: #546 Here is a patch for domxml which implements the set_attribute_node method. Located at: http://www.digarc.com/php_domxml.diff One thing to note is in the section where an attribute already exists. As there can't be dunplicate attributes, only the content from the new attribute node is moved to the existing attribute node. Unlinking the origional attribute node could potential cause a memory leak as it may never be freed. Rob --- ## #631 — Christian Stocker — 2003-04-03T10:21:36+00:00 URL: https://externals.io/message/85#631 · In reply to: #630 > Here is a patch for domxml which implements the set_attribute_node method. > > Located at: http://www.digarc.com/php_domxml.diff > > One thing to note is in the section where an attribute already exists. As > there can't be dunplicate attributes, only the content from the new > attribute node is moved to the existing attribute node. Unlinking the > origional attribute node could potential cause a memory leak as it may never > be freed. Commited and thanks chregu