Bug #12270 Updated: php4ts.dll crashes due to null-pointer assignment on shutdown

ID: 12270 Updated by: zimpel@t-online.de Reported By: zimpel@t-online.de Status: No Feedback Bug Type: Reproducible crash Operating System: Win32 PHP Version: 4.0.6 New Comment: This issue still persists in PHP4.2.2 as I recently checked. I can't provide a script to reproduce the problem, because only the startup and immediate shutdown of the sapi module is sufficient as a trigger. I tried to debug the PHP.exe based on php4ts.dll, but the crash isn't reproducible then. I made a small addition to cgi_main.c in order to invoke the shutdown-code: cgi_sapi_module.shutdown(&cgi_sapi_module); I used the 4.2.2 source distribution and build it on NT4/SP6 with MSVC6. The error is still as described below, except it also happens in debug builds now (probably changed preprocessor directives). I only wonder, if the p->pLast is NULL but the rest of the structure is still intact. If I can provide further support (e.g. logs), don't hestitate to ask. -- cu, Holger Previous Comments: ------------------------------------------------------------------------ [2002-03-04 00:00:01] php-bugs@lists.php.net No feedback was provided for this bug for over a month, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". ------------------------------------------------------------------------ [2002-02-03 20:19:29] yohgaki@php.net Could you try 4.1.1? ------------------------------------------------------------------------ [2001-07-22 15:30:06] zeev@php.net The fix is not valid - p->pLast cannot be NULLif everything works right - i.e., the bug is elsewhere. Do you have a script that reproduces this problem (preferably with the CGI version of PHP)? ------------------------------------------------------------------------ [2001-07-20 03:02:45] zimpel@t-online.de The crash may be only reproducible in release builds with activated bcmath. (In debug builds the Zend efree() function returns prior actual freeing something, if the thread which calls efree() isn't the thread which original allocated the resource). The "call stack" of this issue is: php_module_shutdown_wrapper() // pi3web_sapi.c php_module_shutdown() // main.c zend_shutdown() // zend.c zend_hash_destroy(&module_registry) // zend_hash.c pefree(ht->arBuckets, ht->persistent) // zend_hash.c ... PHP_MSHUTDOWN_FUNCTION(bcmath) // bcmath.c bc_free_num (num) // init.c, the global bcnum value is _two_ efree ((*num)->n_ptr); // zend_alloc.c In efree() the code in macro REMOVE_POINTER_FROM_LIST() crashes #define REMOVE_POINTER_FROM_LIST(p) \ if (!p->persistent && p==AG(head)) { \ AG(head) = p->pNext; \ } else if (p->persistent && p==AG(phead)) { \ AG(phead) = p->pNext; \ } else { \ p->pLast->pNext = p->pNext; \ } \ if (p->pNext) { \ p->pNext->pLast = p->pLast; \ } The reason of the crash is } else { \ p->pLast->pNext = p->pNext; \ if the pointer pLast == NULL. This is true for the last allocated persistent resource. This code is only called when bcmath performs shutdown, because in other calls of efree() the condition p==AG(head) seems to be always true. A probable fix is: } else if (p->pLast) { \ p->pLast->pNext = p->pNext; \ --- regards, Holger Zimmermann ------------------------------------------------------------------------ -- Edit this bug report at http://bugs.php.net/?id=12270&edit=1