#36057 [Fbk->Opn]: php_oci8.dll not thread safe?
ID: 36057 User updated by: ottawasixtyseven at hotmail dot com Reported By: ottawasixtyseven at hotmail dot com -Status: Feedback +Status: Open Bug Type: OCI8 related -Operating System: W2K +Operating System: W2K/IIS5 PHP Version: 5.1.2 New Comment: Is IIS5 a threaded web server? Previous Comments: [2006-01-17 18:22:22] [EMAIL PROTECTED] Works perfectly fine with threaded web-servers like Apache2. [2006-01-17 17:48:58] ottawasixtyseven at hotmail dot com Description: It appears that php_oci8.dll is not thread safe. We're trying to run PHP 5.1 in ISAPI mode using php_oci8.dll to connect to Oracle. We can use ODBC instead of php_oci8.dll but this slows things down by as much as three times. We can also use PHP in CGI mode with php_oci8.dll but this also adversely effects performance. I guess we're just looking for confirmation here. If it's a known issue that php_oci8.dll is not thread safe then we'll have to find another solution. Reproduce code: --- Any code will reproduce this. We are using phpinfo(). We are aware that phpinfo() leaks on purpose (not a bug) but for the purposes of this testing we're not concerned about memory leaks as the test only runs for 5 minutes. Expected result: Expect the web server not to crash during load test. Actual result: -- Server crashes after 20 seconds with thousands of HTTP errors. Works perfectly in ODBC mode. -- Edit this bug report at http://bugs.php.net/?id=36057&edit=1
#36057 [NEW]: php_oci8.dll not thread safe?
From: ottawasixtyseven at hotmail dot com Operating system: W2K PHP version: 5.1.2 PHP Bug Type: Oracle related Bug description: php_oci8.dll not thread safe? Description: It appears that php_oci8.dll is not thread safe. We're trying to run PHP 5.1 in ISAPI mode using php_oci8.dll to connect to Oracle. We can use ODBC instead of php_oci8.dll but this slows things down by as much as three times. We can also use PHP in CGI mode with php_oci8.dll but this also adversely effects performance. I guess we're just looking for confirmation here. If it's a known issue that php_oci8.dll is not thread safe then we'll have to find another solution. Reproduce code: --- Any code will reproduce this. We are using phpinfo(). We are aware that phpinfo() leaks on purpose (not a bug) but for the purposes of this testing we're not concerned about memory leaks as the test only runs for 5 minutes. Expected result: Expect the web server not to crash during load test. Actual result: -- Server crashes after 20 seconds with thousands of HTTP errors. Works perfectly in ODBC mode. -- Edit bug report at http://bugs.php.net/?id=36057&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=36057&r=trysnapshot44 Try a CVS snapshot (PHP 5.1): http://bugs.php.net/fix.php?id=36057&r=trysnapshot51 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=36057&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=36057&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=36057&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=36057&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=36057&r=needscript Try newer version:http://bugs.php.net/fix.php?id=36057&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=36057&r=support Expected behavior:http://bugs.php.net/fix.php?id=36057&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=36057&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=36057&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=36057&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=36057&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=36057&r=dst IIS Stability:http://bugs.php.net/fix.php?id=36057&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=36057&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=36057&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=36057&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=36057&r=mysqlcfg
#9852 [Com]: Header redirect and db connection cause "CGI misbehaved"
ID: 9852
Comment by: ottawasixtyseven at hotmail dot com
Reported By: ron dot baldwin at sourceprose dot com
Status: Closed
Bug Type: IIS related
Operating System: Windows 2000
PHP Version: 4.2.1
New Comment:
Lewid,
php4isapi.dll works perfectly for some people. We are part of the
unfortunate group that experiences lots of server 500 errors. Here is
an excerpt from the latest PHP INSTALL text file:
_
PHP 4 for Windows comes in two flavours - a CGI executable (php.exe),
and several SAPI modules (for exapmle php4isapi.dll). The latter form
is new to PHP 4, and provides significantly improved performance and
some new functionality. However, please note that the SAPI modules are
*NOT* yet considered to be production quality. In particular, with the
ISAPI module, you are likely to encounter serious reliability problems
especially on platforms older than W2K - you may witness a lot of
server 500 errors and suffer from other server modules such as ASP also
failing. You have been warned!
The reason for this is that the PHP SAPI modules are using the
thread-safe version of the PHP code, which is new to PHP 4, and has not
yet been tested and pounded enough to be considered completely stable,
and there are actually a few known bugs. On the other hand, some people
have reported very good results with the SAPI modules, and there a few
reports of problems with the Apache module version. In short - your
mileage may vary; If you need absolute stability, trade the
performance of the SAPI modules with the stability of the CGI
executable.
_
Hopefully you can be part of the increasing numbers that are actually
able to give php4isapi.dll a good pounding. Please make sure to report
any problems you have with it.
Ottawa
Previous Comments:
[2003-03-20 15:28:49] lewid at nc dot rr dot com
What bugs are there in php4isapi.dll (referring to above comment)? I am
using an isapi filter pointing to php4isapi.dll and it seems to have
fixed the cgi issue completely in my development environment.
[2003-03-20 12:30:21] ottawasixtyseven at hotmail dot com
I have PROVEN beyond a shadow of a doubt that IIS can't handle multiple
simultaneous connections to ANY CGI It's not the fault of
PHP.EXE
I've compiled the C code that's listed below and put it in
C:\Inetpub\Scripts. If you would like a copy of the compiled exe drop
me a line.
For the sake of simplicity, this program is designed to be initially
called with no parameters as in http://localhost/Scripts/breakiis.exe
Also, for simplicity, I don't bother following the conventional
name=value&name=value format of the URL string parameters but simply
pass a number. This code is perfectly safe in that it will start the
count at 1 if no parms are passed and if a QUERY_STRING that is
non-numeric is passed, atof will return 0.0 so that is also safe. This
program fully complies with the rules of CGI programming via the GET
method in that it receives the URL string parameters via QUERY_STRING
and sends back output via cout
with a valid header. You will see that running one instance of this in
the browser will work fine. Run multiple instances and you will break
IIS. This program is designed to do nothing more than prove that there
is a flaw in the way that IIS handles CGI processes and that the bug is
in fact with IIS and not PHP.
You *CANNOT* break Apache with multiple instances of this CGI code:
__
#include
#include
#include
#include
char *data;
double count;
int main(void)
{
data = getenv("QUERY_STRING");
if(data == NULL)
count=1;
else
count = atof(data);
printf("Content-Type:text/html\n\n");
printf("Loading page with value %f\n",floor(count));
count++;
printf("location.href='breakiis.exe?%f'",count);
return 0;
}
___
I have launched yet another campaign to try and get Microsoft to fix
this problem but honestly I think we'd have better luck just working
out the bugs in php4isapi.dll. Maybe in the year 2025 Microsoft will
get around to fixing this problem.
Ottawa
----------------
[2003-03-17 17:49:27] ottawasixtyseven at hotmail dot com
Lewid,
Have you considered trying php4isapi.dll? PHP admits that it's *STILL*
not production quality (how many years has it been ???) but some
people have had great success with it.
I think I may have finally figured out why PHP.EXE spits out those CGI
errors. And why on faster machines it happens more often ... IT'S NOT
THREAD-SAFE !!!
I don't know
#9852 [Com]: Header redirect and db connection cause "CGI misbehaved"
ID: 9852
Comment by: ottawasixtyseven at hotmail dot com
Reported By: ron dot baldwin at sourceprose dot com
Status: Closed
Bug Type: IIS related
Operating System: Windows 2000
PHP Version: 4.2.1
New Comment:
I have PROVEN beyond a shadow of a doubt that IIS can't handle multiple
simultaneous connections to ANY CGI It's not the fault of
PHP.EXE
I've compiled the C code that's listed below and put it in
C:\Inetpub\Scripts. If you would like a copy of the compiled exe drop
me a line.
For the sake of simplicity, this program is designed to be initially
called with no parameters as in http://localhost/Scripts/breakiis.exe
Also, for simplicity, I don't bother following the conventional
name=value&name=value format of the URL string parameters but simply
pass a number. This code is perfectly safe in that it will start the
count at 1 if no parms are passed and if a QUERY_STRING that is
non-numeric is passed, atof will return 0.0 so that is also safe. This
program fully complies with the rules of CGI programming via the GET
method in that it receives the URL string parameters via QUERY_STRING
and sends back output via cout
with a valid header. You will see that running one instance of this in
the browser will work fine. Run multiple instances and you will break
IIS. This program is designed to do nothing more than prove that there
is a flaw in the way that IIS handles CGI processes and that the bug is
in fact with IIS and not PHP.
You *CANNOT* break Apache with multiple instances of this CGI code:
__
#include
#include
#include
#include
char *data;
double count;
int main(void)
{
data = getenv("QUERY_STRING");
if(data == NULL)
count=1;
else
count = atof(data);
printf("Content-Type:text/html\n\n");
printf("Loading page with value %f\n",floor(count));
count++;
printf("location.href='breakiis.exe?%f'",count);
return 0;
}
___
I have launched yet another campaign to try and get Microsoft to fix
this problem but honestly I think we'd have better luck just working
out the bugs in php4isapi.dll. Maybe in the year 2025 Microsoft will
get around to fixing this problem.
Ottawa
Previous Comments:
----------------
[2003-03-17 17:49:27] ottawasixtyseven at hotmail dot com
Lewid,
Have you considered trying php4isapi.dll? PHP admits that it's *STILL*
not production quality (how many years has it been ???) but some
people have had great success with it.
I think I may have finally figured out why PHP.EXE spits out those CGI
errors. And why on faster machines it happens more often ... IT'S NOT
THREAD-SAFE !!!
I don't know why this didn't dawn on me earlier. It makes total sense.
The problem occurs when IIS tries to make simultaneous calls to
PHP.EXE. With php4isapi.dll, instead of loading PHP.EXE for each
request, ISAPI uses the thread-safe DLL that's loaded only once. Apache
must handle CGI differently because you NEVER get the CGI error.
We can't use php4isapi.dll with our application because for some reason
it blows up all over the place with server 500 errors. We continue to
pray that the PHP gods will deliver us a rock solid php4isapi.dll.
Until then we deal with the CGI errors and blame it on Bill.
Again, for some reason changing your Performance Options to either
Background services or Applications seems to really make a difference.
Even with this option change frankielam has proven that when opening
multiple instances of his script (see above doit.php) you can generate
CGI errors at will. Try this at home and impress your friends :-)
Please let us know if running php4isapi.dll works for you.
Ottawa
[2003-03-17 07:15:53] lewid at nc dot rr dot com
I am at a loss here - I am a developer for a large company and do not
have a choice as to which web platform I can use - IIS is the tool I
have to work with.
I have been using php on IIS but this growing percentage of CGI errors
on my applications is forcing me to consider using a different
application server, as it does not appear at this time that it will be
resolvable.
Is there ANY hope, or should I just switch to a different application
server, as I do not feel that it is acceptable for my applications to
recieve a significant % of errors.
If anyone has any suggestions please email me - ps - switching to an
open source web server is not an option I can entertain at this time :(
[2003-03-14 18:52:30] [EMAIL PROTECTED]
Friendly suggestion: Stick to OpenSource solutions. :)
---------------
#9852 [Com]: Header redirect and db connection cause "CGI misbehaved"
ID: 9852
Comment by: ottawasixtyseven at hotmail dot com
Reported By: ron dot baldwin at sourceprose dot com
Status: Closed
Bug Type: IIS related
Operating System: Windows 2000
PHP Version: 4.2.1
New Comment:
Lewid,
Have you considered trying php4isapi.dll? PHP admits that it's *STILL*
not production quality (how many years has it been ???) but some
people have had great success with it.
I think I may have finally figured out why PHP.EXE spits out those CGI
errors. And why on faster machines it happens more often ... IT'S NOT
THREAD-SAFE !!!
I don't know why this didn't dawn on me earlier. It makes total sense.
The problem occurs when IIS tries to make simultaneous calls to
PHP.EXE. With php4isapi.dll, instead of loading PHP.EXE for each
request, ISAPI uses the thread-safe DLL that's loaded only once. Apache
must handle CGI differently because you NEVER get the CGI error.
We can't use php4isapi.dll with our application because for some reason
it blows up all over the place with server 500 errors. We continue to
pray that the PHP gods will deliver us a rock solid php4isapi.dll.
Until then we deal with the CGI errors and blame it on Bill.
Again, for some reason changing your Performance Options to either
Background services or Applications seems to really make a difference.
Even with this option change frankielam has proven that when opening
multiple instances of his script (see above doit.php) you can generate
CGI errors at will. Try this at home and impress your friends :-)
Please let us know if running php4isapi.dll works for you.
Ottawa
Previous Comments:
[2003-03-17 07:15:53] lewid at nc dot rr dot com
I am at a loss here - I am a developer for a large company and do not
have a choice as to which web platform I can use - IIS is the tool I
have to work with.
I have been using php on IIS but this growing percentage of CGI errors
on my applications is forcing me to consider using a different
application server, as it does not appear at this time that it will be
resolvable.
Is there ANY hope, or should I just switch to a different application
server, as I do not feel that it is acceptable for my applications to
recieve a significant % of errors.
If anyone has any suggestions please email me - ps - switching to an
open source web server is not an option I can entertain at this time :(
[2003-03-14 18:52:30] [EMAIL PROTECTED]
Friendly suggestion: Stick to OpenSource solutions. :)
----
[2003-03-14 12:53:39] ottawasixtyseven at hotmail dot com
frankielam,
You've hit the nail on the head. It's a problem with IIS. This DOES NOT
HAPPEN *EVER* with Apache. IIS is not able to handle multiple
simultaneous calls to php.exe.
The question is now ... how the hell do we get Micro$haft to fix this?
They are about as responsive to bugs likes this ... as a brick wall! I
wish this was a PHP error because the lads at PHP are usually quite
responsive to bugs.
Anybody have any suggestions on how to get Bill to listen? I've tried
calling support, posting messages, no luck. We have switched all our
servers over to RedHat and the ones that MUST remain Windoze are
running Apache Web server.
It still should be noted that changing the Performance options can
greatly reduce the occurence of the CGI error. Unfortunately, it does
not eliminate it.
Ottawa
[2003-03-05 20:32:01] frankielam at ucr dot com dot hk
I can reproduce the error with the php script below(a simple script
that do nothing but keeps refreshing itself with a different value of
parameter passed into it as GET, REMEMBER to open serveral instances to
run it.). IMHO, this is not a database problem(neither mysql nor
mssql), and this might be a problem that IIS cannot handle sucha high
frequent call to `php.exe', and it does assume that php.exe returns
nothing!! (Am I right? :-D)
doit.php
8<---
testing";
if (isset($_GET["times"]))
$times = ($_GET["times"]) + 1;
else
$times = 0;
//SEE??? even i comment the statement out, infamous cgi error occurs,
STILL!
//$conn = mssql_connect('127.0.0.1', 'sa', '') or die("couldn't
connect");
echo "";
echo "Trying CGI";
echo "$times";
//header("doit.php");
?>
8<---
My config.:
Windows 2000 Advanced Server with SP3
PHP 4.3.1 / 4.2.3 (both tested to have CGI problem)
MSSQL Server 2000
[2003-03-03 17:23:06] gkasten at filnet dot fr
#9852 [Com]: Header redirect and db connection cause "CGI misbehaved"
ID: 9852
Comment by: ottawasixtyseven at hotmail dot com
Reported By: ron dot baldwin at sourceprose dot com
Status: Closed
Bug Type: IIS related
Operating System: Windows 2000
PHP Version: 4.2.1
New Comment:
frankielam,
You've hit the nail on the head. It's a problem with IIS. This DOES NOT
HAPPEN *EVER* with Apache. IIS is not able to handle multiple
simultaneous calls to php.exe.
The question is now ... how the hell do we get Micro$haft to fix this?
They are about as responsive to bugs likes this ... as a brick wall! I
wish this was a PHP error because the lads at PHP are usually quite
responsive to bugs.
Anybody have any suggestions on how to get Bill to listen? I've tried
calling support, posting messages, no luck. We have switched all our
servers over to RedHat and the ones that MUST remain Windoze are
running Apache Web server.
It still should be noted that changing the Performance options can
greatly reduce the occurence of the CGI error. Unfortunately, it does
not eliminate it.
Ottawa
Previous Comments:
[2003-03-05 20:32:01] frankielam at ucr dot com dot hk
I can reproduce the error with the php script below(a simple script
that do nothing but keeps refreshing itself with a different value of
parameter passed into it as GET, REMEMBER to open serveral instances to
run it.). IMHO, this is not a database problem(neither mysql nor
mssql), and this might be a problem that IIS cannot handle sucha high
frequent call to `php.exe', and it does assume that php.exe returns
nothing!! (Am I right? :-D)
doit.php
8<---
testing";
if (isset($_GET["times"]))
$times = ($_GET["times"]) + 1;
else
$times = 0;
//SEE??? even i comment the statement out, infamous cgi error occurs,
STILL!
//$conn = mssql_connect('127.0.0.1', 'sa', '') or die("couldn't
connect");
echo "";
echo "Trying CGI";
echo "$times";
//header("doit.php");
?>
8<---
My config.:
Windows 2000 Advanced Server with SP3
PHP 4.3.1 / 4.2.3 (both tested to have CGI problem)
MSSQL Server 2000
[2003-03-03 17:23:06] gkasten at filnet dot fr
http://support.microsoft.com/default.aspx?scid=kb;en-us;151825
http://bugs.php.net/bug.php?id=9852
Hello bugbrowsers (same comment as 12700, but this thread is better),
I tried too unsuccessfully : -background perf -mdac -admin and various
other commented things above, on IIS w2kSrv & NT4 , php 4.*<=4.3.1 :-(
I had the problem on /phpmyadmin subdir, protected by ACLs.
And only with far-tracerouted client machines.
* I SUCCEEDED with unchecking "directory-security /
allow-anonymous-access" (which is theorically useless because there is
no IUSR_* in the acls of php pages below).
I hope it can help desperate hostmasters, and php-dev-community to
track this @#%! bug.
Guy Kastenbaum - Paris
[2003-02-18 05:15:56] dragel at elelog dot es
I solve the error replacing:
$q=odbc_do($conex,"selec");
for a calling to a function:
function ODBC($conex,$sql){
return odbc_do($conex,$sql);
}
...
$q=ODBC($conex,"select ...");
the use of a function make spend time and solve the problem. It works
for me!
[2003-01-28 05:11:57] mlaukast1 at hotmail dot com
There's an interesting solution to 502 CGI Error in bug report #21681
by [EMAIL PROTECTED] Altough I wasn't able to get rid of the error
entirely, the solution dramatically reduced the appearance of it.
[2003-01-12 15:16:09] theo dot schoeberl at tssystems dot de
We have chanced our PHP-Script from using ODBC to native MSSQL (using
the MSSQL library). The same error (incl. 502 Bad Gateway).
The next try was to change the server name to its IP address within the
connect statement - and it works!
No error since the change, running now over 14 days!
May be there is a problem (known under Windows systems) resolving the
server name?
Hope this helps a lot of PHP developers running Windows systems!
Theo
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/9852
--
Edit this bug report at http://bugs.php.net/?id=9852&edit=1
#9862 [Com]: fopen of http://user:pass@domain:port/file.html failed with Bad file descriptor
ID: 9862
Comment by: ottawasixtyseven at hotmail dot com
Reported By: stenzel at hnm dot de
Status: Closed
Bug Type: Filesystem function related
Operating System: redhat 7.0/apache 1.3.19
PHP Version: 4.0.4pl1
New Comment:
Fixed in latest snapshot. Thank you.
Ottawa
Previous Comments:
[2003-03-03 13:11:21] ottawasixtyseven at hotmail dot com
Hi,
This is still a problem. It appears to be random. Certain combinations
of letters and numbers within the URL will cause the fopen() to fail.
This bug still exists in PHP 4.3
Please re-open this bug.
Thanks,
Ottawa
[2001-04-19 09:38:01] [EMAIL PROTECTED]
No feedback. If problem still perists with soon to be released 4.0.5,
reopen this bug report.
--Jani
[2001-03-20 08:17:16] [EMAIL PROTECTED]
Works for me with latest CVS. Please try the latest CVS snapshot from
http://snaps.php.net/
--Jani
[2001-03-20 05:46:03] stenzel at hnm dot de
$file = "http://user:[EMAIL PROTECTED]:/file.html";
$fh = fopen($file, "r");
while(! feof($fh)) {
...
}
this script fails with the following error:
Warning:
fopen("http://[EMAIL PROTECTED]:/file.html","r")
- Bad file descriptor in ... on line 2
this script runs with php 4.0.3pl1 and $file =
"http://user:[EMAIL PROTECTED]/file.html" works too on php 4.0.4pl1,
but I need the port in combination with a user and password!!
--
Edit this bug report at http://bugs.php.net/?id=9862&edit=1
#10110 [Com]: Problem with fopen() - Bad file descriptor
ID: 10110
Comment by: ottawasixtyseven at hotmail dot com
Reported By: senser at email dot si
Status: Closed
Bug Type: *Directory/Filesystem functions
Operating System: Linux
PHP Version: 4.0.4pl1
New Comment:
Fixed in latest snapshot. Thank you.
Ottawa
Previous Comments:
[2003-03-05 09:33:07] ottawasixtyseven at hotmail dot com
Note: This bug still exists in ALL versions of PHP right up to 4.3.1
and the snapshots.
Ottawa
[2001-04-02 18:28:09] [EMAIL PROTECTED]
This should be fixed in CVS. Try latest CVS snapshot from
http://snaps.php.net/
Reopen this bug report if problem still exists with latest CVS
snapshot.
(I tried your script and it worked just fine)
--Jani
[2001-04-02 07:26:48] senser at email dot si
I have used and tested a script on linux machine with an apache
webserver and php4 installed, i got error of a bad file desctiptor in
the fopen statement:
The code i used is:
$page="http://www.feri.uni-mb.si/";;
$fp=fopen($page,"r") or die("Error");
when the url was http://www.senser.f2s.com/welcome.html";
(my website)
everthing worked fine!
Ales!
--
Edit this bug report at http://bugs.php.net/?id=10110&edit=1
#22579 [Opn]: fopen() number in URL = Bad file descriptor
ID: 22579 User updated by: ottawasixtyseven at hotmail dot com Reported By: ottawasixtyseven at hotmail dot com Status: Open Bug Type: Filesystem function related Operating System: ALL PHP Version: 4.3.0 New Comment: Fixed in latest snapshot. Thank you. Ottawa Previous Comments: [2003-03-11 22:01:04] ottawasixtyseven at hotmail dot com OK. Just wanted to let you know we're trying to test the latest snapshot to see if it fixes the fopen problem. I guess we'll have to weed out the odbc parts. [2003-03-11 12:49:15] [EMAIL PROTECTED] I can't get our application running on the latest snapshot. I can run phpinfo() but when I try to $DB = odbc_connect I get errors. More specifically, when I first echo $DB I get "Resource id #3" when echo it again I get "FATAL: erealloc(): Unable to allocate 1331643757 bytes" I have tried installing the latest snapshot on three separate servers. Two that were already running PHP 4.3 and one clean server. I'm not able to test if the latest snapshot has fixed the fopen() bug. Any ideas why my odbc_connect is failing? What does odbc have to do with fopen() problem? Test with separate script which doesn't have odbc stuff in it.. And the odbc problem, open a new report about that one. -------- [2003-03-06 20:50:16] ottawasixtyseven at hotmail dot com This bug has been reported a few times but keeps getting closed. It is still a problem in PHP 4.3.0 Also see closed bug http://bugs.php.net/bug.php?id=9862 There is a serious problem with fopen when there are numbers in the URL: http://www.xxx.com:8080/some.php?Origin=a&DocNum=1 Result: Warning: fopen() [function.fopen]: php_hostconnect: connect failed in C:\phpfiles\some.php on line 150 Warning: fopen(http://www.xxx.com:8080/some.php?Origin=a&DocNum=1) [function.fopen]: failed to create stream: Bad file descriptor in C:\phpfiles\some.php on line 150 Remove the port number in the URL and it works fine: http://www.xxx.com/some.php?Origin=a&DocNum=1 This seems to be a random bug that occurs on some machines and not others. We can reproduce it 100% of the time if someone wants to check on our server. Please don't just test this on one machine and report back that it works for you. There is something wrong here and we really need to get to the bottom of it. It's not a redirection problem. Thanks. Keep up the great work! Ottawa -- Edit this bug report at http://bugs.php.net/?id=22579&edit=1
#22649 [Opn]: odbc_connect FATAL: erealloc()
ID: 22649
User updated by: ottawasixtyseven at hotmail dot com
Reported By: ottawasixtyseven at hotmail dot com
Status: Open
Bug Type: ODBC related
Operating System: Windows
PHP Version: 4CVS-2003-03-11 (stable)
New Comment:
This is fixed in the latest 4.3 snapshot March 12 2003.
Thank you for the quick response.
Ottawa
Previous Comments:
[2003-03-12 07:38:15] ottawasixtyseven at hotmail dot com
My programmers said my description was note quite accurate. Here is the
programmers version of our problem:
I can't get our application running on the latest snapshot. I can run
phpinfo() but when I try to use
$DB = odbc_connect ( 'database', '', ''); and then try to create a
table I get errors:
include('common.php'); // this include has
$DB = odbc_connect ('dsn' ,'', '');
i do an echo of $DB in common.php and get Resource id #3
then in the main script.
echo "THE VALUE OF THE DB IS : $DB";
$SQL = "CREATE TABLE $TableName ($TableColumns)";
if ( !odbc_exec ( $DB, $SQL ) )
{
echo "FAILURE OF '$SQL' !\n";
$Errors++;
}
else
{
echo "OK! \n";
}
when i echo $DB again just before the odbc_exec I get:
"FATAL: erealloc(): Unable to allocate 1331643757 bytes"
I have tried installing the latest snapshot on three separate servers.
Two that were already running PHP 4.3 and one clean server.
this code works on all other versions of php except the latest
snapshot.
Ottawa
[2003-03-11 22:17:20] ottawasixtyseven at hotmail dot com
I can't get our application running on the latest snapshot. I can run
phpinfo() but when I try to use $DB = odbc_connect ( 'database', '',
'' ); and then try to create a table I get errors:
echo "THE VALUE OF THE DB IS : $DB";
$SQL = "CREATE TABLE $TableName ($TableColumns)";
if ( !odbc_exec ( $DB, $SQL ) )
{
echo "FAILURE OF '$SQL' !\n";
$Errors++;
}
else
{
echo "OK! \n";
}
For the first echo statement above I get "Resource id #3"
When I try to create the table I get:
"FATAL: erealloc(): Unable to allocate 1331643757 bytes"
I have tried installing the latest snapshot on three separate servers.
Two that were already running PHP 4.3 and one clean server.
Ottawa
--
Edit this bug report at http://bugs.php.net/?id=22649&edit=1
#22649 [Opn]: odbc_connect FATAL: erealloc()
ID: 22649
User updated by: ottawasixtyseven at hotmail dot com
Reported By: ottawasixtyseven at hotmail dot com
Status: Open
Bug Type: ODBC related
Operating System: Windows
PHP Version: 4CVS-2003-03-11 (stable)
New Comment:
My programmers said my description was note quite accurate. Here is the
programmers version of our problem:
I can't get our application running on the latest snapshot. I can run
phpinfo() but when I try to use
$DB = odbc_connect ( 'database', '', ''); and then try to create a
table I get errors:
include('common.php'); // this include has
$DB = odbc_connect ('dsn' ,'', '');
i do an echo of $DB in common.php and get Resource id #3
then in the main script.
echo "THE VALUE OF THE DB IS : $DB";
$SQL = "CREATE TABLE $TableName ($TableColumns)";
if ( !odbc_exec ( $DB, $SQL ) )
{
echo "FAILURE OF '$SQL' !\n";
$Errors++;
}
else
{
echo "OK! \n";
}
when i echo $DB again just before the odbc_exec I get:
"FATAL: erealloc(): Unable to allocate 1331643757 bytes"
I have tried installing the latest snapshot on three separate servers.
Two that were already running PHP 4.3 and one clean server.
this code works on all other versions of php except the latest
snapshot.
Ottawa
Previous Comments:
[2003-03-11 22:17:20] ottawasixtyseven at hotmail dot com
I can't get our application running on the latest snapshot. I can run
phpinfo() but when I try to use $DB = odbc_connect ( 'database', '',
'' ); and then try to create a table I get errors:
echo "THE VALUE OF THE DB IS : $DB";
$SQL = "CREATE TABLE $TableName ($TableColumns)";
if ( !odbc_exec ( $DB, $SQL ) )
{
echo "FAILURE OF '$SQL' !\n";
$Errors++;
}
else
{
echo "OK! \n";
}
For the first echo statement above I get "Resource id #3"
When I try to create the table I get:
"FATAL: erealloc(): Unable to allocate 1331643757 bytes"
I have tried installing the latest snapshot on three separate servers.
Two that were already running PHP 4.3 and one clean server.
Ottawa
--
Edit this bug report at http://bugs.php.net/?id=22649&edit=1
#22649 [NEW]: odbc_connect FATAL: erealloc()
From: ottawasixtyseven at hotmail dot com
Operating system: Windows
PHP version: 4CVS-2003-03-11 (stable)
PHP Bug Type: ODBC related
Bug description: odbc_connect FATAL: erealloc()
I can't get our application running on the latest snapshot. I can run
phpinfo() but when I try to use $DB = odbc_connect ( 'database', '', ''
); and then try to create a table I get errors:
echo "THE VALUE OF THE DB IS : $DB";
$SQL = "CREATE TABLE $TableName ($TableColumns)";
if ( !odbc_exec ( $DB, $SQL ) )
{
echo "FAILURE OF '$SQL' !\n";
$Errors++;
}
else
{
echo "OK! \n";
}
For the first echo statement above I get "Resource id #3"
When I try to create the table I get:
"FATAL: erealloc(): Unable to allocate 1331643757 bytes"
I have tried installing the latest snapshot on three separate servers. Two
that were already running PHP 4.3 and one clean server.
Ottawa
--
Edit bug report at http://bugs.php.net/?id=22649&edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=22649&r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=22649&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=22649&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=22649&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=22649&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=22649&r=support
Expected behavior: http://bugs.php.net/fix.php?id=22649&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=22649&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=22649&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=22649&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=22649&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=22649&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=22649&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=22649&r=gnused
#22579 [Fbk->Opn]: fopen() number in URL = Bad file descriptor
ID: 22579 User updated by: ottawasixtyseven at hotmail dot com Reported By: ottawasixtyseven at hotmail dot com -Status: Feedback +Status: Open Bug Type: Filesystem function related Operating System: ALL PHP Version: 4.3.0 New Comment: OK. Just wanted to let you know we're trying to test the latest snapshot to see if it fixes the fopen problem. I guess we'll have to weed out the odbc parts. Previous Comments: [2003-03-11 12:49:15] [EMAIL PROTECTED] I can't get our application running on the latest snapshot. I can run phpinfo() but when I try to $DB = odbc_connect I get errors. More specifically, when I first echo $DB I get "Resource id #3" when echo it again I get "FATAL: erealloc(): Unable to allocate 1331643757 bytes" I have tried installing the latest snapshot on three separate servers. Two that were already running PHP 4.3 and one clean server. I'm not able to test if the latest snapshot has fixed the fopen() bug. Any ideas why my odbc_connect is failing? What does odbc have to do with fopen() problem? Test with separate script which doesn't have odbc stuff in it.. And the odbc problem, open a new report about that one. -------- [2003-03-06 20:50:16] ottawasixtyseven at hotmail dot com This bug has been reported a few times but keeps getting closed. It is still a problem in PHP 4.3.0 Also see closed bug http://bugs.php.net/bug.php?id=9862 There is a serious problem with fopen when there are numbers in the URL: http://www.xxx.com:8080/some.php?Origin=a&DocNum=1 Result: Warning: fopen() [function.fopen]: php_hostconnect: connect failed in C:\phpfiles\some.php on line 150 Warning: fopen(http://www.xxx.com:8080/some.php?Origin=a&DocNum=1) [function.fopen]: failed to create stream: Bad file descriptor in C:\phpfiles\some.php on line 150 Remove the port number in the URL and it works fine: http://www.xxx.com/some.php?Origin=a&DocNum=1 This seems to be a random bug that occurs on some machines and not others. We can reproduce it 100% of the time if someone wants to check on our server. Please don't just test this on one machine and report back that it works for you. There is something wrong here and we really need to get to the bottom of it. It's not a redirection problem. Thanks. Keep up the great work! Ottawa -- Edit this bug report at http://bugs.php.net/?id=22579&edit=1
#22579 [Fbk->Opn]: fopen() number in URL = Bad file descriptor
ID: 22579 User updated by: ottawasixtyseven at hotmail dot com Reported By: ottawasixtyseven at hotmail dot com -Status: Feedback +Status: Open Bug Type: Filesystem function related Operating System: ALL PHP Version: 4.3.0 New Comment: I can't get our application running on the latest snapshot. I can run phpinfo() but when I try to $DB = odbc_connect I get errors. More specifically, when I first echo $DB I get "Resource id #3" when echo it again I get "FATAL: erealloc(): Unable to allocate 1331643757 bytes" I have tried installing the latest snapshot on three separate servers. Two that were already running PHP 4.3 and one clean server. I'm not able to test if the latest snapshot has fixed the fopen() bug. Any ideas why my odbc_connect is failing? Ottawa Previous Comments: [2003-03-06 22:22:26] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip ---- [2003-03-06 20:50:16] ottawasixtyseven at hotmail dot com This bug has been reported a few times but keeps getting closed. It is still a problem in PHP 4.3.0 Also see closed bug http://bugs.php.net/bug.php?id=9862 There is a serious problem with fopen when there are numbers in the URL: http://www.xxx.com:8080/some.php?Origin=a&DocNum=1 Result: Warning: fopen() [function.fopen]: php_hostconnect: connect failed in C:\phpfiles\some.php on line 150 Warning: fopen(http://www.xxx.com:8080/some.php?Origin=a&DocNum=1) [function.fopen]: failed to create stream: Bad file descriptor in C:\phpfiles\some.php on line 150 Remove the port number in the URL and it works fine: http://www.xxx.com/some.php?Origin=a&DocNum=1 This seems to be a random bug that occurs on some machines and not others. We can reproduce it 100% of the time if someone wants to check on our server. Please don't just test this on one machine and report back that it works for you. There is something wrong here and we really need to get to the bottom of it. It's not a redirection problem. Thanks. Keep up the great work! Ottawa -- Edit this bug report at http://bugs.php.net/?id=22579&edit=1
#22579 [NEW]: fopen() number in URL = Bad file descriptor
From: ottawasixtyseven at hotmail dot com Operating system: ALL PHP version: 4.3.0 PHP Bug Type: Filesystem function related Bug description: fopen() number in URL = Bad file descriptor This bug has been reported a few times but keeps getting closed. It is still a problem in PHP 4.3.0 Also see closed bug http://bugs.php.net/bug.php?id=9862 There is a serious problem with fopen when there are numbers in the URL: http://www.xxx.com:8080/some.php?Origin=a&DocNum=1 Result: Warning: fopen() [function.fopen]: php_hostconnect: connect failed in C:\phpfiles\some.php on line 150 Warning: fopen(http://www.xxx.com:8080/some.php?Origin=a&DocNum=1) [function.fopen]: failed to create stream: Bad file descriptor in C:\phpfiles\some.php on line 150 Remove the port number in the URL and it works fine: http://www.xxx.com/some.php?Origin=a&DocNum=1 This seems to be a random bug that occurs on some machines and not others. We can reproduce it 100% of the time if someone wants to check on our server. Please don't just test this on one machine and report back that it works for you. There is something wrong here and we really need to get to the bottom of it. It's not a redirection problem. Thanks. Keep up the great work! Ottawa -- Edit bug report at http://bugs.php.net/?id=22579&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=22579&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=22579&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=22579&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=22579&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=22579&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=22579&r=support Expected behavior: http://bugs.php.net/fix.php?id=22579&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=22579&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=22579&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=22579&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=22579&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=22579&r=dst IIS Stability: http://bugs.php.net/fix.php?id=22579&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=22579&r=gnused
#10110 [Com]: Problem with fopen() - Bad file descriptor
ID: 10110
Comment by: ottawasixtyseven at hotmail dot com
Reported By: senser at email dot si
Status: Closed
Bug Type: *Directory/Filesystem functions
Operating System: Linux
PHP Version: 4.0.4pl1
New Comment:
Note: This bug still exists in ALL versions of PHP right up to 4.3.1
and the snapshots.
Ottawa
Previous Comments:
[2003-03-05 09:31:17] ottawasixtyseven at hotmail dot com
PLEASE RE-OPEN THIS BUG REPORT.
THE PROBLEM WITH THE FOPEN() IS THAT IT'S RANDOM. CERTAIN SEQUENCES OF
CHARACTERS IN THE URL CAUSE IT TO FAIL. SIMPLY TESTING ON ONE OR TWO
MACHINES IS NOT SUFFICIENT!!!
THE SIMPLE FACT THAT A DIFFERENT URL CAUSES EVERYTHING TO EITHER WORK
FINE OR FAIL PROVES THIS.
PLEASE RE-OPEN THIS BUG REPORT.
Ottawa
[2001-04-02 18:28:09] [EMAIL PROTECTED]
This should be fixed in CVS. Try latest CVS snapshot from
http://snaps.php.net/
Reopen this bug report if problem still exists with latest CVS
snapshot.
(I tried your script and it worked just fine)
--Jani
[2001-04-02 07:26:48] senser at email dot si
I have used and tested a script on linux machine with an apache
webserver and php4 installed, i got error of a bad file desctiptor in
the fopen statement:
The code i used is:
$page="http://www.feri.uni-mb.si/";;
$fp=fopen($page,"r") or die("Error");
when the url was http://www.senser.f2s.com/welcome.html";
(my website)
everthing worked fine!
Ales!
--
Edit this bug report at http://bugs.php.net/?id=10110&edit=1
#10110 [Com]: Problem with fopen() - Bad file descriptor
ID: 10110
Comment by: ottawasixtyseven at hotmail dot com
Reported By: senser at email dot si
Status: Closed
Bug Type: *Directory/Filesystem functions
Operating System: Linux
PHP Version: 4.0.4pl1
New Comment:
PLEASE RE-OPEN THIS BUG REPORT.
THE PROBLEM WITH THE FOPEN() IS THAT IT'S RANDOM. CERTAIN SEQUENCES OF
CHARACTERS IN THE URL CAUSE IT TO FAIL. SIMPLY TESTING ON ONE OR TWO
MACHINES IS NOT SUFFICIENT!!!
THE SIMPLE FACT THAT A DIFFERENT URL CAUSES EVERYTHING TO EITHER WORK
FINE OR FAIL PROVES THIS.
PLEASE RE-OPEN THIS BUG REPORT.
Ottawa
Previous Comments:
[2001-04-02 18:28:09] [EMAIL PROTECTED]
This should be fixed in CVS. Try latest CVS snapshot from
http://snaps.php.net/
Reopen this bug report if problem still exists with latest CVS
snapshot.
(I tried your script and it worked just fine)
--Jani
[2001-04-02 07:26:48] senser at email dot si
I have used and tested a script on linux machine with an apache
webserver and php4 installed, i got error of a bad file desctiptor in
the fopen statement:
The code i used is:
$page="http://www.feri.uni-mb.si/";;
$fp=fopen($page,"r") or die("Error");
when the url was http://www.senser.f2s.com/welcome.html";
(my website)
everthing worked fine!
Ales!
--
Edit this bug report at http://bugs.php.net/?id=10110&edit=1
#9862 [Com]: fopen of http://user:pass@domain:port/file.html failed with Bad file descriptor
ID: 9862
Comment by: ottawasixtyseven at hotmail dot com
Reported By: stenzel at hnm dot de
Status: Closed
Bug Type: Filesystem function related
Operating System: redhat 7.0/apache 1.3.19
PHP Version: 4.0.4pl1
New Comment:
Hi,
This is still a problem. It appears to be random. Certain combinations
of letters and numbers within the URL will cause the fopen() to fail.
This bug still exists in PHP 4.3
Please re-open this bug.
Thanks,
Ottawa
Previous Comments:
[2001-04-19 09:38:01] [EMAIL PROTECTED]
No feedback. If problem still perists with soon to be released 4.0.5,
reopen this bug report.
--Jani
[2001-03-20 08:17:16] [EMAIL PROTECTED]
Works for me with latest CVS. Please try the latest CVS snapshot from
http://snaps.php.net/
--Jani
[2001-03-20 05:46:03] stenzel at hnm dot de
$file = "http://user:[EMAIL PROTECTED]:/file.html";
$fh = fopen($file, "r");
while(! feof($fh)) {
...
}
this script fails with the following error:
Warning:
fopen("http://[EMAIL PROTECTED]:/file.html","r")
- Bad file descriptor in ... on line 2
this script runs with php 4.0.3pl1 and $file =
"http://user:[EMAIL PROTECTED]/file.html" works too on php 4.0.4pl1,
but I need the port in combination with a user and password!!
--
Edit this bug report at http://bugs.php.net/?id=9862&edit=1
