#21513 [Com]: shutdown functions not executed if timed out
ID: 21513
Comment by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Feedback
Bug Type: Scripting Engine problem
Operating System: WinXP
PHP Version: 4.3.0
New Comment:
[EMAIL PROTECTED]:
This script works just fine for me (using CLI):
[skipped]
I tested your script. The output is:
PHP Fatal error: Maximum execution time of 1 second exceeded in
c:\exp.php on line 16
PHP Fatal error: Maximum execution time of 1 second exceeded in
c:\exp.php on line 7
test.log contains only one Start line.
I tried with both my own (pretty much cleaned up) php.ini and
recommended php.ini.
I suspect it is only Windows-related problem.
Previous Comments:
[2003-01-20 22:47:06] [EMAIL PROTECTED]
And this is related to http://bugs.php.net/bug.php?id=14542
(and maybe to http://bugs.php.net/bug.php?id=14251 ?)
[2003-01-20 22:44:38] [EMAIL PROTECTED]
This script works just fine for me (using CLI):
?php
error_log (Start\n, 3, test.log);
function boo()
{
error_log (Shutdown - function 'foo'\n, 3, test.log);
}
register_shutdown_function(boo);
/* not necessary, just to show the error sooner */
set_time_limit(1);
/* infinite loop to simulate long processing */
for (;;) {}
error_log (\nEnd\n, 3, test.log);
?
In test.log I have now:
cut
Start
Shutdown - function 'foo'
cut
Which is the expected output.
Can you try this script?
[2003-01-08 02:53:17] [EMAIL PROTECTED]
This problem is absolutely critical if you do DB cleanups, transactions
processing or other similar things in shutdown functions. Can be
especially bad if you need to commit/rollback transactions with
persistent DB connections.
--
?php
function boo()
{
...do_anything...; // never ever gets called
}
register_shutdown_function(boo);
set_time_limit(3); // not necessary, just to show the error sooner
for (;;) { // infinite loop to simulate long processing
}
?
--
Error message:
Fatal error: Maximum execution time of 3 seconds exceeded in c:\exp.php
on line 10
Fatal error: Maximum execution time of 3 seconds exceeded in c:\exp.php
on line 4
Does not depend on whether we run script as CGI/SAPI or CLI.
Report #14542 looks similar but is different IMHO.
--
Edit this bug report at http://bugs.php.net/?id=21513edit=1
#21808 [Bgs-Opn]: autoglobals won't work with a custom error page
ID: 21808 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Bogus +Status: Open Bug Type: Scripting Engine problem Operating System: linux apache 2.0.43 PHP Version: 4.3.0 New Comment: I have in httpd.conf Alias /_autofiles/error.html /home/apache/errors/404.html ErrorDocument 404 /errors/404.html when i do http://test.lan/errors/404.html?test=abc it will show up in de $_GET and in de $_REQUEST when i do http://test.lan/nonexistentpage.html?test=abc it won't show up in $_GET OR in $_REQUEST However it will be in $_SERVER[REDIRECT_QUERY_STRING] and $_SERVER[REQUEST_URI] Gr, Wico Previous Comments: [2003-01-21 23:36:28] [EMAIL PROTECTED] Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Thank you for your interest in PHP. This is normla behaviour wit Apache. Please read this: http://httpd.apache.org/docs/custom-error.html Not a bug. [2003-01-21 18:57:22] [EMAIL PROTECTED] Please provide the following pieces of information: 1) A link to a phpinfo(); page on your server. 2) The relevant source of the script which calls your error page. (i.e.: header(Location: myerrorpage.php?arg=my+error+message); ) 3) The source to your error page. [2003-01-21 16:01:02] [EMAIL PROTECTED] Hiya When i have an error page with php but requesting the error page with an argument it won't show up in the scrip as $_REQUEST['arg'] or something The arg is however in the $_SERVER[REDIRECT_QUERY_STRING] AND in the $_SERVER[REQUEST_URI] Gr, Wico -- Edit this bug report at http://bugs.php.net/?id=21808edit=1
#21808 [Opn]: autoglobals won't work with a custom error page
ID: 21808 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Scripting Engine problem Operating System: linux apache 2.0.43 PHP Version: 4.3.0 New Comment: ofcourse is in httpd.conf Alias /errors/404.html /home/apache/errors/404.html ErrorDocument 404 /errors/404.html Previous Comments: [2003-01-22 03:17:40] [EMAIL PROTECTED] I have in httpd.conf Alias /_autofiles/error.html /home/apache/errors/404.html ErrorDocument 404 /errors/404.html when i do http://test.lan/errors/404.html?test=abc it will show up in de $_GET and in de $_REQUEST when i do http://test.lan/nonexistentpage.html?test=abc it won't show up in $_GET OR in $_REQUEST However it will be in $_SERVER[REDIRECT_QUERY_STRING] and $_SERVER[REQUEST_URI] Gr, Wico [2003-01-21 23:36:28] [EMAIL PROTECTED] Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Thank you for your interest in PHP. This is normla behaviour wit Apache. Please read this: http://httpd.apache.org/docs/custom-error.html Not a bug. [2003-01-21 18:57:22] [EMAIL PROTECTED] Please provide the following pieces of information: 1) A link to a phpinfo(); page on your server. 2) The relevant source of the script which calls your error page. (i.e.: header(Location: myerrorpage.php?arg=my+error+message); ) 3) The source to your error page. [2003-01-21 16:01:02] [EMAIL PROTECTED] Hiya When i have an error page with php but requesting the error page with an argument it won't show up in the scrip as $_REQUEST['arg'] or something The arg is however in the $_SERVER[REDIRECT_QUERY_STRING] AND in the $_SERVER[REQUEST_URI] Gr, Wico -- Edit this bug report at http://bugs.php.net/?id=21808edit=1
#21808 [Opn-Bgs]: autoglobals won't work with a custom error page
ID: 21808 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Scripting Engine problem Operating System: linux apache 2.0.43 PHP Version: 4.3.0 New Comment: Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php Exactly as it should behave - not a bug. Precies zoals het zou moeten werken - geen bug. Derick Previous Comments: [2003-01-22 03:19:43] [EMAIL PROTECTED] ofcourse is in httpd.conf Alias /errors/404.html /home/apache/errors/404.html ErrorDocument 404 /errors/404.html [2003-01-22 03:17:40] [EMAIL PROTECTED] I have in httpd.conf Alias /_autofiles/error.html /home/apache/errors/404.html ErrorDocument 404 /errors/404.html when i do http://test.lan/errors/404.html?test=abc it will show up in de $_GET and in de $_REQUEST when i do http://test.lan/nonexistentpage.html?test=abc it won't show up in $_GET OR in $_REQUEST However it will be in $_SERVER[REDIRECT_QUERY_STRING] and $_SERVER[REQUEST_URI] Gr, Wico [2003-01-21 23:36:28] [EMAIL PROTECTED] Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Thank you for your interest in PHP. This is normla behaviour wit Apache. Please read this: http://httpd.apache.org/docs/custom-error.html Not a bug. [2003-01-21 18:57:22] [EMAIL PROTECTED] Please provide the following pieces of information: 1) A link to a phpinfo(); page on your server. 2) The relevant source of the script which calls your error page. (i.e.: header(Location: myerrorpage.php?arg=my+error+message); ) 3) The source to your error page. [2003-01-21 16:01:02] [EMAIL PROTECTED] Hiya When i have an error page with php but requesting the error page with an argument it won't show up in the scrip as $_REQUEST['arg'] or something The arg is however in the $_SERVER[REDIRECT_QUERY_STRING] AND in the $_SERVER[REQUEST_URI] Gr, Wico -- Edit this bug report at http://bugs.php.net/?id=21808edit=1
#21814 [NEW]: false array keys
From: [EMAIL PROTECTED] Operating system: linux PHP version: 4CVS-2003-01-22 (stable) PHP Bug Type: Scripting Engine problem Bug description: false array keys One can create a key as integer 0 and access it with key boolean false but one cannot create an array with boolean false as the key. In otherwords: $arr = array(false = 'bar'); // array() $arr = array((int)false = 'bar'); // array(0='bar') $arr = array(0 = 'bar'); print $arr[false];// bar print $arr[(int)false]; // bar This seems inconsistent. From the documentation: Using TRUE as a key will evalute to integer 1 as key. Using FALSE as a key will evalute to integer 0 as key. Please explain the reasoning behind the current behavior. -- Edit bug report at http://bugs.php.net/?id=21814edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21814r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21814r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21814r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21814r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21814r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21814r=support Expected behavior: http://bugs.php.net/fix.php?id=21814r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21814r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21814r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21814r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21814r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21814r=dst IIS Stability: http://bugs.php.net/fix.php?id=21814r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=21814r=gnused
#21773 [Opn]: The process is killed after OCIFetch()
ID: 21773
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: OCI8 related
Operating System: Solaris 2.8
PHP Version: 4.3.0
New Comment:
I have tried without @ but the visualization of any errors is not had,
the process falls without leaving anybody trace.
The following version of the script is more complete:
?php
set_time_limit(0);
ini_set('display_errors','0');
ini_set('log_errors','1');
//START
$dbConnection = @OCILogon(USER_ID, PASSWORD, SID);
// infinite loop
$error=0;
do
{
$query=SELECT DATA FROM PROV;
$stmt = @OCIParse($dbConnection,$query);
OCIDefineByName($stmt,DATA,$data);
OCIExecute($stmt);
$err_ora = OCIError($stmt);
if ($err_ora)
{
$error=1;
}
While (OCIFetch($stmt) ($error==0))
{
}
OCIFreeStatement($stmt);
sleep(2);
}while ($error==0);
OCILogoff($dbConnection);
?
Thank for any suggestion
Previous Comments:
[2003-01-21 17:18:05] [EMAIL PROTECTED]
Can you please try without these @ signs? If you don't like the
errors/warnings being displayed on your webpages, you can turn
display_errors off and log_errors on, so you can find the
errors/warnings in your log file.
ini_set('display_errors','0');
ini_set('log_errors','1');
[2003-01-21 03:19:26] [EMAIL PROTECTED]
I don't receive any error or I don't perhaps succeed in capturing it.
[2003-01-20 14:52:10] [EMAIL PROTECTED]
Do you see OCI8 Recursive call! such an error message?
[2003-01-20 10:51:56] [EMAIL PROTECTED]
Before the connection to the db it is present the following statement:
//Set max execution time to infinite
set_time_limit(0);
The loop is stopped when there is an error, in this case the variable
$error=1.
Thanks
[2003-01-20 10:51:54] [EMAIL PROTECTED]
Before the connection to the db it is present the following statement:
//Set max execution time to infinite
set_time_limit(0);
The loop is stopped when there is an error, in this case the variable
$error=1.
Thanks
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/21773
--
Edit this bug report at http://bugs.php.net/?id=21773edit=1
#21815 [NEW]: Buffer loss with fpassthru on popen
From: [EMAIL PROTECTED]
Operating system: Linux 2.4
PHP version: 4.3.0
PHP Bug Type: Filesystem function related
Bug description: Buffer loss with fpassthru on popen
When calling fpassthru() on a file pointer opened with popen(), it fails if
there has been already read from that pointer.
$fp = popen(/bin/ls /, r);
if ($fp) {
$line = fgets($fp, 1024);
print $line;
fpassthru($fp);
}
Results in the following error:
fpassthru(): 77 bytes of buffered data lost during conversion to FILE*!
The same script works fine with php 4.2.3. It also works fine if there
hasn't been read from the file before (i.e. omitting the fgets() line in
above example).
--
Edit bug report at http://bugs.php.net/?id=21815edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=21815r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=21815r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=21815r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=21815r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=21815r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=21815r=support
Expected behavior: http://bugs.php.net/fix.php?id=21815r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=21815r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=21815r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=21815r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21815r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=21815r=dst
IIS Stability: http://bugs.php.net/fix.php?id=21815r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=21815r=gnused
#20884 [Com]: Session file stay forever
ID: 20884 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: Session related Operating System: FreeBSD 4.5 PHP Version: 4.2.3 New Comment: My PHP server has the same problem.PHP version is 4.3.0, apache Version is 2.0.43. Please tell me how to fix it. Thanks! Previous Comments: [2002-12-08 02:40:44] [EMAIL PROTECTED] Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php [2002-12-08 01:27:59] [EMAIL PROTECTED] Here's my conf: [Session] session.save_handler = files session.save_path = /tmp session.use_cookies = 1 session.name = PHPSESSID session.auto_start = 0 session.cookie_lifetime = 0 session.cookie_path = / session.cookie_domain = session.serialize_handler = php session.gc_probability = 1 session.gc_maxlifetime = 1440 session.referer_check = session.entropy_length = 0 session.entropy_file = ;session.entropy_length = 16 ;session.entropy_file = /dev/urandom session.cache_limiter = nocache session.cache_expire = 180 session.use_trans_sid = 1 I start session and even if the user close it's browser, the session file stay forever... It stay there and I have to delete them else I get an hundred of session file created I tested it on my 2 box (Freebsd4.5) and it does that too -- Edit this bug report at http://bugs.php.net/?id=20884edit=1
#21815 [Opn-Asn]: Buffer loss with fpassthru on popen
ID: 21815
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Assigned
Bug Type: Filesystem function related
Operating System: Linux 2.4
PHP Version: 4.3.0
-Assigned To:
+Assigned To: wez
New Comment:
I know what the problem is - assigning to myself
Previous Comments:
[2003-01-22 04:01:43] [EMAIL PROTECTED]
When calling fpassthru() on a file pointer opened with popen(), it
fails if there has been already read from that pointer.
$fp = popen(/bin/ls /, r);
if ($fp) {
$line = fgets($fp, 1024);
print $line;
fpassthru($fp);
}
Results in the following error:
fpassthru(): 77 bytes of buffered data lost during conversion to
FILE*!
The same script works fine with php 4.2.3. It also works fine if there
hasn't been read from the file before (i.e. omitting the fgets() line
in above example).
--
Edit this bug report at http://bugs.php.net/?id=21815edit=1
#21674 [Opn-Fbk]: Warning: main(lang.php) [function.main]: failed to create stream: No such file
ID: 21674
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Feedback
Bug Type: *URL Functions
Operating System: Cobalt RAQ4 Apache/Linux
PHP Version: 4.3.0
New Comment:
Just to be extra sure:
in config.php, do lines 97 and 98 look like this:
var_dump(ini_get('include_path'));
include ('extras.php');
If not, please make sure they do and report back.
If they do, then something really strange is going on.
Previous Comments:
[2003-01-21 22:52:29] [EMAIL PROTECTED]
Hello PHP.NET:
So is this bug a stream related 4.3.0 bug or not?
[2003-01-18 02:31:51] [EMAIL PROTECTED]
Did you try ? :
chown o+r / /home /home/sites \
/home/sites/site2 \
/home/sites/site2/web \
/home/sites/site2/web/IV
Up to 4.2.3 x permission is need on ALL directories to the include.
Since 4.3.0 rx permissions are required.
Don't know why.
Cordialy.
[2003-01-17 15:59:32] [EMAIL PROTECTED]
You did not ask me to place above line that include fails. You asked me
to place above require_once in the config.php file. That I can confirm.
[2003-01-17 14:23:11] [EMAIL PROTECTED]
and can you confirm that the var_dump(ini_get('include_path')) is on
the line immediately above the include that fails?
I'm asking because the line numbers in the report don't seem to have
changed, and I would have expected them to at least have increased by
1.
[2003-01-17 14:11:08] [EMAIL PROTECTED]
OK. At your request, here are my results.
string(14) .:/usr/lib/php string(14) .:/usr/lib/php
Warning: main(lang.php) [function.main]: failed to create stream: No
such file or directory in /home/sites/site2/web/IV/config.php on line
97
Warning: main() [function.main]: Failed opening 'lang.php' for
inclusion (include_path='') in /home/sites/site2/web/IV/config.php on
line 97
Warning: main(extras.php) [function.main]: failed to create stream: No
such file or directory in /home/sites/site2/web/IV/config.php on line
98
Warning: main() [function.main]: Failed opening 'extras.php' for
inclusion (include_path='') in /home/sites/site2/web/IV/config.php on
line 98
Hello - Testing PHP 4.3.0 bug# 21674// End - Copy and Save this code as
phpbug21674.php
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/21674
--
Edit this bug report at http://bugs.php.net/?id=21674edit=1
#19113 [Com]: HTTP status 200 returned on HTTP CONNECT when mod_proxy not in use
ID: 19113 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Apache related Operating System: any PHP Version: 4.3.0 New Comment: It *is* severe because when I see in apache access_log a message like this: 24.153.155.146 - - [22/Jan/2003:01:25:48 +0300] CONNECT maildelivery.somewhere:25 HTTP/1.0 200 44623 - - it is threatening enough for me to put away what I was doing and start staring at my httpd.conf. And that only takes 3-4 hours to just find this bug-report and make myself comfortable about this new PHP feature. Previous Comments: [2003-01-19 04:57:37] [EMAIL PROTECTED] Well can you tell me why it is severe? Okay it is maybe not correct that it reacts on any string but basicly why should it not react on TINTE / HTTP/1.0 This could be a valid request if the server has loaded mod_tinte v1.0 or whatever. If you dislike the feature you can always check for a valid (from your point of view) request method from within your scripts. [2003-01-18 20:33:41] [EMAIL PROTECTED] This problem seems more severe than reported here, at least in 4.1.3 with Apache 1.3.26 shipped with Debian GNU/Linux 3.0.1: If mod_php4 is enabled, any (!) string (try foobar\n\n instead of GET / HTTP/1.0\n\n) will return the home page from $DOCUMENT_ROOT/index.php. If we comment out the LoadModule directive for mod_php4, the server returns correctly 501 method not implemented. Interestingly we couldn't reproduce it on an Apache 1.3.26 with PHP 4.2.2, but this may be because of the tested virtual host is not the first one in the httpd.conf. We noticed this while trying to figure out why the Apache answered to requests like \xe3P (probably trying to exploit some bugs in some webserver) with 200 OK instead of 501 method not implemented. An example: With mod_php4: telnet our_host 80 Trying ###.###.###.###... Connected to our_host. Escape character is '^]'. \xe3P !DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.01 Transitional//EN HTML HEAD TITLEour_host home page/TITLE /HEAD [...] Without mod_php4: telnet our_host 80 Trying ###.###.###.###... Connected to our_host. Escape character is '^]'. \xe3P !DOCTYPE HTML PUBLIC -//IETF//DTD HTML 2.0//EN HTMLHEAD TITLE501 Method Not Implemented/TITLE /HEADBODY H1Method Not Implemented/H1 \xe3P to /index.php not supported.P Invalid method in request \\xe3PP HR ADDRESSApache/1.3.26 Server at our_host Port 80/ADDRESS /BODY/HTML Connection closed by foreign host. Maybe also interessting: A very long string (e.g. 80.000 characters) correctly leads to an error 414 Request-URI Too Large, equal if mod_php4 is loaded or not. This looks like mod_php4 handles any possible request method, which is passed to it. Is this really the wanted behaviour? Why should PHP change Apache's behaviour in such cases? [2003-01-05 07:41:37] [EMAIL PROTECTED] Verified in Apache 1.3.27/Linux/PHP 4.3.0 [2003-01-04 16:48:32] [EMAIL PROTECTED] Yes; [EMAIL PROTECTED] is correct. My previous comment (bug possibly fixed) was in haste. The problem still exists in 4.3.0. Please, someone in the PHP crew investigate this fully, as it's becoming more and more of an issue and seems to be affecting essentially everyone who uses PHP and Apache. [2003-01-03 23:39:16] [EMAIL PROTECTED] Problem still exists in PHP 4.3.0, i'm running Apache 1.3.27 on FreeBSD. 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/19113 -- Edit this bug report at http://bugs.php.net/?id=19113edit=1
#21773 [Opn-Csd]: The process is killed after OCIFetch()
ID: 21773
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Closed
Bug Type: OCI8 related
Operating System: Solaris 2.8
PHP Version: 4.3.0
New Comment:
The error has been found, the function OCIFetch() is not responsible
but the function echo in the cycle while it causes an error from the
moment that after the run of the
script the shell is closed.
Thank you and sorry for all.
Previous Comments:
[2003-01-22 03:44:10] [EMAIL PROTECTED]
I have tried without @ but the visualization of any errors is not had,
the process falls without leaving anybody trace.
The following version of the script is more complete:
?php
set_time_limit(0);
ini_set('display_errors','0');
ini_set('log_errors','1');
//START
$dbConnection = @OCILogon(USER_ID, PASSWORD, SID);
// infinite loop
$error=0;
do
{
$query=SELECT DATA FROM PROV;
$stmt = @OCIParse($dbConnection,$query);
OCIDefineByName($stmt,DATA,$data);
OCIExecute($stmt);
$err_ora = OCIError($stmt);
if ($err_ora)
{
$error=1;
}
While (OCIFetch($stmt) ($error==0))
{
}
OCIFreeStatement($stmt);
sleep(2);
}while ($error==0);
OCILogoff($dbConnection);
?
Thank for any suggestion
[2003-01-21 17:18:05] [EMAIL PROTECTED]
Can you please try without these @ signs? If you don't like the
errors/warnings being displayed on your webpages, you can turn
display_errors off and log_errors on, so you can find the
errors/warnings in your log file.
ini_set('display_errors','0');
ini_set('log_errors','1');
[2003-01-21 03:19:26] [EMAIL PROTECTED]
I don't receive any error or I don't perhaps succeed in capturing it.
[2003-01-20 14:52:10] [EMAIL PROTECTED]
Do you see OCI8 Recursive call! such an error message?
[2003-01-20 10:51:56] [EMAIL PROTECTED]
Before the connection to the db it is present the following statement:
//Set max execution time to infinite
set_time_limit(0);
The loop is stopped when there is an error, in this case the variable
$error=1.
Thanks
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/21773
--
Edit this bug report at http://bugs.php.net/?id=21773edit=1
#17088 [Com]: GET/POST variables not registered
ID: 17088
Comment by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: No Feedback
Bug Type: Scripting Engine problem
Operating System: WindowsXP Pro
PHP Version: 4.2.0
New Comment:
Using 4.4.0-dev as a CGI, I am seeing this as well. Dumping the
various variables indicates this is a PHP bug:
From var_dump($GLOBALS):
[REQUEST_METHOD]=
string(3) GET
[QUERY_STRING]=
string(31) url=footitle=barblog_name=bag
[REQUEST_URI]=
string(53) /blog/trackbackto.cgi?url=footitle=barblog_name=bag
[HTTP_POST_VARS]=
array(0) {
}
[_POST]=
array(0) {
}
[HTTP_GET_VARS]=
array(0) {
}
[_GET]=
array(0) {
}
I am using PHP built from CVS as of some time during 4.4.0-dev, on
RedHat Linux 7.2, with Apache 1.3.27. I am now rebuilding PHP from CVS
HEAD to see if there's any change.
Previous Comments:
[2002-12-22 01:00:02] [EMAIL PROTECTED]
No feedback was provided for this bug for over 2 weeks, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to Open.
[2002-12-06 19:34:14] [EMAIL PROTECTED]
Should have added that there were some fixes made for CGI just recently
that might fix this too..
[2002-12-06 19:33:37] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-latest.zip
[2002-05-10 08:09:40] [EMAIL PROTECTED]
... and the answer is: COnfiguration error.
While struggling with the cgi.force_redirect I had started using the
command-line version to parse .php files. Obviously enough there were
no entries in $_GET, $_POST et al.
Since there were at least 3 of us Bozos who did that, perhaps it's
worth a mention in the documentation or FAQ.
[2002-05-09 20:14:08] [EMAIL PROTECTED]
Please see also bug # 16848 with similar difficulty running on Linux.
Also note that I have this problem on OmniHTTPd on Windows 98 (which I
tried after the above comment on Xitami).
With similar problems on 2 operating systems and 3 servers it looks to
me like either a real PHP problem or a configuration error of some
kind.
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/17088
--
Edit this bug report at http://bugs.php.net/?id=17088edit=1
#17088 [Com]: GET/POST variables not registered
ID: 17088
Comment by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: No Feedback
Bug Type: Scripting Engine problem
Operating System: WindowsXP Pro
PHP Version: 4.2.0
New Comment:
Curiously enough, and I don't know if it's related, but my
Header('content-type: text/xml') wasn't processed. I had to explicitly
'print content-type: text/xml\r\n\r\n' to get the header emitted.
Right now CVS HEAD isn't building with a
'/ext/standard/basic_functions.c:2827: `ZEND_INI_PARSER_POP_ENTRY'
undeclared (first use in this function)' but I'm working on that.
(Last time this happened I had to re-checkout the source tree, which
indicates that 'make clean' is missing something..)
Previous Comments:
[2003-01-22 06:44:18] [EMAIL PROTECTED]
Using 4.4.0-dev as a CGI, I am seeing this as well. Dumping the
various variables indicates this is a PHP bug:
From var_dump($GLOBALS):
[REQUEST_METHOD]=
string(3) GET
[QUERY_STRING]=
string(31) url=footitle=barblog_name=bag
[REQUEST_URI]=
string(53) /blog/trackbackto.cgi?url=footitle=barblog_name=bag
[HTTP_POST_VARS]=
array(0) {
}
[_POST]=
array(0) {
}
[HTTP_GET_VARS]=
array(0) {
}
[_GET]=
array(0) {
}
I am using PHP built from CVS as of some time during 4.4.0-dev, on
RedHat Linux 7.2, with Apache 1.3.27. I am now rebuilding PHP from CVS
HEAD to see if there's any change.
[2002-12-22 01:00:02] [EMAIL PROTECTED]
No feedback was provided for this bug for over 2 weeks, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to Open.
[2002-12-06 19:34:14] [EMAIL PROTECTED]
Should have added that there were some fixes made for CGI just recently
that might fix this too..
[2002-12-06 19:33:37] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-latest.zip
[2002-05-10 08:09:40] [EMAIL PROTECTED]
... and the answer is: COnfiguration error.
While struggling with the cgi.force_redirect I had started using the
command-line version to parse .php files. Obviously enough there were
no entries in $_GET, $_POST et al.
Since there were at least 3 of us Bozos who did that, perhaps it's
worth a mention in the documentation or FAQ.
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/17088
--
Edit this bug report at http://bugs.php.net/?id=17088edit=1
#21816 [NEW]: preg_replace has problem with arrays
From: [EMAIL PROTECTED] Operating system: Windows XP PHP version: 4.3.0 PHP Bug Type: *Regular Expressions Bug description: preg_replace has problem with arrays ?php // Hi, while using the following code i experienced // an interesting behaviour of preg_replace(): $string = Say a [word0] about [word1] and [word2]; $search[0] =[word0]; $search[1]= [word1]; $search[2]= [word2]; $replace[0]=betterWord0; $replace[2]=betterWord2; $replace[1]=betterWord1; $string = preg_replace($search,$replace,$string); echo Result is:BR . $string; echo BRBRResult should be:BR Say a [betterWord0] about [betterWord1] and [betterWord2]; // result should be: //Say a [betterWord0] about [betterWord1] and [betterWord2] // // but produces: //Say a [betterWord0] about [betterWord2] and [betterWord1] // // Seems like the order in which i build my array // is the order for replacing...and not the index // of $array[$index] // // // Has someone an idea, about what's happening here? // // just a guy addicted to php ;-) ? -- Edit bug report at http://bugs.php.net/?id=21816edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21816r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21816r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21816r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21816r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21816r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21816r=support Expected behavior: http://bugs.php.net/fix.php?id=21816r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21816r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21816r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21816r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21816r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21816r=dst IIS Stability: http://bugs.php.net/fix.php?id=21816r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=21816r=gnused
#21817 [NEW]: Error to compile php 4.2.3 in make phase
From: [EMAIL PROTECTED] Operating system: Linux Conectiva 8 PHP version: 4.2.3 PHP Bug Type: Compile Failure Bug description: Error to compile php 4.2.3 in make phase I do ./configure with this parameters: '--prefix=/usr/bin' \ '--disable-debug' \ '--enable-pic' \ '--enable-inline-optimization' \ '--enable-shared' \ '--disable-static' \ '--with-config-file-path=/etc/php4/apache' \ '--with-exec-dir=/usr/bin' \ '--with-regex=system' \ '--with-gettext' \ '--with-png' \ '--with-zlib' \ '--enable-magic-quotes' \ '--enable-safe-mode' \ '--enable-sockets' \ '--enable-sysvsem' \ '--enable-sysvshm' \ '--enable-track-vars' \ '--enable-wddx' \ '--enable-snmp' \ '--enable-ftp' \ '--enable-bcmath' \ '--with-mysql=/usr/src/mysql-3.23.54a' \ '--without-unixODBC' \ '--with-xml' \ '--with-imap' \ '--with-mcrypt=/usr/lib/libmcrypt' \ '--with-readline=/usr/src/readline-4.3' all it´s ok until now, but when I run 'make' this error occurs: root@ php-4.2.3]# make Making all in Zend /bin/sh: cd: Zend: File or directory not found make: *** [all-recursive] Error 1 But Zend directory is there ... Thanks in advance -- Edit bug report at http://bugs.php.net/?id=21817edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21817r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21817r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21817r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21817r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21817r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21817r=support Expected behavior: http://bugs.php.net/fix.php?id=21817r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21817r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21817r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21817r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21817r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21817r=dst IIS Stability: http://bugs.php.net/fix.php?id=21817r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=21817r=gnused
#21817 [Opn-Fbk]: Error to compile php 4.2.3 in make phase
ID: 21817 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: Compile Failure Operating System: Linux Conectiva 8 PHP Version: 4.2.3 New Comment: 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 Previous Comments: [2003-01-22 07:45:52] [EMAIL PROTECTED] I do ./configure with this parameters: '--prefix=/usr/bin' \ '--disable-debug' \ '--enable-pic' \ '--enable-inline-optimization' \ '--enable-shared' \ '--disable-static' \ '--with-config-file-path=/etc/php4/apache' \ '--with-exec-dir=/usr/bin' \ '--with-regex=system' \ '--with-gettext' \ '--with-png' \ '--with-zlib' \ '--enable-magic-quotes' \ '--enable-safe-mode' \ '--enable-sockets' \ '--enable-sysvsem' \ '--enable-sysvshm' \ '--enable-track-vars' \ '--enable-wddx' \ '--enable-snmp' \ '--enable-ftp' \ '--enable-bcmath' \ '--with-mysql=/usr/src/mysql-3.23.54a' \ '--without-unixODBC' \ '--with-xml' \ '--with-imap' \ '--with-mcrypt=/usr/lib/libmcrypt' \ '--with-readline=/usr/src/readline-4.3' all it´s ok until now, but when I run 'make' this error occurs: root@ php-4.2.3]# make Making all in Zend /bin/sh: cd: Zend: File or directory not found make: *** [all-recursive] Error 1 But Zend directory is there ... Thanks in advance -- Edit this bug report at http://bugs.php.net/?id=21817edit=1
#13465 [Com]: imap_fetchstructure problem
ID: 13465 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: IMAP related Operating System: Red Hat 7.1 (Seawolf) PHP Version: 4.0.6 New Comment: I've found the following explanation for this problem (although many mail clients interpret the content as html, imap do not so, but it seems to be an error on side of the sender not of the receiver): [...] Once again, let me emphasize that Content-Type: text/html without the mandatory MIME-Version header is garbage. It violates both MIME and the older format. See also: - http://www.faqchest.com/prgm/wuimap-l/imap-01/imap-0110/imap-011002/imap01103110_15803.html - http://www.faqchest.com/prgm/wuimap-l/imap-01/imap-0110/imap-011002/imap01103111_18907.html - http://www.faqchest.com/prgm/wuimap-l/imap-01/imap-0110/imap-011002/imap01103001_02507.html Previous Comments: [2001-10-19 02:42:37] [EMAIL PROTECTED] If it is a bug (which I doubt), it's not a PHP bug, but a bug in the library that the imap extension used. I recommend to check this out with the imap guys. Not a PHP bug bogus. [2001-10-19 00:00:16] [EMAIL PROTECTED] Nobody knows how to solve this problem??? [2001-09-26 22:05:51] [EMAIL PROTECTED] The list of modules I compiled PHP with: ./configure --with-apxs=/usr/local/apache/bin/apxs \ --with-mysql=/usr/local/mysql \ --with-imap=/usr/local/imap \ --with-language=korean \ --with-charset=euc_kr \ --with-zlib \ --enable-track-vars \ --disbale-debug \ --enable-modules=so \ --with-config-file-path=/usr/local/apache/conf \ My server environments: OS - Red Hat 7.1 PHP- 4.0.6 qmail - 1.03 imap - 4.7 apache - 1.3.20 mysql - 3.23.39 If a mail header contains 'Mime-Version: 1.0', imap_fetchstructure works ok. However If not, imap_fetchstructure always returns the type value as text and the subtype value as plain. For example, suppose I receive the following mail. x-sender: [EMAIL PROTECTED] x-receiver: [EMAIL PROTECTED] Received: from myonair.com by gaultier with Microsoft SMTPSVC(5.0.2172.1); Tue, 25 Sep 2001 11:34:08 +0900 Received: (qmail 31008 invoked by uid 99); 25 Sep 2001 11:39:49 +0900(KST) Date: 25 Sep 2001 11:39:49 +0900(KST) Message-ID: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: test From: [EMAIL PROTECTED] Content-Type: text/html; charset=ks_c_5601-1987 Return-Path: [EMAIL PROTECTED] X-OriginalArrivalTime: 25 Sep 2001 02:34:08.0868 (UTC) FILETIME=[8DAA4240:01C1456A] iframe frameborder=0 scrolling=no topmargin=0 leftmargin=0 src=http://mail.myonair.com/letter/mail_to.html?user_no=2; width=620 height=450/iframe The mail content type is text/html, but imap_fetchstructure returns the content type as text/plain because there is not 'Mime-Version: 1.0' in the mail header. If the mail header contains 'Mime-Version: 1.0', imap_fetchstructure works properly. Is this a kind of bug? -- Edit this bug report at http://bugs.php.net/?id=13465edit=1
#21816 [Opn]: preg_replace has problem with arrays
ID: 21816 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: *Regular Expressions Operating System: Windows XP PHP Version: 4.3.0 New Comment: ?php // Hi, while using the following code i experienced // an interesting behaviour of preg_replace(): $string = Say a [word0] about [word1] and [word2]; $search[0] =[word0]; $search[1]= [word1]; $search[2]= [word2]; $replace[0]=betterWord0; $replace[2]=betterWord2; $replace[1]=betterWord1; $string2 = preg_replace($search,$replace,$string); echo Result is:BR . $string2; echo BRBRResult should be:BR Say a [betterWord0] about [betterWord1] and [betterWord2]; // result should be: //Say a [betterWord0] about [betterWord1] and [betterWord2] // // but produces: //Say a [betterWord0] about [betterWord2] and [betterWord1] // // Seems like the order in which i build my array // is the order for replacing...and not the index // of $array[$index] // // if you add a ksort it works fine: ksort($search,SORT_NUMERIC); ksort($replace,SORT_NUMERIC); reset($search); reset($replace); $string3 = preg_replace($search,$replace,$string); echo BRBRCorrected (ksort) Result is:BR . $string3; // // Has someone an idea, about what's happening here? // // just a guy addicted to php ;-) ? Previous Comments: [2003-01-22 07:43:39] [EMAIL PROTECTED] ?php // Hi, while using the following code i experienced // an interesting behaviour of preg_replace(): $string = Say a [word0] about [word1] and [word2]; $search[0] =[word0]; $search[1]= [word1]; $search[2]= [word2]; $replace[0]=betterWord0; $replace[2]=betterWord2; $replace[1]=betterWord1; $string = preg_replace($search,$replace,$string); echo Result is:BR . $string; echo BRBRResult should be:BR Say a [betterWord0] about [betterWord1] and [betterWord2]; // result should be: //Say a [betterWord0] about [betterWord1] and [betterWord2] // // but produces: //Say a [betterWord0] about [betterWord2] and [betterWord1] // // Seems like the order in which i build my array // is the order for replacing...and not the index // of $array[$index] // // // Has someone an idea, about what's happening here? // // just a guy addicted to php ;-) ? -- Edit this bug report at http://bugs.php.net/?id=21816edit=1
#21814 [Opn-Asn]: false array keys
ID: 21814 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Assigned Bug Type: Scripting Engine problem Operating System: linux PHP Version: 4CVS-2003-01-22 (stable) -Assigned To: +Assigned To: iliaa Previous Comments: [2003-01-22 03:30:25] [EMAIL PROTECTED] One can create a key as integer 0 and access it with key boolean false but one cannot create an array with boolean false as the key. In otherwords: $arr = array(false = 'bar'); // array() $arr = array((int)false = 'bar'); // array(0='bar') $arr = array(0 = 'bar'); print $arr[false];// bar print $arr[(int)false]; // bar This seems inconsistent. From the documentation: Using TRUE as a key will evalute to integer 1 as key. Using FALSE as a key will evalute to integer 0 as key. Please explain the reasoning behind the current behavior. -- Edit this bug report at http://bugs.php.net/?id=21814edit=1
#21814 [Asn-Csd]: false array keys
ID: 21814 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Assigned +Status: Closed Bug Type: Scripting Engine problem Operating System: linux PHP Version: 4CVS-2003-01-22 (stable) Assigned To: iliaa New Comment: This bug has been fixed in CVS. In case this was a PHP problem, snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. Previous Comments: [2003-01-22 03:30:25] [EMAIL PROTECTED] One can create a key as integer 0 and access it with key boolean false but one cannot create an array with boolean false as the key. In otherwords: $arr = array(false = 'bar'); // array() $arr = array((int)false = 'bar'); // array(0='bar') $arr = array(0 = 'bar'); print $arr[false];// bar print $arr[(int)false]; // bar This seems inconsistent. From the documentation: Using TRUE as a key will evalute to integer 1 as key. Using FALSE as a key will evalute to integer 0 as key. Please explain the reasoning behind the current behavior. -- Edit this bug report at http://bugs.php.net/?id=21814edit=1
#21818 [NEW]: strange result with strtr()
From: [EMAIL PROTECTED]
Operating system: Mandrake 8
PHP version: 4.2.3
PHP Bug Type: Strings related
Bug description: strange result with strtr()
when i execute this expression,
echo $val=strtr('1',array('','\'));
i obtain the following result :
\
infact of 1
i try to make this operation with some other number but the problème seems
appear only with the string '1'
PS: sorry for my poor english
--
Edit bug report at http://bugs.php.net/?id=21818edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=21818r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=21818r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=21818r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=21818r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=21818r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=21818r=support
Expected behavior: http://bugs.php.net/fix.php?id=21818r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=21818r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=21818r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=21818r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21818r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=21818r=dst
IIS Stability: http://bugs.php.net/fix.php?id=21818r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=21818r=gnused
#21818 [Opn]: strange result with strtr()
ID: 21818
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Strings related
Operating System: Mandrake 8
PHP Version: 4.2.3
New Comment:
on freeBSD I observed the same issue
Previous Comments:
[2003-01-22 08:53:49] [EMAIL PROTECTED]
when i execute this expression,
echo $val=strtr('1',array('','\'));
i obtain the following result :
\
infact of 1
i try to make this operation with some other number but the problème
seems appear only with the string '1'
PS: sorry for my poor english
--
Edit this bug report at http://bugs.php.net/?id=21818edit=1
#21819 [NEW]: Corrupted uploaded binary files
From: [EMAIL PROTECTED] Operating system: Linux RedHar 8.0 PHP version: 4.3.0 PHP Bug Type: HTTP related Bug description: Corrupted uploaded binary files When uploading binary files (about 5kB and up), they get corrupted, not the whole file but some way from the beginning. The size is increased about 90%, actual number of bytes varies with different browsers. PHP versions tried: 4.3.0 and 4.3.1-dev (200301211230). Configured with './configure' '--with-apxs2' '--with-openssl' '--enable-calendar' '--with-curl' '--with-gd' '--with-jpeg-dir=/usr/lib' '--with-png-dir=/usr/lib' '--enable-mime-magic' '--with-mysql' '--enable-magic-quotes' '--with-zlib-dir=/usr/lib' '--with-config-file-path=/etc' Apache version: 2.0.43 -- Edit bug report at http://bugs.php.net/?id=21819edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21819r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21819r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21819r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21819r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21819r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21819r=support Expected behavior: http://bugs.php.net/fix.php?id=21819r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21819r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21819r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21819r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21819r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21819r=dst IIS Stability: http://bugs.php.net/fix.php?id=21819r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=21819r=gnused
#21729 [Fbk-Opn]: imagettftext don't work with a image copied resized from another
ID: 21729
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: Open
Bug Type: GD related
Operating System: Linux
PHP Version: 4.3.0
New Comment:
This is the original script modified only for running without external
parameters. You can download the image bottone1.png by the url
http://www.i-dome.com/microtools/bottoni/bottone01.png and the font
BOOMBOX.TTF by url http://www.i-dome.com/microtools/fonts/BOOMBOX.TTF
The program must run with this parameters:
testo=the text
larghezza=the width (default 96 pix)
The program run correctly on version 4.2.3 of PHP with gd2.0.4. Also it
runs correctly when I give the parameter larghezza (with) at the
original image width (96).
Thank you very much
Paolo Morandi
?
$currpath=substr($SCRIPT_FILENAME,0,strrpos($SCRIPT_FILENAME,/));
$margin_width=8; // pixel of margin
$margin_height=23; //pixel from top to write
$default_size=18; //default character dimension
$colors=array(102,153,51);
error_reporting(E_ALL);
$center=$margin_width;
$size=$default_size;
$isize=getimagesize(bottone01.png);
if(empty($larghezza) || $larghezza $isize[0])
$larghezza=$isize[0];
if($larghezza 640)
$larghezza=640;
$width=$larghezza - ($margin_width * 2);
$tsize=imagettfbbox($size, 0, $currpath/BOOMBOX.TTF,$testo);
$twidth=$tsize[2]-$tsize[0];
// echo
0=$tsize[0]|1=$tsize[1]|2=$tsize[2]|3=$tsize[3]|4=$tsize[4]|5=$tsize[5]|6=$tsize[6]|7=$tsize[7]|BR;
// echo size=$size|width=$width|twidth=$twidth|center=$center|BR;
if($twidth $width)
{
$size=round(($size*($width/$twidth)),0);
$tsize=imagettfbbox($size, 0, $currpath/BOOMBOX.TTF,$testo);
$twidth=$tsize[2]-$tsize[0];
}
$center+=round((($width-$twidth)/2),0);
// echo size=$size|width=$width|twidth=$twidth|center=$center|BR;
// imagettftext(image, size, angole, x, y, colore, font, testo)
$im = ImageCreateFromPNG(bottone01.png);
if($larghezza==$isize[0]) //in this case run correct
{
$im = ImageCreateFromPNG (bottone01.png);
}
else // in this case don't show the text
{
$im1 = ImageCreateFromPNG (bottone01.png);
$im=ImageCreateTrueColor($larghezza, $isize[1]);
ImageCopy($im, $im1,0,0,0,0,$margin_width,$isize[1]);
ImageCopyResized($im, $im1, $margin_width, 0, $margin_width, 0,
$width, $isize[1], round($isize[0]-($margin_width * 2),0), $isize[1]);
ImageCopy($im,
$im1,$margin_width+$width-1,0,$isize[0]-$margin_width,0,$margin_width,$isize[1]);
ImageDestroy($im1);
}
// ImageAlphaBlending($im, true);
$tc = ImageColorAllocate ($im, $colors[0], $colors[1],
$colors[2]);
imagettftext($im, $size, 0, $center, $margin_height, $tc,
$currpath/BOOMBOX.TTF,$testo);
// ImageAlphaBlending($im, false);
header(Content-Type: image/png\n\n);
ImagePNG($im);
?
Previous Comments:
[2003-01-20 19:22:48] [EMAIL PROTECTED]
Hello,
Can you provide a small script to reproduce your problem, this function
works like a charm here.
This line:
$tc = ImageColorAllocate ($im, $colors[$color][0],
$colors[$color][1], $colors[$color][2]);
can be your problem. Check the $color array, or set
error_reporting(E_ALL); to see if they are initialized correctly (btw,
use always this flag to develop).
Second point, ImageAlphaBlending is useless in your case,
ImageColorAllocate allocates a color with an opaque alpha channel.
thank's for your interest,
pierre
[2003-01-19 07:27:08] [EMAIL PROTECTED]
Don't show the text also with the latest CVS version.
[2003-01-18 13:17:24] [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-01-18 11:17:51] [EMAIL PROTECTED]
This code work fine on PHP 4.2.3 compiled with gd2.0.4, but give a
image without text with php 4.3 compiled with internal gd support. I
have this problem only in the image resized and not with the original
image:
if($width==$isize[0]) //original size: this work
{
$im = ImageCreateFromPNG (bottoni/.$tipo_bottone);
}
else // to resize: don't work
{
$im1 = ImageCreateFromPNG(bottoni/.$tipo_bottone);
$im=ImageCreateTrueColor($width, $isize[1]);
ImageCopy($im, im1,0,0,0,0,$margin_width,$isize[1]);
ImageCopyResized($im, $im1, $margin_width, 0, $margin_width, 0,
$width, $isize[1], round($isize[0]-($margin_width * 2),0), $isize[1]);
ImageCopy($im,
#21820 [NEW]: bc break in parser
From: [EMAIL PROTECTED]
Operating system:
PHP version: 4.3.0
PHP Bug Type: Scripting Engine problem
Bug description: bc break in parser
I don't think this is a bug, but someone sent it to me via
email, so I'm proxy-submitting:
Hello George-
I stumbled upon a serious bug in the string parser and it
goes something like this:
$arr = array('foo' = 'bar');
print $arr['foo'];
This used to provide a parse error but now instead we get
this one of level E_NOTICE:
Notice: Undefined index: 'foo' in /tmp/a.php on line 4
/tmp/a.php(4) : Notice - Undefined index: 'foo'
This is a serious problem as it moved an error from
parse to E_NOTICE, fails silently as most have error
reporting turned down, shows a misleading error as foo
is defined, and breaks BC.
Tested latest 4_3 HEAD (4.3.1-dev). I would try php5
but I get segfault when trying to compile/use it :)
Have a nice day,
Philip Olson
cc: derick
--
Edit bug report at http://bugs.php.net/?id=21820edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=21820r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=21820r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=21820r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=21820r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=21820r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=21820r=support
Expected behavior: http://bugs.php.net/fix.php?id=21820r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=21820r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=21820r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=21820r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21820r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=21820r=dst
IIS Stability: http://bugs.php.net/fix.php?id=21820r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=21820r=gnused
#21797 [Bgs-Csd]: compile stops, commad-line too long
ID: 21797 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Bogus +Status: Closed Bug Type: Compile Failure Operating System: Solaris 6 PHP Version: 4.3.0 New Comment: fixed by an upgrade of sed. Previous Comments: [2003-01-21 09:57:31] [EMAIL PROTECTED] Due to a bug in the installed sed on your system the build fails. Install GNU sed and it should be okay. Thank you for your interest in PHP. nbsp; [2003-01-21 09:54:35] [EMAIL PROTECTED] Hi, I have a problem compiling php on my sun workstation. The make stops with the error message: /bin/sh libtool .. Command line too long Command line too long Command line too long gcc: main/php_ini: No such file or directory I replaced the very long list of arguments with .. Its more than 3kb long. The problem was reported prior and solved in earlier versions but It appeared again. -- Edit this bug report at http://bugs.php.net/?id=21797edit=1
#21797 [Csd-Bgs]: compile stops, commad-line too long
ID: 21797 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Closed +Status: Bogus Bug Type: Compile Failure Operating System: Solaris 6 PHP Version: 4.3.0 New Comment: it's not a bug, so we leave it at bogus Previous Comments: [2003-01-22 09:40:58] [EMAIL PROTECTED] fixed by an upgrade of sed. [2003-01-21 09:57:31] [EMAIL PROTECTED] Due to a bug in the installed sed on your system the build fails. Install GNU sed and it should be okay. Thank you for your interest in PHP. nbsp; [2003-01-21 09:54:35] [EMAIL PROTECTED] Hi, I have a problem compiling php on my sun workstation. The make stops with the error message: /bin/sh libtool .. Command line too long Command line too long Command line too long gcc: main/php_ini: No such file or directory I replaced the very long list of arguments with .. Its more than 3kb long. The problem was reported prior and solved in earlier versions but It appeared again. -- Edit this bug report at http://bugs.php.net/?id=21797edit=1
#21757 [Fbk-Opn]: session_register (); does not do it's job!
ID: 21757
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: Open
Bug Type: Session related
Operating System: Windows XP Pro
PHP Version: 4.3.0
New Comment:
I don't know. I haven't changed any values but some paths so I could
make ir work. everything other is left unchanged (default).
Previous Comments:
[2003-01-20 13:54:17] [EMAIL PROTECTED]
Does your php.ini allow PHP to set cookie session?
[2003-01-20 10:40:38] [EMAIL PROTECTED]
Well, Previous version of PHP I used was 4.23 and everything went well.
Now in PHP 4.3 session_register ('string'); or $_SESSION [string];
does not register these 'string' variables when going from one page to
another. And by the way, echoing session_id (); in every new page you
go to (using hyperlinks, not opening new IE window) it gives you
different session ID and as far as I know that should not be changhing
unless you open another browser window. Why don't you try registering
variable and in another page writing if (session_is_registered
('string')) echo 'success';
I bet you won't see success though you should!
[2003-01-19 17:52:30] [EMAIL PROTECTED]
Not enough information was provided for us to be able
to handle this bug. Please re-read the instructions at
http://bugs.php.net/how-to-report.php
If you can provide more information, feel free to add it
to this bug and change the status back to Open.
Thank you for your interest in PHP.
A) updating category.
B) Not enough info, and from what I can tell so far this is probably
Bogus.
[2003-01-19 15:38:38] [EMAIL PROTECTED]
Here is the simple peace of code with the link to the page itself.
Session ID has to stay the same all the time as it is assigned to the
browser window (this conclusion is made by my own experiance :) ).
Tested with IE 6.0
//Start here
?session_start ();?
html
head
title/title
/head
body
?php
echo session_id ().'br';
?
a href=session_id.phpTest_Link/a
/body
/html
--
Edit this bug report at http://bugs.php.net/?id=21757edit=1
#21817 [Fbk-Opn]: Error to compile php 4.2.3 in make phase
ID: 21817 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: Compile Failure Operating System: Linux Conectiva 8 PHP Version: 4.2.3 New Comment: I get the latest version and try to compile and get the following error: gcc -Iext/imap/ -I/usr/src/php/ext/imap/ -DPHP_ATOM_INC -I/usr/src/php/include -I/usr/src/php/main -I/usr/src/php -I/usr/src/php/Zend -I/usr/include/imap -I/usr/local/include -I/usr/src/mysql-3.23.54a/include -I/usr/src/php/ext/xml/expat -I/usr/src/php/TSRM -g -O2 -c /usr/src/php/ext/imap/php_imap.c -o ext/imap/php_imap.o echo ext/imap/php_imap.lo /usr/src/php/ext/imap/php_imap.c: In function `zm_startup_imap': /usr/src/php/ext/imap/php_imap.c:424: `auth_gss' undeclared (first use in this function) /usr/src/php/ext/imap/php_imap.c:424: (Each undeclared identifier is reported only once /usr/src/php/ext/imap/php_imap.c:424: for each function it appears in.) make: *** [ext/imap/php_imap.lo] Error 1 Previous Comments: [2003-01-22 08:08:11] [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-01-22 07:45:52] [EMAIL PROTECTED] I do ./configure with this parameters: '--prefix=/usr/bin' \ '--disable-debug' \ '--enable-pic' \ '--enable-inline-optimization' \ '--enable-shared' \ '--disable-static' \ '--with-config-file-path=/etc/php4/apache' \ '--with-exec-dir=/usr/bin' \ '--with-regex=system' \ '--with-gettext' \ '--with-png' \ '--with-zlib' \ '--enable-magic-quotes' \ '--enable-safe-mode' \ '--enable-sockets' \ '--enable-sysvsem' \ '--enable-sysvshm' \ '--enable-track-vars' \ '--enable-wddx' \ '--enable-snmp' \ '--enable-ftp' \ '--enable-bcmath' \ '--with-mysql=/usr/src/mysql-3.23.54a' \ '--without-unixODBC' \ '--with-xml' \ '--with-imap' \ '--with-mcrypt=/usr/lib/libmcrypt' \ '--with-readline=/usr/src/readline-4.3' all it´s ok until now, but when I run 'make' this error occurs: root@ php-4.2.3]# make Making all in Zend /bin/sh: cd: Zend: File or directory not found make: *** [all-recursive] Error 1 But Zend directory is there ... Thanks in advance -- Edit this bug report at http://bugs.php.net/?id=21817edit=1
#21674 [Fbk-Opn]: Warning: main(lang.php) [function.main]: failed to create stream: No such file
ID: 21674
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: Open
Bug Type: *URL Functions
Operating System: Cobalt RAQ4 Apache/Linux
PHP Version: 4.3.0
New Comment:
Hello Wez:
Not it does not look like that. I was asked to include
var_dump(ini_get('include_path'));
before the require_once statement in the primary script,
phpbug21674.php
Remember there are two scripts located in different paths representing
two different virtual domains.
/home/site3/phpbug21674.php (contains a require_once
(/home/sites/site2/web/IV/config.php);
and /home/sites/site2/web/IV/config.php --- contains
include_once ('lang.php');
include ('extras.php');
However, I did go back and also added the var_dump to config.php to
reflect as follows:
var_dump(ini_get('include_path'));
include_once ('lang.php');
include ('extras.php');
Results: Same results = Failed to create stream:
Again, this script worked fine on PHP 4.1.2 Now it seems to get it to
work, I have to reference the absolute path.
Previous Comments:
[2003-01-22 05:00:55] [EMAIL PROTECTED]
Just to be extra sure:
in config.php, do lines 97 and 98 look like this:
var_dump(ini_get('include_path'));
include ('extras.php');
If not, please make sure they do and report back.
If they do, then something really strange is going on.
[2003-01-21 22:52:29] [EMAIL PROTECTED]
Hello PHP.NET:
So is this bug a stream related 4.3.0 bug or not?
[2003-01-18 02:31:51] [EMAIL PROTECTED]
Did you try ? :
chown o+r / /home /home/sites \
/home/sites/site2 \
/home/sites/site2/web \
/home/sites/site2/web/IV
Up to 4.2.3 x permission is need on ALL directories to the include.
Since 4.3.0 rx permissions are required.
Don't know why.
Cordialy.
[2003-01-17 15:59:32] [EMAIL PROTECTED]
You did not ask me to place above line that include fails. You asked me
to place above require_once in the config.php file. That I can confirm.
[2003-01-17 14:23:11] [EMAIL PROTECTED]
and can you confirm that the var_dump(ini_get('include_path')) is on
the line immediately above the include that fails?
I'm asking because the line numbers in the report don't seem to have
changed, and I would have expected them to at least have increased by
1.
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/21674
--
Edit this bug report at http://bugs.php.net/?id=21674edit=1
#21821 [NEW]: Unsetting $_COOKIE[session_name()] shouldn't warn, but send new cookie
From: [EMAIL PROTECTED]
Operating system: BSD/OS 4.2
PHP version: 4.3.0
PHP Bug Type: Session related
Bug description: Unsetting $_COOKIE[session_name()] shouldn't warn, but send new
cookie
The following script:
?php
error_reporting(E_ALL);
if(isset($_COOKIE[session_name()]) !file_exists(session_save_path(NULL)
. '/sess_' . session_id(NULL)))
unset($_COOKIE[session_name()]);
ini_set('session.use_only_cookies', TRUE);
ini_set('session.cookie_lifetime', 7 * 24 * 3600);
ini_set('session.gc_lifetime', 7 * 24 * 3600);
session_start();
?
html
body
a href=?php echo $_SERVER['PHP_SELF']; ??foo=?php echo time();
?refresh/a
pre
?php var_dump($_SESSION); ?
/pre
/body
/html
?php
$_SESSION['test'] = 'hi' . $_GET['foo'];
?
Creates warnings about illegal chars in the session id. However - there is
no valid session here, as there is no valid cookie. It should send a new
cookie instead, with a new generated session id. However - it sets an
empty id:
Set-Cookie: PHPSESSID=; expires=Wed, 29-Jan-2003 17:37:42 GMT; path=/
If I also unset $_SESSION, it doesn't change anything.
--
Edit bug report at http://bugs.php.net/?id=21821edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=21821r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=21821r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=21821r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=21821r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=21821r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=21821r=support
Expected behavior: http://bugs.php.net/fix.php?id=21821r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=21821r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=21821r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=21821r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21821r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=21821r=dst
IIS Stability: http://bugs.php.net/fix.php?id=21821r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=21821r=gnused
#21821 [Opn-Bgs]: Unsetting $_COOKIE[session_name()] shouldn't warn, but send new cookie
ID: 21821
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Bogus
Bug Type: Session related
Operating System: BSD/OS 4.2
PHP Version: 4.3.0
New Comment:
Ahum - NULL (inserted for readibility) apparently is '' not, void.
Previous Comments:
[2003-01-22 11:43:11] [EMAIL PROTECTED]
The following script:
?php
error_reporting(E_ALL);
if(isset($_COOKIE[session_name()])
!file_exists(session_save_path(NULL) . '/sess_' . session_id(NULL)))
unset($_COOKIE[session_name()]);
ini_set('session.use_only_cookies', TRUE);
ini_set('session.cookie_lifetime', 7 * 24 * 3600);
ini_set('session.gc_lifetime', 7 * 24 * 3600);
session_start();
?
html
body
a href=?php echo $_SERVER['PHP_SELF']; ??foo=?php echo time();
?refresh/a
pre
?php var_dump($_SESSION); ?
/pre
/body
/html
?php
$_SESSION['test'] = 'hi' . $_GET['foo'];
?
Creates warnings about illegal chars in the session id. However - there
is no valid session here, as there is no valid cookie. It should send a
new cookie instead, with a new generated session id. However - it sets
an empty id:
Set-Cookie: PHPSESSID=; expires=Wed, 29-Jan-2003 17:37:42 GMT; path=/
If I also unset $_SESSION, it doesn't change anything.
--
Edit this bug report at http://bugs.php.net/?id=21821edit=1
#21816 [Com]: preg_replace has problem with arrays
ID: 21816 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: *Regular Expressions Operating System: Windows XP PHP Version: 4.3.0 New Comment: The search strings used in the preg_replace() function are regular expressions. [abc] is a regular expression which matches any of the characters a, b or c. Either use str_replace() to replace your strings, or learn to use regular expressions http://de3.php.net/manual/en/pcre.pattern.syntax.php. Previous Comments: [2003-01-22 08:41:20] [EMAIL PROTECTED] ?php // Hi, while using the following code i experienced // an interesting behaviour of preg_replace(): $string = Say a [word0] about [word1] and [word2]; $search[0] =[word0]; $search[1]= [word1]; $search[2]= [word2]; $replace[0]=betterWord0; $replace[2]=betterWord2; $replace[1]=betterWord1; $string2 = preg_replace($search,$replace,$string); echo Result is:BR . $string2; echo BRBRResult should be:BR Say a [betterWord0] about [betterWord1] and [betterWord2]; // result should be: //Say a [betterWord0] about [betterWord1] and [betterWord2] // // but produces: //Say a [betterWord0] about [betterWord2] and [betterWord1] // // Seems like the order in which i build my array // is the order for replacing...and not the index // of $array[$index] // // if you add a ksort it works fine: ksort($search,SORT_NUMERIC); ksort($replace,SORT_NUMERIC); reset($search); reset($replace); $string3 = preg_replace($search,$replace,$string); echo BRBRCorrected (ksort) Result is:BR . $string3; // // Has someone an idea, about what's happening here? // // just a guy addicted to php ;-) ? [2003-01-22 07:43:39] [EMAIL PROTECTED] ?php // Hi, while using the following code i experienced // an interesting behaviour of preg_replace(): $string = Say a [word0] about [word1] and [word2]; $search[0] =[word0]; $search[1]= [word1]; $search[2]= [word2]; $replace[0]=betterWord0; $replace[2]=betterWord2; $replace[1]=betterWord1; $string = preg_replace($search,$replace,$string); echo Result is:BR . $string; echo BRBRResult should be:BR Say a [betterWord0] about [betterWord1] and [betterWord2]; // result should be: //Say a [betterWord0] about [betterWord1] and [betterWord2] // // but produces: //Say a [betterWord0] about [betterWord2] and [betterWord1] // // Seems like the order in which i build my array // is the order for replacing...and not the index // of $array[$index] // // // Has someone an idea, about what's happening here? // // just a guy addicted to php ;-) ? -- Edit this bug report at http://bugs.php.net/?id=21816edit=1
#21797 [Com]: compile stops, commad-line too long
ID: 21797 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: Compile Failure Operating System: Solaris 6 PHP Version: 4.3.0 New Comment: Could we please add GNU sed to the list of prerequisites on http://www.php.net/manual/en/install.solaris.php? Previous Comments: [2003-01-22 09:41:45] [EMAIL PROTECTED] it's not a bug, so we leave it at bogus [2003-01-22 09:40:58] [EMAIL PROTECTED] fixed by an upgrade of sed. [2003-01-21 09:57:31] [EMAIL PROTECTED] Due to a bug in the installed sed on your system the build fails. Install GNU sed and it should be okay. Thank you for your interest in PHP. nbsp; [2003-01-21 09:54:35] [EMAIL PROTECTED] Hi, I have a problem compiling php on my sun workstation. The make stops with the error message: /bin/sh libtool .. Command line too long Command line too long Command line too long gcc: main/php_ini: No such file or directory I replaced the very long list of arguments with .. Its more than 3kb long. The problem was reported prior and solved in earlier versions but It appeared again. -- Edit this bug report at http://bugs.php.net/?id=21797edit=1
#21797 [Bgs]: compile stops, commad-line too long
ID: 21797 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: Compile Failure Operating System: Solaris 6 PHP Version: 4.3.0 New Comment: yeah, I added GNU sed as requirement now; should be online in a couple of days. Previous Comments: [2003-01-22 12:35:59] [EMAIL PROTECTED] Could we please add GNU sed to the list of prerequisites on http://www.php.net/manual/en/install.solaris.php? [2003-01-22 09:41:45] [EMAIL PROTECTED] it's not a bug, so we leave it at bogus [2003-01-22 09:40:58] [EMAIL PROTECTED] fixed by an upgrade of sed. [2003-01-21 09:57:31] [EMAIL PROTECTED] Due to a bug in the installed sed on your system the build fails. Install GNU sed and it should be okay. Thank you for your interest in PHP. nbsp; [2003-01-21 09:54:35] [EMAIL PROTECTED] Hi, I have a problem compiling php on my sun workstation. The make stops with the error message: /bin/sh libtool .. Command line too long Command line too long Command line too long gcc: main/php_ini: No such file or directory I replaced the very long list of arguments with .. Its more than 3kb long. The problem was reported prior and solved in earlier versions but It appeared again. -- Edit this bug report at http://bugs.php.net/?id=21797edit=1
#19918 [Com]: no libphp4.so produced
ID: 19918 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Compile Failure Operating System: HP-UX 11.00 PHP Version: 4.3.0 New Comment: i have the same probleme with PHP 4.3 + SAPI NSAPI on HP-UX 11! /bin/sh libtool --silent --mode=link gcc -g -O2 -DZTS -prefer-pic -rpath /opt/php43/php-4.3.0/libs -avoid-version -module -L/usr/lo cal/lib -L/opt/bzip2/lib -L/opt/jpeg-6/lib -L/opt/libpng/lib -L/opt/xpm/lib -L/opt/freetype/lib -L/opt/T1/lib -L/opt/gd/lib -R /usr /local/lib -R /opt/bzip2/lib -R /opt/jpeg-6/lib -R /opt/libpng/lib -R /opt/xpm/lib -R /opt/freetype/lib -R /opt/T1/lib -R /opt/gd/li b ext/zlib/zlib.lo ext/zlib/zlib_fopen_wrapper.lo ext/bz2/bz2.lo ext/ctype/ctype.lo ext/gd/gd.lo ext/gd/gdttf.lo ext/gd/gdcache.lo e xt/overload/overload.lo ext/pcre/pcrelib/maketables.lo ext/pcre/pcrelib/get.lo ext/pcre/pcrelib/study.lo ext/pcre/pcrelib/pcre.lo ex t/pcre/php_pcre.lo ext/session/session.lo ext/session/mod_files.lo ext/session/mod_mm.lo ext/session/mod_user.lo ext/standard/array. lo ext/standard/base64.lo ext/standard/basic_functions.lo ext/standard/browscap.lo ext/standard/crc32.lo ext/standard/crypt.lo ext/s tandard/cyr_convert.lo ext/standard/datetime.lo ext/standard/dir.lo ext/standard/dl.lo ext/standard/dns.lo ext/standard/exec.lo ext/ standard/file.lo ext/standard/filestat.lo ext/standard/flock_compat.lo ext/standard/formatted_print.lo ext/standard/fsock.lo ext/sta ndard/head.lo ext/standard/html.lo ext/standard/image.lo ext/standard/info.lo ext/standard/iptc.lo ext/standard/lcg.lo ext/standard/ link.lo ext/standard/mail.lo ext/standard/math.lo ext/standard/md5.lo ext/standard/metaphone.lo ext/standard/microtime.lo ext/standa rd/pack.lo ext/standard/pageinfo.lo ext/standard/parsedate.lo ext/standard/quot_print.lo ext/standard/rand.lo ext/standard/reg.lo ex t/standard/soundex.lo ext/standard/string.lo ext/standard/scanf.lo ext/standard/syslog.lo ext/standard/type.lo ext/standard/uniqid.l o ext/standard/url.lo ext/standard/url_scanner.lo ext/standard/var.lo ext/standard/versioning.lo ext/standard/assert.lo ext/standard /strnatcmp.lo ext/standard/levenshtein.lo ext/standard/incomplete_class.lo ext/standard/url_scanner_ex.lo ext/standard/ftp_fopen_wra pper.lo ext/standard/http_fopen_wrapper.lo ext/standard/php_fopen_wrapper.lo ext/standard/credits.lo ext/standard/css.lo ext/standar d/var_unserializer.lo ext/standard/ftok.lo ext/standard/aggregation.lo ext/standard/sha1.lo ext/tokenizer/tokenizer.lo regex/regcomp .lo regex/regexec.lo regex/regerror.lo regex/regfree.lo TSRM/TSRM.lo TSRM/tsrm_strtok_r.lo TSRM/tsrm_virtual_cwd.lo main/main.lo mai n/snprintf.lo main/spprintf.lo main/php_sprintf.lo main/safe_mode.lo main/fopen_wrappers.lo main/alloca.lo main/php_ini.lo main/SAPI .lo main/rfc1867.lo main/php_content_types.lo main/strlcpy.lo main/strlcat.lo main/mergesort.lo main/reentrancy.lo main/php_variable s.lo main/php_ticks.lo main/streams.lo main/network.lo main/php_open_temporary_file.lo main/php_logos.lo main/output.lo main/memory_ streams.lo main/user_streams.lo Zend/zend_language_parser.lo Zend/zend_language_scanner.lo Zend/zend_ini_parser.lo Zend/zend_ini_sca nner.lo Zend/zend_alloc.lo Zend/zend_compile.lo Zend/zend_constants.lo Zend/zend_dynamic_array.lo Zend/zend_execute_API.lo Zend/zend _highlight.lo Zend/zend_llist.lo Zend/zend_opcode.lo Zend/zend_operators.lo Zend/zend_ptr_stack.lo Zend/zend_stack.lo Zend/zend_vari ables.lo Zend/zend.lo Zend/zend_API.lo Zend/zend_extensions.lo Zend/zend_hash.lo Zend/zend_list.lo Zend/zend_indent.lo Zend/zend_bui ltin_functions.lo Zend/zend_sprintf.lo Zend/zend_ini.lo Zend/zend_qsort.lo Zend/zend_multibyte.lo Zend/zend_execute.lo sapi/nsapi/ns api.lo main/internal_functions.lo -lgd -lt1 -lttf -lX11 -lXpm -lpng -lz -ljpeg -lbz2 -lz -lcrypt -lm -lnsl -lpthread -lcrypt -o lib php4.la *** Warning: This library needs some functionality provided by -lcrypt. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have. *** Warning: This library needs some functionality provided by -lcrypt. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have. *** Warning: libtool could not satisfy all declared inter-library *** dependencies of module libphp4. Therefore, libtool will create *** a static module, that should work as long as the dlopening *** application is linked with the -dlopen flag. and when make install: Installing PHP CLI binary:/opt/php43/bin/ Installing PHP SAPI module cp: cannot access libs/libphp4.sl: No such file or directory make: *** [install-sapi] Error 1 i think are libtool probleme on hp-ux
#21823 [NEW]: improperly detecting gcc3 as cross compiler
From: [EMAIL PROTECTED] Operating system: Gentoo Linux 1.4 PHP version: 4.3.0 PHP Bug Type: Compile Failure Bug description: improperly detecting gcc3 as cross compiler When installing PHP 4.3 on my system running GCC 3.2.1, I get the following output. This is obviously incorrect. If you need any further info, please ask. arsenic root # emerge php Calculating dependencies ...done! emerge (1 of 1) dev-php/php-4.3.0-r2 to / md5 ;-) php-4.3.0.tar.bz2 Unpacking source... Unpacking php-4.3.0.tar.bz2 Source unpacked. ssl gdbm mysql truetype jpeg Compiling imap with SSL support libwww flash xml2 crypt creating cache ./config.cache checking for Cygwin environment... no checking for mingw32 environment... no checking for working sed... sed checking host system type... i686-pc-linux-gnu Updated php_version.h checking for gcc... gcc checking whether the C compiler (gcc -march=i686 -O3 -pipe ) works... yes checking whether the C compiler (gcc -march=i686 -O3 -pipe ) is a cross-compiler... yes checking whether we are using GNU C... yes checking whether gcc accepts -g... yes checking whether gcc and cc understand -c and -o together... yes checking how to run the C preprocessor... gcc -E checking for AIX... no checking if compiler supports -R... no checking if compiler supports -Wl,-rpath,... yes checking for ranlib... ranlib checking whether ln -s works... yes checking for gawk... gawk checking for bison... bison -y checking bison version... 1.35 (ok) checking for flex... flex checking for yywrap in -lfl... yes checking lex output file root... lex.yy checking whether yytext is a pointer... yes checking for working const... yes checking flex version... 2.5.4 (ok) checking for pthreads_cflags... checking for pthreads_lib... Configuring SAPI modules checking for AOLserver support... no checking for Apache 1.x module support via DSO through APXS... no checking for Apache 1.x module support... no checking for mod_charset compatibility option... no checking for Apache 2.0 module support via DSO through APXS... no checking for Caudium support... no checking for CLI build... yes checking for embedded SAPI library support... no checking for Zeus ISAPI support... no checking for NSAPI support... no checking for PHTTPD support... no checking for Pi3Web support... no checking for Roxen/Pike support... no checking for Servlet support... no checking for thttpd... no checking for TUX... no checking for webjames... no checking for CGI build... no checking for chosen SAPI module... cli Running system checks checking for missing declarations of reentrant functions... done checking for sendmail... /usr/sbin/sendmail checking whether system uses EBCDIC... no checking for socket... yes checking for htonl... yes checking for gethostname... yes checking for gethostbyaddr... yes checking for yp_get_default_domain... no checking for __yp_get_default_domain... no checking for yp_get_default_domain in -lnsl... yes checking for dlopen... yes checking for sin in -lm... yes checking for res_search... no checking for __res_search... no checking for res_search in -lresolv... yes checking for res_search in -lbind... no checking for __res_search in -lbind... no checking for res_search in -lsocket... no checking for __res_search in -lsocket... no checking for inet_aton... yes checking for dn_skipname... no checking for __dn_skipname... no checking for dn_skipname in -lresolv... no checking for __dn_skipname in -lresolv... yes checking for dn_skipname in -lbind... no checking for __dn_skipname in -lbind... no checking for ANSI C header files... yes checking for dirent.h that defines DIR... yes checking for opendir in -ldir... no checking for fclose declaration... ok checking for ApplicationServices/ApplicationServices.h... no checking for sys/types.h... yes checking for sys/time.h... yes checking for netinet/in.h... yes checking for alloca.h... yes checking for arpa/inet.h... yes checking for arpa/nameser.h... yes checking for assert.h... yes checking for crypt.h... yes checking for fcntl.h... yes checking for grp.h... yes checking for ieeefp.h... no checking for langinfo.h... yes checking for limits.h... yes checking for locale.h... yes checking for monetary.h... yes checking for mach-o/dyld.h... no checking for netdb.h... yes checking for pwd.h... yes checking for resolv.h... yes checking for signal.h... yes checking for stdarg.h... yes checking for stdlib.h... yes checking for string.h... yes checking for syslog.h... yes checking for sysexits.h... yes checking for sys/file.h... yes checking for sys/mman.h... yes checking for sys/mount.h... yes checking for sys/poll.h... yes checking for sys/resource.h... yes checking for sys/select.h... yes checking for sys/socket.h... yes checking for sys/statfs.h... yes checking for sys/statvfs.h... yes checking for sys/vfs.h... yes checking for
#21820 [Com]: bc break in parser
ID: 21820
Comment by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type:Scripting Engine problem
PHP Version: 4.3.0
New Comment:
patch up at http://www2.omniti.com/~george/
zend.patch.2002012101
patch allows for $arr['foo'] to be parsed correctly (this
seems better than disallowing it)
Previous Comments:
[2003-01-22 09:19:20] [EMAIL PROTECTED]
I don't think this is a bug, but someone sent it to me via
email, so I'm proxy-submitting:
Hello George-
I stumbled upon a serious bug in the string parser and it
goes something like this:
$arr = array('foo' = 'bar');
print $arr['foo'];
This used to provide a parse error but now instead we get
this one of level E_NOTICE:
Notice: Undefined index: 'foo' in /tmp/a.php on line 4
/tmp/a.php(4) : Notice - Undefined index: 'foo'
This is a serious problem as it moved an error from
parse to E_NOTICE, fails silently as most have error
reporting turned down, shows a misleading error as foo
is defined, and breaks BC.
Tested latest 4_3 HEAD (4.3.1-dev). I would try php5
but I get segfault when trying to compile/use it :)
Have a nice day,
Philip Olson
cc: derick
--
Edit this bug report at http://bugs.php.net/?id=21820edit=1
#21820 [Opn]: bc break in parser
ID: 21820
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type:Scripting Engine problem
PHP Version: 4.3.0
New Comment:
Allowing it would be nice but this topic has come up many times. Not
sure why it's not been implemented though, maybe there are reasons? I
forget them.
One feature request for this:
http://bugs.php.net/bug.php?id=15677
Previous Comments:
[2003-01-22 13:25:11] [EMAIL PROTECTED]
patch up at http://www2.omniti.com/~george/
zend.patch.2002012101
patch allows for $arr['foo'] to be parsed correctly (this
seems better than disallowing it)
[2003-01-22 09:19:20] [EMAIL PROTECTED]
I don't think this is a bug, but someone sent it to me via
email, so I'm proxy-submitting:
Hello George-
I stumbled upon a serious bug in the string parser and it
goes something like this:
$arr = array('foo' = 'bar');
print $arr['foo'];
This used to provide a parse error but now instead we get
this one of level E_NOTICE:
Notice: Undefined index: 'foo' in /tmp/a.php on line 4
/tmp/a.php(4) : Notice - Undefined index: 'foo'
This is a serious problem as it moved an error from
parse to E_NOTICE, fails silently as most have error
reporting turned down, shows a misleading error as foo
is defined, and breaks BC.
Tested latest 4_3 HEAD (4.3.1-dev). I would try php5
but I get segfault when trying to compile/use it :)
Have a nice day,
Philip Olson
cc: derick
--
Edit this bug report at http://bugs.php.net/?id=21820edit=1
#21820 [Com]: bc break in parser
ID: 21820
Comment by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type:Scripting Engine problem
PHP Version: 4.3.0
New Comment:
this patch fixes that feature request/bug as well
Previous Comments:
[2003-01-22 13:43:05] [EMAIL PROTECTED]
Allowing it would be nice but this topic has come up many times. Not
sure why it's not been implemented though, maybe there are reasons? I
forget them.
One feature request for this:
http://bugs.php.net/bug.php?id=15677
[2003-01-22 13:25:11] [EMAIL PROTECTED]
patch up at http://www2.omniti.com/~george/
zend.patch.2002012101
patch allows for $arr['foo'] to be parsed correctly (this
seems better than disallowing it)
[2003-01-22 09:19:20] [EMAIL PROTECTED]
I don't think this is a bug, but someone sent it to me via
email, so I'm proxy-submitting:
Hello George-
I stumbled upon a serious bug in the string parser and it
goes something like this:
$arr = array('foo' = 'bar');
print $arr['foo'];
This used to provide a parse error but now instead we get
this one of level E_NOTICE:
Notice: Undefined index: 'foo' in /tmp/a.php on line 4
/tmp/a.php(4) : Notice - Undefined index: 'foo'
This is a serious problem as it moved an error from
parse to E_NOTICE, fails silently as most have error
reporting turned down, shows a misleading error as foo
is defined, and breaks BC.
Tested latest 4_3 HEAD (4.3.1-dev). I would try php5
but I get segfault when trying to compile/use it :)
Have a nice day,
Philip Olson
cc: derick
--
Edit this bug report at http://bugs.php.net/?id=21820edit=1
#21820 [Opn]: bc break in parser
ID: 21820
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type:Scripting Engine problem
PHP Version: 4.3.0
New Comment:
Point was, maybe there is a reason this was not implemented.
And btw, this is a bug as 'foo' is defined yet the error says it's
not.
Previous Comments:
[2003-01-22 13:45:54] [EMAIL PROTECTED]
this patch fixes that feature request/bug as well
[2003-01-22 13:43:05] [EMAIL PROTECTED]
Allowing it would be nice but this topic has come up many times. Not
sure why it's not been implemented though, maybe there are reasons? I
forget them.
One feature request for this:
http://bugs.php.net/bug.php?id=15677
[2003-01-22 13:25:11] [EMAIL PROTECTED]
patch up at http://www2.omniti.com/~george/
zend.patch.2002012101
patch allows for $arr['foo'] to be parsed correctly (this
seems better than disallowing it)
[2003-01-22 09:19:20] [EMAIL PROTECTED]
I don't think this is a bug, but someone sent it to me via
email, so I'm proxy-submitting:
Hello George-
I stumbled upon a serious bug in the string parser and it
goes something like this:
$arr = array('foo' = 'bar');
print $arr['foo'];
This used to provide a parse error but now instead we get
this one of level E_NOTICE:
Notice: Undefined index: 'foo' in /tmp/a.php on line 4
/tmp/a.php(4) : Notice - Undefined index: 'foo'
This is a serious problem as it moved an error from
parse to E_NOTICE, fails silently as most have error
reporting turned down, shows a misleading error as foo
is defined, and breaks BC.
Tested latest 4_3 HEAD (4.3.1-dev). I would try php5
but I get segfault when trying to compile/use it :)
Have a nice day,
Philip Olson
cc: derick
--
Edit this bug report at http://bugs.php.net/?id=21820edit=1
#21533 [Opn]: Trouble building PHP w/ GD and including ImageTTFxxx functions
ID: 21533 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: GD related Operating System: RH 7.2 PHP Version: 4.3.0 New Comment: The version of gd.c that I have is supposed to be 4.3.0. I still believe it is incorrect. If you are referring to the statement: Line 2951: #else /* !USE_GD_IMGSTRTTF */ that 'else' is related to a USE_GD_IMGSTRTTF and is not the same as any HAVE_GD_STRINGxxx defines. I'm saying that if USE_GD_IMGSTRTTF *is* defined, but neither HAVE_GD_STRINGFT nor HAVE_GD_STRINGTTF is defined, it will leave the variable 'error' undefined, and then try to use it (resulting in the possibility of a crash). Do you still disagree? Previous Comments: [2003-01-21 14:20:13] [EMAIL PROTECTED] The ifdef is correct, because no matter what the value will be assigned to error. There is another ifdef surrounding this code which has an else condition that is used to set a value to error. So the crash you are seeing comes from elsewhere. [2003-01-21 09:28:38] [EMAIL PROTECTED] PHP build: configure --with-apxs=/usr/local/apache/bin/apxs --with-mysql=/usr/local/mysql --enable-track-vars --with-imap=/usr/local/imap --with-gd --enable-ftp --enable-sysvsem --enable-sysvshm --enable-sockets --with-gettext --with-mm=/usr/local/lib/mm --with-jpeg-dir=/usr/lib --with-zlib-dir=/usr/local --with-openssl=/usr/local/ssl --with-ttf --enable-gd-native-ttf --enable-gd-imgstrttf --with-freetype-dir=/usr/local --with-dom FreeType: freetype-1.3.1.tar.gz was untarred and built and installed with: configure make make install [2003-01-20 17:11:22] [EMAIL PROTECTED] What was the configure line ? And exactly what freetype 1.x version was installed? And how? [2003-01-20 16:48:08] [EMAIL PROTECTED] I'm really not a Linux developer, and although what you are asking for sounds easy enough, I don't know how to give you what you want. I would like to reiterate that there are 2 issues here: 1. Configure incorrectly reporting my support for FreeType2 2. gd.c has code that given certain #if conditions, leaves the variable 'error' undefined. The crash is occuring because of the reference to this floating pointer. I assume you want a backtrace to determine the line of code that is crashing, but I'm *giving* you the line of code that is crashing. [2003-01-09 19:44:35] [EMAIL PROTECTED] Can you generate a backtrace from the core file and please provide the shortest possible version of the script that can be used to duplicate the crash. 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/21533 -- Edit this bug report at http://bugs.php.net/?id=21533edit=1
#21824 [NEW]: PHP-Based AIM Bot
From: [EMAIL PROTECTED] Operating system: all PHP version: 4.3.0 PHP Bug Type: Feature/Change Request Bug description: PHP-Based AIM Bot Any thoughts on converting the Perl Net::AIM module to PHP? I think it would be great to be able to code an AIM bot in PHP. has this been discussed regarding the possibility of converting the AIM protocols and make it an option for compiling into PHP? -- Edit bug report at http://bugs.php.net/?id=21824edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21824r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21824r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21824r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21824r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21824r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21824r=support Expected behavior: http://bugs.php.net/fix.php?id=21824r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21824r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21824r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21824r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21824r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21824r=dst IIS Stability: http://bugs.php.net/fix.php?id=21824r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=21824r=gnused
#21824 [Opn]: PHP-Based AIM Bot
ID: 21824 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Feature/Change Request Operating System: all PHP Version: 4.3.0 New Comment: Speak of the devil, I was just thinking of this on my way home last night (well, ICQ technically, but the idea is the same). The conclusion I came to, and others may feel free to disagree with me, is that such modules are best built as PEAR classes rather than PHP extensions. The fact that you're now mentioning that Perl has it as a PEAR-equivalent style module just bolsters that position. If you feel adventurous, I'd recommend working on the conversion yourself. You've got the basic framework to start from in Perl's Net::AIM module, it simply needs to be built into a PHP class. Previous Comments: [2003-01-22 14:12:35] [EMAIL PROTECTED] Any thoughts on converting the Perl Net::AIM module to PHP? I think it would be great to be able to code an AIM bot in PHP. has this been discussed regarding the possibility of converting the AIM protocols and make it an option for compiling into PHP? -- Edit this bug report at http://bugs.php.net/?id=21824edit=1
#21825 [NEW]: Fatal error: Nesting level too deep
From: [EMAIL PROTECTED] Operating system: Linux 2.4.19 PHP version: 4.3.0 PHP Bug Type: Reproducible crash Bug description: Fatal error: Nesting level too deep This error occurs at the bottom of every PHP-parsed page: Fatal error: Nesting level too deep - recursive dependency? in Unknown on line 0 The pages seem to render okay, but the error appears to end each page. It even spit out the same error dozens of times on make test, and after sending in the test results. ./configure --with-apxs=/usr/local/apache/bin/apxs --enable-trans-sid --enable-track-vars --with-gd --with-pdflib --with-jpeg-dir --with-tiff-dir --with-pspell --with-freetype-dir --enable-gd-native-ttf --with-png-dir --with-zlib-dir --with-ttf --with-mysql=/usr/local/mysql The system is MDK9 and Apache 1.3.26 -- Edit bug report at http://bugs.php.net/?id=21825edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21825r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21825r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21825r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21825r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21825r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21825r=support Expected behavior: http://bugs.php.net/fix.php?id=21825r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21825r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21825r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21825r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21825r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21825r=dst IIS Stability: http://bugs.php.net/fix.php?id=21825r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=21825r=gnused
#21818 [Opn-Bgs]: strange result with strtr()
ID: 21818
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Bogus
Bug Type: Strings related
Operating System: Mandrake 8
PHP Version: 4.2.3
New Comment:
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
You are not specifying the array correctly.
it should be array('#' = '\#');
Otherwise it uses numeric keys for each array element 0 for # and 1 for
\#. Meaning that all 0s will be replaced with '#' and all 1s will be
replaced with \#.
Previous Comments:
[2003-01-22 08:56:55] [EMAIL PROTECTED]
on freeBSD I observed the same issue
[2003-01-22 08:53:49] [EMAIL PROTECTED]
when i execute this expression,
echo $val=strtr('1',array('','\'));
i obtain the following result :
\
infact of 1
i try to make this operation with some other number but the problème
seems appear only with the string '1'
PS: sorry for my poor english
--
Edit this bug report at http://bugs.php.net/?id=21818edit=1
#21816 [Opn-Bgs]: preg_replace has problem with arrays
ID: 21816 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: *Regular Expressions Operating System: Windows XP PHP Version: 4.3.0 New Comment: Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php The replacment is done in the order the array was created, if you want it to be done based on array keys that run an appropriate sorting function before executing the preg_replace function. Previous Comments: [2003-01-22 12:14:45] [EMAIL PROTECTED] The search strings used in the preg_replace() function are regular expressions. [abc] is a regular expression which matches any of the characters a, b or c. Either use str_replace() to replace your strings, or learn to use regular expressions http://de3.php.net/manual/en/pcre.pattern.syntax.php. [2003-01-22 08:41:20] [EMAIL PROTECTED] ?php // Hi, while using the following code i experienced // an interesting behaviour of preg_replace(): $string = Say a [word0] about [word1] and [word2]; $search[0] =[word0]; $search[1]= [word1]; $search[2]= [word2]; $replace[0]=betterWord0; $replace[2]=betterWord2; $replace[1]=betterWord1; $string2 = preg_replace($search,$replace,$string); echo Result is:BR . $string2; echo BRBRResult should be:BR Say a [betterWord0] about [betterWord1] and [betterWord2]; // result should be: //Say a [betterWord0] about [betterWord1] and [betterWord2] // // but produces: //Say a [betterWord0] about [betterWord2] and [betterWord1] // // Seems like the order in which i build my array // is the order for replacing...and not the index // of $array[$index] // // if you add a ksort it works fine: ksort($search,SORT_NUMERIC); ksort($replace,SORT_NUMERIC); reset($search); reset($replace); $string3 = preg_replace($search,$replace,$string); echo BRBRCorrected (ksort) Result is:BR . $string3; // // Has someone an idea, about what's happening here? // // just a guy addicted to php ;-) ? [2003-01-22 07:43:39] [EMAIL PROTECTED] ?php // Hi, while using the following code i experienced // an interesting behaviour of preg_replace(): $string = Say a [word0] about [word1] and [word2]; $search[0] =[word0]; $search[1]= [word1]; $search[2]= [word2]; $replace[0]=betterWord0; $replace[2]=betterWord2; $replace[1]=betterWord1; $string = preg_replace($search,$replace,$string); echo Result is:BR . $string; echo BRBRResult should be:BR Say a [betterWord0] about [betterWord1] and [betterWord2]; // result should be: //Say a [betterWord0] about [betterWord1] and [betterWord2] // // but produces: //Say a [betterWord0] about [betterWord2] and [betterWord1] // // Seems like the order in which i build my array // is the order for replacing...and not the index // of $array[$index] // // // Has someone an idea, about what's happening here? // // just a guy addicted to php ;-) ? -- Edit this bug report at http://bugs.php.net/?id=21816edit=1
#17996 [Com]: make fails with image.c , line 439.23: 1506-334 (S) Identifier uchar has
ID: 17996 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: Compile Failure Operating System: AIX 4.3.3 PHP Version: 4.3.0-dev New Comment: Our PHP 4.3.0 build failed to compile sapi/cli/php on our AIX machine, with over one hundred error messages like: cc: 1501-218 file ext/ctype/ctype.lo contains an incorrect file suffix The causes of this are rather subtle: 1. GNU libtool will usually not create static objects under AIX. 2. But the PHP developers want libtool to create static objects. 3. So the PHP developers provide their own ./libtool in the source tree which will create them, which they run with /bin/sh libtool. 4. Unfortunately, while /bin/sh file usually looks for file in the current directory before searching through $PATH, on AIX it looks through $PATH first; thus the PHP Makefile winds up running /usr/local/bin/libtool (or wherever you have it installed) instead. Thus the solution is to modify the PHP Makefile so that the line LIBTOOL = $(SHELL) libtool --silent instead reads LIBTOOL = $(SHELL) ./libtool --silent Technical notes: When you compile and install libtool, it runs a script called libtool.m4 which, around line 2363 in the libtool-1.4.3 source, disables AIX static linking with the explanation that: On AIX, shared libraries and static libraries use the same namespace, and are all built from PIC. It disables static linking by setting enable_static=no when it writes your libtool script; the ./libtool script in the PHP build directory works precisely because this variable is set to yes instead. Previous Comments: [2002-12-12 06:39:33] [EMAIL PROTECTED] Ignore that last post, being a bit of a muppet, using the wrong version. [2002-12-12 04:25:10] [EMAIL PROTECTED] I've exactly the same problem, same version of AIX etc. I have apache 2.0.43 installed and am using php 4.2.3. Is this a compiler issue? Or is it worth while trying 4.3.0RC3 I need to get this working fairly desperately. So any help is welcome. Thanks Julian [2002-08-08 13:07:58] [EMAIL PROTECTED] This is not a problem in PHP, but a problem with your (configuration of your) system. Please ask support questions on the appropriate mailinglist. [2002-08-08 12:54:33] [EMAIL PROTECTED] I would like to believe you but although it says Target all is up to date the file it is looking for (libs/libphp4.so) hasn't been created. [2002-08-08 11:58:16] [EMAIL PROTECTED] Glad to hear the bug is fixed, but your new problem is an end user problem, not a PHP bug. Please figure out your installation, and where you want things to go. If you still have trouble with that, ask on the php-general list for help. 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/17996 -- Edit this bug report at http://bugs.php.net/?id=17996edit=1
#16692 [Com]: Cannot find or read import file: /usr/local/apache2/bin/httpd.exp
ID: 16692 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: No Feedback Bug Type: Apache2 related Operating System: AIX PHP Version: 4.2.0 New Comment: Our PHP 4.3.0 build failed to compile sapi/cli/php on our AIX machine, with over one hundred error messages like: cc: 1501-218 file ext/ctype/ctype.lo contains an incorrect file suffix The causes of this are rather subtle: 1. GNU libtool will usually not create static objects under AIX. 2. But the PHP developers want libtool to create static objects. 3. So the PHP developers provide their own ./libtool in the source tree which will create them, which they run with /bin/sh libtool. 4. Unfortunately, while /bin/sh file usually looks for file in the current directory before searching through $PATH, on AIX it looks through $PATH first; thus the PHP Makefile winds up running /usr/local/bin/libtool (or wherever you have it installed) instead. Thus the solution is to modify the PHP Makefile so that the line LIBTOOL = $(SHELL) libtool --silent instead reads LIBTOOL = $(SHELL) ./libtool --silent Technical notes: When you compile and install libtool, it runs a script called libtool.m4 which, around line 2363 in the libtool-1.4.3 source, disables AIX static linking with the explanation that: On AIX, shared libraries and static libraries use the same namespace, and are all built from PIC. It disables static linking by setting enable_static=no when it writes your libtool script; the ./libtool script in the PHP build directory works precisely because this variable is set to yes instead. Previous Comments: [2002-10-27 01:00:02] [EMAIL PROTECTED] No feedback was provided for this bug for over 2 weeks, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to Open. [2002-10-09 14:36:16] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip Could you please see if the problem persists with Apache 2.0.43 and PHP 4.3-dev. [2002-05-22 03:51:59] [EMAIL PROTECTED] This also happens with Apache 2.0.36 apxs-script. After running ./configure you have to edit the config_vars.mk. Search for httpd.exp and change it to $prefix/modules/httpd.exp (as Aaron wrote). Then run make - without problems. [2002-05-07 19:29:23] [EMAIL PROTECTED] Did you use a special Apache layout? Does the httpd.exp file exist anywhere in your apache install tree? (I would expect it to be in $prefix/modules/httpd.exp) I won't mark this closed yet, but it seems likely to be a problem with Apache 2.0.35's apxs, and you might want to try using 2.0.36. [2002-04-23 00:11:11] [EMAIL PROTECTED] Reclassified. (and changed the summary) Those 'incorrect file..' warnings can be ignored. 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/16692 -- Edit this bug report at http://bugs.php.net/?id=16692edit=1
#10108 [Com]: cc 1501:218 file XXX contains an incorrect file suffix
ID: 10108 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: Compile Failure Operating System: AIX V4.3.3 PHP Version: 4.3.0-dev New Comment: This does not look like quite the same bug to me as #14245, and I suggest the following might resolve this bug: Our PHP 4.3.0 build failed to compile sapi/cli/php on our AIX machine, with over one hundred error messages like: cc: 1501-218 file ext/ctype/ctype.lo contains an incorrect file suffix The causes of this are rather subtle: 1. GNU libtool will usually not create static objects under AIX. 2. But the PHP developers want libtool to create static objects. 3. So the PHP developers provide their own ./libtool in the source tree which will create them, which they run with /bin/sh libtool. 4. Unfortunately, while /bin/sh file usually looks for file in the current directory before searching through $PATH, on AIX it looks through $PATH first; thus the PHP Makefile winds up running /usr/local/bin/libtool (or wherever you have it installed) instead. Thus the solution is to modify the PHP Makefile so that the line LIBTOOL = $(SHELL) libtool --silent instead reads LIBTOOL = $(SHELL) ./libtool --silent Technical notes: When you compile and install libtool, it runs a script called libtool.m4 which, around line 2363 in the libtool-1.4.3 source, disables AIX static linking with the explanation that: On AIX, shared libraries and static libraries use the same namespace, and are all built from PIC. It disables static linking by setting enable_static=no when it writes your libtool script; the ./libtool script in the PHP build directory works precisely because this variable is set to yes instead. Previous Comments: [2003-01-20 16:56:24] [EMAIL PROTECTED] I'm bogusing this since this is again the same bug as is reported in http://bugs.php.net/bug.php?id=14245 Please add any useful comments with extra info to that report instead. Thank you. [2002-08-03 01:00:10] [EMAIL PROTECTED] No feedback was provided for this bug for over a month, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to Open. [2002-07-08 10:22:34] [EMAIL PROTECTED] Sorry, don't checked the right directory. .libs/ directory contains : libphp4.a libphp4.exp libphp4.la-../libphp4.la libphp4.lai libphp4.so.0 [2002-07-08 10:20:14] [EMAIL PROTECTED] The ./libs directory is empty at this end of the compilation. [2002-07-02 20:29:31] [EMAIL PROTECTED] After compile..do you have anything in .libs/ ? 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/10108 -- Edit this bug report at http://bugs.php.net/?id=10108edit=1
#21819 [Opn-Fbk]: Corrupted uploaded binary files
ID: 21819 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: HTTP related Operating System: Linux RedHar 8.0 PHP Version: 4.3.0 New Comment: Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to Open. Thank you for your interest in PHP. Please provide the script you are using to upload the files and the script used to handle the actual files uploads. Previous Comments: [2003-01-22 08:59:41] [EMAIL PROTECTED] When uploading binary files (about 5kB and up), they get corrupted, not the whole file but some way from the beginning. The size is increased about 90%, actual number of bytes varies with different browsers. PHP versions tried: 4.3.0 and 4.3.1-dev (200301211230). Configured with './configure' '--with-apxs2' '--with-openssl' '--enable-calendar' '--with-curl' '--with-gd' '--with-jpeg-dir=/usr/lib' '--with-png-dir=/usr/lib' '--enable-mime-magic' '--with-mysql' '--enable-magic-quotes' '--with-zlib-dir=/usr/lib' '--with-config-file-path=/etc' Apache version: 2.0.43 -- Edit this bug report at http://bugs.php.net/?id=21819edit=1
#21825 [Opn-Csd]: Fatal error: Nesting level too deep
ID: 21825 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: Reproducible crash Operating System: Linux 2.4.19 PHP Version: 4.3.0 New Comment: Strange, but pointing extension_dir to /usr/local/lib/php/extension (which doesn't seem to contain anything useful) as opposed to /usr/lib/php/extensions seems to have fixed the issue. I saw those other reports, but had compiled (or I thought) 4.3.0 successfully before. Previous Comments: [2003-01-22 15:04:01] [EMAIL PROTECTED] Can you please find the extension_dir setting in your php.ini and make sure that it points to the directory with your newly built modules? There have been reports where this Nesting level too deep was caused by an extension_dir that pointed to the modules of a previous PHP installation. [2003-01-22 14:31:54] [EMAIL PROTECTED] This error occurs at the bottom of every PHP-parsed page: Fatal error: Nesting level too deep - recursive dependency? in Unknown on line 0 The pages seem to render okay, but the error appears to end each page. It even spit out the same error dozens of times on make test, and after sending in the test results. ./configure --with-apxs=/usr/local/apache/bin/apxs --enable-trans-sid --enable-track-vars --with-gd --with-pdflib --with-jpeg-dir --with-tiff-dir --with-pspell --with-freetype-dir --enable-gd-native-ttf --with-png-dir --with-zlib-dir --with-ttf --with-mysql=/usr/local/mysql The system is MDK9 and Apache 1.3.26 -- Edit this bug report at http://bugs.php.net/?id=21825edit=1
#21823 [Opn-Fbk]: improperly detecting gcc3 as cross compiler
ID: 21823 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: Compile Failure Operating System: Gentoo Linux 1.4 PHP Version: 4.3.0 New Comment: Change -march=i686 to -march=pentium2 and try again. Previous Comments: [2003-01-22 12:54:58] [EMAIL PROTECTED] When installing PHP 4.3 on my system running GCC 3.2.1, I get the following output. This is obviously incorrect. If you need any further info, please ask. arsenic root # emerge php Calculating dependencies ...done! emerge (1 of 1) dev-php/php-4.3.0-r2 to / md5 ;-) php-4.3.0.tar.bz2 Unpacking source... Unpacking php-4.3.0.tar.bz2 Source unpacked. ssl gdbm mysql truetype jpeg Compiling imap with SSL support libwww flash xml2 crypt creating cache ./config.cache checking for Cygwin environment... no checking for mingw32 environment... no checking for working sed... sed checking host system type... i686-pc-linux-gnu Updated php_version.h checking for gcc... gcc checking whether the C compiler (gcc -march=i686 -O3 -pipe ) works... yes checking whether the C compiler (gcc -march=i686 -O3 -pipe ) is a cross-compiler... yes checking whether we are using GNU C... yes checking whether gcc accepts -g... yes checking whether gcc and cc understand -c and -o together... yes checking how to run the C preprocessor... gcc -E checking for AIX... no checking if compiler supports -R... no checking if compiler supports -Wl,-rpath,... yes checking for ranlib... ranlib checking whether ln -s works... yes checking for gawk... gawk checking for bison... bison -y checking bison version... 1.35 (ok) checking for flex... flex checking for yywrap in -lfl... yes checking lex output file root... lex.yy checking whether yytext is a pointer... yes checking for working const... yes checking flex version... 2.5.4 (ok) checking for pthreads_cflags... checking for pthreads_lib... Configuring SAPI modules checking for AOLserver support... no checking for Apache 1.x module support via DSO through APXS... no checking for Apache 1.x module support... no checking for mod_charset compatibility option... no checking for Apache 2.0 module support via DSO through APXS... no checking for Caudium support... no checking for CLI build... yes checking for embedded SAPI library support... no checking for Zeus ISAPI support... no checking for NSAPI support... no checking for PHTTPD support... no checking for Pi3Web support... no checking for Roxen/Pike support... no checking for Servlet support... no checking for thttpd... no checking for TUX... no checking for webjames... no checking for CGI build... no checking for chosen SAPI module... cli Running system checks checking for missing declarations of reentrant functions... done checking for sendmail... /usr/sbin/sendmail checking whether system uses EBCDIC... no checking for socket... yes checking for htonl... yes checking for gethostname... yes checking for gethostbyaddr... yes checking for yp_get_default_domain... no checking for __yp_get_default_domain... no checking for yp_get_default_domain in -lnsl... yes checking for dlopen... yes checking for sin in -lm... yes checking for res_search... no checking for __res_search... no checking for res_search in -lresolv... yes checking for res_search in -lbind... no checking for __res_search in -lbind... no checking for res_search in -lsocket... no checking for __res_search in -lsocket... no checking for inet_aton... yes checking for dn_skipname... no checking for __dn_skipname... no checking for dn_skipname in -lresolv... no checking for __dn_skipname in -lresolv... yes checking for dn_skipname in -lbind... no checking for __dn_skipname in -lbind... no checking for ANSI C header files... yes checking for dirent.h that defines DIR... yes checking for opendir in -ldir... no checking for fclose declaration... ok checking for ApplicationServices/ApplicationServices.h... no checking for sys/types.h... yes checking for sys/time.h... yes checking for netinet/in.h... yes checking for alloca.h... yes checking for arpa/inet.h... yes checking for arpa/nameser.h... yes checking for assert.h... yes checking for crypt.h... yes checking for fcntl.h... yes checking for grp.h... yes checking for ieeefp.h... no checking for langinfo.h... yes checking for limits.h... yes checking for locale.h... yes checking for monetary.h... yes checking for mach-o/dyld.h... no checking for netdb.h... yes checking for pwd.h... yes checking for resolv.h... yes checking for signal.h... yes checking for stdarg.h... yes checking for stdlib.h... yes checking for string.h... yes checking for syslog.h... yes checking for sysexits.h... yes checking for sys/file.h... yes checking for sys/mman.h... yes checking for
#21817 [Opn-Fbk]: Error to compile php 4.2.3 in make phase
ID: 21817 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: Compile Failure Operating System: Linux Conectiva 8 PHP Version: 4.2.3 New Comment: What version of c-client are you using? Previous Comments: [2003-01-22 10:28:04] [EMAIL PROTECTED] I get the latest version and try to compile and get the following error: gcc -Iext/imap/ -I/usr/src/php/ext/imap/ -DPHP_ATOM_INC -I/usr/src/php/include -I/usr/src/php/main -I/usr/src/php -I/usr/src/php/Zend -I/usr/include/imap -I/usr/local/include -I/usr/src/mysql-3.23.54a/include -I/usr/src/php/ext/xml/expat -I/usr/src/php/TSRM -g -O2 -c /usr/src/php/ext/imap/php_imap.c -o ext/imap/php_imap.o echo ext/imap/php_imap.lo /usr/src/php/ext/imap/php_imap.c: In function `zm_startup_imap': /usr/src/php/ext/imap/php_imap.c:424: `auth_gss' undeclared (first use in this function) /usr/src/php/ext/imap/php_imap.c:424: (Each undeclared identifier is reported only once /usr/src/php/ext/imap/php_imap.c:424: for each function it appears in.) make: *** [ext/imap/php_imap.lo] Error 1 [2003-01-22 08:08:11] [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-01-22 07:45:52] [EMAIL PROTECTED] I do ./configure with this parameters: '--prefix=/usr/bin' \ '--disable-debug' \ '--enable-pic' \ '--enable-inline-optimization' \ '--enable-shared' \ '--disable-static' \ '--with-config-file-path=/etc/php4/apache' \ '--with-exec-dir=/usr/bin' \ '--with-regex=system' \ '--with-gettext' \ '--with-png' \ '--with-zlib' \ '--enable-magic-quotes' \ '--enable-safe-mode' \ '--enable-sockets' \ '--enable-sysvsem' \ '--enable-sysvshm' \ '--enable-track-vars' \ '--enable-wddx' \ '--enable-snmp' \ '--enable-ftp' \ '--enable-bcmath' \ '--with-mysql=/usr/src/mysql-3.23.54a' \ '--without-unixODBC' \ '--with-xml' \ '--with-imap' \ '--with-mcrypt=/usr/lib/libmcrypt' \ '--with-readline=/usr/src/readline-4.3' all it´s ok until now, but when I run 'make' this error occurs: root@ php-4.2.3]# make Making all in Zend /bin/sh: cd: Zend: File or directory not found make: *** [all-recursive] Error 1 But Zend directory is there ... Thanks in advance -- Edit this bug report at http://bugs.php.net/?id=21817edit=1
#21824 [Opn]: PHP-Based AIM Bot
ID: 21824 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Feature/Change Request Operating System: all PHP Version: 4.3.0 New Comment: heh, well, I'm no PEAR developer so I guess I'll need to wait for someone else. Previous Comments: [2003-01-22 14:26:01] [EMAIL PROTECTED] Speak of the devil, I was just thinking of this on my way home last night (well, ICQ technically, but the idea is the same). The conclusion I came to, and others may feel free to disagree with me, is that such modules are best built as PEAR classes rather than PHP extensions. The fact that you're now mentioning that Perl has it as a PEAR-equivalent style module just bolsters that position. If you feel adventurous, I'd recommend working on the conversion yourself. You've got the basic framework to start from in Perl's Net::AIM module, it simply needs to be built into a PHP class. [2003-01-22 14:12:35] [EMAIL PROTECTED] Any thoughts on converting the Perl Net::AIM module to PHP? I think it would be great to be able to code an AIM bot in PHP. has this been discussed regarding the possibility of converting the AIM protocols and make it an option for compiling into PHP? -- Edit this bug report at http://bugs.php.net/?id=21824edit=1
#21819 [Fbk-Opn]: Corrupted uploaded binary files
ID: 21819
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: Open
Bug Type: HTTP related
Operating System: Linux RedHar 8.0
PHP Version: 4.3.0
New Comment:
The script goes like this:
html
body
?
echo $_FILES['userfile']['name']. ;
echo $_FILES['userfile']['type']. ;
echo $_FILES['userfile']['size']. ;
echo $_FILES['userfile']['tmp_name']. ;
echo $_FILES['userfile']['error']. ;
if (move_uploaded_file($_FILES['userfile']['tmp_name'],
/var/www/hosts/se8.org/htdocs/temp/image.jpg)) {
echo moved;
} else {
echo not_moved;
}
?
p
form action=test.php method=post enctype=multipart/form-data
input type=file name=userfile
input type=submit
/form
/body
/html
When I upload a 11463 byte image, it grows to 22575 bytes and corrutps.
Previous Comments:
[2003-01-22 15:44:58] [EMAIL PROTECTED]
Not enough information was provided for us to be able
to handle this bug. Please re-read the instructions at
http://bugs.php.net/how-to-report.php
If you can provide more information, feel free to add it
to this bug and change the status back to Open.
Thank you for your interest in PHP.
Please provide the script you are using to upload the files and the
script used to handle the actual files uploads.
[2003-01-22 08:59:41] [EMAIL PROTECTED]
When uploading binary files (about 5kB and up), they get corrupted, not
the whole file but some way from the beginning. The size is increased
about 90%, actual number of bytes varies with different browsers.
PHP versions tried: 4.3.0 and 4.3.1-dev (200301211230).
Configured with './configure' '--with-apxs2' '--with-openssl'
'--enable-calendar' '--with-curl' '--with-gd'
'--with-jpeg-dir=/usr/lib' '--with-png-dir=/usr/lib'
'--enable-mime-magic' '--with-mysql' '--enable-magic-quotes'
'--with-zlib-dir=/usr/lib' '--with-config-file-path=/etc'
Apache version: 2.0.43
--
Edit this bug report at http://bugs.php.net/?id=21819edit=1
#21823 [Fbk-Opn]: improperly detecting gcc as cross compiler
ID: 21823 User updated by: [EMAIL PROTECTED] -Summary: improperly detecting gcc3 as cross compiler Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: Compile Failure Operating System: Gentoo Linux 1.4 PHP Version: 4.3.0 New Comment: Ack. I'm running too many servers. I was wrong about this one running GCC 3.2.1. It's still running 2.95 version. I've included the output of gcc -v below. Sorry for the confusion! Reading specs from /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/specs gcc version 2.95.3 20010315 (release) Previous Comments: [2003-01-22 15:47:57] [EMAIL PROTECTED] Change -march=i686 to -march=pentium2 and try again. [2003-01-22 12:54:58] [EMAIL PROTECTED] When installing PHP 4.3 on my system running GCC 3.2.1, I get the following output. This is obviously incorrect. If you need any further info, please ask. arsenic root # emerge php Calculating dependencies ...done! emerge (1 of 1) dev-php/php-4.3.0-r2 to / md5 ;-) php-4.3.0.tar.bz2 Unpacking source... Unpacking php-4.3.0.tar.bz2 Source unpacked. ssl gdbm mysql truetype jpeg Compiling imap with SSL support libwww flash xml2 crypt creating cache ./config.cache checking for Cygwin environment... no checking for mingw32 environment... no checking for working sed... sed checking host system type... i686-pc-linux-gnu Updated php_version.h checking for gcc... gcc checking whether the C compiler (gcc -march=i686 -O3 -pipe ) works... yes checking whether the C compiler (gcc -march=i686 -O3 -pipe ) is a cross-compiler... yes checking whether we are using GNU C... yes checking whether gcc accepts -g... yes checking whether gcc and cc understand -c and -o together... yes checking how to run the C preprocessor... gcc -E checking for AIX... no checking if compiler supports -R... no checking if compiler supports -Wl,-rpath,... yes checking for ranlib... ranlib checking whether ln -s works... yes checking for gawk... gawk checking for bison... bison -y checking bison version... 1.35 (ok) checking for flex... flex checking for yywrap in -lfl... yes checking lex output file root... lex.yy checking whether yytext is a pointer... yes checking for working const... yes checking flex version... 2.5.4 (ok) checking for pthreads_cflags... checking for pthreads_lib... Configuring SAPI modules checking for AOLserver support... no checking for Apache 1.x module support via DSO through APXS... no checking for Apache 1.x module support... no checking for mod_charset compatibility option... no checking for Apache 2.0 module support via DSO through APXS... no checking for Caudium support... no checking for CLI build... yes checking for embedded SAPI library support... no checking for Zeus ISAPI support... no checking for NSAPI support... no checking for PHTTPD support... no checking for Pi3Web support... no checking for Roxen/Pike support... no checking for Servlet support... no checking for thttpd... no checking for TUX... no checking for webjames... no checking for CGI build... no checking for chosen SAPI module... cli Running system checks checking for missing declarations of reentrant functions... done checking for sendmail... /usr/sbin/sendmail checking whether system uses EBCDIC... no checking for socket... yes checking for htonl... yes checking for gethostname... yes checking for gethostbyaddr... yes checking for yp_get_default_domain... no checking for __yp_get_default_domain... no checking for yp_get_default_domain in -lnsl... yes checking for dlopen... yes checking for sin in -lm... yes checking for res_search... no checking for __res_search... no checking for res_search in -lresolv... yes checking for res_search in -lbind... no checking for __res_search in -lbind... no checking for res_search in -lsocket... no checking for __res_search in -lsocket... no checking for inet_aton... yes checking for dn_skipname... no checking for __dn_skipname... no checking for dn_skipname in -lresolv... no checking for __dn_skipname in -lresolv... yes checking for dn_skipname in -lbind... no checking for __dn_skipname in -lbind... no checking for ANSI C header files... yes checking for dirent.h that defines DIR... yes checking for opendir in -ldir... no checking for fclose declaration... ok checking for ApplicationServices/ApplicationServices.h... no checking for sys/types.h... yes checking for sys/time.h... yes checking for netinet/in.h... yes checking for alloca.h... yes checking for arpa/inet.h... yes checking for arpa/nameser.h... yes checking for assert.h... yes checking for crypt.h... yes checking for fcntl.h... yes checking for grp.h... yes checking for ieeefp.h... no checking for langinfo.h... yes checking
#21824 [Opn-Csd]: PHP-Based AIM Bot
ID: 21824 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: Feature/Change Request Operating System: all PHP Version: 4.3.0 New Comment: This is not a bug system for suggestions for new PEAR classes. Try your concerns on the pear-dev list. And there should be nothing stopping you from being a PEAR developer. They don't bite. Previous Comments: [2003-01-22 16:03:01] [EMAIL PROTECTED] heh, well, I'm no PEAR developer so I guess I'll need to wait for someone else. [2003-01-22 14:26:01] [EMAIL PROTECTED] Speak of the devil, I was just thinking of this on my way home last night (well, ICQ technically, but the idea is the same). The conclusion I came to, and others may feel free to disagree with me, is that such modules are best built as PEAR classes rather than PHP extensions. The fact that you're now mentioning that Perl has it as a PEAR-equivalent style module just bolsters that position. If you feel adventurous, I'd recommend working on the conversion yourself. You've got the basic framework to start from in Perl's Net::AIM module, it simply needs to be built into a PHP class. [2003-01-22 14:12:35] [EMAIL PROTECTED] Any thoughts on converting the Perl Net::AIM module to PHP? I think it would be great to be able to code an AIM bot in PHP. has this been discussed regarding the possibility of converting the AIM protocols and make it an option for compiling into PHP? -- Edit this bug report at http://bugs.php.net/?id=21824edit=1
#21823 [Opn-Fbk]: improperly detecting gcc as cross compiler
ID: 21823 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: Compile Failure Operating System: Gentoo Linux 1.4 PHP Version: 4.3.0 New Comment: In that case remove -pipe and try again. Previous Comments: [2003-01-22 16:16:35] [EMAIL PROTECTED] Ack. I'm running too many servers. I was wrong about this one running GCC 3.2.1. It's still running 2.95 version. I've included the output of gcc -v below. Sorry for the confusion! Reading specs from /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/specs gcc version 2.95.3 20010315 (release) [2003-01-22 15:47:57] [EMAIL PROTECTED] Change -march=i686 to -march=pentium2 and try again. [2003-01-22 12:54:58] [EMAIL PROTECTED] When installing PHP 4.3 on my system running GCC 3.2.1, I get the following output. This is obviously incorrect. If you need any further info, please ask. arsenic root # emerge php Calculating dependencies ...done! emerge (1 of 1) dev-php/php-4.3.0-r2 to / md5 ;-) php-4.3.0.tar.bz2 Unpacking source... Unpacking php-4.3.0.tar.bz2 Source unpacked. ssl gdbm mysql truetype jpeg Compiling imap with SSL support libwww flash xml2 crypt creating cache ./config.cache checking for Cygwin environment... no checking for mingw32 environment... no checking for working sed... sed checking host system type... i686-pc-linux-gnu Updated php_version.h checking for gcc... gcc checking whether the C compiler (gcc -march=i686 -O3 -pipe ) works... yes checking whether the C compiler (gcc -march=i686 -O3 -pipe ) is a cross-compiler... yes checking whether we are using GNU C... yes checking whether gcc accepts -g... yes checking whether gcc and cc understand -c and -o together... yes checking how to run the C preprocessor... gcc -E checking for AIX... no checking if compiler supports -R... no checking if compiler supports -Wl,-rpath,... yes checking for ranlib... ranlib checking whether ln -s works... yes checking for gawk... gawk checking for bison... bison -y checking bison version... 1.35 (ok) checking for flex... flex checking for yywrap in -lfl... yes checking lex output file root... lex.yy checking whether yytext is a pointer... yes checking for working const... yes checking flex version... 2.5.4 (ok) checking for pthreads_cflags... checking for pthreads_lib... Configuring SAPI modules checking for AOLserver support... no checking for Apache 1.x module support via DSO through APXS... no checking for Apache 1.x module support... no checking for mod_charset compatibility option... no checking for Apache 2.0 module support via DSO through APXS... no checking for Caudium support... no checking for CLI build... yes checking for embedded SAPI library support... no checking for Zeus ISAPI support... no checking for NSAPI support... no checking for PHTTPD support... no checking for Pi3Web support... no checking for Roxen/Pike support... no checking for Servlet support... no checking for thttpd... no checking for TUX... no checking for webjames... no checking for CGI build... no checking for chosen SAPI module... cli Running system checks checking for missing declarations of reentrant functions... done checking for sendmail... /usr/sbin/sendmail checking whether system uses EBCDIC... no checking for socket... yes checking for htonl... yes checking for gethostname... yes checking for gethostbyaddr... yes checking for yp_get_default_domain... no checking for __yp_get_default_domain... no checking for yp_get_default_domain in -lnsl... yes checking for dlopen... yes checking for sin in -lm... yes checking for res_search... no checking for __res_search... no checking for res_search in -lresolv... yes checking for res_search in -lbind... no checking for __res_search in -lbind... no checking for res_search in -lsocket... no checking for __res_search in -lsocket... no checking for inet_aton... yes checking for dn_skipname... no checking for __dn_skipname... no checking for dn_skipname in -lresolv... no checking for __dn_skipname in -lresolv... yes checking for dn_skipname in -lbind... no checking for __dn_skipname in -lbind... no checking for ANSI C header files... yes checking for dirent.h that defines DIR... yes checking for opendir in -ldir... no checking for fclose declaration... ok checking for ApplicationServices/ApplicationServices.h... no checking for sys/types.h... yes checking for sys/time.h... yes checking for netinet/in.h... yes checking for alloca.h... yes checking for arpa/inet.h... yes checking for arpa/nameser.h... yes checking for assert.h... yes checking for crypt.h... yes checking for fcntl.h... yes
#21823 [Fbk-Opn]: improperly detecting gcc as cross compiler
ID: 21823 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: Compile Failure Operating System: Gentoo Linux 1.4 PHP Version: 4.3.0 New Comment: Okay, I tried that first. Here's the interesting parts of the configure output: CLIP checking for gcc... gcc checking whether the C compiler (gcc -march=i686 -O3 ) works... yes checking whether the C compiler (gcc -march=i686 -O3 ) is a cross-compiler... yes CLIP checking for fopencookie... yes configure: error: can not run test program while cross compiling !!! ERROR: dev-php/php-4.3.0-r2 failed. !!! Function src_compile, Line 137, Exitcode 1 !!! bad ./configure That failing, I decided to try stripping of the -O3 as well, just in case. Here's the interesting output from that: CLIP checking for gcc... gcc checking whether the C compiler (gcc -march=i686 ) works... yes checking whether the C compiler (gcc -march=i686 ) is a cross-compiler... yes CLIP checking for fopencookie... yes configure: error: can not run test program while cross compiling !!! ERROR: dev-php/php-4.3.0-r2 failed. !!! Function src_compile, Line 137, Exitcode 1 !!! bad ./configure As you can see, there is absolutely no change happening here. The only thing I can think of that /might/ have caused this, although I have no idea how, is that I did just install MySQL 4 on my box. When I went to reinstall PHP to link it to the new libs, I noticed this problem. Previous Comments: [2003-01-22 16:22:28] [EMAIL PROTECTED] In that case remove -pipe and try again. [2003-01-22 16:16:35] [EMAIL PROTECTED] Ack. I'm running too many servers. I was wrong about this one running GCC 3.2.1. It's still running 2.95 version. I've included the output of gcc -v below. Sorry for the confusion! Reading specs from /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/specs gcc version 2.95.3 20010315 (release) [2003-01-22 15:47:57] [EMAIL PROTECTED] Change -march=i686 to -march=pentium2 and try again. [2003-01-22 12:54:58] [EMAIL PROTECTED] When installing PHP 4.3 on my system running GCC 3.2.1, I get the following output. This is obviously incorrect. If you need any further info, please ask. arsenic root # emerge php Calculating dependencies ...done! emerge (1 of 1) dev-php/php-4.3.0-r2 to / md5 ;-) php-4.3.0.tar.bz2 Unpacking source... Unpacking php-4.3.0.tar.bz2 Source unpacked. ssl gdbm mysql truetype jpeg Compiling imap with SSL support libwww flash xml2 crypt creating cache ./config.cache checking for Cygwin environment... no checking for mingw32 environment... no checking for working sed... sed checking host system type... i686-pc-linux-gnu Updated php_version.h checking for gcc... gcc checking whether the C compiler (gcc -march=i686 -O3 -pipe ) works... yes checking whether the C compiler (gcc -march=i686 -O3 -pipe ) is a cross-compiler... yes checking whether we are using GNU C... yes checking whether gcc accepts -g... yes checking whether gcc and cc understand -c and -o together... yes checking how to run the C preprocessor... gcc -E checking for AIX... no checking if compiler supports -R... no checking if compiler supports -Wl,-rpath,... yes checking for ranlib... ranlib checking whether ln -s works... yes checking for gawk... gawk checking for bison... bison -y checking bison version... 1.35 (ok) checking for flex... flex checking for yywrap in -lfl... yes checking lex output file root... lex.yy checking whether yytext is a pointer... yes checking for working const... yes checking flex version... 2.5.4 (ok) checking for pthreads_cflags... checking for pthreads_lib... Configuring SAPI modules checking for AOLserver support... no checking for Apache 1.x module support via DSO through APXS... no checking for Apache 1.x module support... no checking for mod_charset compatibility option... no checking for Apache 2.0 module support via DSO through APXS... no checking for Caudium support... no checking for CLI build... yes checking for embedded SAPI library support... no checking for Zeus ISAPI support... no checking for NSAPI support... no checking for PHTTPD support... no checking for Pi3Web support... no checking for Roxen/Pike support... no checking for Servlet support... no checking for thttpd... no checking for TUX... no checking for webjames... no checking for CGI build... no checking for chosen SAPI module... cli Running system checks checking for missing declarations of reentrant functions... done checking for sendmail... /usr/sbin/sendmail checking whether system uses EBCDIC...
#21826 [NEW]: variables dont return value even if they are seen in phpinfo()
From: [EMAIL PROTECTED] Operating system: windows 2000 PHP version: 4.2.3 PHP Bug Type: *General Issues Bug description: variables dont return value even if they are seen in phpinfo() My IIS5 crashes, and after reinstaling it, I can make any query to MySQL base, or get any calculation on primary page, but when I want some variable to PUT or GET to another script, I don't get it's value. Another thing, when put on beggining of page command PHPINFO () i see variables and it's values but scripts dont get them. Also I have been enabled REGISTER_GLOBALS in my Ini file. Please help me to solve this problem. -- Edit bug report at http://bugs.php.net/?id=21826edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21826r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21826r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21826r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21826r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21826r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21826r=support Expected behavior: http://bugs.php.net/fix.php?id=21826r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21826r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21826r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21826r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21826r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21826r=dst IIS Stability: http://bugs.php.net/fix.php?id=21826r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=21826r=gnused
#21533 [Opn-Fbk]: Trouble building PHP w/ GD and including ImageTTFxxx functions
ID: 21533 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: GD related Operating System: RH 7.2 PHP Version: 4.3.0 New Comment: If you change char *error; to char *error = NULL; does the segmentation fault you are seeing go away? Previous Comments: [2003-01-22 13:57:11] [EMAIL PROTECTED] The version of gd.c that I have is supposed to be 4.3.0. I still believe it is incorrect. If you are referring to the statement: Line 2951: #else /* !USE_GD_IMGSTRTTF */ that 'else' is related to a USE_GD_IMGSTRTTF and is not the same as any HAVE_GD_STRINGxxx defines. I'm saying that if USE_GD_IMGSTRTTF *is* defined, but neither HAVE_GD_STRINGFT nor HAVE_GD_STRINGTTF is defined, it will leave the variable 'error' undefined, and then try to use it (resulting in the possibility of a crash). Do you still disagree? [2003-01-21 14:20:13] [EMAIL PROTECTED] The ifdef is correct, because no matter what the value will be assigned to error. There is another ifdef surrounding this code which has an else condition that is used to set a value to error. So the crash you are seeing comes from elsewhere. [2003-01-21 09:28:38] [EMAIL PROTECTED] PHP build: configure --with-apxs=/usr/local/apache/bin/apxs --with-mysql=/usr/local/mysql --enable-track-vars --with-imap=/usr/local/imap --with-gd --enable-ftp --enable-sysvsem --enable-sysvshm --enable-sockets --with-gettext --with-mm=/usr/local/lib/mm --with-jpeg-dir=/usr/lib --with-zlib-dir=/usr/local --with-openssl=/usr/local/ssl --with-ttf --enable-gd-native-ttf --enable-gd-imgstrttf --with-freetype-dir=/usr/local --with-dom FreeType: freetype-1.3.1.tar.gz was untarred and built and installed with: configure make make install [2003-01-20 17:11:22] [EMAIL PROTECTED] What was the configure line ? And exactly what freetype 1.x version was installed? And how? [2003-01-20 16:48:08] [EMAIL PROTECTED] I'm really not a Linux developer, and although what you are asking for sounds easy enough, I don't know how to give you what you want. I would like to reiterate that there are 2 issues here: 1. Configure incorrectly reporting my support for FreeType2 2. gd.c has code that given certain #if conditions, leaves the variable 'error' undefined. The crash is occuring because of the reference to this floating pointer. I assume you want a backtrace to determine the line of code that is crashing, but I'm *giving* you the line of code that is crashing. 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/21533 -- Edit this bug report at http://bugs.php.net/?id=21533edit=1
#21262 [Opn-Bgs]: crash or fail when outputting large amounts of text quickly
ID: 21262 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Reproducible crash Operating System: WinXP PHP Version: 4.3.0 New Comment: Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php I've explained before and I will attempt to explain once again. When output buffering is turned on the system does not output the text right away but rather fills up a memory buffer that is displayed in one large block. If the text you are trying to output exceeds the avaliable system memory then the error you are seeing will occur. This cannot be helped, the solution is to either disable output buffering or not use things like gz_handler, which cause ALL of the output to be buffered in memory rather then output the data in chunks (default chunk size 4096 bytes). Previous Comments: [2003-01-16 10:20:56] [EMAIL PROTECTED] This bug has been present for over a year, maybe since the beginning of PHP. We're still getting people passing the buck.. [2003-01-15 16:44:33] [EMAIL PROTECTED] I am using Apache version 2.0.43 with the sapi php module. I downloaded the latest stable snapshot of php (4.3.1) but it still reproduced the same orignial problem discussed. Regards [2003-01-14 19:25:17] [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 (and what apache version is it?) [2003-01-14 13:34:57] [EMAIL PROTECTED] I can confirm this bug including the for loop provided earlier in this bug thread. I am using php 4.3.0 with Apache 2.0.43 with Windows XP Home Edition. I found this bug report after noticing the same effect with a large piece of php that I have been writing. I have found that turning off error reporting in php.ini helps but does not solve the problem totally. I found that using the flush() function helped but was not a reliable solution. This seems a blatant problem which is making debugging and development almost impossible and very frustrating. Is there any update on confirming the bug? Regards [2003-01-10 23:42:44] [EMAIL PROTECTED] Ridiculous.. how on earth can they look at this: PHP Fatal error: Allowed memory size of 8388608 bytes exhausted (tried to allocate 10240 bytes) And say its a bug in IE? I agree with the first assesment - this is a likely a CRITICAL bug. I have seen pages fail for no reason on linux too, who knows if this problem could be responsible. This needs to be looked at by someone at the top. 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/21262 -- Edit this bug report at http://bugs.php.net/?id=21262edit=1
#21812 [Opn-Fbk]: Apache crashes when require_once has array in directory name
ID: 21812
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Feedback
Bug Type: Reproducible crash
Operating System: Win2000
PHP Version: 4.3.0
New Comment:
Has the change on memory_limit entry solved the require_once problem
too?
Previous Comments:
[2003-01-21 21:27:16] [EMAIL PROTECTED]
memory_limit = 80M
in php.ini fixed the XML process error. It can now read the full XML
file without blowing up Apache.
[2003-01-21 21:07:24] [EMAIL PROTECTED]
I found a new error causing the same error message from Apache 2. This
error is from an XML processing loop. I think the Apache 2 error
message must be issued any time Apache runs out of memory. Perhaps PHP
is trampling over the end of it's memory allocation or something
similar.
I will try a few more tests then increase PHP's memory allocation in
php.ini and see if that fixes the problem.
[2003-01-21 20:26:06] [EMAIL PROTECTED]
require_once();
Parse error: parse error, unexpected ')' in C:\webapps\display.php on
line 10
require_once('');
Fatal error: main() [function.main]: Failed opening required ''
(include_path='.;c:/include;c:/') in C:\webapps\display.php on line 10
require_once('cc');
Warning: main(cc) [function.main]: failed to create stream: No such
file or directory in C:\webapps\display.php on line 10
Fatal error: main() [function.main]: Failed opening required 'cc'
(include_path='.;c:/include;c:/') in C:\webapps\display.php on line 10
require_once(array('cc'));
Notice: Array to string conversion in C:\webapps\display.php on line
10
Warning: main(Array) [function.main]: failed to create stream: No such
file or directory in C:\webapps\display.php on line 10
Fatal error: main() [function.main]: Failed opening required 'Array'
(include_path='.;c:/include;c:/') in C:\webapps\display.php on line 10
The error does not occur when require_once() receives a simple non
string. The error occured when the non string was an array of varied
elements including other arrays and possibly objects. The error occured
repeatedly until I found the offending assignment statement.
I tried to reproduce the error on the first require_once in the script
but did not succeed. The original error was deep in a script with
several requires and some requires including scripts containing
requires. I have now changed the script to a less complicated set of
requires and may not be able to reproduce the depth.
It is possible the crash was caused by the requires looping on
themselves but that type of error usually requires a second or two
before Apache runs out of memory (currently over 500 Mb free). The
crashes were instant.
php.ini has nothing set to increase available memory or change safe
mode or anything else. It runs as a module.
[2003-01-21 19:38:21] [EMAIL PROTECTED]
Sorry, I just mistook the platform is *nix.
As I can't reproduce this on my Linux box, this problem is likely to
be Windows specific.
Does Apache segfault when giving a non-existent file name to
require_once()
rather than an array?
[2003-01-21 19:24:28] [EMAIL PROTECTED]
I looked at the instructions for backtrace. They do not translate to
Win2000. I will install Cygwin and see if the instructions work with
Win2000 Cygwin.
Our Unix systems have old releases of PHP and Apache so it might be a
while before I can reproduce the test on Unix.
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/21812
--
Edit this bug report at http://bugs.php.net/?id=21812edit=1
#21533 [Fbk-Opn]: Trouble building PHP w/ GD and including ImageTTFxxx functions
ID: 21533 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: GD related Operating System: RH 7.2 PHP Version: 4.3.0 New Comment: I would like to help you, but it would take some time to get my server back in the state where the error was occurring. I have since installed FreeType 2.x so that now things do build and work correctly. So, I can't confirm the fact that the crash would go away. But, since variable error is undefined, it easily could cause a crash. Certainly initializing it to NULL would improve the random nature of undefined variables. My original post was meant to help out the development of PHP by relaying my experience and pointing to specific lines of code that seem problematic. There is clearly a mistake in the gd.c code. You may choose not to do anything about it. And, it may not affect too many installations, but any decent software engineer would say that the code is risky at best. Previous Comments: [2003-01-22 17:08:34] [EMAIL PROTECTED] If you change char *error; to char *error = NULL; does the segmentation fault you are seeing go away? [2003-01-22 13:57:11] [EMAIL PROTECTED] The version of gd.c that I have is supposed to be 4.3.0. I still believe it is incorrect. If you are referring to the statement: Line 2951: #else /* !USE_GD_IMGSTRTTF */ that 'else' is related to a USE_GD_IMGSTRTTF and is not the same as any HAVE_GD_STRINGxxx defines. I'm saying that if USE_GD_IMGSTRTTF *is* defined, but neither HAVE_GD_STRINGFT nor HAVE_GD_STRINGTTF is defined, it will leave the variable 'error' undefined, and then try to use it (resulting in the possibility of a crash). Do you still disagree? [2003-01-21 14:20:13] [EMAIL PROTECTED] The ifdef is correct, because no matter what the value will be assigned to error. There is another ifdef surrounding this code which has an else condition that is used to set a value to error. So the crash you are seeing comes from elsewhere. [2003-01-21 09:28:38] [EMAIL PROTECTED] PHP build: configure --with-apxs=/usr/local/apache/bin/apxs --with-mysql=/usr/local/mysql --enable-track-vars --with-imap=/usr/local/imap --with-gd --enable-ftp --enable-sysvsem --enable-sysvshm --enable-sockets --with-gettext --with-mm=/usr/local/lib/mm --with-jpeg-dir=/usr/lib --with-zlib-dir=/usr/local --with-openssl=/usr/local/ssl --with-ttf --enable-gd-native-ttf --enable-gd-imgstrttf --with-freetype-dir=/usr/local --with-dom FreeType: freetype-1.3.1.tar.gz was untarred and built and installed with: configure make make install [2003-01-20 17:11:22] [EMAIL PROTECTED] What was the configure line ? And exactly what freetype 1.x version was installed? And how? 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/21533 -- Edit this bug report at http://bugs.php.net/?id=21533edit=1
#21823 [Opn-Csd]: improperly detecting gcc as cross compiler
ID: 21823 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: Compile Failure Operating System: Gentoo Linux 1.4 PHP Version: 4.3.0 New Comment: I just did some more testing, and building PHP outside of the Gentoo build system works fine, so this bug is with their build system, not with PHP itself. I'll take it up with them. Previous Comments: [2003-01-22 16:28:38] [EMAIL PROTECTED] Okay, I tried that first. Here's the interesting parts of the configure output: CLIP checking for gcc... gcc checking whether the C compiler (gcc -march=i686 -O3 ) works... yes checking whether the C compiler (gcc -march=i686 -O3 ) is a cross-compiler... yes CLIP checking for fopencookie... yes configure: error: can not run test program while cross compiling !!! ERROR: dev-php/php-4.3.0-r2 failed. !!! Function src_compile, Line 137, Exitcode 1 !!! bad ./configure That failing, I decided to try stripping of the -O3 as well, just in case. Here's the interesting output from that: CLIP checking for gcc... gcc checking whether the C compiler (gcc -march=i686 ) works... yes checking whether the C compiler (gcc -march=i686 ) is a cross-compiler... yes CLIP checking for fopencookie... yes configure: error: can not run test program while cross compiling !!! ERROR: dev-php/php-4.3.0-r2 failed. !!! Function src_compile, Line 137, Exitcode 1 !!! bad ./configure As you can see, there is absolutely no change happening here. The only thing I can think of that /might/ have caused this, although I have no idea how, is that I did just install MySQL 4 on my box. When I went to reinstall PHP to link it to the new libs, I noticed this problem. [2003-01-22 16:22:28] [EMAIL PROTECTED] In that case remove -pipe and try again. [2003-01-22 16:16:35] [EMAIL PROTECTED] Ack. I'm running too many servers. I was wrong about this one running GCC 3.2.1. It's still running 2.95 version. I've included the output of gcc -v below. Sorry for the confusion! Reading specs from /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/specs gcc version 2.95.3 20010315 (release) [2003-01-22 15:47:57] [EMAIL PROTECTED] Change -march=i686 to -march=pentium2 and try again. [2003-01-22 12:54:58] [EMAIL PROTECTED] When installing PHP 4.3 on my system running GCC 3.2.1, I get the following output. This is obviously incorrect. If you need any further info, please ask. arsenic root # emerge php Calculating dependencies ...done! emerge (1 of 1) dev-php/php-4.3.0-r2 to / md5 ;-) php-4.3.0.tar.bz2 Unpacking source... Unpacking php-4.3.0.tar.bz2 Source unpacked. ssl gdbm mysql truetype jpeg Compiling imap with SSL support libwww flash xml2 crypt creating cache ./config.cache checking for Cygwin environment... no checking for mingw32 environment... no checking for working sed... sed checking host system type... i686-pc-linux-gnu Updated php_version.h checking for gcc... gcc checking whether the C compiler (gcc -march=i686 -O3 -pipe ) works... yes checking whether the C compiler (gcc -march=i686 -O3 -pipe ) is a cross-compiler... yes checking whether we are using GNU C... yes checking whether gcc accepts -g... yes checking whether gcc and cc understand -c and -o together... yes checking how to run the C preprocessor... gcc -E checking for AIX... no checking if compiler supports -R... no checking if compiler supports -Wl,-rpath,... yes checking for ranlib... ranlib checking whether ln -s works... yes checking for gawk... gawk checking for bison... bison -y checking bison version... 1.35 (ok) checking for flex... flex checking for yywrap in -lfl... yes checking lex output file root... lex.yy checking whether yytext is a pointer... yes checking for working const... yes checking flex version... 2.5.4 (ok) checking for pthreads_cflags... checking for pthreads_lib... Configuring SAPI modules checking for AOLserver support... no checking for Apache 1.x module support via DSO through APXS... no checking for Apache 1.x module support... no checking for mod_charset compatibility option... no checking for Apache 2.0 module support via DSO through APXS... no checking for Caudium support... no checking for CLI build... yes checking for embedded SAPI library support... no checking for Zeus ISAPI support... no checking for NSAPI support... no checking for PHTTPD support... no checking for Pi3Web support... no checking for Roxen/Pike support... no checking for Servlet support... no checking for thttpd... no
#21812 [Fbk-Opn]: Apache crashes when require_once has array in directory name
ID: 21812
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: Open
Bug Type: Reproducible crash
Operating System: Win2000
PHP Version: 4.3.0
New Comment:
The require_once error has not occurred when using 80Mb.
The original require structure ended up including every component in
the system. I added a few if statements to include only those
components required for the script. The original mess might have used
up the default 8Mb of memory. My clean version probably uses less than
1 Mb for my code.
I am using the PHP binary compiled with all options. I think that comes
to about 4 Mb. If that 4 Mb is loaded in to the default 8Mb when
running PHP as a module then my original code would have easily used
the remaining 4 Mb. Changing the allocation to 80Mb may have, in
effect, increased available memory from 4 Mb to 76 Mb.
Previous Comments:
[2003-01-22 17:28:25] [EMAIL PROTECTED]
Has the change on memory_limit entry solved the require_once problem
too?
[2003-01-21 21:27:16] [EMAIL PROTECTED]
memory_limit = 80M
in php.ini fixed the XML process error. It can now read the full XML
file without blowing up Apache.
[2003-01-21 21:07:24] [EMAIL PROTECTED]
I found a new error causing the same error message from Apache 2. This
error is from an XML processing loop. I think the Apache 2 error
message must be issued any time Apache runs out of memory. Perhaps PHP
is trampling over the end of it's memory allocation or something
similar.
I will try a few more tests then increase PHP's memory allocation in
php.ini and see if that fixes the problem.
[2003-01-21 20:26:06] [EMAIL PROTECTED]
require_once();
Parse error: parse error, unexpected ')' in C:\webapps\display.php on
line 10
require_once('');
Fatal error: main() [function.main]: Failed opening required ''
(include_path='.;c:/include;c:/') in C:\webapps\display.php on line 10
require_once('cc');
Warning: main(cc) [function.main]: failed to create stream: No such
file or directory in C:\webapps\display.php on line 10
Fatal error: main() [function.main]: Failed opening required 'cc'
(include_path='.;c:/include;c:/') in C:\webapps\display.php on line 10
require_once(array('cc'));
Notice: Array to string conversion in C:\webapps\display.php on line
10
Warning: main(Array) [function.main]: failed to create stream: No such
file or directory in C:\webapps\display.php on line 10
Fatal error: main() [function.main]: Failed opening required 'Array'
(include_path='.;c:/include;c:/') in C:\webapps\display.php on line 10
The error does not occur when require_once() receives a simple non
string. The error occured when the non string was an array of varied
elements including other arrays and possibly objects. The error occured
repeatedly until I found the offending assignment statement.
I tried to reproduce the error on the first require_once in the script
but did not succeed. The original error was deep in a script with
several requires and some requires including scripts containing
requires. I have now changed the script to a less complicated set of
requires and may not be able to reproduce the depth.
It is possible the crash was caused by the requires looping on
themselves but that type of error usually requires a second or two
before Apache runs out of memory (currently over 500 Mb free). The
crashes were instant.
php.ini has nothing set to increase available memory or change safe
mode or anything else. It runs as a module.
[2003-01-21 19:38:21] [EMAIL PROTECTED]
Sorry, I just mistook the platform is *nix.
As I can't reproduce this on my Linux box, this problem is likely to
be Windows specific.
Does Apache segfault when giving a non-existent file name to
require_once()
rather than an array?
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/21812
--
Edit this bug report at http://bugs.php.net/?id=21812edit=1
#20142 [Opn-Bgs]: Session and EscapeShellCmd problem
ID: 20142 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Session related Operating System: Win 2K PHP Version: 4.2.3 New Comment: Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php EscapeShellCmd adds \ to the variable, which changes $test from b'lah to b\'lah nothing buggy or unusual about that. Previous Comments: [2002-11-25 16:08:21] [EMAIL PROTECTED] I have installed the win32 version listed above and still get the same problem. The session count of characters is still off. [2002-11-15 01:37:51] [EMAIL PROTECTED] let's keep this in feedback status then until we get the real feedback. [2002-11-14 20:41:55] [EMAIL PROTECTED] I tried using the http://snaps.php.net/win32/php4-win32-latest.zip download, but it crashed my system. I don't think it was the software. It was more likely the hardware. I am currently rebuilding the server and will try again when it is up. Thank you. [2002-11-14 01:47:41] [EMAIL PROTECTED] No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to Open. Thank you. [2002-10-28 17:46:17] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip 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/20142 -- Edit this bug report at http://bugs.php.net/?id=20142edit=1
#20320 [Opn-Fbk]: _call() crashes with bus error in some circumstances
ID: 20320
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Feedback
Bug Type: Zend Engine 2 problem
Operating System: OS X 10.1.5
PHP Version: 4CVS-2002-11-08
New Comment:
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
Previous Comments:
[2002-11-08 16:52:04] [EMAIL PROTECTED]
some kind of hashtable problem, looks like. variations on a simple
command-line class definition crash with a bus error, trying to catch
undefined method call with a __call() method.
here is backtrace showing some things that work and some that don't:
(gdb) r -r 'class foo { function __call($m,$a) { echo abcdefg\n;
return; } } $x = new foo; $x-nothere();'
Starting program: /usr/local/book/php4-ze2/sapi/cli/php -r 'class foo {
function __call($m,$a) { echo abcdefg\n; return; } } $x = new foo;
$x-nothere();'
[Switching to process 21057 thread 0x3413]
abcdefg
Program exited normally.
(gdb) r -r 'class foo { function __call($m,$a) { echo abcdef\n;
return; } } $x = new foo; $x-nothere();'
Starting program: /usr/local/book/php4-ze2/sapi/cli/php -r 'class foo {
function __call($m,$a) { echo abcdef\n; return; } } $x = new foo;
$x-nothere();'
[Switching to process 21062 thread 0x3713]
Program received signal EXC_BAD_ACCESS, Could not access memory.
0x001c06e0 in _zend_is_inconsistent (ht=0x0, file=0x208d38
/Users/tater/book/php4-ze2/Zend/zend_hash.c, line=871) at
/Users/tater/book/php4-ze2/Zend/zend_hash.c:78
78 if (ht-inconsistent==HT_OK) {
(gdb) bt
#0 0x001c06e0 in _zend_is_inconsistent (ht=0x0, file=0x208d38
/Users/tater/book/php4-ze2/Zend/zend_hash.c, line=871) at
/Users/tater/book/php4-ze2/Zend/zend_hash.c:78
#1 0x001c3a9c in zend_hash_find (ht=0x0, arKey=0x6eda60 __call,
nKeyLength=7, pData=0xb284) at
/Users/tater/book/php4-ze2/Zend/zend_hash.c:871
#2 0x001aab38 in call_user_function_ex (function_table=0x0,
object_pp=0x0, function_name=0xb340, retval_ptr_ptr=0xb360,
param_count=2, params=0xb358, no_separation=0, symbol_table=0x0) at
/Users/tater/book/php4-ze2/Zend/zend_execute_API.c:558
#3 0x001cfb54 in zend_std_call_user_call (ht=0, return_value=0x6ed958,
this_ptr=0x0, return_value_used=0) at
/Users/tater/book/php4-ze2/Zend/zend_object_handlers.c:353
#4 0x001da1f0 in zend_do_fcall_common_helper (execute_data=0xb5c8,
op_array=0x6ed1b8) at
/Users/tater/book/php4-ze2/Zend/zend_execute.c:2422
#5 0x001da900 in zend_do_fcall_by_name_handler
(execute_data=0xb5c8, op_array=0x6ed1b8) at
/Users/tater/book/php4-ze2/Zend/zend_execute.c:2514
#6 0x001d3adc in execute (op_array=0x6ed1b8) at
/Users/tater/book/php4-ze2/Zend/zend_execute.c:1194
#7 0x001ab8b0 in zend_eval_string (str=0xbbf1 class foo {
function __call($m,$a) { echo \abcdef\\n\; return; } } $x = new foo;
$x-nothere();, retval_ptr=0x0, string_name=0x20a790 Command line
code) at /Users/tater/book/php4-ze2/Zend/zend_execute_API.c:757
#8 0x001e47c0 in main (argc=3, argv=0xbb1c) at
/Users/tater/book/php4-ze2/sapi/cli/php_cli.c:743
#9 0x1a44 in _start ()
#10 0x1874 in start ()
(gdb) r -r 'class foo { function __call($m,$a) { echo abcdefg\n; } }
$x = new foo; $x-nothere();'
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /usr/local/book/php4-ze2/sapi/cli/php -r 'class foo {
function __call($m,$a) { echo abcdefg\n; } } $x = new foo;
$x-nothere();'
[Switching to process 21067 thread 0x3d0f]
Program received signal EXC_BAD_ACCESS, Could not access memory.
0x001c06e0 in _zend_is_inconsistent (ht=0x0, file=0x208d38
/Users/tater/book/php4-ze2/Zend/zend_hash.c, line=871) at
/Users/tater/book/php4-ze2/Zend/zend_hash.c:78
78 if (ht-inconsistent==HT_OK) {
(gdb) r -r 'class foo { function __call($m,$a) { echo abcdef\n; } }
$x = new foo; $x-nothere();'
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /usr/local/book/php4-ze2/sapi/cli/php -r 'class foo {
function __call($m,$a) { echo abcdef\n; } } $x = new foo;
$x-nothere();'
[Switching to process 21072 thread 0x400b]
Program received signal EXC_BAD_ACCESS, Could not access memory.
0x001c06e0 in _zend_is_inconsistent (ht=0x0, file=0x208d38
/Users/tater/book/php4-ze2/Zend/zend_hash.c, line=871) at
/Users/tater/book/php4-ze2/Zend/zend_hash.c:78
78 if (ht-inconsistent==HT_OK) {
(gdb) r -r 'class foo { function __call($m,$a) { echo abcde\n; } }
$x = new foo; $x-nothere();'
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /usr/local/book/php4-ze2/sapi/cli/php -r 'class foo {
function __call($m,$a) { echo abcde\n; } } $x = new foo;
#21827 [NEW]: form post magic variables clumped together
From: [EMAIL PROTECTED] Operating system: Linux PHP version: 4.3.0 PHP Bug Type: Scripting Engine problem Bug description: form post magic variables clumped together Hello, When I post a html form with 3 hidden fields, with 3 or less alphanumerics as the values, and 4 or less alphanumerics as the NAME of the first field, and a submit button having a name value, the first field variable has clumped all the other post data in it, instead of just the magic variable for field 1 like it should. Using phpinfo, there is _ENV[+] after _ENV[REMOTE_PORT] that shows the telltale clump, or a line and a square when the form does not meet the above situation. I do not know what this _ENV[+] is but think it's a clue. There's also _SERVER[+] and in the Environment a plain + after REMOTE_PORT that will be the name of my hidden field 1 with the clump data. I have seen many other complaints in the bug section about variables missing or broken, but noone tracked down the cause as well as this. It takes 3 simultaneous conditions. You can see this in action at http://www.zewy.com/phpclump.php I'm going to put a hidden field with 1000 as the value on every page as my work-around. 999 didn't work, it's only 3 alphanumerics. If you could find a fix it would be appreciated. BTW, one day, it's my dream to have millions of $$$ and donate it to open source developers.. You make the world a better place. Thanks -- Edit bug report at http://bugs.php.net/?id=21827edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21827r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21827r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21827r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21827r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21827r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21827r=support Expected behavior: http://bugs.php.net/fix.php?id=21827r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21827r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21827r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21827r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21827r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21827r=dst IIS Stability: http://bugs.php.net/fix.php?id=21827r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=21827r=gnused
#21827 [Com]: form post magic variables clumped together
ID: 21827 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Scripting Engine problem Operating System: Linux PHP Version: 4.3.0 New Comment: Here's how to stop the clumps (workaround) 1. Always have the first form variable have a name 5 or more letters 2. Don't have a name on the submit button 3. Have the value of any hidden field 4 or more letters or numbers -Sol Previous Comments: [2003-01-22 18:18:35] [EMAIL PROTECTED] Hello, When I post a html form with 3 hidden fields, with 3 or less alphanumerics as the values, and 4 or less alphanumerics as the NAME of the first field, and a submit button having a name value, the first field variable has clumped all the other post data in it, instead of just the magic variable for field 1 like it should. Using phpinfo, there is _ENV[+] after _ENV[REMOTE_PORT] that shows the telltale clump, or a line and a square when the form does not meet the above situation. I do not know what this _ENV[+] is but think it's a clue. There's also _SERVER[+] and in the Environment a plain + after REMOTE_PORT that will be the name of my hidden field 1 with the clump data. I have seen many other complaints in the bug section about variables missing or broken, but noone tracked down the cause as well as this. It takes 3 simultaneous conditions. You can see this in action at http://www.zewy.com/phpclump.php I'm going to put a hidden field with 1000 as the value on every page as my work-around. 999 didn't work, it's only 3 alphanumerics. If you could find a fix it would be appreciated. BTW, one day, it's my dream to have millions of $$$ and donate it to open source developers.. You make the world a better place. Thanks -- Edit this bug report at http://bugs.php.net/?id=21827edit=1
#21626 [NEW]: gdfgfdg
From: [EMAIL PROTECTED] Operating system: ffgh PHP version: 4.3.0 PHP Bug Type: Variables related Bug description: gdfgfdg br / bNotice/b: Undefined variable: in in b/usr/src/web/php/php-bugs-web/report.php/b on line b263/bbr / -- Edit bug report at http://bugs.php.net/?id=21626edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21626r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21626r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21626r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21626r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21626r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21626r=support Expected behavior: http://bugs.php.net/fix.php?id=21626r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21626r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21626r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21626r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21626r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21626r=dst IIS Stability: http://bugs.php.net/fix.php?id=21626r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=21626r=gnused
#20142 [Bgs]: Session and EscapeShellCmd problem
ID: 20142 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: Session related Operating System: Win 2K PHP Version: 4.2.3 New Comment: The EscapeShellCmd was not the problem. The issue was with how sessions are stored. Please read the post for Oct 28, 2002 for a full explanation. In a nutshell: The session is saved with a number indicating the length of the variable, however it does not count the / as a character and is thus one less than the actual number of characters in the string, thus confusing the session information and reporting an error. Previous Comments: [2003-01-22 17:48:57] [EMAIL PROTECTED] Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php EscapeShellCmd adds \ to the variable, which changes $test from b'lah to b\'lah nothing buggy or unusual about that. [2002-11-25 16:08:21] [EMAIL PROTECTED] I have installed the win32 version listed above and still get the same problem. The session count of characters is still off. [2002-11-15 01:37:51] [EMAIL PROTECTED] let's keep this in feedback status then until we get the real feedback. [2002-11-14 20:41:55] [EMAIL PROTECTED] I tried using the http://snaps.php.net/win32/php4-win32-latest.zip download, but it crashed my system. I don't think it was the software. It was more likely the hardware. I am currently rebuilding the server and will try again when it is up. Thank you. [2002-11-14 01:47:41] [EMAIL PROTECTED] No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to Open. Thank you. 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/20142 -- Edit this bug report at http://bugs.php.net/?id=20142edit=1
#20970 [Opn-Fbk]: make fails (gcc: regex/r: No such file or directory)
ID: 20970 Updated by: [EMAIL PROTECTED] -Summary: Fatal error: Nesting level too deep - recursive dependency? in Unknown on line Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: Compile Failure Operating System: Sun2.7 PHP Version: 4.3.1-dev New Comment: Can you send me the Makefile that is generated with that configure line?? (using the latest stable CVS snapshot) Previous Comments: [2003-01-20 11:35:23] [EMAIL PROTECTED] If compiled without --with-nsapi option, Following error message displayed during Make: gcc: regex/r: No such file or directory make: *** [sapi/cgi/php] Error 1 [2003-01-17 21:07:49] [EMAIL PROTECTED] If you drop the --with-nsapi option from the configure line, does it compile succesfully then? [2003-01-15 17:46:52] [EMAIL PROTECTED] Following error encountered while executing Make command: /home/ghoshj/PHP/php4-STABLE-200301150030/sapi/nsapi/nsapi.c: In function `sapi_ nsapi_read_post': /home/ghoshj/PHP/php4-STABLE-200301150030/sapi/nsapi/nsapi.c:211: warning: unuse d variable `content_length_str' /home/ghoshj/PHP/php4-STABLE-200301150030/sapi/nsapi/nsapi.c: In function `nsapi _request_ctor': /home/ghoshj/PHP/php4-STABLE-200301150030/sapi/nsapi/nsapi.c:409: warning: unuse d variable `path_info' /home/ghoshj/PHP/php4-STABLE-200301150030/sapi/nsapi/nsapi.c: In function `nsapi _request_dtor': /home/ghoshj/PHP/php4-STABLE-200301150030/sapi/nsapi/nsapi.c:450: warning: passi ng arg 1 of `nsapi_free' discards qualifiers from pointer target type /home/ghoshj/PHP/php4-STABLE-200301150030/sapi/nsapi/nsapi.c:452: warning: passi ng arg 1 of `nsapi_free' discards qualifiers from pointer target type /home/ghoshj/PHP/php4-STABLE-200301150030/sapi/nsapi/nsapi.c:545:63: warning: / * within comment /home/ghoshj/PHP/php4-STABLE-200301150030/sapi/nsapi/nsapi.c:547:1: warning: /* within comment . gcc: ext/standard/a: No such file or directory make: *** [sapi/cli/php] Error 1 [2003-01-15 17:40:35] [EMAIL PROTECTED] Directory php4-STABLE-200301150030 created PHP_VERSION 4.3.1-dev Configuration is OK ./configure --enable-debug --enable-libgcc --enable-dbx \ --enable-ftp --enable-inline-optimization \ --with-nsapi=/export/webtools/netscape/server4 \ --with-pgsql=/usr/local/pgsql \ --with-oracle=/export/webtools/app/oracle/product/8.1.7 [2003-01-14 19:23:12] [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 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/20970 -- Edit this bug report at http://bugs.php.net/?id=20970edit=1
#21828 [NEW]: printer_list doesn't list any printers
From: [EMAIL PROTECTED] Operating system: Win/XP PHP version: 4.3.0 PHP Bug Type: Unknown/Other Function Bug description: printer_list doesn't list any printers printer_list(PRINTER_NUM_LOCAL) does not return any printers. We have successfully used this function on a Win98/PWS configuration, but fails on Win/XP with IIS. I noted the advice in bug 14301 to install 4.3 but still no go. Any advice would be appreciated. -- Edit bug report at http://bugs.php.net/?id=21828edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21828r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21828r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21828r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21828r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21828r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21828r=support Expected behavior: http://bugs.php.net/fix.php?id=21828r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21828r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21828r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21828r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21828r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21828r=dst IIS Stability: http://bugs.php.net/fix.php?id=21828r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=21828r=gnused
#21518 [Com]: ImageCreateFromString() causes segmentation fault
ID: 21518 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: Reproducible crash Operating System: Redhat Linux 7.2 PHP Version: 4.3.0 Assigned To: iliaa New Comment: I've downloaded the Stable (4.3.x-dev Built On: Jan 23, 2003 00:30 GMT) and the same script pointed by [EMAIL PROTECTED] still happens. CONFIGS: -My configure file is like: './configure' '--with-apxs' '--with-sybase=shared,/usr/local/ftds' '--with-mssql=shared,/usr/local/ftds' '--disable-ctype' '--with-gd=/usr' '--with-jpeg=/usr' '--with-png=/usr' -My HTTP server version is Apache/1.3.23 -Apache loaded modules are: mod_php4, mod_ssl, mod_gzip, mod_bandwidth, mod_setenvif, mod_so, mod_usertrack, mod_headers, mod_expires, mod_digest, mod_auth_mysql, mod_auth_db, mod_auth_anon, mod_auth, mod_access, mod_rewrite, mod_alias, mod_proxy, mod_userdir, mod_actions, mod_imap, mod_asis, mod_cgi, mod_dir, mod_autoindex, mod_include, mod_info, mod_status, mod_negotiation, mod_mime, mod_log_referer, mod_log_agent, mod_log_config, mod_define, mod_env, http_core -Error message is (note that the child pid refers to httpd -DSSL -DGZIP): [Wed Jan 22 23:08:54 2003] [notice] child pid 22099 exit signal Segmentation fault (11) Previous Comments: [2003-01-08 12:12:14] [EMAIL PROTECTED] This bug has been fixed in CVS. In case this was a PHP problem, snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. [2003-01-08 12:04:10] [EMAIL PROTECTED] Information about the PHP build is also available at: http://www.kis.fotodom.com/phpinfo.php [2003-01-08 12:02:03] [EMAIL PROTECTED] Try with this one: http://www.kis.fotodom.com/gfx/test.psd [2003-01-08 11:53:46] [EMAIL PROTECTED] Could you please a provide a sample file that always causes a segmentation fault? [2003-01-08 11:11:23] [EMAIL PROTECTED] Update: In occasions (twice) I have received a Warning message about an unsupported image type, which is what I wanted in the first place. However, in the other 50+ occasions, the script simply crashes. 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/21518 -- Edit this bug report at http://bugs.php.net/?id=21518edit=1
#21828 [Opn]: printer_list doesn't list any printers
ID: 21828 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Unknown/Other Function Operating System: Win/XP PHP Version: 4.3.0 New Comment: should read printer_list(PRINTER_ENUM_LOCAL) Previous Comments: [2003-01-22 19:12:16] [EMAIL PROTECTED] printer_list(PRINTER_NUM_LOCAL) does not return any printers. We have successfully used this function on a Win98/PWS configuration, but fails on Win/XP with IIS. I noted the advice in bug 14301 to install 4.3 but still no go. Any advice would be appreciated. -- Edit this bug report at http://bugs.php.net/?id=21828edit=1
#21823 [Csd-Bgs]: improperly detecting gcc as cross compiler
ID: 21823 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Closed +Status: Bogus Bug Type: Compile Failure Operating System: Gentoo Linux 1.4 PHP Version: 4.3.0 New Comment: not php bug - bogus Previous Comments: [2003-01-22 17:31:53] [EMAIL PROTECTED] I just did some more testing, and building PHP outside of the Gentoo build system works fine, so this bug is with their build system, not with PHP itself. I'll take it up with them. [2003-01-22 16:28:38] [EMAIL PROTECTED] Okay, I tried that first. Here's the interesting parts of the configure output: CLIP checking for gcc... gcc checking whether the C compiler (gcc -march=i686 -O3 ) works... yes checking whether the C compiler (gcc -march=i686 -O3 ) is a cross-compiler... yes CLIP checking for fopencookie... yes configure: error: can not run test program while cross compiling !!! ERROR: dev-php/php-4.3.0-r2 failed. !!! Function src_compile, Line 137, Exitcode 1 !!! bad ./configure That failing, I decided to try stripping of the -O3 as well, just in case. Here's the interesting output from that: CLIP checking for gcc... gcc checking whether the C compiler (gcc -march=i686 ) works... yes checking whether the C compiler (gcc -march=i686 ) is a cross-compiler... yes CLIP checking for fopencookie... yes configure: error: can not run test program while cross compiling !!! ERROR: dev-php/php-4.3.0-r2 failed. !!! Function src_compile, Line 137, Exitcode 1 !!! bad ./configure As you can see, there is absolutely no change happening here. The only thing I can think of that /might/ have caused this, although I have no idea how, is that I did just install MySQL 4 on my box. When I went to reinstall PHP to link it to the new libs, I noticed this problem. [2003-01-22 16:22:28] [EMAIL PROTECTED] In that case remove -pipe and try again. [2003-01-22 16:16:35] [EMAIL PROTECTED] Ack. I'm running too many servers. I was wrong about this one running GCC 3.2.1. It's still running 2.95 version. I've included the output of gcc -v below. Sorry for the confusion! Reading specs from /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/specs gcc version 2.95.3 20010315 (release) [2003-01-22 15:47:57] [EMAIL PROTECTED] Change -march=i686 to -march=pentium2 and try again. 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/21823 -- Edit this bug report at http://bugs.php.net/?id=21823edit=1
#21826 [Opn-Bgs]: variables dont return value even if they are seen in phpinfo()
ID: 21826 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: *General Issues Operating System: windows 2000 PHP Version: 4.2.3 New Comment: Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Thank you for your interest in PHP. [EMAIL PROTECTED] Previous Comments: [2003-01-22 17:05:19] [EMAIL PROTECTED] My IIS5 crashes, and after reinstaling it, I can make any query to MySQL base, or get any calculation on primary page, but when I want some variable to PUT or GET to another script, I don't get it's value. Another thing, when put on beggining of page command PHPINFO () i see variables and it's values but scripts dont get them. Also I have been enabled REGISTER_GLOBALS in my Ini file. Please help me to solve this problem. -- Edit this bug report at http://bugs.php.net/?id=21826edit=1
#21821 [Bgs]: Unsetting $_COOKIE[session_name()] shouldn't warn, but send new cookie
ID: 21821
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Bogus
Bug Type: Session related
Operating System: BSD/OS 4.2
PHP Version: 4.3.0
New Comment:
And this really doesn't work like that..
You can't set/unset cookies by mangling the $_COOKIE[] array anyway.
Please ask support questions elsewhere.
Previous Comments:
[2003-01-22 11:49:29] [EMAIL PROTECTED]
Ahum - NULL (inserted for readibility) apparently is '' not, void.
[2003-01-22 11:43:11] [EMAIL PROTECTED]
The following script:
?php
error_reporting(E_ALL);
if(isset($_COOKIE[session_name()])
!file_exists(session_save_path(NULL) . '/sess_' . session_id(NULL)))
unset($_COOKIE[session_name()]);
ini_set('session.use_only_cookies', TRUE);
ini_set('session.cookie_lifetime', 7 * 24 * 3600);
ini_set('session.gc_lifetime', 7 * 24 * 3600);
session_start();
?
html
body
a href=?php echo $_SERVER['PHP_SELF']; ??foo=?php echo time();
?refresh/a
pre
?php var_dump($_SESSION); ?
/pre
/body
/html
?php
$_SESSION['test'] = 'hi' . $_GET['foo'];
?
Creates warnings about illegal chars in the session id. However - there
is no valid session here, as there is no valid cookie. It should send a
new cookie instead, with a new generated session id. However - it sets
an empty id:
Set-Cookie: PHPSESSID=; expires=Wed, 29-Jan-2003 17:37:42 GMT; path=/
If I also unset $_SESSION, it doesn't change anything.
--
Edit this bug report at http://bugs.php.net/?id=21821edit=1
#20970 [Fbk-Opn]: make fails (gcc: regex/r: No such file or directory)
ID: 20970 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: Compile Failure Operating System: Sun2.7 PHP Version: 4.3.1-dev New Comment: Following points: - Make step got resolved by applying the suggestion as mentioned in Bug#19533 that is installing GNU SED 4.0 in /usr/local/bin and giving it the precedence. - Make install finished - Webserver bounced - Testing in Progess Previous Comments: [2003-01-22 19:12:13] [EMAIL PROTECTED] Can you send me the Makefile that is generated with that configure line?? (using the latest stable CVS snapshot) [2003-01-20 11:35:23] [EMAIL PROTECTED] If compiled without --with-nsapi option, Following error message displayed during Make: gcc: regex/r: No such file or directory make: *** [sapi/cgi/php] Error 1 [2003-01-17 21:07:49] [EMAIL PROTECTED] If you drop the --with-nsapi option from the configure line, does it compile succesfully then? [2003-01-15 17:46:52] [EMAIL PROTECTED] Following error encountered while executing Make command: /home/ghoshj/PHP/php4-STABLE-200301150030/sapi/nsapi/nsapi.c: In function `sapi_ nsapi_read_post': /home/ghoshj/PHP/php4-STABLE-200301150030/sapi/nsapi/nsapi.c:211: warning: unuse d variable `content_length_str' /home/ghoshj/PHP/php4-STABLE-200301150030/sapi/nsapi/nsapi.c: In function `nsapi _request_ctor': /home/ghoshj/PHP/php4-STABLE-200301150030/sapi/nsapi/nsapi.c:409: warning: unuse d variable `path_info' /home/ghoshj/PHP/php4-STABLE-200301150030/sapi/nsapi/nsapi.c: In function `nsapi _request_dtor': /home/ghoshj/PHP/php4-STABLE-200301150030/sapi/nsapi/nsapi.c:450: warning: passi ng arg 1 of `nsapi_free' discards qualifiers from pointer target type /home/ghoshj/PHP/php4-STABLE-200301150030/sapi/nsapi/nsapi.c:452: warning: passi ng arg 1 of `nsapi_free' discards qualifiers from pointer target type /home/ghoshj/PHP/php4-STABLE-200301150030/sapi/nsapi/nsapi.c:545:63: warning: / * within comment /home/ghoshj/PHP/php4-STABLE-200301150030/sapi/nsapi/nsapi.c:547:1: warning: /* within comment . gcc: ext/standard/a: No such file or directory make: *** [sapi/cli/php] Error 1 [2003-01-15 17:40:35] [EMAIL PROTECTED] Directory php4-STABLE-200301150030 created PHP_VERSION 4.3.1-dev Configuration is OK ./configure --enable-debug --enable-libgcc --enable-dbx \ --enable-ftp --enable-inline-optimization \ --with-nsapi=/export/webtools/netscape/server4 \ --with-pgsql=/usr/local/pgsql \ --with-oracle=/export/webtools/app/oracle/product/8.1.7 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/20970 -- Edit this bug report at http://bugs.php.net/?id=20970edit=1
#21757 [Opn-Bgs]: session_register (); does not do it's job!
ID: 21757
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Bogus
Bug Type: Session related
Operating System: Windows XP Pro
PHP Version: 4.3.0
New Comment:
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions.
Thank you for your interest in PHP.
[EMAIL PROTECTED]
Previous Comments:
[2003-01-22 10:11:35] [EMAIL PROTECTED]
I don't know. I haven't changed any values but some paths so I could
make ir work. everything other is left unchanged (default).
[2003-01-20 13:54:17] [EMAIL PROTECTED]
Does your php.ini allow PHP to set cookie session?
[2003-01-20 10:40:38] [EMAIL PROTECTED]
Well, Previous version of PHP I used was 4.23 and everything went well.
Now in PHP 4.3 session_register ('string'); or $_SESSION [string];
does not register these 'string' variables when going from one page to
another. And by the way, echoing session_id (); in every new page you
go to (using hyperlinks, not opening new IE window) it gives you
different session ID and as far as I know that should not be changhing
unless you open another browser window. Why don't you try registering
variable and in another page writing if (session_is_registered
('string')) echo 'success';
I bet you won't see success though you should!
[2003-01-19 17:52:30] [EMAIL PROTECTED]
Not enough information was provided for us to be able
to handle this bug. Please re-read the instructions at
http://bugs.php.net/how-to-report.php
If you can provide more information, feel free to add it
to this bug and change the status back to Open.
Thank you for your interest in PHP.
A) updating category.
B) Not enough info, and from what I can tell so far this is probably
Bogus.
[2003-01-19 15:38:38] [EMAIL PROTECTED]
Here is the simple peace of code with the link to the page itself.
Session ID has to stay the same all the time as it is assigned to the
browser window (this conclusion is made by my own experiance :) ).
Tested with IE 6.0
//Start here
?session_start ();?
html
head
title/title
/head
body
?php
echo session_id ().'br';
?
a href=session_id.phpTest_Link/a
/body
/html
--
Edit this bug report at http://bugs.php.net/?id=21757edit=1
#21262 [Bgs-Opn]: crash or fail when outputting large amounts of text quickly
ID: 21262 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Bogus +Status: Open -Bug Type: Reproducible crash +Bug Type: Performance problem Operating System: WinXP PHP Version: 4.3.0 New Comment: You are wrong. If it was a memory error, PHP should display the standard out of memory message. AS I EXPLAINED, this also happens with very SMALL amounts of data. The use of large blocks of data is just an easy way to REPRO. Surely there must be more people working on PHP than you? Previous Comments: [2003-01-22 17:12:39] [EMAIL PROTECTED] Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php I've explained before and I will attempt to explain once again. When output buffering is turned on the system does not output the text right away but rather fills up a memory buffer that is displayed in one large block. If the text you are trying to output exceeds the avaliable system memory then the error you are seeing will occur. This cannot be helped, the solution is to either disable output buffering or not use things like gz_handler, which cause ALL of the output to be buffered in memory rather then output the data in chunks (default chunk size 4096 bytes). [2003-01-16 10:20:56] [EMAIL PROTECTED] This bug has been present for over a year, maybe since the beginning of PHP. We're still getting people passing the buck.. [2003-01-15 16:44:33] [EMAIL PROTECTED] I am using Apache version 2.0.43 with the sapi php module. I downloaded the latest stable snapshot of php (4.3.1) but it still reproduced the same orignial problem discussed. Regards [2003-01-14 19:25:17] [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 (and what apache version is it?) [2003-01-14 13:34:57] [EMAIL PROTECTED] I can confirm this bug including the for loop provided earlier in this bug thread. I am using php 4.3.0 with Apache 2.0.43 with Windows XP Home Edition. I found this bug report after noticing the same effect with a large piece of php that I have been writing. I have found that turning off error reporting in php.ini helps but does not solve the problem totally. I found that using the flush() function helped but was not a reliable solution. This seems a blatant problem which is making debugging and development almost impossible and very frustrating. Is there any update on confirming the bug? Regards 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/21262 -- Edit this bug report at http://bugs.php.net/?id=21262edit=1
#21829 [NEW]: fsockopen() crashes on 2 of 3 servers (w/ gdb trace)
From: [EMAIL PROTECTED]
Operating system: mandrake 8.2, 2.4.18-8.1mdk
PHP version: 4.3.0
PHP Bug Type: Reproducible crash
Bug description: fsockopen() crashes on 2 of 3 servers (w/ gdb trace)
Compiling 4.3.0 and php4-STABLE-200301222030 on 3 servers, one works and
two segfault. The simple script below illustrates the problem; on one
server it runs, on two it faults. The three servers are essentially
identical; php.ini on all are identical.
Build details and gdb backtrace are below. I also have fopen(http://;)
failing the same way, not surprising. The failure appears to be in DNS
resolution. Glad to supply more info as needed.
?php
$fd = fsockopen(www.yahoo.com, 80, $errno, $errstr);
if( !$fd ) {
echo yahoo not available;
exit();
} else {
fputs($fd,GET / HTTP/1.0\r\n\r\n);
fputs($fd,Host: $host\r\n\r\n);
while (!feof($fd)) {
echo fread($fd,16000);
}
fclose($fd);
}
?
=
php was built with the following options:
./configure \
--with-gd \
--with-mysql=/usr \
--with-exec-dir=/var/lib/php \
--with-java=/usr/local/jdk \
--enable-unified-odbc \
--enable-safe-mode=yes \
--enable-track-vars \
--enable-ftp \
--with-expat-dir=/usr \
--with-xml \
--with-dom=/usr \
--with-dom-xslt=/usr \
--with-dom-exslt=/usr \
--enable-xslt \
--with-xslt-sablot=/usr \
--with-sablot-js=/usr \
--with-zlib \
--with-ldap \
--with-openssl \
--disable-debug \
--disable-debugger \
--with-config-file-path=/etc/httpd/conf
The bind version on all servers is 8.3.3, patched with ISC patches prior
to 8.3.4 release from recent bugs.
=
gdb run commands:
gdb stacktrace:(gdb) set args fsock_yahoo.php
(gdb) run
Starting program: /usr/local/bin/php fsock_yahoo.php
[New Thread 1024 (LWP 3639)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1024 (LWP 3639)]
0x081335d5 in php_network_getaddresses (host=0x831c59c www.yahoo.com,
sal=0xbfffc634) at /usr/local/php4/main/network.c:215
215 *(struct sockaddr_in *)*sap =
#0 0x081335d5 in php_network_getaddresses (host=0x831c59c
www.yahoo.com,
sal=0xbfffc634) at /usr/local/php4/main/network.c:215
#1 0x08133810 in php_hostconnect (host=0x831c59c www.yahoo.com,
port=80,
socktype=1, timeout=0xbfffc6b0) at /usr/local/php4/main/network.c:410
#2 0x08133b5f in _php_stream_sock_open_host (host=0x831c59c
www.yahoo.com,
port=80, socktype=1, timeout=0xbfffc6b0, persistent_id=0x0)
at /usr/local/php4/main/network.c:619
#3 0x080ee025 in php_fsockopen_stream (ht=4, return_value=0x831c5dc,
this_ptr=0x0, return_value_used=1, persistent=0)
at /usr/local/php4/ext/standard/fsock.c:218
#4 0x080ee1ed in zif_fsockopen (ht=4, return_value=0x831c5dc,
this_ptr=0x0,
return_value_used=1) at /usr/local/php4/ext/standard/fsock.c:278
#5 0x0815d2d2 in execute (op_array=0x8322504)
at /usr/local/php4/Zend/zend_execute.c:1596
#6 0x0814cdf3 in zend_execute_scripts (type=8, retval=0x0, file_count=3)
at /usr/local/php4/Zend/zend.c:864
#7 0x0812992b in php_execute_script (primary_file=0xb560)
at /usr/local/php4/main/main.c:1573
#8 0x08164488 in main (argc=2, argv=0xb604)
at /usr/local/php4/sapi/cli/php_cli.c:746
#9 0x405be280 in __libc_start_main () from /lib/libc.so.6
--
Edit bug report at http://bugs.php.net/?id=21829edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=21829r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=21829r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=21829r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=21829r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=21829r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=21829r=support
Expected behavior: http://bugs.php.net/fix.php?id=21829r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=21829r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=21829r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=21829r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21829r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=21829r=dst
IIS Stability: http://bugs.php.net/fix.php?id=21829r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=21829r=gnused
#21817 [Fbk]: Error to compile php 4.2.3 in make phase
ID: 21817 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback -Bug Type: Compile Failure +Bug Type: IMAP related Operating System: Linux Conectiva 8 -PHP Version: 4.2.3 +PHP Version: 4.3.1-dev New Comment: And what configure line did you use? And is HAVE_IMAP_AUTH_GSS defined in main/php_config.h ?? Previous Comments: [2003-01-22 15:59:40] [EMAIL PROTECTED] What version of c-client are you using? [2003-01-22 10:28:04] [EMAIL PROTECTED] I get the latest version and try to compile and get the following error: gcc -Iext/imap/ -I/usr/src/php/ext/imap/ -DPHP_ATOM_INC -I/usr/src/php/include -I/usr/src/php/main -I/usr/src/php -I/usr/src/php/Zend -I/usr/include/imap -I/usr/local/include -I/usr/src/mysql-3.23.54a/include -I/usr/src/php/ext/xml/expat -I/usr/src/php/TSRM -g -O2 -c /usr/src/php/ext/imap/php_imap.c -o ext/imap/php_imap.o echo ext/imap/php_imap.lo /usr/src/php/ext/imap/php_imap.c: In function `zm_startup_imap': /usr/src/php/ext/imap/php_imap.c:424: `auth_gss' undeclared (first use in this function) /usr/src/php/ext/imap/php_imap.c:424: (Each undeclared identifier is reported only once /usr/src/php/ext/imap/php_imap.c:424: for each function it appears in.) make: *** [ext/imap/php_imap.lo] Error 1 [2003-01-22 08:08:11] [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-01-22 07:45:52] [EMAIL PROTECTED] I do ./configure with this parameters: '--prefix=/usr/bin' \ '--disable-debug' \ '--enable-pic' \ '--enable-inline-optimization' \ '--enable-shared' \ '--disable-static' \ '--with-config-file-path=/etc/php4/apache' \ '--with-exec-dir=/usr/bin' \ '--with-regex=system' \ '--with-gettext' \ '--with-png' \ '--with-zlib' \ '--enable-magic-quotes' \ '--enable-safe-mode' \ '--enable-sockets' \ '--enable-sysvsem' \ '--enable-sysvshm' \ '--enable-track-vars' \ '--enable-wddx' \ '--enable-snmp' \ '--enable-ftp' \ '--enable-bcmath' \ '--with-mysql=/usr/src/mysql-3.23.54a' \ '--without-unixODBC' \ '--with-xml' \ '--with-imap' \ '--with-mcrypt=/usr/lib/libmcrypt' \ '--with-readline=/usr/src/readline-4.3' all it´s ok until now, but when I run 'make' this error occurs: root@ php-4.2.3]# make Making all in Zend /bin/sh: cd: Zend: File or directory not found make: *** [all-recursive] Error 1 But Zend directory is there ... Thanks in advance -- Edit this bug report at http://bugs.php.net/?id=21817edit=1
#21262 [Opn-Fbk]: crash or fail when outputting large amounts of text quickly
ID: 21262 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: Performance problem Operating System: WinXP PHP Version: 4.3.0 New Comment: Please provide a SHORT but complete example script that can be used to reproduce this. (the one you provided doesn't cause any crashes) Previous Comments: [2003-01-22 19:41:51] [EMAIL PROTECTED] You are wrong. If it was a memory error, PHP should display the standard out of memory message. AS I EXPLAINED, this also happens with very SMALL amounts of data. The use of large blocks of data is just an easy way to REPRO. Surely there must be more people working on PHP than you? [2003-01-22 17:12:39] [EMAIL PROTECTED] Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php I've explained before and I will attempt to explain once again. When output buffering is turned on the system does not output the text right away but rather fills up a memory buffer that is displayed in one large block. If the text you are trying to output exceeds the avaliable system memory then the error you are seeing will occur. This cannot be helped, the solution is to either disable output buffering or not use things like gz_handler, which cause ALL of the output to be buffered in memory rather then output the data in chunks (default chunk size 4096 bytes). [2003-01-16 10:20:56] [EMAIL PROTECTED] This bug has been present for over a year, maybe since the beginning of PHP. We're still getting people passing the buck.. [2003-01-15 16:44:33] [EMAIL PROTECTED] I am using Apache version 2.0.43 with the sapi php module. I downloaded the latest stable snapshot of php (4.3.1) but it still reproduced the same orignial problem discussed. Regards [2003-01-14 19:25:17] [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 (and what apache version is it?) 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/21262 -- Edit this bug report at http://bugs.php.net/?id=21262edit=1
#20970 [Opn]: make fails (gcc: regex/r: No such file or directory)
ID: 20970 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Compile Failure Operating System: Sun2.7 PHP Version: 4.3.1-dev New Comment: Preliminary test completed Following error is not displayed ANY MORE Fatal error: Nesting level too deep - recursive dependency? in Unknown on line Previous Comments: [2003-01-22 19:29:32] [EMAIL PROTECTED] Following points: - Make step got resolved by applying the suggestion as mentioned in Bug#19533 that is installing GNU SED 4.0 in /usr/local/bin and giving it the precedence. - Make install finished - Webserver bounced - Testing in Progess [2003-01-22 19:12:13] [EMAIL PROTECTED] Can you send me the Makefile that is generated with that configure line?? (using the latest stable CVS snapshot) [2003-01-20 11:35:23] [EMAIL PROTECTED] If compiled without --with-nsapi option, Following error message displayed during Make: gcc: regex/r: No such file or directory make: *** [sapi/cgi/php] Error 1 [2003-01-17 21:07:49] [EMAIL PROTECTED] If you drop the --with-nsapi option from the configure line, does it compile succesfully then? [2003-01-15 17:46:52] [EMAIL PROTECTED] Following error encountered while executing Make command: /home/ghoshj/PHP/php4-STABLE-200301150030/sapi/nsapi/nsapi.c: In function `sapi_ nsapi_read_post': /home/ghoshj/PHP/php4-STABLE-200301150030/sapi/nsapi/nsapi.c:211: warning: unuse d variable `content_length_str' /home/ghoshj/PHP/php4-STABLE-200301150030/sapi/nsapi/nsapi.c: In function `nsapi _request_ctor': /home/ghoshj/PHP/php4-STABLE-200301150030/sapi/nsapi/nsapi.c:409: warning: unuse d variable `path_info' /home/ghoshj/PHP/php4-STABLE-200301150030/sapi/nsapi/nsapi.c: In function `nsapi _request_dtor': /home/ghoshj/PHP/php4-STABLE-200301150030/sapi/nsapi/nsapi.c:450: warning: passi ng arg 1 of `nsapi_free' discards qualifiers from pointer target type /home/ghoshj/PHP/php4-STABLE-200301150030/sapi/nsapi/nsapi.c:452: warning: passi ng arg 1 of `nsapi_free' discards qualifiers from pointer target type /home/ghoshj/PHP/php4-STABLE-200301150030/sapi/nsapi/nsapi.c:545:63: warning: / * within comment /home/ghoshj/PHP/php4-STABLE-200301150030/sapi/nsapi/nsapi.c:547:1: warning: /* within comment . gcc: ext/standard/a: No such file or directory make: *** [sapi/cli/php] Error 1 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/20970 -- Edit this bug report at http://bugs.php.net/?id=20970edit=1
#21262 [Fbk-Opn]: crash or fail when outputting large amounts of text quickly
ID: 21262 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: Performance problem Operating System: WinXP PHP Version: 4.3.0 New Comment: This is not always reproducible, this is as good as we can come up with. It appears to only reproduce for people unwilling to do anything about it. Previous Comments: [2003-01-22 19:47:57] [EMAIL PROTECTED] Please provide a SHORT but complete example script that can be used to reproduce this. (the one you provided doesn't cause any crashes) [2003-01-22 19:41:51] [EMAIL PROTECTED] You are wrong. If it was a memory error, PHP should display the standard out of memory message. AS I EXPLAINED, this also happens with very SMALL amounts of data. The use of large blocks of data is just an easy way to REPRO. Surely there must be more people working on PHP than you? [2003-01-22 17:12:39] [EMAIL PROTECTED] Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php I've explained before and I will attempt to explain once again. When output buffering is turned on the system does not output the text right away but rather fills up a memory buffer that is displayed in one large block. If the text you are trying to output exceeds the avaliable system memory then the error you are seeing will occur. This cannot be helped, the solution is to either disable output buffering or not use things like gz_handler, which cause ALL of the output to be buffered in memory rather then output the data in chunks (default chunk size 4096 bytes). [2003-01-16 10:20:56] [EMAIL PROTECTED] This bug has been present for over a year, maybe since the beginning of PHP. We're still getting people passing the buck.. [2003-01-15 16:44:33] [EMAIL PROTECTED] I am using Apache version 2.0.43 with the sapi php module. I downloaded the latest stable snapshot of php (4.3.1) but it still reproduced the same orignial problem discussed. Regards 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/21262 -- Edit this bug report at http://bugs.php.net/?id=21262edit=1
#21820 [Opn-Ver]: bc break in parser
ID: 21820
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Verified
Bug Type:Scripting Engine problem
PHP Version: 4.3.0
New Comment:
Anyone remember in what version of PHP this did work? :)
Correct (?) way to do this is:
?php
$arr = array('foo' = 'bar');
print {$arr['foo']};
?
Or at least I've started to use that just because of this bug.
Previous Comments:
[2003-01-22 13:56:01] [EMAIL PROTECTED]
Point was, maybe there is a reason this was not implemented.
And btw, this is a bug as 'foo' is defined yet the error says it's
not.
[2003-01-22 13:45:54] [EMAIL PROTECTED]
this patch fixes that feature request/bug as well
[2003-01-22 13:43:05] [EMAIL PROTECTED]
Allowing it would be nice but this topic has come up many times. Not
sure why it's not been implemented though, maybe there are reasons? I
forget them.
One feature request for this:
http://bugs.php.net/bug.php?id=15677
[2003-01-22 13:25:11] [EMAIL PROTECTED]
patch up at http://www2.omniti.com/~george/
zend.patch.2002012101
patch allows for $arr['foo'] to be parsed correctly (this
seems better than disallowing it)
[2003-01-22 09:19:20] [EMAIL PROTECTED]
I don't think this is a bug, but someone sent it to me via
email, so I'm proxy-submitting:
Hello George-
I stumbled upon a serious bug in the string parser and it
goes something like this:
$arr = array('foo' = 'bar');
print $arr['foo'];
This used to provide a parse error but now instead we get
this one of level E_NOTICE:
Notice: Undefined index: 'foo' in /tmp/a.php on line 4
/tmp/a.php(4) : Notice - Undefined index: 'foo'
This is a serious problem as it moved an error from
parse to E_NOTICE, fails silently as most have error
reporting turned down, shows a misleading error as foo
is defined, and breaks BC.
Tested latest 4_3 HEAD (4.3.1-dev). I would try php5
but I get segfault when trying to compile/use it :)
Have a nice day,
Philip Olson
cc: derick
--
Edit this bug report at http://bugs.php.net/?id=21820edit=1
#21262 [Opn]: crash or fail when outputting large amounts of text quickly
ID: 21262 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Performance problem Operating System: WinXP PHP Version: 4.3.0 New Comment: You really need to correct your attitude first. We're all volunteers here and don't get paid for this shit.. Previous Comments: [2003-01-22 19:49:33] [EMAIL PROTECTED] This is not always reproducible, this is as good as we can come up with. It appears to only reproduce for people unwilling to do anything about it. [2003-01-22 19:47:57] [EMAIL PROTECTED] Please provide a SHORT but complete example script that can be used to reproduce this. (the one you provided doesn't cause any crashes) [2003-01-22 19:41:51] [EMAIL PROTECTED] You are wrong. If it was a memory error, PHP should display the standard out of memory message. AS I EXPLAINED, this also happens with very SMALL amounts of data. The use of large blocks of data is just an easy way to REPRO. Surely there must be more people working on PHP than you? [2003-01-22 17:12:39] [EMAIL PROTECTED] Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php I've explained before and I will attempt to explain once again. When output buffering is turned on the system does not output the text right away but rather fills up a memory buffer that is displayed in one large block. If the text you are trying to output exceeds the avaliable system memory then the error you are seeing will occur. This cannot be helped, the solution is to either disable output buffering or not use things like gz_handler, which cause ALL of the output to be buffered in memory rather then output the data in chunks (default chunk size 4096 bytes). [2003-01-16 10:20:56] [EMAIL PROTECTED] This bug has been present for over a year, maybe since the beginning of PHP. We're still getting people passing the buck.. 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/21262 -- Edit this bug report at http://bugs.php.net/?id=21262edit=1
#21819 [Opn]: Corrupted uploaded binary files
ID: 21819
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
-Bug Type: HTTP related
+Bug Type: Apache2 related
Operating System: Linux RedHar 8.0
-PHP Version: 4.3.0
+PHP Version: 4.3.1
New Comment:
I guess the problem (again) is apache2. It's really not ready for
production yet, so you should consider using
Apache 1.3.27 which really works..
Reclassified.
Previous Comments:
[2003-01-22 16:07:04] [EMAIL PROTECTED]
The script goes like this:
html
body
?
echo $_FILES['userfile']['name']. ;
echo $_FILES['userfile']['type']. ;
echo $_FILES['userfile']['size']. ;
echo $_FILES['userfile']['tmp_name']. ;
echo $_FILES['userfile']['error']. ;
if (move_uploaded_file($_FILES['userfile']['tmp_name'],
/var/www/hosts/se8.org/htdocs/temp/image.jpg)) {
echo moved;
} else {
echo not_moved;
}
?
p
form action=test.php method=post enctype=multipart/form-data
input type=file name=userfile
input type=submit
/form
/body
/html
When I upload a 11463 byte image, it grows to 22575 bytes and corrutps.
[2003-01-22 15:44:58] [EMAIL PROTECTED]
Not enough information was provided for us to be able
to handle this bug. Please re-read the instructions at
http://bugs.php.net/how-to-report.php
If you can provide more information, feel free to add it
to this bug and change the status back to Open.
Thank you for your interest in PHP.
Please provide the script you are using to upload the files and the
script used to handle the actual files uploads.
[2003-01-22 08:59:41] [EMAIL PROTECTED]
When uploading binary files (about 5kB and up), they get corrupted, not
the whole file but some way from the beginning. The size is increased
about 90%, actual number of bytes varies with different browsers.
PHP versions tried: 4.3.0 and 4.3.1-dev (200301211230).
Configured with './configure' '--with-apxs2' '--with-openssl'
'--enable-calendar' '--with-curl' '--with-gd'
'--with-jpeg-dir=/usr/lib' '--with-png-dir=/usr/lib'
'--enable-mime-magic' '--with-mysql' '--enable-magic-quotes'
'--with-zlib-dir=/usr/lib' '--with-config-file-path=/etc'
Apache version: 2.0.43
--
Edit this bug report at http://bugs.php.net/?id=21819edit=1
#21830 [NEW]: libphp4.so not created
From: [EMAIL PROTECTED] Operating system: RedHat 7.3 PHP version: 4.3.0 PHP Bug Type: Compile Failure Bug description: libphp4.so not created I am trying to create the DSO version for Apache 2.0.44 $ ./configure --with-mysql --with-axps2=/web/bin/apxs Normal output. $ make all (does not complete) $ make libphp4.la [snip] ext/ctype/ctype.lo: file not recognized: File truncated collect2: ld returned 1 exit status make: *** [libphp4.la] Error 1 $ make libs/libphp4.bundle [snip]... /usr/lib/gcc-lib/i386-redhat-linux/2.96/../../../crt1.o: In function `_start': /usr/lib/gcc-lib/i386-redhat-linux/2.96/../../../crt1.o(.text+0x18): undefined reference to `main' collect2: ld returned 1 exit status make: *** [libs/libphp4.bundle] Error 1 There is nothing in libs and there is nothing in .libs I have also tried this with php4-STABLE-200301220430 and I get the same results. -- Edit bug report at http://bugs.php.net/?id=21830edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21830r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21830r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21830r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21830r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21830r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21830r=support Expected behavior: http://bugs.php.net/fix.php?id=21830r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21830r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21830r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21830r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21830r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21830r=dst IIS Stability: http://bugs.php.net/fix.php?id=21830r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=21830r=gnused
#21262 [Opn]: crash or fail when outputting large amounts of text quickly
ID: 21262 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Performance problem Operating System: WinXP PHP Version: 4.3.0 New Comment: My attitude is a result of iliaa's disrespect for MY time and work on this. I have nothing but respect for people that volunteer to improve PHP. Like I am doing myself by trying to point out bugs. I don't get paid to try OVER AND OVER to get people to recognize problems, and it is less fun than just fixing them myself would be, I assure you. But I have other projects I am committed to. The most I can do is keep pushing through the bureaucratic atmosphere created by people more interesting in closing bugs than fixing them. As I mentioned before, it's very much like trying to get bugs fixed at Microsoft. I don't know why, but this open source project has managed to duplicate the beauracracy aspect of large corporations very well. Perhaps its a lack of accountability from the lack of personal code ownership. Anyway, I submit to you that in NO CASE should PHP exit in an error condition without showing an error message. If this is INTENDED behavior then let me see the words memory exceeded, quitting. Until I see them, this is a bug. In fact, I very much doubt that this is intended behavior. When the buffer is full, PHP waits for it to be transmitted then continues. It does not simply crash. To state that crashing is not a bug shows a fundamental misunderstanding of programming, and indeed of the difference between all that is good and evil. Previous Comments: [2003-01-22 19:55:14] [EMAIL PROTECTED] You really need to correct your attitude first. We're all volunteers here and don't get paid for this shit.. [2003-01-22 19:49:33] [EMAIL PROTECTED] This is not always reproducible, this is as good as we can come up with. It appears to only reproduce for people unwilling to do anything about it. [2003-01-22 19:47:57] [EMAIL PROTECTED] Please provide a SHORT but complete example script that can be used to reproduce this. (the one you provided doesn't cause any crashes) [2003-01-22 19:41:51] [EMAIL PROTECTED] You are wrong. If it was a memory error, PHP should display the standard out of memory message. AS I EXPLAINED, this also happens with very SMALL amounts of data. The use of large blocks of data is just an easy way to REPRO. Surely there must be more people working on PHP than you? [2003-01-22 17:12:39] [EMAIL PROTECTED] Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php I've explained before and I will attempt to explain once again. When output buffering is turned on the system does not output the text right away but rather fills up a memory buffer that is displayed in one large block. If the text you are trying to output exceeds the avaliable system memory then the error you are seeing will occur. This cannot be helped, the solution is to either disable output buffering or not use things like gz_handler, which cause ALL of the output to be buffered in memory rather then output the data in chunks (default chunk size 4096 bytes). 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/21262 -- Edit this bug report at http://bugs.php.net/?id=21262edit=1
#21830 [Opn-Fbk]: libphp4.so not created
ID: 21830 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: Compile Failure Operating System: RedHat 7.3 PHP Version: 4.3.0 New Comment: Please check this report, and the last comment in it: http://bugs.php.net/bug.php?id=19924 This really isn't any PHP bug but something done wrong. (rm config.cache / make clean usually helps.) Previous Comments: [2003-01-22 20:08:09] [EMAIL PROTECTED] I am trying to create the DSO version for Apache 2.0.44 $ ./configure --with-mysql --with-axps2=/web/bin/apxs Normal output. $ make all (does not complete) $ make libphp4.la [snip] ext/ctype/ctype.lo: file not recognized: File truncated collect2: ld returned 1 exit status make: *** [libphp4.la] Error 1 $ make libs/libphp4.bundle [snip]... /usr/lib/gcc-lib/i386-redhat-linux/2.96/../../../crt1.o: In function `_start': /usr/lib/gcc-lib/i386-redhat-linux/2.96/../../../crt1.o(.text+0x18): undefined reference to `main' collect2: ld returned 1 exit status make: *** [libs/libphp4.bundle] Error 1 There is nothing in libs and there is nothing in .libs I have also tried this with php4-STABLE-200301220430 and I get the same results. -- Edit this bug report at http://bugs.php.net/?id=21830edit=1
#21830 [Com]: libphp4.so not created
ID: 21830 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: Compile Failure Operating System: RedHat 7.3 PHP Version: 4.3.0 New Comment: Ok. I just removed config.cache and did make clean. Running make again... I will report results shortly. Previous Comments: [2003-01-22 20:14:52] [EMAIL PROTECTED] Please check this report, and the last comment in it: http://bugs.php.net/bug.php?id=19924 This really isn't any PHP bug but something done wrong. (rm config.cache / make clean usually helps.) [2003-01-22 20:08:09] [EMAIL PROTECTED] I am trying to create the DSO version for Apache 2.0.44 $ ./configure --with-mysql --with-axps2=/web/bin/apxs Normal output. $ make all (does not complete) $ make libphp4.la [snip] ext/ctype/ctype.lo: file not recognized: File truncated collect2: ld returned 1 exit status make: *** [libphp4.la] Error 1 $ make libs/libphp4.bundle [snip]... /usr/lib/gcc-lib/i386-redhat-linux/2.96/../../../crt1.o: In function `_start': /usr/lib/gcc-lib/i386-redhat-linux/2.96/../../../crt1.o(.text+0x18): undefined reference to `main' collect2: ld returned 1 exit status make: *** [libs/libphp4.bundle] Error 1 There is nothing in libs and there is nothing in .libs I have also tried this with php4-STABLE-200301220430 and I get the same results. -- Edit this bug report at http://bugs.php.net/?id=21830edit=1
#21820 [Ver]: bc break in parser
ID: 21820
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Verified
Bug Type:Scripting Engine problem
PHP Version: 4.3.0
New Comment:
This bug appeared in 4.3.0 as a result of the lexer changes
added to ZE1 and ZE2 in november to speed up
variableinterpolation in strings.
Previous to 4.3 this was valid:
echo $a[b];
but
echo $a['b']; generated a parse error.
The bug manifests itself by turning this parse error into a
non-sensical E_NOTICE error.
The patch 'fixes' the bug by making
echo $a['b'];
work, which has been a pending feature request and seems
nice (to me), or at least harmless.
Previous Comments:
[2003-01-22 19:53:20] [EMAIL PROTECTED]
Anyone remember in what version of PHP this did work? :)
Correct (?) way to do this is:
?php
$arr = array('foo' = 'bar');
print {$arr['foo']};
?
Or at least I've started to use that just because of this bug.
[2003-01-22 13:56:01] [EMAIL PROTECTED]
Point was, maybe there is a reason this was not implemented.
And btw, this is a bug as 'foo' is defined yet the error says it's
not.
[2003-01-22 13:45:54] [EMAIL PROTECTED]
this patch fixes that feature request/bug as well
[2003-01-22 13:43:05] [EMAIL PROTECTED]
Allowing it would be nice but this topic has come up many times. Not
sure why it's not been implemented though, maybe there are reasons? I
forget them.
One feature request for this:
http://bugs.php.net/bug.php?id=15677
[2003-01-22 13:25:11] [EMAIL PROTECTED]
patch up at http://www2.omniti.com/~george/
zend.patch.2002012101
patch allows for $arr['foo'] to be parsed correctly (this
seems better than disallowing it)
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/21820
--
Edit this bug report at http://bugs.php.net/?id=21820edit=1
#21830 [Com]: libphp4.so not created
ID: 21830 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: Compile Failure Operating System: RedHat 7.3 PHP Version: 4.3.0 New Comment: $ make libphp4.la [snip] ext/ctype/ctype.lo: file not recognized: File truncated collect2: ld returned 1 exit status make: *** [libphp4.la] Error 1 $ cat ext/ctype/ctype.lo [one blank line] $ make libs/libphp4.bundle [snip] /usr/lib/gcc-lib/i386-redhat-linux/2.96/../../../crt1.o: In function `_start': /usr/lib/gcc-lib/i386-redhat-linux/2.96/../../../crt1.o(.text+0x18): undefined reference to `main' collect2: ld returned 1 exit status make: *** [libs/libphp4.bundle] Error 1 $ rpm -qf /usr/lib/gcc-lib/i386-redhat-linux/2.96/../../../crt1.o glibc-devel-2.2.5-42 Should I be using gcc3 perhaps? Previous Comments: [2003-01-22 20:23:14] [EMAIL PROTECTED] Ok. I just removed config.cache and did make clean. Running make again... I will report results shortly. [2003-01-22 20:14:52] [EMAIL PROTECTED] Please check this report, and the last comment in it: http://bugs.php.net/bug.php?id=19924 This really isn't any PHP bug but something done wrong. (rm config.cache / make clean usually helps.) [2003-01-22 20:08:09] [EMAIL PROTECTED] I am trying to create the DSO version for Apache 2.0.44 $ ./configure --with-mysql --with-axps2=/web/bin/apxs Normal output. $ make all (does not complete) $ make libphp4.la [snip] ext/ctype/ctype.lo: file not recognized: File truncated collect2: ld returned 1 exit status make: *** [libphp4.la] Error 1 $ make libs/libphp4.bundle [snip]... /usr/lib/gcc-lib/i386-redhat-linux/2.96/../../../crt1.o: In function `_start': /usr/lib/gcc-lib/i386-redhat-linux/2.96/../../../crt1.o(.text+0x18): undefined reference to `main' collect2: ld returned 1 exit status make: *** [libs/libphp4.bundle] Error 1 There is nothing in libs and there is nothing in .libs I have also tried this with php4-STABLE-200301220430 and I get the same results. -- Edit this bug report at http://bugs.php.net/?id=21830edit=1
#21830 [Fbk]: libphp4.so not created
ID: 21830 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: Compile Failure Operating System: RedHat 7.3 PHP Version: 4.3.0 New Comment: 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 That libs/libphp4.bundle is NOT meant for Linux, it's for MacOSX so using it does not help. Please try the snapshot. Previous Comments: [2003-01-22 20:39:25] [EMAIL PROTECTED] $ make libphp4.la [snip] ext/ctype/ctype.lo: file not recognized: File truncated collect2: ld returned 1 exit status make: *** [libphp4.la] Error 1 $ cat ext/ctype/ctype.lo [one blank line] $ make libs/libphp4.bundle [snip] /usr/lib/gcc-lib/i386-redhat-linux/2.96/../../../crt1.o: In function `_start': /usr/lib/gcc-lib/i386-redhat-linux/2.96/../../../crt1.o(.text+0x18): undefined reference to `main' collect2: ld returned 1 exit status make: *** [libs/libphp4.bundle] Error 1 $ rpm -qf /usr/lib/gcc-lib/i386-redhat-linux/2.96/../../../crt1.o glibc-devel-2.2.5-42 Should I be using gcc3 perhaps? [2003-01-22 20:23:14] [EMAIL PROTECTED] Ok. I just removed config.cache and did make clean. Running make again... I will report results shortly. [2003-01-22 20:14:52] [EMAIL PROTECTED] Please check this report, and the last comment in it: http://bugs.php.net/bug.php?id=19924 This really isn't any PHP bug but something done wrong. (rm config.cache / make clean usually helps.) [2003-01-22 20:08:09] [EMAIL PROTECTED] I am trying to create the DSO version for Apache 2.0.44 $ ./configure --with-mysql --with-axps2=/web/bin/apxs Normal output. $ make all (does not complete) $ make libphp4.la [snip] ext/ctype/ctype.lo: file not recognized: File truncated collect2: ld returned 1 exit status make: *** [libphp4.la] Error 1 $ make libs/libphp4.bundle [snip]... /usr/lib/gcc-lib/i386-redhat-linux/2.96/../../../crt1.o: In function `_start': /usr/lib/gcc-lib/i386-redhat-linux/2.96/../../../crt1.o(.text+0x18): undefined reference to `main' collect2: ld returned 1 exit status make: *** [libs/libphp4.bundle] Error 1 There is nothing in libs and there is nothing in .libs I have also tried this with php4-STABLE-200301220430 and I get the same results. -- Edit this bug report at http://bugs.php.net/?id=21830edit=1
#21830 [Fbk]: libphp4.so not created
ID: 21830 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: Compile Failure Operating System: RedHat 7.3 PHP Version: 4.3.0 New Comment: btw. Were you able to compile any previous PHP versions?? Like 4.2.3 ?? Previous Comments: [2003-01-22 20:43:57] [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 That libs/libphp4.bundle is NOT meant for Linux, it's for MacOSX so using it does not help. Please try the snapshot. [2003-01-22 20:39:25] [EMAIL PROTECTED] $ make libphp4.la [snip] ext/ctype/ctype.lo: file not recognized: File truncated collect2: ld returned 1 exit status make: *** [libphp4.la] Error 1 $ cat ext/ctype/ctype.lo [one blank line] $ make libs/libphp4.bundle [snip] /usr/lib/gcc-lib/i386-redhat-linux/2.96/../../../crt1.o: In function `_start': /usr/lib/gcc-lib/i386-redhat-linux/2.96/../../../crt1.o(.text+0x18): undefined reference to `main' collect2: ld returned 1 exit status make: *** [libs/libphp4.bundle] Error 1 $ rpm -qf /usr/lib/gcc-lib/i386-redhat-linux/2.96/../../../crt1.o glibc-devel-2.2.5-42 Should I be using gcc3 perhaps? [2003-01-22 20:23:14] [EMAIL PROTECTED] Ok. I just removed config.cache and did make clean. Running make again... I will report results shortly. [2003-01-22 20:14:52] [EMAIL PROTECTED] Please check this report, and the last comment in it: http://bugs.php.net/bug.php?id=19924 This really isn't any PHP bug but something done wrong. (rm config.cache / make clean usually helps.) [2003-01-22 20:08:09] [EMAIL PROTECTED] I am trying to create the DSO version for Apache 2.0.44 $ ./configure --with-mysql --with-axps2=/web/bin/apxs Normal output. $ make all (does not complete) $ make libphp4.la [snip] ext/ctype/ctype.lo: file not recognized: File truncated collect2: ld returned 1 exit status make: *** [libphp4.la] Error 1 $ make libs/libphp4.bundle [snip]... /usr/lib/gcc-lib/i386-redhat-linux/2.96/../../../crt1.o: In function `_start': /usr/lib/gcc-lib/i386-redhat-linux/2.96/../../../crt1.o(.text+0x18): undefined reference to `main' collect2: ld returned 1 exit status make: *** [libs/libphp4.bundle] Error 1 There is nothing in libs and there is nothing in .libs I have also tried this with php4-STABLE-200301220430 and I get the same results. -- Edit this bug report at http://bugs.php.net/?id=21830edit=1
