[PHP-DEV] Bug #11969: PHP repeats ODBC queries when using include()...
From: [EMAIL PROTECTED]
Operating system: Windws 98
PHP version: 4.0.6
PHP Bug Type: Scripting Engine problem
Bug description: PHP repeats ODBC queries when using include()...
Hello, I have once again found another bug...you guys couldn't possibly
remove them all, could you? :)
Anyway, my problem is a very interesting one (this will take a while to
read - so bear with me)...took me a while and lots of testing to verify
that PHP v4.0.6 has a *MAJOR* problem with the ODBC engine when using
include's (relative/absolute - doesn't matter). The short story is that
there is no problem if you only include() one file. However, in my case,
I've got includes 5-7 levels deep with file I/O and what-not...but no
database calls except in the top-level routine. Here is the SQL code I was
running against a database (trimmed down a bit):
include("$DBDir/initdb.php");
$sql = "SELECT MAX(ProdTitle_ID) AS Max_ProdTitle_ID
FROM ProdTitle";
$sql_result = odbc_exec($db, $sql);
odbc_fetch_row($sql_result);
...
$sql = "INSERT INTO ProdTitle (ProdTitle_ID, ProdTitle_X, ProdDesc_X,
ProdLogo_X, ProdScreens_X)
VALUES ($Max_ProdTitle_ID, '$ProdTitle_X', '$ProdDesc_X',
'$ProdLogo_X', '$ProdScreens_X')";
echo "$sql";
$sql_result = odbc_exec($db, $sql);
...
include("$DBDir/enddb.php");
initdb.php and enddb.php perform normal odbc_connect and odbc_close
operations. This portion of the code works fine. However, when I add the
following line:
include("index.php");
PHP now does something extremely bizarre. index.php contains the following
data:
PHP parses the includes and displays everything correctly on the page,
however, when I check the database 1 extra row has been added, I have
verified that PHP is re-executing the starting script, but it refuses to
display anything from the 'echo "$sql";' line of code. Even more
bizarre is that if I add, say, a SELECT statement and execute it but don't
retrieve any results, PHP re-executes the starting script 3 times (thus 3
extra rows in the database). If there were a loopback in the script, PHP
would run forever (I turned off the time-limit). If it was some scripting
error, the 'echo "$sql";' result would have shown up in the
response page. So, PHP is restarting the script on its own and destroying
data integrity. Here is a snippet of a SQL capture that verifies what I've
been talking about:
First the SELECT statement...
fffc020f-fffae443 ENTER SQLExecDirect
HSTMT 00D7076C
UCHAR * 0x00797670 [ -3] "SELECT MAX(ProdTitle_ID) AS
Max_ProdTitle_ID\ d\ aFROM ProdTitle\ 0"
SDWORD-3
fffc020f-fffae443 EXIT SQLExecDirect with return code 0
(SQL_SUCCESS)
HSTMT 00D7076C
UCHAR * 0x00797670 [ -3] "SELECT MAX(ProdTitle_ID) AS
Max_ProdTitle_ID\ d\ aFROM ProdTitle\ 0"
SDWORD-3
Now the INSERT statement - Note the values being inserted!!!
fffc020f-fffae443 ENTER SQLExecDirect
HSTMT 00D70C00
UCHAR * 0x0079AA60 [ -3] "INSERT INTO ProdTitle
(ProdTitle_ID, ProdTitle_X, ProdDesc_X, ProdLogo_X, ProdScreens_X)\ d\ a
VALUES (5, 'asdf', 'asdf', ' ', ' ')\ 0"
SDWORD-3
fffc020f-fffae443 EXIT SQLExecDirect with return code 0
(SQL_SUCCESS)
HSTMT 00D70C00
UCHAR * 0x0079AA60 [ -3] "INSERT INTO ProdTitle
(ProdTitle_ID, ProdTitle_X, ProdDesc_X, ProdLogo_X, ProdScreens_X)\ d\ a
VALUES (5, 'asdf', 'asdf', ' ', ' ')\ 0"
SDWORD-3
So far so good. At this point the log file shows that the connection is
being dropped and even the environment handle is destroyed. Then, all of a
sudden, the connection is re-instated and two more queries are processed:
First the SELECT statement (basically the same as before)...
fffb7f03-fffb93db ENTER SQLExecDirect
HSTMT 00D7076C
UCHAR * 0x00796A90 [ -3] "SELECT MAX(ProdTitle_ID) AS
Max_ProdTitle_ID\ d\ aFROM ProdTitle\ 0"
SDWORD-3
fffb7f03-fffb93db EXIT SQLExecDirect with return code 0
(SQL_SUCCESS)
HSTMT 00D7076C
UCHAR * 0x00796A90 [ -3] "SELECT MAX(ProdTitle_ID) AS
Max_ProdTitle_ID\ d\ aFROM ProdTitle\ 0"
SDWORD-3
Next, the INSERT statement - this one is *VERY* different...
fffb7f03-fffb93db ENTER SQLExecDirect
[PHP-DEV] Bug #11921 Updated: Apache 1.3.20, mod_ssl 2.8.4, PHP 4.0.4 crashes in CGI mode
ID: 11921
User Update by: [EMAIL PROTECTED]
Status: Open
Bug Type: Reproducible crash
Operating system: Windows 98
PHP Version: 4.0.6
Description: Apache 1.3.20, mod_ssl 2.8.4, PHP 4.0.4 crashes in CGI mode
Seems like someone else has been having a similar problem (Bug #10904 - I got curious
as to what the other reproducible bugs were). My previous comments should help narrow
this problem down further (and actually make it reproducible). My guess is that it is
not only Windows platforms, but possibly even Linux...but that has yet to be proven.
Right now I'm not in the mood to log into Linux and give myself another headache. One
at a time is plenty for me :)
(XiFusion is also for Linux, so it would be interesting to see if Apache fails under
Linux due to the
Apache->Perl->XiFusion->PHP combo).
Thomas Hruska
Previous Comments:
---
[2001-07-06 04:42:34] [EMAIL PROTECTED]
The Short Description is supposed to be 4.0.6, although the bug is also in 4.0.4.
4.0.5 is untested for the bug.
---
[2001-07-06 04:38:22] [EMAIL PROTECTED]
Using the default PHP 4.0.6 package for Win32 (downloaded straight from php.net), I
have found an interesting combination that causes Apache 1.3.20 to core dump. My
objective was to set up an SSL server to seamlessly work with the Xitami webserver,
Apache is the obvious choice here.
The first thing I did was download and install Apache 1.3.20 for Win32. Then, I
applied the patches located in Apache_1.3.20-Mod_SSL_2.8.4-OpenSSL_0.9.6a-WIN32.zip on
the contributions page of the www.modssl.org site. Finally, I configured and set up
the SSL virtual server (both a self-signed and a CA-signed certificate work) and got
everything working. I wrote a short Perl script that would call XiFusion with the
correct parameters:
#!c:/perl/bin/perl
$ENV{"SCRIPT_NAME"} = $ENV{"REDIRECT_URL"};
system "c:\xifusion\xifusion.exe c:\php4\php.exe";
Side Note: I am the author of XiFusion v2.5 (a wrapper for CGIs under the Xitami
webserver for ColdFusion and PHP ).
This setup worked fine...sort of. I have tried everything I can think of to prove
that PHP isn't the culprit, but it is. Here is what happens:
1) The browser connects to the SSL server.
2) The browser request a PHP page. Apache sees that PHP extensions are aliased to a
type, thus it checks out the action it should take. It then executes the previously
mentioned Perl script.
3) The Perl script modifies an environment variable and calls XiFusion.
4) XiFusion does its thing and executes PHP (I've checked to see if XiFusion or the
Perl script were the problem and they are not).
5) PHP then starts to process the page.
6) ApacheCore.dll for some reason core dumps. I have no idea why it does this (it is
somewhat random, but *VERY* reproducible).
7) The odd thing is is that when I click "Close" on the dialog box, Apache reloads
and acts like nothing happened...weird (none of the log files show that an error
occurred either...even weirder).
What is even weirder than all that is if I switch from CGI mode to module mode (modify
conf/httpd.conf), there is no problem...even under normal Apache 1.3 API.
I've scoured google.com as well as the PHP databases for any solution to this very
interesting bug. I've been re-building everything (Apache, OpenSSL, mod_ssl) from
sources to see if I can improve the situation any. So far, no luck (no, I didn't
forget to replace the DLLs in the Windowssystem directory). I've seen references to
the
-DEAPI compile option for PHP, so I will try that out tomorrow to see if that helps
(but knowing my luck so far... :)
This bug is also in PHP v4.0.4.
Pertinent Machine Info.:
OS: Win98
Dual PIII 500 mHz CPUs
384MB RAM (I try to maintain about 150MB free using RamIdle)
18GB HD (5 GB free on the Win98 partition)
I really want to use the XiFusion wrapper program rather than the module since I can
get more control through XiFusion than I can through Apache.
Sorry, no gdb backtrace. My debugging methods are usually lots of good ol' fashioned
printf statements ;)
Thomas Hruska
Shining Light Productions
"Meeting the Needs of Fellow Programmers"
---
Full Bug description available at: http://bugs.php.net/?id=11921
--
PHP Development Mailing List
[PHP-DEV] Bug #11921 Updated: Apache 1.3.20, mod_ssl 2.8.4, PHP 4.0.4 crashes in CGI mode
ID: 11921
User Update by: [EMAIL PROTECTED]
Status: Open
Bug Type: Reproducible crash
Operating system: Windows 98
PHP Version: 4.0.6
Description: Apache 1.3.20, mod_ssl 2.8.4, PHP 4.0.4 crashes in CGI mode
The Short Description is supposed to be 4.0.6, although the bug is also in 4.0.4.
4.0.5 is untested for the bug.
Previous Comments:
---
[2001-07-06 04:38:22] [EMAIL PROTECTED]
Using the default PHP 4.0.6 package for Win32 (downloaded straight from php.net), I
have found an interesting combination that causes Apache 1.3.20 to core dump. My
objective was to set up an SSL server to seamlessly work with the Xitami webserver,
Apache is the obvious choice here.
The first thing I did was download and install Apache 1.3.20 for Win32. Then, I
applied the patches located in Apache_1.3.20-Mod_SSL_2.8.4-OpenSSL_0.9.6a-WIN32.zip on
the contributions page of the www.modssl.org site. Finally, I configured and set up
the SSL virtual server (both a self-signed and a CA-signed certificate work) and got
everything working. I wrote a short Perl script that would call XiFusion with the
correct parameters:
#!c:/perl/bin/perl
$ENV{"SCRIPT_NAME"} = $ENV{"REDIRECT_URL"};
system "c:\xifusion\xifusion.exe c:\php4\php.exe";
Side Note: I am the author of XiFusion v2.5 (a wrapper for CGIs under the Xitami
webserver for ColdFusion and PHP ).
This setup worked fine...sort of. I have tried everything I can think of to prove
that PHP isn't the culprit, but it is. Here is what happens:
1) The browser connects to the SSL server.
2) The browser request a PHP page. Apache sees that PHP extensions are aliased to a
type, thus it checks out the action it should take. It then executes the previously
mentioned Perl script.
3) The Perl script modifies an environment variable and calls XiFusion.
4) XiFusion does its thing and executes PHP (I've checked to see if XiFusion or the
Perl script were the problem and they are not).
5) PHP then starts to process the page.
6) ApacheCore.dll for some reason core dumps. I have no idea why it does this (it is
somewhat random, but *VERY* reproducible).
7) The odd thing is is that when I click "Close" on the dialog box, Apache reloads
and acts like nothing happened...weird (none of the log files show that an error
occurred either...even weirder).
What is even weirder than all that is if I switch from CGI mode to module mode (modify
conf/httpd.conf), there is no problem...even under normal Apache 1.3 API.
I've scoured google.com as well as the PHP databases for any solution to this very
interesting bug. I've been re-building everything (Apache, OpenSSL, mod_ssl) from
sources to see if I can improve the situation any. So far, no luck (no, I didn't
forget to replace the DLLs in the Windowssystem directory). I've seen references to
the
-DEAPI compile option for PHP, so I will try that out tomorrow to see if that helps
(but knowing my luck so far... :)
This bug is also in PHP v4.0.4.
Pertinent Machine Info.:
OS: Win98
Dual PIII 500 mHz CPUs
384MB RAM (I try to maintain about 150MB free using RamIdle)
18GB HD (5 GB free on the Win98 partition)
I really want to use the XiFusion wrapper program rather than the module since I can
get more control through XiFusion than I can through Apache.
Sorry, no gdb backtrace. My debugging methods are usually lots of good ol' fashioned
printf statements ;)
Thomas Hruska
Shining Light Productions
"Meeting the Needs of Fellow Programmers"
---
Full Bug description available at: http://bugs.php.net/?id=11921
--
PHP Development Mailing List
[PHP-DEV] Bug #11921: Apache 1.3.20, mod_ssl 2.8.4, PHP 4.0.4 crashes in CGI mode
From: [EMAIL PROTECTED]
Operating system: Windows 98
PHP version: 4.0.6
PHP Bug Type: Reproducible crash
Bug description: Apache 1.3.20, mod_ssl 2.8.4, PHP 4.0.4 crashes in CGI mode
Using the default PHP 4.0.6 package for Win32 (downloaded straight from php.net), I
have found an interesting combination that causes Apache 1.3.20 to core dump. My
objective was to set up an SSL server to seamlessly work with the Xitami webserver,
Apache is the obvious choice here.
The first thing I did was download and install Apache 1.3.20 for Win32. Then, I
applied the patches located in Apache_1.3.20-Mod_SSL_2.8.4-OpenSSL_0.9.6a-WIN32.zip on
the contributions page of the www.modssl.org site. Finally, I configured and set up
the SSL virtual server (both a self-signed and a CA-signed certificate work) and got
everything working. I wrote a short Perl script that would call XiFusion with the
correct parameters:
#!c:/perl/bin/perl
$ENV{"SCRIPT_NAME"} = $ENV{"REDIRECT_URL"};
system "c:\\xifusion\\xifusion.exe c:\\php4\\php.exe";
Side Note: I am the author of XiFusion v2.5 (a wrapper for CGIs under the Xitami
webserver for ColdFusion and PHP ).
This setup worked fine...sort of. I have tried everything I can think of to prove
that PHP isn't the culprit, but it is. Here is what happens:
1) The browser connects to the SSL server.
2) The browser request a PHP page. Apache sees that PHP extensions are aliased to a
type, thus it checks out the action it should take. It then executes the previously
mentioned Perl script.
3) The Perl script modifies an environment variable and calls XiFusion.
4) XiFusion does its thing and executes PHP (I've checked to see if XiFusion or the
Perl script were the problem and they are not).
5) PHP then starts to process the page.
6) ApacheCore.dll for some reason core dumps. I have no idea why it does this (it is
somewhat random, but *VERY* reproducible).
7) The odd thing is is that when I click "Close" on the dialog box, Apache reloads
and acts like nothing happened...weird (none of the log files show that an error
occurred either...even weirder).
What is even weirder than all that is if I switch from CGI mode to module mode (modify
conf/httpd.conf), there is no problem...even under normal Apache 1.3 API.
I've scoured google.com as well as the PHP databases for any solution to this very
interesting bug. I've been re-building everything (Apache, OpenSSL, mod_ssl) from
sources to see if I can improve the situation any. So far, no luck (no, I didn't
forget to replace the DLLs in the Windows\system directory). I've seen references to
the
-DEAPI compile option for PHP, so I will try that out tomorrow to see if that helps
(but knowing my luck so far... :)
This bug is also in PHP v4.0.4.
Pertinent Machine Info.:
OS: Win98
Dual PIII 500 mHz CPUs
384MB RAM (I try to maintain about 150MB free using RamIdle)
18GB HD (5 GB free on the Win98 partition)
I really want to use the XiFusion wrapper program rather than the module since I can
get more control through XiFusion than I can through Apache.
Sorry, no gdb backtrace. My debugging methods are usually lots of good ol' fashioned
printf statements ;)
Thomas Hruska
Shining Light Productions
"Meeting the Needs of Fellow Programmers"
--
Edit Bug report at: http://bugs.php.net/?id=11921&edit=1
--
PHP Development Mailing List
