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:
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>
Previous Comments:
------------------------------------------------------------------------
[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
