PHP 4.0 Bug #4939: Unhandled Exception in PHP4TS.DLL - Access Violation

From: Date: Fri, 09 Jun 2000 17:56:23 +0000
Subject: PHP 4.0 Bug #4939: Unhandled Exception in PHP4TS.DLL - Access Violation
Groups: php.dev 
Request: Send a blank email to php-dev+get-20813@lists.php.net to get a copy of this message
From: fredm@mail.telepac.pt Operating system: WIN NT4 SP6 PHP version: 4.0 Latest CVS (09/06/2000) PHP Bug Type: Reproduceable crash Bug description: Unhandled Exception in PHP4TS.DLL - Access Violation I am raising this bug as a response to the request made by Andi, when closing Bug #4434. Although I am not the originator of 4434, I have been experiencing the same problem. I checked the WIN32 binaries for 4.0.1, mentioned by Andi, and the same problem exists when using those binaries. The problem also exists in the latest CVS. I attach below the information that I have been able to collect about the problem. I posted this yesterday on PHP-DEV, and so I assume that Andi had not seen it. ----- yesterdays append to php-dev------------------------- I am still trying unsuccessfully, to fix my reproducible crash. So I thought I would try to collect all the information together, and perhaps someone could point me to the next thing to try. I am pretty certain that my bug is the same as 4434, and 4646 - the exception addresses were the same. I also think that it is quite likely that it is also the same as bug as 4653, 4705, and 4803. The bug has affected RC2, PHP4.0, and the latest CVS. I am running on Win NT4 SP6(Sorry, but I need to) I am using Apache 1.3.11. The failing script is a straight <? phpinfo(); ?> If I compile the Release_TS version then the symptoms are: A failure dialog box indicating OLEMainThreadWndName: php.exe Application error which is then replaced by Unhandled Exception in PHP4TS.DLL - Access Violation. If I compile the DEBUG_TS version, the script works fine and the page is displayed. If I modify the RELEASE_TS project settings, to include debugging options and recompile I have the same failure, but I have quite a bit more information. The trace is main.c(really php4\sapi\cgi\cgi_main.c . . . if (cgi || SG(request_info).path_translated) { file_handle.handle.fp = php_fopen_primary_script(); <------ call to php_open_primary script file_handle.filename = SG(request_info).path_translated; . . . Calls php_fopen_primary_script(In fopen_wrappers.c) . . . if ('/' != fn[l - 1] || '\\' != fn[l - 1]) /* l is never 0 */ fn[l++] = '/'; if ('/' == path_info[0]) l--; strcpy(fn + l, path_info); STR_FREE(SG(request_info).path_translated); <-----call to efree SG(request_info).path_translated = fn; . . . Calls _efree . . . HANDLE_BLOCK_INTERRUPTIONS(); REMOVE_POINTER_FROM_LIST(p); <------- Access violation occurs here. . . . I am pretty certain that we are quite fouled up by the time we get to the call to php_fopen_primary_script whilst we are in main, as argc = 0, argv cannot be evaluated, and the core globals seem to be trash, but I cannot find any way to let the debugger step me through to this call, if I access from the browser. If I execute from the debugger directly, I am not CGI, and go a completely different path through the logic. I feel that I have a lot of information about this problem, and if I were a PHP internals guru, I should have enough pointers(no pun intended) to the solution. Alas however, I am not, but my knowledge is slowly growing. If anybody can see the solution from this info, or if not, can point me the way forward to find it myself, I would appreciate it.

« previous php.dev (#20813) next »