#45953 [NEW]: Sign-Bit Manipulating is buggy
From: ben at umingo dot de Operating system: Windows XP 32Bit PHP version: 5.2.6 PHP Bug Type: Output Control Bug description: Sign-Bit Manipulating is buggy Description: Problem is with sign bit. If i have 0x81234567 then first bit is set to 1 (sign bit). I would expect that number to be negative, as all integers are signed 32 bit integers. If i echo that number, it is positive! If i compute something with this number, it turns negative! I have a standard PHP 5.2.6 Version and did not modify anything at it. Reproduce code: --- ? //sign bit is not handled correctly //a | a is expected to be a ... //WORKS NOT echo with sign bit br; echo (0x81234567 | 0x81234567); //result is negative echo br; echo (0x81234567 );//result is positive echo brwithout sign bit br; //WORKS echo (0x71234567 | 0x71234567); echo br; echo (0x71234567 ); ? Expected result: with sign bit -2128394905 -2128394905 without sign bit 1898136935 1898136935 Actual result: -- with sign bit -2128394905 2166572391 without sign bit 1898136935 1898136935 -- Edit bug report at http://bugs.php.net/?id=45953edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=45953r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=45953r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=45953r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=45953r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=45953r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=45953r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=45953r=needscript Try newer version:http://bugs.php.net/fix.php?id=45953r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=45953r=support Expected behavior:http://bugs.php.net/fix.php?id=45953r=notwrong Not enough info: http://bugs.php.net/fix.php?id=45953r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=45953r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=45953r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=45953r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=45953r=dst IIS Stability:http://bugs.php.net/fix.php?id=45953r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=45953r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=45953r=float No Zend Extensions: http://bugs.php.net/fix.php?id=45953r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=45953r=mysqlcfg
#45953 [Opn-Bgs]: Sign-Bit Manipulating is buggy
ID: 45953 Updated by: [EMAIL PROTECTED] Reported By: ben at umingo dot de -Status: Open +Status: Bogus Bug Type: Output Control Operating System: Windows XP 32Bit PHP Version: 5.2.6 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 What's happening is that when the script is parsed and compiled, 0x81234567 actually becomes a float/double type since, as you mention, it's too big for 32-bit signed range and the intended behavior is to keep it positive (as it would be on platforms with 64-bit longs) and not restrict it to integer type only. The bitwise operators like | only operate on integers, and it converts a float/double to int first, which results in overflow to a negative number that you're seeing. Typecasting to (int) will also force the overflow (same internal conversion used by bitwise operators), and give the result you expect (on 32-bit platform anyway). Example: ?php var_dump(0x81234567); var_dump(0x81234567 | 0x81234567); var_dump((int) 0x81234567); Output: float(2166572391) int(-2128394905) int(-2128394905) Previous Comments: [2008-08-30 10:23:30] ben at umingo dot de Description: Problem is with sign bit. If i have 0x81234567 then first bit is set to 1 (sign bit). I would expect that number to be negative, as all integers are signed 32 bit integers. If i echo that number, it is positive! If i compute something with this number, it turns negative! I have a standard PHP 5.2.6 Version and did not modify anything at it. Reproduce code: --- ? //sign bit is not handled correctly //a | a is expected to be a ... //WORKS NOT echo with sign bit br; echo (0x81234567 | 0x81234567); //result is negative echo br; echo (0x81234567 );//result is positive echo brwithout sign bit br; //WORKS echo (0x71234567 | 0x71234567); echo br; echo (0x71234567 ); ? Expected result: with sign bit -2128394905 -2128394905 without sign bit 1898136935 1898136935 Actual result: -- with sign bit -2128394905 2166572391 without sign bit 1898136935 1898136935 -- Edit this bug report at http://bugs.php.net/?id=45953edit=1
#45950 [Opn-Bgs]: Running make results in non-writable sections errors
ID: 45950 Updated by: [EMAIL PROTECTED] Reported By: jackcsprat at yahoo dot com -Status: Open +Status: Bogus Bug Type: Compile Failure Operating System: Solaris 10 PHP Version: 5.2CVS-2008-08-29 (CVS) New Comment: Solaris is braindead. You need to have everything either as shared or static. Get shared zlib installed and it should work. Not PHP bug. Previous Comments: [2008-08-29 17:52:54] jackcsprat at yahoo dot com Description: I am trying to compile php 5.2.5 on a Solaris 10 server. My configure string mentioned below works fine, however, when I run make, I see a zillion lines similar to the following: .urem 0xc88 /usr/local/lib/libz.a(deflate.o) .urem 0x1398 /usr/local/lib/libz.a(inflate.o) .urem 0x7c/usr/local/lib/libz.a(adler32.o) Then the make stops with the following error: ld: fatal: relocations remain against allocatable but non-writable sections collect2: ld returned 1 exit status make: *** [libphp5.la] Error 1 Reproduce code: --- Here is my configure string: ./configure --prefix=/usr/local/php5 \ --with-apx2=/var/apps/apache/bin/apxs \ --with-ldap=/usr/local/etc/openldap \ --with-imap-dir=/usr/local/imap-2006e \ --with-imap-ssl \ --with-imap=/usr/local/imap-2006e \ --with-mysql=/var/apps/mysql \ --with-mysqli=/var/apps/mysql/bin/mysql_config \ --with-xsl=/usr/local/include/libxslt \ --with-ncurses \ --enable-xslt \ --with-xslt-sablot \ --with-bz2=/usr \ --with-gd \ --with-gdbm=/usr/local/lib \ --with-openssl \ --with-zlib \ --with-freetype-dir=/usr/local/include/freetype2/freetype/freetype.h \ --with-expat-dir \ --with-tiff-dir \ --with-jpeg-dir=/usr/local/include/jpeglib.h \ --with-png-dir=/usr/include/libpng12/png.h \ --with-mcrypt \ --with-curl \ --with-curlwrappers \ --with-gettext \ --disable-short-tags \ --disable-debug \ --enable-calendar \ --enable-ctype \ --enable-discard-path \ --enable-exif \ --enable-ftp \ --enable-memory-limit \ --enable-sysvem \ --enable-sysvshm \ --enable-gd-native-ttf \ --enable-soap \ --enable-shmop \ --enable-sockets \ --enable-xslt \ --enable-mbstring \ --with-sqlite=shared \ --with-pdo-sqlite=shared \ --with-pdo-mysql=shared,/var/apps/mysql \ --enable-pdo=shared \ --enable-bcmath Expected result: After running make, I expect a successful output so I can then run make install and complete the php build. Actual result: -- My gcc version info: --- gcc -v Reading specs from /usr/local/lib/gcc/sparc-sun-solaris2.10/3.4.6/specs Configured with: ../configure --with-as=/usr/ccs/bin/as --with-ld=/usr/ccs/bin/ld --enable-shared --enable-languages=c,c++,f77 Thread model: posix gcc version 3.4.6 my ld version ( I have also tried with the gnu ld - same issue) --- ld -V ld: Software Generation Utilities - Solaris Link Editors: 5.10-1.489 -- Edit this bug report at http://bugs.php.net/?id=45950edit=1
#45947 [Bgs]: Apache env variables changed by PHP IN Apache
ID: 45947
Updated by: [EMAIL PROTECTED]
Reported By: regis dot leroy at makina-corpus dot com
Status: Bogus
Bug Type: Apache2 related
Operating System: Linux Debian
PHP Version: 5.2.6
New Comment:
Jani, which bug is it? Or do you mean that #13961 is actually bogus?
As it is fine to change the name in PHP, it should not change the
apache (or more generally the server/system's) one.
Previous Comments:
[2008-08-30 16:03:23] [EMAIL PROTECTED]
Please do not submit the same bug more than once. An existing
bug report already describes this very problem. Even if you feel
that your issue is somewhat different, the resolution is likely
to be the same.
Thank you for your interest in PHP.
[2008-08-29 13:37:18] regis dot leroy at makina-corpus dot com
Description:
reopening Bug #39927 and Bug #13961 which seems to have been marked
Bogus because of a Bogus reviewer.
Apache Env set by, for example:
BrowserMatch MSIE 4\.0b2; nokeepalive downgrade-1.0
force-response-1.0
Is treaten in PHP to become downgrade-1_0 with an _. that's OK, its'
for security reasons.
But it is changed in Apache, and so Apache will not modify the response
to make his 'forced downgrade to HTTP/1.0'.
That's REALLY BAAAD.
This breaks Apache mechanism to handle bad browser which do not
understand well HTTP/1.1 (with chunked responses on bad Java soap parses
for exemple).
I reedit the bug to give a workaround for people interested:
in PHP write such things:
if ($_SERVER['downgrade-1_0']){
apache_setenv('downgrade-1.0','true');
}
Beware of safe mode allowed env vars if you're in safe mode.
Now you have to right behaviour $_SERVER contains only strings without
dots but Apache have the right env to behave well.
Shame on PHP
Reproduce code:
---
see previous bugs
Expected result:
response in HTTP/1.0
Actual result:
--
response in HTTP/1.1
--
Edit this bug report at http://bugs.php.net/?id=45947edit=1
#45947 [Opn-Bgs]: Apache env variables changed by PHP IN Apache
ID: 45947
Updated by: [EMAIL PROTECTED]
Reported By: regis dot leroy at makina-corpus dot com
-Status: Open
+Status: Bogus
Bug Type: Apache2 related
Operating System: Linux Debian
PHP Version: 5.2.6
New Comment:
Please do not submit the same bug more than once. An existing
bug report already describes this very problem. Even if you feel
that your issue is somewhat different, the resolution is likely
to be the same.
Thank you for your interest in PHP.
Previous Comments:
[2008-08-29 13:37:18] regis dot leroy at makina-corpus dot com
Description:
reopening Bug #39927 and Bug #13961 which seems to have been marked
Bogus because of a Bogus reviewer.
Apache Env set by, for example:
BrowserMatch MSIE 4\.0b2; nokeepalive downgrade-1.0
force-response-1.0
Is treaten in PHP to become downgrade-1_0 with an _. that's OK, its'
for security reasons.
But it is changed in Apache, and so Apache will not modify the response
to make his 'forced downgrade to HTTP/1.0'.
That's REALLY BAAAD.
This breaks Apache mechanism to handle bad browser which do not
understand well HTTP/1.1 (with chunked responses on bad Java soap parses
for exemple).
I reedit the bug to give a workaround for people interested:
in PHP write such things:
if ($_SERVER['downgrade-1_0']){
apache_setenv('downgrade-1.0','true');
}
Beware of safe mode allowed env vars if you're in safe mode.
Now you have to right behaviour $_SERVER contains only strings without
dots but Apache have the right env to behave well.
Shame on PHP
Reproduce code:
---
see previous bugs
Expected result:
response in HTTP/1.0
Actual result:
--
response in HTTP/1.1
--
Edit this bug report at http://bugs.php.net/?id=45947edit=1
#45947 [Bgs-Csd]: Apache env variables changed by PHP IN Apache
ID: 45947
Updated by: [EMAIL PROTECTED]
Reported By: regis dot leroy at makina-corpus dot com
-Status: Bogus
+Status: Closed
Bug Type: Apache2 related
Operating System: Linux Debian
PHP Version: 5.2.6
New Comment:
I don't think this one is bogus. Ilia was wrong in 13961. Only the
value is copied, not the key there. And in 39927 I replied to the last
commenter who seemed to want to disable the . - _ munging when
register_globals is off, but missed the original point of the code
modifying the passed in key. We dropped the ball multiple times on this
one.
I'll commit a fix in a bit.
Previous Comments:
[2008-08-30 16:17:50] [EMAIL PROTECTED]
Jani, which bug is it? Or do you mean that #13961 is actually bogus?
As it is fine to change the name in PHP, it should not change the
apache (or more generally the server/system's) one.
[2008-08-30 16:03:23] [EMAIL PROTECTED]
Please do not submit the same bug more than once. An existing
bug report already describes this very problem. Even if you feel
that your issue is somewhat different, the resolution is likely
to be the same.
Thank you for your interest in PHP.
[2008-08-29 13:37:18] regis dot leroy at makina-corpus dot com
Description:
reopening Bug #39927 and Bug #13961 which seems to have been marked
Bogus because of a Bogus reviewer.
Apache Env set by, for example:
BrowserMatch MSIE 4\.0b2; nokeepalive downgrade-1.0
force-response-1.0
Is treaten in PHP to become downgrade-1_0 with an _. that's OK, its'
for security reasons.
But it is changed in Apache, and so Apache will not modify the response
to make his 'forced downgrade to HTTP/1.0'.
That's REALLY BAAAD.
This breaks Apache mechanism to handle bad browser which do not
understand well HTTP/1.1 (with chunked responses on bad Java soap parses
for exemple).
I reedit the bug to give a workaround for people interested:
in PHP write such things:
if ($_SERVER['downgrade-1_0']){
apache_setenv('downgrade-1.0','true');
}
Beware of safe mode allowed env vars if you're in safe mode.
Now you have to right behaviour $_SERVER contains only strings without
dots but Apache have the right env to behave well.
Shame on PHP
Reproduce code:
---
see previous bugs
Expected result:
response in HTTP/1.0
Actual result:
--
response in HTTP/1.1
--
Edit this bug report at http://bugs.php.net/?id=45947edit=1
#45955 [NEW]: Mime-encoded UTF-8 subject is limited to 47 characters.
From: alexanderpas at yahoo dot co dot uk Operating system: Irrelevant PHP version: 5.2.6 PHP Bug Type: Mail related Bug description: Mime-encoded UTF-8 subject is limited to 47 characters. Description: an Mime-encoded UTF-8 subject is limited to 47 characters, because php doesn't allow \n into $subject of the mail function, and RFC 2047 requires CRLF SPACE to seperate multiple lines of encoded text php documentation: quotemail() [...] $subject [...] must not contain any newline characters, or the mail may not be sent properly./quote RFC 2047 quoteAn 'encoded-word' may not be more than 75 characters long, including 'charset', 'encoding', 'encoded-text', and delimiters. If it is desirable to encode more text than will fit in an 'encoded-word' of 75 characters, multiple 'encoded-word's (separated by CRLF SPACE) may be used./quote -- Edit bug report at http://bugs.php.net/?id=45955edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=45955r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=45955r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=45955r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=45955r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=45955r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=45955r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=45955r=needscript Try newer version:http://bugs.php.net/fix.php?id=45955r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=45955r=support Expected behavior:http://bugs.php.net/fix.php?id=45955r=notwrong Not enough info: http://bugs.php.net/fix.php?id=45955r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=45955r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=45955r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=45955r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=45955r=dst IIS Stability:http://bugs.php.net/fix.php?id=45955r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=45955r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=45955r=float No Zend Extensions: http://bugs.php.net/fix.php?id=45955r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=45955r=mysqlcfg
#45954 [NEW]: memory leak with unset(array)
From: mail at milianw dot de
Operating system: linux, windows
PHP version: 5.2.6
PHP Bug Type: Performance problem
Bug description: memory leak with unset(array)
Description:
When you setup an array and unset() it afterwards, not all memory is
freed. I've run the code below on various PHP versions, including 5.2.6
(via Xampp) on Linux and Windows and always get output like:
startup:64296
array setup:13789672
unsetted array: 129284
The end value is more than twice as large as the start value.
Also interestingly is that low values in the for loop [e.g. for($i = 0; $i
1; ++$i)] result in outputs like
startup: 64296
array setup:64864
unsetted array: 64864
Could it be that unset() relies on the Garbage Collector to do the work
instead of really destroying the variables? But then I find it strange that
even if I put a sleep(10) after the unset I still get the same outputs for
unsetted array.
Reproduce code:
---
?php
echo startup:.memory_get_usage().\n;
$array = array();
for ($i = 0; $i 10; ++$i) {
$array[] = 'foobar';
}
echo array setup:.memory_get_usage().\n;
unset($array);
echo unsetted array: .memory_get_usage().\n;
Expected result:
My expectations would be that the value reported at the end would be
nearly equal to the startup value.
Additionally a call to unset() should (imo) not rely on the GC but do the
deleting itself instantaneously.
NOTE: I've seen http://bugs.php.net/bug.php?id=41713 which tells a similar
story, but it should be fixed as far as the bug report tells. Additionally
it was Windows only yet I spotted the described behaviour first on a Linux
machine.
--
Edit bug report at http://bugs.php.net/?id=45954edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=45954r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=45954r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=45954r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=45954r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=45954r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=45954r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=45954r=needscript
Try newer version:http://bugs.php.net/fix.php?id=45954r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=45954r=support
Expected behavior:http://bugs.php.net/fix.php?id=45954r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=45954r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=45954r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=45954r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=45954r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=45954r=dst
IIS Stability:http://bugs.php.net/fix.php?id=45954r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=45954r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=45954r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=45954r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=45954r=mysqlcfg
#13961 [Bgs-Csd]: some characters in server variable names are silently changed
ID: 13961
Updated by: [EMAIL PROTECTED]
Reported By: lampa at fee dot vutbr dot cz
-Status: Bogus
+Status: Closed
Bug Type: Apache related
Operating System: any
PHP Version: 4CVS, 5CVS
Assigned To: derick
New Comment:
Fixed in 5.2, 5.3 and 6 CVS
Previous Comments:
[2004-03-31 12:39:48] daniele at orlandi dot com
It still isn't fixed in PHP 4.3.5, php still corrupts apache's
environment and here's the proof:
--- httpd.conf
BrowserMatch a downgrade-1.0 force-response-1.0 nokeepalive
--- a.html
html
body
/body
/html
--- a.php
?
echo ciao;
?
GET /a.html HTTP/1.1
Host: stef.uli.it
Connection: close
User-Agent: a
HTTP/1.0 200 OK
Date: Wed, 31 Mar 2004 17:35:57 GMT
Server: Apache/2.0.49 (Unix) mod_ssl/2.0.49 OpenSSL/0.9.7b PHP/4.3.5
Last-Modified: Wed, 31 Mar 2004 17:35:43 GMT
ETag: 522e8-1e-c69ff9c0
Accept-Ranges: bytes
Content-Length: 30
Connection: close
Content-Type: text/html
html
body
/body
/html
Connection closed by foreign host.
---
GET /a.php HTTP/1.1
Host: stef.uli.it
Connection: close
User-Agent: a
HTTP/1.1 200 OK
Date: Wed, 31 Mar 2004 17:34:57 GMT
Server: Apache/2.0.49 (Unix) mod_ssl/2.0.49 OpenSSL/0.9.7b PHP/4.3.5
X-Powered-By: PHP/4.3.5
Connection: close
Transfer-Encoding: chunked
Content-Type: text/html
4
ciao
0
Connection closed by foreign host.
--
As you see, the PHP response discards force-response-1.0 and still
responds with HTTP/1.1.
My Cisco 7960 IP phones has a broken HTTP/1.1 client and isn't able to
cope with chunked transfer encoding and I'm not able to make it work.
[2003-11-18 19:52:08] [EMAIL PROTECTED]
This is infact fixed php_register_variable() is actually a wrapper
around php_register_variable_safe() which always makes a copy of the
original before passing it to php_register_variable_ex().
[2003-11-14 07:06:13] lampa at fee dot vutbr dot cz
Still not fixed in 4.3.4
[2003-11-11 18:15:11] daniele at orlandi dot com
This bug is still present in php 4.3.4 and may be harmful since all the
BrowserMatch functionality to workaround browser bugs in Apache is
essentially disabled.
As a proof of concept i patched sapi/apache2handler/sapi_apache2.c
(apache2filter is probably affected too) and the problem went away.
Note that the patch may not be perfect as I don't know how Apache and
PHP work internally very well.
--- php-4.3.4/sapi/apache2handler/sapi_apache2.c2003-10-02
05:24:43.0 +0200
+++ php-4.3.4-patched/sapi/apache2handler/sapi_apache2.c
2003-11-11 23:52:06.0 +0100
@@ -227,9 +227,14 @@
char *key, *val;
zval **path_translated_zv;
+ char *t;
+
APR_ARRAY_FOREACH_OPEN(arr, key, val)
if (!val) val = empty_string;
- php_register_variable(key, val, track_vars_array
TSRMLS_CC);
+
+ t = estrndup(key, strlen(key));
+ php_register_variable(t, val, track_vars_array
TSRMLS_CC);
+ efree(t);
APR_ARRAY_FOREACH_CLOSE()
[2001-12-11 09:57:36] lampa at fee dot vutbr dot cz
Not fixed in 4.1.0. Why? To be clear, one call is neccessary:
for (i = 0; i arr-nelts; i++) {
char *val,*key;
if (elts[i].val) {
val = elts[i].val;
} else {
val = empty_string;
}
key = estrdup(elts[i].key); /* HERE */
php_register_variable(key, val, track_vars_array
ELS_CC PLS_CC)
;
}
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/13961
--
Edit this bug report at http://bugs.php.net/?id=13961edit=1
#39927 [Bgs-Csd]: server variable names are silently changed
ID: 39927 Updated by: [EMAIL PROTECTED] Reported By: to_devnull at yahoo dot com -Status: Bogus +Status: Closed Bug Type: Apache related Operating System: all PHP Version: 5.2.0 New Comment: Fixed in 5.2, 5.3 and 6 CVS Previous Comments: [2006-12-23 01:26:07] [EMAIL PROTECTED] I think the answer to that should be pretty obvious. We don't want to change behaviour of the code with and without register_globals. An app would have to check the register_globals setting in order to determine what the variable is called. That's even more confusing than the current situation where it is simply consistently changed. Once you realize that server variables may not contain spaces or dots, it is quite straightforward to write code against that. In fact, even when register_globals is completely removed, I doubt this will change since it would break backward compatibility with all existing apps. [2006-12-23 00:58:32] judas dot iscariote at gmail dot com Ilia: This behaviour is pretty much broken, why it does not check when register_globals is disabled and behaves correctly ? (and maybe drop register_globals in 5.3 or asap will be nice too ;) ) [2006-12-22 21:58:27] to_devnull at yahoo dot com This a strange reply (Read a manual, this is not a bug). Am I doing anything wrong here? I'm using default php installation and register_globals is Off in php.ini. Is there a way to configure php not to touch values in r-subprocess_env? My point is that php silently breaks Apache behavior by modifying specific data that is supposed to be read-only. If Apache allows force-response-1.0 in its subprocess_env table, why php changes it? If php wants to modify input var names, it should make a copy. I may be totally wrong and miss some important configuration issue. In this case I'd greatly appreciate if you point me in the right direction. But canned response is not an answer. [2006-12-22 03:34:42] [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 This is legacy of register_globals, as long as it exists . and spaces in input var names will be converted to underscores. [2006-12-22 00:28:27] to_devnull at yahoo dot com Description: I'm reopening Bug #13961 since some moron marked it as bogus and I can't comment on it: http://bugs.php.net/bug.php?id=13961 Apache module mod_setenvif sets variables in r-subprocess_env. If variable name contains character ., then sapi_apache_register_server_variables() will replace it with _. This breaks internal variables like force-response-1.0 (php changes it to force-response-1_0). I hit this bug with PHP4.4.3/PHP5 and latest Apache 1.3.37. Spent several hours tracing in debugger why downgrade-1.0 becomes downgrade-1_0. This is a serious bug -- basically it's impossible to downgrade client request/server response to HTTP 1.0 (or disable chunking) if php is involved. What a shame! Reproduce code: --- I actually traced it by shoving a static string containing '.' in r-subprocess_env and thus getting Apache to core dump when php tries to write to read-only memory in php_register_variable_ex(). -- Edit this bug report at http://bugs.php.net/?id=39927edit=1
#45948 [Opn-Fbk]: [PATCH] dom extension segfaults because of another apache module
ID: 45948 Updated by: [EMAIL PROTECTED] Reported By: thomas dot jarosch at intra2net dot com -Status: Open +Status: Feedback Bug Type: DOM XML related Operating System: linux PHP Version: 5.2.6 New Comment: Please provide patches against HEAD, PHP_5_3 and PHP_5_2 branches. Previous Comments: [2008-08-29 15:52:42] thomas dot jarosch at intra2net dot com The link somehow gets cropped by the bugtracker, the filename is php-5.2.6-fix-libxmlpp-clash.patch [2008-08-29 15:51:30] thomas dot jarosch at intra2net dot com Description: Hello together, like last time in bug #29599, another apache module is using libxml2 and registering a global create/delete node callback. Right now PHP crashes on our site while using the dom extension because the callback still points to the other module. Guess libxml2 is to blame for providing -global- callbacks. Attached patch makes sure everything is clean and shiny when enter/leaving the request handled by PHP. The performance impact should be close to nothing. Hope it's useful to someone else. Link to patch: http://www.intra2net.com/de/download/opensource/php-5.2.6-fix- Thomas -- Edit this bug report at http://bugs.php.net/?id=45948edit=1
#45956 [NEW]: Design problem: parse_ini_file lacks ability to handle errors gracefully
From: bugs at timj dot co dot uk
Operating system: irrelevant
PHP version: 5.2.6
PHP Bug Type: Filesystem function related
Bug description: Design problem: parse_ini_file lacks ability to handle errors
gracefully
Description:
This seems to be a design error rather than a bug: parse_ini_file() does
not provide any way to handle errors gracefully. In the event of a syntax
error, it throws an E_WARNING *but* the return value is simply an empty
array (the same as a - valid - empty file) instead of FALSE. Thus there is
no way to trap the error (via @ prefix) and handle it in a more graceful
way than an E_WARNING.
I would argue that changing the return value to FALSE in the case of an
invalid file is a reasonable change, since the only situations it will
break are ones where currently PHP throws a warning anyway.
Reproduce code:
---
This is what it would be nice to be able to do:
$ini = @parse_ini_file('some_invalid.ini');
if ($ini === false) {
// error: do something graceful
}
// normal execution
Expected result:
The code section // do something graceful executes
Actual result:
--
The code section // normal execution executes
--
Edit bug report at http://bugs.php.net/?id=45956edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=45956r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=45956r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=45956r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=45956r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=45956r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=45956r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=45956r=needscript
Try newer version:http://bugs.php.net/fix.php?id=45956r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=45956r=support
Expected behavior:http://bugs.php.net/fix.php?id=45956r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=45956r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=45956r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=45956r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=45956r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=45956r=dst
IIS Stability:http://bugs.php.net/fix.php?id=45956r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=45956r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=45956r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=45956r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=45956r=mysqlcfg
#45957 [Opn-Bgs]: I accidentally a whole namespace
ID: 45957 Updated by: [EMAIL PROTECTED] Reported By: nobody at example dot org -Status: Open +Status: Bogus Bug Type:Unknown/Other Function PHP Version: 5.2.6 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. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. Oops? Have to be more careful next time! Not possible since namespaces are first included in 5.3, of course. :-P Previous Comments: [2008-08-30 20:02:15] nobody at example dot org Description: I accidentally a whole namespace, is that bad? -- Edit this bug report at http://bugs.php.net/?id=45957edit=1
#45957 [Bgs]: I accidentally a whole namespace
ID: 45957 User updated by: nobody at example dot org Reported By: nobody at example dot org Status: Bogus Bug Type:Unknown/Other Function PHP Version: 5.2.6 New Comment: I can't believe I let that slip my mind. Dammit. Previous Comments: [2008-08-30 20:18:33] [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. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. Oops? Have to be more careful next time! Not possible since namespaces are first included in 5.3, of course. :-P [2008-08-30 20:02:15] nobody at example dot org Description: I accidentally a whole namespace, is that bad? -- Edit this bug report at http://bugs.php.net/?id=45957edit=1
#45957 [NEW]: I accidentally a whole namespace
From: nobody at example dot org Operating system: PHP version: 5.2.6 PHP Bug Type: Unknown/Other Function Bug description: I accidentally a whole namespace Description: I accidentally a whole namespace, is that bad? -- Edit bug report at http://bugs.php.net/?id=45957edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=45957r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=45957r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=45957r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=45957r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=45957r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=45957r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=45957r=needscript Try newer version:http://bugs.php.net/fix.php?id=45957r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=45957r=support Expected behavior:http://bugs.php.net/fix.php?id=45957r=notwrong Not enough info: http://bugs.php.net/fix.php?id=45957r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=45957r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=45957r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=45957r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=45957r=dst IIS Stability:http://bugs.php.net/fix.php?id=45957r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=45957r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=45957r=float No Zend Extensions: http://bugs.php.net/fix.php?id=45957r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=45957r=mysqlcfg
#45956 [Opn-Asn]: Design problem: parse_ini_file lacks ability to handle errors gracefully
ID: 45956
Updated by: [EMAIL PROTECTED]
Reported By: bugs at timj dot co dot uk
-Status: Open
+Status: Assigned
Bug Type: Filesystem function related
-Operating System: irrelevant
+Operating System: *
-PHP Version: 5.2.6
+PHP Version: 5CVS, 6CVS (2008-08-31)
-Assigned To:
+Assigned To: jani
New Comment:
It's a bug. Oversight, but bug nevertheless.
Previous Comments:
[2008-08-30 18:59:21] bugs at timj dot co dot uk
Description:
This seems to be a design error rather than a bug: parse_ini_file()
does not provide any way to handle errors gracefully. In the event of a
syntax error, it throws an E_WARNING *but* the return value is simply an
empty array (the same as a - valid - empty file) instead of FALSE. Thus
there is no way to trap the error (via @ prefix) and handle it in a more
graceful way than an E_WARNING.
I would argue that changing the return value to FALSE in the case of an
invalid file is a reasonable change, since the only situations it will
break are ones where currently PHP throws a warning anyway.
Reproduce code:
---
This is what it would be nice to be able to do:
$ini = @parse_ini_file('some_invalid.ini');
if ($ini === false) {
// error: do something graceful
}
// normal execution
Expected result:
The code section // do something graceful executes
Actual result:
--
The code section // normal execution executes
--
Edit this bug report at http://bugs.php.net/?id=45956edit=1
#45943 [Opn-Bgs]: php5-cgi crashes when changing gettext (*.mo) file
ID: 45943 Updated by: [EMAIL PROTECTED] Reported By: atomo64 at gmail dot com -Status: Open +Status: Bogus Bug Type: Reproducible crash Operating System: Debian GNU/Linux PHP Version: 5.2.6 New Comment: That's actually bug in gettext itself. And actually feature. It was never meant to support changing the .mo file during runtime. We can't do anything in PHP to prevent the crash, unless there's some support from gettext itself to allow this.. Previous Comments: [2008-08-29 01:11:16] atomo64 at gmail dot com Description: [This is http://bugs.debian.org/440775] Whenever the templates/translations are changed and the .mo files regenerated, PHP instances start to crash. Most likely they do not detect file change and still treate it as old one. Restarting PHP solves this. Actual result: -- #0 0x7fdf99718f81 in ?? () from /lib/libc.so.6 #1 0x7fdf9971a0e6 in ?? () from /lib/libc.so.6 #2 0x004c75b0 in zif_gettext (ht=17334608, return_value=0x10877d8, return_value_ptr=0xe61230, this_ptr=0x, return_value_used=-16843009) at /tmp/buildd/php5-5.2.6/ext/gettext/gettext.c:192 #3 0x7fdf9596f90d in ?? () from /usr/lib/php5/20060613/suhosin.so #4 0x006a0059 in zend_do_fcall_common_helper_SPEC (execute_data=0x7fffa3f7e3e0) at /tmp/buildd/php5-5.2.6/Zend/zend_vm_execute.h:202 #5 0x0068b8c4 in execute (op_array=0x1074d58) at /tmp/buildd/php5-5.2.6/Zend/zend_vm_execute.h:92 #6 0x7fdf9596fd96 in ?? () from /usr/lib/php5/20060613/suhosin.so #7 0x00667678 in zend_execute_scripts (type=32767, retval=0x0, file_count=-1544034840) at /tmp/buildd/php5-5.2.6/Zend/zend.c:1215 #8 0x00621fa8 in php_execute_script (primary_file=Cannot access memory at address 0x8000a3f7d550 ) at /tmp/buildd/php5-5.2.6/main/main.c:2026 #9 0x006df7ed in main (argc=-1544016504, argv=0x7fffa3f80980) at /tmp/buildd/php5-5.2.6/sapi/cgi/cgi_main.c:1927 (I know suhosin is there, but it is irrelevant as the bug report was originally reported with a version of Debian's php5 package which was not built with suhosin). -- Edit this bug report at http://bugs.php.net/?id=45943edit=1
#45956 [Asn-Csd]: parse_ini_file() does not return false with syntax errors in parsed file
ID: 45956
Updated by: [EMAIL PROTECTED]
Reported By: bugs at timj dot co dot uk
-Status: Assigned
+Status: Closed
Bug Type: Filesystem function related
Operating System: *
PHP Version: 5CVS, 6CVS (2008-08-31)
Assigned To: jani
New Comment:
This bug has been fixed in CVS.
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/.
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2008-08-30 22:41:26] [EMAIL PROTECTED]
It's a bug. Oversight, but bug nevertheless.
[2008-08-30 18:59:21] bugs at timj dot co dot uk
Description:
This seems to be a design error rather than a bug: parse_ini_file()
does not provide any way to handle errors gracefully. In the event of a
syntax error, it throws an E_WARNING *but* the return value is simply an
empty array (the same as a - valid - empty file) instead of FALSE. Thus
there is no way to trap the error (via @ prefix) and handle it in a more
graceful way than an E_WARNING.
I would argue that changing the return value to FALSE in the case of an
invalid file is a reasonable change, since the only situations it will
break are ones where currently PHP throws a warning anyway.
Reproduce code:
---
This is what it would be nice to be able to do:
$ini = @parse_ini_file('some_invalid.ini');
if ($ini === false) {
// error: do something graceful
}
// normal execution
Expected result:
The code section // do something graceful executes
Actual result:
--
The code section // normal execution executes
--
Edit this bug report at http://bugs.php.net/?id=45956edit=1
#45928 [Opn-Ctl]: large scripts from stdin are stripped at 16K border
ID: 45928 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Critical Bug Type: CGI related Operating System: Mac OS X 10.5 PHP Version: 5.3CVS-2008-08-26 (CVS) Previous Comments: [2008-08-26 18:24:52] [EMAIL PROTECTED] Description: any php-file which is larger that 16Kb will result in parse error on Mac OS X, if run as following: cat largefile.php|php -l while the following options will work: php -l largefile.php php -l largefile.php -l flag is optional. it can be reproduced without it too I discussed this with Rasmus (he was able to reproduce this problem too), and he mentioned, that this bug is most likely re2c-related Expected result: No syntax errors detected in - Actual result: -- PHP Parse error: syntax error, unexpected $end in -- Edit this bug report at http://bugs.php.net/?id=45928edit=1
#45954 [Opn-Bgs]: memory leak with unset(array)
ID: 45954
Updated by: [EMAIL PROTECTED]
Reported By: mail at milianw dot de
-Status: Open
+Status: Bogus
Bug Type: Performance problem
Operating System: *
PHP Version: 5.2.6
New Comment:
unset() is not free(). PHP uses memory manager that does the actual
garbage cleanup during request shutdown.
Previous Comments:
[2008-08-30 16:12:43] mail at milianw dot de
Description:
When you setup an array and unset() it afterwards, not all memory is
freed. I've run the code below on various PHP versions, including 5.2.6
(via Xampp) on Linux and Windows and always get output like:
startup:64296
array setup:13789672
unsetted array: 129284
The end value is more than twice as large as the start value.
Also interestingly is that low values in the for loop [e.g. for($i = 0;
$i 1; ++$i)] result in outputs like
startup: 64296
array setup:64864
unsetted array: 64864
Could it be that unset() relies on the Garbage Collector to do the work
instead of really destroying the variables? But then I find it strange
that even if I put a sleep(10) after the unset I still get the same
outputs for unsetted array.
Reproduce code:
---
?php
echo startup:.memory_get_usage().\n;
$array = array();
for ($i = 0; $i 10; ++$i) {
$array[] = 'foobar';
}
echo array setup:.memory_get_usage().\n;
unset($array);
echo unsetted array: .memory_get_usage().\n;
Expected result:
My expectations would be that the value reported at the end would be
nearly equal to the startup value.
Additionally a call to unset() should (imo) not rely on the GC but do
the deleting itself instantaneously.
NOTE: I've seen http://bugs.php.net/bug.php?id=41713 which tells a
similar story, but it should be fixed as far as the bug report tells.
Additionally it was Windows only yet I spotted the described behaviour
first on a Linux machine.
--
Edit this bug report at http://bugs.php.net/?id=45954edit=1
#45945 [Opn-Fbk]: Apache byterange output filter nullified if mod_php5 output 8000 bytes
ID: 45945 Updated by: [EMAIL PROTECTED] Reported By: djimenez at conduit-it dot com -Status: Open +Status: Feedback Bug Type: Apache2 related Operating System: Ubuntu - gutsy gibbon PHP Version: 5.2.6 New Comment: What have you set your output_buffering to? (check from phpinfo() output) Previous Comments: [2008-08-29 04:15:37] djimenez at conduit-it dot com Description: Apache2 supports byte range response with an output filter. Static files over 8000 bytes work fine, but mod_php5 served content only works correctly if it is = 8000 bytes To test I used telnet to submit an HTTP Range request for the included PHP file from an apache2 server configured with mod_php5. Example requests are in the actual results. Reproduce code: --- ?php // upto and including 8000 bytes will allow the byterange filter to work // // NOTE: 8000 byte limit was found by manual trial and error, may vary per system, but // my guess would be it has to do with a byte buffer either in mod_php5 or apache2 echo str_repeat(., 8000); // anything over 8000 bytes will fail (full response) //echo \n...one toke over the line; ? Expected result: Apache's byterange output filter should handle range requests for PHP responses 8000 bytes. Actual result: -- While the test scripts second echo is commented, I get the expected results: $ telnet dev.conduit-it.com 80 Trying 10.42.84.2... Connected to dev.conduit-it.com. Escape character is '^]'. GET /test.php HTTP/1.1 Host:dev.conduit-it.com Range:bytes=0-24 Connection:close HTTP/1.1 206 Partial Content Date: Fri, 29 Aug 2008 03:43:20 GMT Content-Range: bytes 0-24/8000 Content-Length: 25 Connection: close Content-Type: text/html .Connection closed by foreign host. We can also see it working for multiple ranges: $ telnet dev.conduit-it.com 80 Trying 10.42.84.2... Connected to dev.conduit-it.com. Escape character is '^]'. GET /test.php HTTP/1.1 Host:dev.conduit-it.com Range:bytes=0-24,50-74 Connection:close HTTP/1.1 206 Partial Content Date: Fri, 29 Aug 2008 03:45:44 GMT Content-Length: 240 Connection: close Content-Type: multipart/byteranges; boundary=455911696d6f354a2 --455911696d6f354a2 Content-type: text/html Content-range: bytes 0-24/8000 . --455911696d6f354a2 Content-type: text/html Content-range: bytes 50-74/8000 . --455911696d6f354a2-- Connection closed by foreign host. So apache is doing all the work for us, until we uncomment the second echo statement in the repro. script. This puts us over the 8000 byte limit. At that point, both example requests will return full 200 OK responses (so content is 8000 periods + our message) -- Edit this bug report at http://bugs.php.net/?id=45945edit=1
#45945 [Fbk-Opn]: Apache byterange output filter nullified if mod_php5 output 8000 bytes
ID: 45945 User updated by: djimenez at conduit-it dot com Reported By: djimenez at conduit-it dot com -Status: Feedback +Status: Open Bug Type: Apache2 related Operating System: Ubuntu - gutsy gibbon PHP Version: 5.2.6 New Comment: output buffering was set to Off, though setting it to something else still had the same result with the test on my box. Previous Comments: [2008-08-31 00:32:04] [EMAIL PROTECTED] What have you set your output_buffering to? (check from phpinfo() output) [2008-08-29 04:15:37] djimenez at conduit-it dot com Description: Apache2 supports byte range response with an output filter. Static files over 8000 bytes work fine, but mod_php5 served content only works correctly if it is = 8000 bytes To test I used telnet to submit an HTTP Range request for the included PHP file from an apache2 server configured with mod_php5. Example requests are in the actual results. Reproduce code: --- ?php // upto and including 8000 bytes will allow the byterange filter to work // // NOTE: 8000 byte limit was found by manual trial and error, may vary per system, but // my guess would be it has to do with a byte buffer either in mod_php5 or apache2 echo str_repeat(., 8000); // anything over 8000 bytes will fail (full response) //echo \n...one toke over the line; ? Expected result: Apache's byterange output filter should handle range requests for PHP responses 8000 bytes. Actual result: -- While the test scripts second echo is commented, I get the expected results: $ telnet dev.conduit-it.com 80 Trying 10.42.84.2... Connected to dev.conduit-it.com. Escape character is '^]'. GET /test.php HTTP/1.1 Host:dev.conduit-it.com Range:bytes=0-24 Connection:close HTTP/1.1 206 Partial Content Date: Fri, 29 Aug 2008 03:43:20 GMT Content-Range: bytes 0-24/8000 Content-Length: 25 Connection: close Content-Type: text/html .Connection closed by foreign host. We can also see it working for multiple ranges: $ telnet dev.conduit-it.com 80 Trying 10.42.84.2... Connected to dev.conduit-it.com. Escape character is '^]'. GET /test.php HTTP/1.1 Host:dev.conduit-it.com Range:bytes=0-24,50-74 Connection:close HTTP/1.1 206 Partial Content Date: Fri, 29 Aug 2008 03:45:44 GMT Content-Length: 240 Connection: close Content-Type: multipart/byteranges; boundary=455911696d6f354a2 --455911696d6f354a2 Content-type: text/html Content-range: bytes 0-24/8000 . --455911696d6f354a2 Content-type: text/html Content-range: bytes 50-74/8000 . --455911696d6f354a2-- Connection closed by foreign host. So apache is doing all the work for us, until we uncomment the second echo statement in the repro. script. This puts us over the 8000 byte limit. At that point, both example requests will return full 200 OK responses (so content is 8000 periods + our message) -- Edit this bug report at http://bugs.php.net/?id=45945edit=1
#45945 [Com]: Apache byterange output filter nullified if mod_php5 output 8000 bytes
ID: 45945 Comment by: djimenez at conduit-it dot com Reported By: djimenez at conduit-it dot com Status: Open Bug Type: Apache2 related Operating System: Ubuntu - gutsy gibbon PHP Version: 5.2.6 New Comment: I used amazon ec2 to test and reconfirm this bug on a base install of apache2 and php5.2.6 in ubuntu intrepid ibex. No changes to the php.ini (which I've included without comments and empty sections): [PHP] engine = On zend.ze1_compatibility_mode = Off short_open_tag = On asp_tags = Off precision= 12 y2k_compliance = On output_buffering = Off zlib.output_compression = Off implicit_flush = Off unserialize_callback_func= serialize_precision = 100 allow_call_time_pass_reference = On safe_mode = Off safe_mode_gid = Off safe_mode_include_dir = safe_mode_exec_dir = safe_mode_allowed_env_vars = PHP_ safe_mode_protected_env_vars = LD_LIBRARY_PATH disable_functions = disable_classes = expose_php = On max_execution_time = 30 ; Maximum execution time of each script, in seconds max_input_time = 60 ; Maximum amount of time each script may spend parsing request data memory_limit = 16M ; Maximum amount of memory a script may consume (16MB) error_reporting = E_ALL ~E_NOTICE display_errors = On display_startup_errors = Off log_errors = Off log_errors_max_len = 1024 ignore_repeated_errors = Off ignore_repeated_source = Off report_memleaks = On track_errors = Off variables_order = EGPCS register_globals = Off register_long_arrays = On register_argc_argv = On auto_globals_jit = On post_max_size = 8M magic_quotes_gpc = On magic_quotes_runtime = Off magic_quotes_sybase = Off auto_prepend_file = auto_append_file = default_mimetype = text/html doc_root = user_dir = enable_dl = Off file_uploads = On upload_max_filesize = 2M allow_url_fopen = On allow_url_include = Off default_socket_timeout = 60 [Syslog] define_syslog_variables = Off [mail function] SMTP = localhost smtp_port = 25 [SQL] sql.safe_mode = Off [ODBC] odbc.allow_persistent = On odbc.check_persistent = On odbc.max_persistent = -1 odbc.max_links = -1 odbc.defaultlrl = 4096 odbc.defaultbinmode = 1 [MySQL] mysql.allow_persistent = On mysql.max_persistent = -1 mysql.max_links = -1 mysql.default_port = mysql.default_socket = mysql.default_host = mysql.default_user = mysql.default_password = mysql.connect_timeout = 60 mysql.trace_mode = Off [MySQLi] mysqli.max_links = -1 mysqli.default_port = 3306 mysqli.default_socket = mysqli.default_host = mysqli.default_user = mysqli.default_pw = mysqli.reconnect = Off [mSQL] msql.allow_persistent = On msql.max_persistent = -1 msql.max_links = -1 [PostgresSQL] pgsql.allow_persistent = On pgsql.auto_reset_persistent = Off pgsql.max_persistent = -1 pgsql.max_links = -1 pgsql.ignore_notice = 0 pgsql.log_notice = 0 [Sybase] sybase.allow_persistent = On sybase.max_persistent = -1 sybase.max_links = -1 sybase.min_error_severity = 10 sybase.min_message_severity = 10 sybase.compatability_mode = Off [Sybase-CT] sybct.allow_persistent = On sybct.max_persistent = -1 sybct.max_links = -1 sybct.min_server_severity = 10 sybct.min_client_severity = 10 [bcmath] bcmath.scale = 0 [Informix] ifx.default_host = ifx.default_user = ifx.default_password = ifx.allow_persistent = On ifx.max_persistent = -1 ifx.max_links = -1 ifx.textasvarchar = 0 ifx.byteasvarchar = 0 ifx.charasvarchar = 0 ifx.blobinfile = 0 ifx.nullformat = 0 [Session] session.save_handler = files session.use_cookies = 1 session.name = PHPSESSID session.auto_start = 0 session.cookie_lifetime = 0 session.cookie_path = / session.cookie_domain = session.cookie_httponly = session.serialize_handler = php session.gc_divisor = 100 session.gc_maxlifetime = 1440 session.bug_compat_42 = 1 session.bug_compat_warn = 1 session.referer_check = session.entropy_length = 0 session.entropy_file = session.cache_limiter = nocache session.cache_expire = 180 session.use_trans_sid = 0 session.hash_function = 0 session.hash_bits_per_character = 4 url_rewriter.tags = a=href,area=href,frame=src,input=src,form=,fieldset= [MSSQL] mssql.allow_persistent = On mssql.max_persistent = -1 mssql.max_links = -1 mssql.min_error_severity = 10 mssql.min_message_severity = 10 mssql.compatability_mode = Off mssql.secure_connection = Off [Tidy] tidy.clean_output = Off [soap] soap.wsdl_cache_enabled=1 soap.wsdl_cache_dir=/tmp soap.wsdl_cache_ttl=86400 Previous Comments: [2008-08-31 01:48:44] djimenez at conduit-it dot com output buffering was set to Off, though setting it to something else still had the same result with the test on my box. [2008-08-31 00:32:04] [EMAIL PROTECTED] What have you set your output_buffering to? (check from phpinfo() output) [2008-08-29 04:15:37] djimenez at
