ID: 21872 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Reproducible crash Operating System: Windows 2000 PHP Version: 4.3.0 New Comment:
Unfortunately, applying the aforementioned patches to my production server does not eliminate the problem. That box is a Dual Xeon of some speed, as opposed to my single P4 testing box. In order to exhibit the error there, I re-create the test script above to hold 50 iframes. I see the error approximately one out of 400 requests in conjunction with a MSSQL/ODBC call. I appologize for making you read all this. Previous Comments: ------------------------------------------------------------------------ [2003-01-25 18:21:01] [EMAIL PROTECTED] As of this morning, I cannot duplicate the error on my test box (Win2000 professional). While I await the return of the CGI error, and if anyone is curious, they could ponder the following changes I made to my system. I am not asking for this bug's state to be changed to BOGUS or CLOSED, I just want to continue providing as much information as I can. I know there are a lot of people experiencing similar problems. 1) I restarted my system, which I do every few weeks. However, this hasn't solved anything in the past, but I wanted to include it just because it could offer a clue if the problem doesn't present itself until X hours after a reboot. (Probably not a good clue, but a clue none-the-less). 2) In restarting my system, I also applied the latest patches recommended by Microsoft's Windows Update. These patches were from the last two weeks, and did not look to imply a fix for this issue. Again, these were the DEFAULT patches recommended. 3) I picked two additional patches from Windows Update that were not defaults. If anyone savvy with the Win32 programming of PHP is reading, I'd be curious if you could check out these two KB articles and see if they could possibly relate. The second one seems particularly interesting, as it relates specifically to timing. http://support.microsoft.com/default.aspx?scid=KB;en-us;Q322842 http://support.microsoft.com/default.aspx?scid=KB;en-us;Q322913 I think that is it. I understand it is extremely poor troubleshooting practice to attempt multiple 'fixes' at once, but when you've been struggling with something for months you tend to get to the point where you don't think any more changes will actually help anything. At least I can pinpoint the two added patches which might shed light on something. Again, I'll keep you posted and continue to test this issue, and would be happy to respond with any information requested. ------------------------------------------------------------------------ [2003-01-24 22:02:29] [EMAIL PROTECTED] Additionally, I can offer the test script. Here is a bare-bones example. Testing this just now, it will error on at least one of the 6 iframes EVERY refresh. 1/6 requests is an error. Sorry the actual DSN and SQL query does no good, but if you really wanted to try this it will save a little hassle. <? if ($_GET['dummy']) { print "<html><body>x</body></html>"; exit(); } $sql_params = array( 'DSN' => 'myDSN', 'user' => 'user', 'pass' => 'pass', 'query' => 'SELECT DISTINCT field1 FROM table1', ); $conn = odbc_connect($sql_params['DSN'], $sql_params['user'], $sql_params['pass']) or die("Couldn't connect to SQL Server on {$sql_params['DSN']}"); $conn_id = odbc_exec($conn, $sql_params['query']); print odbc_num_fields($conn_id); odbc_free_result($conn_id); ?> <IFRAME width='300px' height='300px' scrolling='no' src="test_bug.php?dummy=true"></IFRAME> <IFRAME width='300px' height='300px' scrolling='no' src="test_bug.php?dummy=true"></IFRAME> <IFRAME width='300px' height='300px' scrolling='no' src="test_bug.php?dummy=true"></IFRAME> <IFRAME width='300px' height='300px' scrolling='no' src="test_bug.php?dummy=true"></IFRAME> <IFRAME width='300px' height='300px' scrolling='no' src="test_bug.php?dummy=true"></IFRAME> <IFRAME width='300px' height='300px' scrolling='no' src="test_bug.php?dummy=true"></IFRAME> ------------------------------------------------------------------------ [2003-01-24 21:36:18] [EMAIL PROTECTED] When calling a PHP script that is using MSSQL or ODBC calls, I can reporduce this error at least one out of every ten tries, on multiple machines. I'm at the end of my rope trying to figure it out myself. If I can reproduce the error, I figure I am a prime candidate to help solve it. The error states: CGI Error The specified CGI application misbehaved by not returning a complete set of HTTP headers. The headers it did return are: And that's it. There is nothing after "are:" This is how I reproduce (test for) the error: I have a PHP script that generates a webpage. That webpage contains 4 iframes. (The iframes are nothing more than a php page that echoes <html><body>x</body></html>. The main page prints the code to invoke the iframes, and it also makes an MSSQL or ODBC query. NOTE: I can also reproduce this error when making a database call in conjuction with a header("location: ...") redirect as well, but that's a little more annoying to test than the iframes since it doesn't happen every time. So, every reload on the main page is essentially 5 PHP requests (1 main + 4 iframes). If I refresh this test page, I can get at least one of the iframes to error every 5 tries. Which, of course, is at least one error every 25 requests. Now on to the DB. If I comment out the DB call (be it an MSSQL or ODBC query) I cannot reproduce the error. This is my guess... the bug happens when PHP attempts to service a request at the exact moment something closes in the DB call. I'm sorry I can't do any better than that for troubleshooting. But, logically, the error is random enough that it doesn't happen EVERY time, so all I can guess is that it is a pure timing issue, which happens more frequently the more you hit the server as it is making a DB request. Any other info I can offer... I can reproduce this with IIS on three Win2000 Servers and one Win2000 Professional box. I am not using Named Pipes. I've tried several versions of ntwdblib.dll and am currently using the one included with PHP 4.3.0 (12/27/2002). I only have SQL 2000 servers to connect to, but I've reproduced this bug with the three of them that I use regularly. My desktop (the Windows 2000 Professional) box is what I test with most often, and it is running Service Pack 3 and is using the current MDAC (2.7 I believe). I did not use the Win32 'installer' ... rather installed via the latest .zip and my production boxes are SMP machines, so until SAPI is given the thread-safe go-ahead I have to stick with the .exe I can't think of anything more off the top of my head, but I would be more than willing to give whatever feedback is requested. Unfortunately, I thought this bug was only MSSQL related for some reason, so I've been putting off switching everything to ODBC. I was very saddened today when I experienced the error with ODBC as well. I've got approximately one week to solve this before I have to launch a new site with my company, and while the lauch will go either way, I don't want the executives to question my decision to use PHP instead of VBscript (as the other developers here know VB, and my argument/skills seemed strong enough to sway to the PHP side). I'm not trying to pull any heart strings here, like I said, the site is going to launch CGI errors or not, I'd just rather have it flawless (and not field end-user calls on the issue to boot). ------------------------------------------------------------------------ -- Edit this bug report at http://bugs.php.net/?id=21872&edit=1
