ID: 25570 Updated by: [EMAIL PROTECTED] -Summary: Interpreter crashes reproducibly (2) Reported By: robert at profundis dot se -Status: Open +Status: Feedback Bug Type: Apache2 related -Operating System: WinXP SP1 +Operating System: SLES 8.0 zSeries s390 IBM -PHP Version: 5CVS-2004-04-22 (dev) +PHP Version: 4.3.9RC3 -Assigned To: +Assigned To: jorton New Comment:
Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip I've committed a possible fix for this to 5.0 and 5.1, please apply: http://cvs.apache.org/~jorton/php_abort.diff or wait for a 5.0-dev or 5.1-dev snapshot to show up with this applied. Previous Comments: ------------------------------------------------------------------------ [2004-10-20 10:47:31] [EMAIL PROTECTED] Ah, good call. The interesting exit(-1) call is in Zend: _zend_bailout to be specific. And in fact zend_bailout is called from php_handle_aborted_connection, which can be called outside the zend_first_try/zend_end_try block in the 2.0 SAPI, so that looks like the bug. ------------------------------------------------------------------------ [2004-10-17 18:55:56] mwhitlock at whitsoftdev dot com Unsigned 4294967295 is the same as -1 in 32-bit two's complement signed math. It looks to me as if we're not encountering a segfault (since that would generate a different message in httpd.log) but rather an error trap somewhere that is calling exit(-1). Calling exit(..) from a dynamic link library kills the host process, which in this case would be the Apache child process. Seems like the solution is just finding where PHP is calling exit(-1) and changing it to somehow more gracefully aborting the request rather than forcefully exiting the process. Exiting the process wouldn't be a problem for the CLI since a separate process is created to handle every request, but as an Apache module, exit(..) is simply wrong. ------------------------------------------------------------------------ [2004-10-15 14:42:37] jonathan at schwarzelan dot de Sorry guys - got to correct the above said... With outputting results in the 4294967295 Crash - without it results to 3221225477 Apache crash shame on me... ------------------------------------------------------------------------ [2004-10-15 14:40:29] jonathan at schwarzelan dot de Some extra Information on the Bug (sorry no traces-) Not only outputting stuff leads to this error - Just having a loop of 140 doing querys on mysql and without saving data from those querys filling an array like $arr[$i][0]="" crashes Apache with said logfile occurence - Found with Win2k, Php 5.1.0-dev and 2.0.50 Apache and XPSP1, Php 5.0.2 release and 2.0.50 Apache ------------------------------------------------------------------------ [2004-10-14 20:34:48] robert at profundis dot se > Can you get a backtrace of the crash? Eek, not easily. This is Windows :( Not saying one can't make a backtrace on Windows, but I'm not sure how to go about doing it. Last time around I had a test machine to tinker with, not so this time. My guess is that it is a thread issue, since it occurs when two requests (threads) are inside the handler, and one of them is aborted (according to my investigations last time). I'm not too familiar with the code, but maybe some overlooked global related to aborted connections? I can also add that I can't say for sure it ever was fixed. I don't remember if the version I've been running was the one I modified myself or a cvs snapshot. ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/25570 -- Edit this bug report at http://bugs.php.net/?id=25570&edit=1
