Bug #52571 [Csd-Bgs]: socket_read function returns max 1305 bytes remote, OK local
Edit report at http://bugs.php.net/bug.php?id=52571edit=1
ID: 52571
Updated by: m...@php.net
Reported by:jim_ivers at americantours dot com
Summary:socket_read function returns max 1305 bytes remote,
OK local
-Status: Closed
+Status: Bogus
Type: Bug
Package:Streams related
Operating System: Centos 5 (redhat clone)
PHP Version:5.3.3
Block user comment: N
Previous Comments:
[2010-08-11 20:29:25] jim_ivers at americantours dot com
To clarify, the socket server is remote or local, the php code is always
local.
Turns out one of the libraries on the remote server is using unicode, 4
bytes to the character. Thus the string it is trying to return is 4
times as long as the string length.
[2010-08-09 22:45:00] jim_ivers at americantours dot com
Description:
I have a php script running on apache that reads a string from a TCP
socket on a server. Using the below script on a local server works. I
cannot get it to return more than 1305 bytes remotely. The remote server
reports sending the whole string (about 4K bytes) back.
The following is a short version of the code below:
while(($sting = socket_read($socket, $slen, PHP_BINARY_READ)) !==
false) {
$out = $out.$sting;
if(strlen($out) = $slen) break;
}
I get a warning that the socket closed, then the string:
bWarning/b: socket_read() [a
href='function.socket-read'function.socket-read/a]: unable to read
from socket [104]: Connection reset by peer in
b/usr/local/apache2/htdocs/mikidel.php/b on line b473/bbr /
returnstringabcdefg.
using php 5.3.3 w Apache/2.2.14 (Unix) PHP/5.3.3 on Centos 5 ( redhat
clone)
./configure --enable-xml --enable-dom --with-openssl --enable-sockets
--enable-debug --with-config-file-path=/etc --with-curl --with-zlib
--enable-ftp --enable-soap --with-sybase-ct=/sybase
--with-libxml-dir=/usr --prefix=/usr/local/apache2/php
--with-config-file-path=/usr/local/apache/php --with-gettext
--with-apxs2=/usr/local/apache2/bin/apxs
php.ini standard vanilla
note that the remote socket is C code, and I have tried using
write(socket...) and send(socket...). Both work locally since there are
no \n or \r. Neither work remotely.
Test script:
---
// Create a TCP/IP Socket
$socket = socket_create (AF_INET, SOCK_STREAM, 0);
if ($socket 0) { echo socket() failed: reason: . strerror
($socket) . \n; }
// Connect to Target
$result = socket_connect ($socket, $address, $service_port);
if ($result 0) { echo connect() failed.\nReason: ($result) .
strerror($result) . \n; }
$tmp = socket_read ($socket, 6, PHP_BINARY_READ);
$slen = (int)($tmp-6);
$out = (string)$tmp;
$sting = socket_read($socket, $slen, PHP_BINARY_READ);
$out = $out.$sting;
while(($sting = socket_read($socket, $slen, PHP_BINARY_READ)) !==
false) {
$out = $out.$sting;
if(strlen($out) = $slen) break;
}
// Close Socket
socket_close ($socket);
return $out.\n;
Expected result:
The script should work remotely since it works locally.
Obviously if I ask for 4k bytes from a remote socket, it should return
4k bytes, since it does so from a local socket.
Actual result:
--
bWarning/b: socket_read() [a
href='function.socket-read'function.socket-read/a]: unable to read
from socket [104]: Connection reset by peer in
b/usr/local/apache2/htdocs/mikidel.php/b on line b473/bbr /
returnstringabcdefg.
--
Edit this bug report at http://bugs.php.net/bug.php?id=52571edit=1
[PHP-BUG] Bug #52589 [NEW]: com_exception when read array from object-property
From:
Operating system: WinXP
PHP version: 5.3.3
Package: COM related
Bug Type: Bug
Bug description:com_exception when read array from object-property
Description:
I have small test ActiveX DLL writen in VB6.
It is code of DLL:
Option Explicit
Private str_Text() As String
Public Property Get Text(index As Integer) As String
ReDim str_Text(3)
str_Text(0) = Test zero string
str_Text(1) = Test first string
str_Text(2) = Test second string
If ((index 0) Or (index = 3)) Then
Text =
Else
Text = str_Text(index)
End If
End Property
Public Property Get Count() As Long
Count = 3
End Property
When I trying read array from Text property PHP page generate error, but in
VB6
it's working correct.
Test script:
---
?php
$obj = new COM('TestCOM.Class1') or die('COM init failed.');
$j = $obj-Count;
print $j.br;
for ($i=0; $i$j; $i++)
{
$str = $obj-Text[$i];
print $str.br ;
}
?
Expected result:
3
Test zero string
Test first string
Test second string
Actual result:
--
3
Fatal error: Uncaught exception 'com_exception' with message 'Error
[0x8002000f]
ÐаÑамеÑÑ ÑвлÑеÑÑÑ Ð¾Ð±ÑзаÑелÑнÑм. ' in
C:\Inetpub\_web_script_\SKU_Buffer\docsgenerator\xls.php:8 Stack trace: #0
C:\Inetpub\_web_script_\SKU_Buffer\docsgenerator\xls.php(8): unknown() #1
{main}
thrown in C:\Inetpub\_web_script_\SKU_Buffer\docsgenerator\xls.php on line
8
--
Edit bug report at http://bugs.php.net/bug.php?id=52589edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=52589r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=52589r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=52589r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=52589r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=52589r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=52589r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=52589r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=52589r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=52589r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=52589r=support
Expected behavior:
http://bugs.php.net/fix.php?id=52589r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=52589r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=52589r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=52589r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52589r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=52589r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=52589r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=52589r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=52589r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=52589r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=52589r=mysqlcfg
Bug #52589 [Com]: com_exception when read array from object-property
Edit report at http://bugs.php.net/bug.php?id=52589edit=1
ID: 52589
Comment by: stinger25 at yandex dot ru
Reported by:stinger25 at yandex dot ru
Summary:com_exception when read array from object-property
Status: Open
Type: Bug
Package:COM related
Operating System: WinXP
PHP Version:5.3.3
Block user comment: N
New Comment:
It's working if instead property write method.
VB6 Code
Public Function ReadText(index) As String
Dim ret As String
ReDim str_Text(3)
str_Text(0) = Test zero string
str_Text(1) = Test first string
str_Text(2) = Test second string
If ((index 0) Or (index = 3)) Then
ret =
Else
ret = str_Text(index)
End If
ReadText = ret
End Function
and in PHP page
?php
$obj = new COM('TestCOM.Class1') or die('COM init failed.');
$j = $obj-Count;
print $j.br;
for ($i=0; $i$j; $i++)
{
// $str = $obj-Text[$i];
$str = $obj-ReadText($i);
print $str.br ;
}
?
Actual result:
3
Test zero string
Test first string
Test second string
Previous Comments:
[2010-08-12 08:52:30] stinger25 at yandex dot ru
Description:
I have small test ActiveX DLL writen in VB6.
It is code of DLL:
Option Explicit
Private str_Text() As String
Public Property Get Text(index As Integer) As String
ReDim str_Text(3)
str_Text(0) = Test zero string
str_Text(1) = Test first string
str_Text(2) = Test second string
If ((index 0) Or (index = 3)) Then
Text =
Else
Text = str_Text(index)
End If
End Property
Public Property Get Count() As Long
Count = 3
End Property
When I trying read array from Text property PHP page generate error, but
in VB6
it's working correct.
Test script:
---
?php
$obj = new COM('TestCOM.Class1') or die('COM init failed.');
$j = $obj-Count;
print $j.br;
for ($i=0; $i$j; $i++)
{
$str = $obj-Text[$i];
print $str.br ;
}
?
Expected result:
3
Test zero string
Test first string
Test second string
Actual result:
--
3
Fatal error: Uncaught exception 'com_exception' with message 'Error
[0x8002000f]
ÐаÑамеÑÑ ÑвлÑеÑÑÑ Ð¾Ð±ÑзаÑелÑнÑм. ' in
C:\Inetpub\_web_script_\SKU_Buffer\docsgenerator\xls.php:8 Stack trace:
#0
C:\Inetpub\_web_script_\SKU_Buffer\docsgenerator\xls.php(8): unknown()
#1 {main}
thrown in C:\Inetpub\_web_script_\SKU_Buffer\docsgenerator\xls.php on
line 8
--
Edit this bug report at http://bugs.php.net/bug.php?id=52589edit=1
[PHP-BUG] Bug #52590 [NEW]: Hang on
From: Operating system: Windows NT 5.1 b. 2600 SP3 i586 PHP version: 5.3.3 Package: MySQL related Bug Type: Bug Bug description:Hang on Description: When can't connect to server (example: firewall) it hangs on. Do not returns of mysql_connect() or others functions (but returns from mysql_error(), mysql_get_client_info() and others). mysql_get_client_info() returns: mysqlnd 5.0.7-dev - 091210 - $Revision: 300533 $ php_info() returns: System Windows NT PCC 5.1 build 2600 (Windows XP Professional Service Pack 3) i586 Build Date Jul 21 2010 20:00:47 CompilerMSVC6 (Visual C++ 6.0) Architecturex86 Configure Command cscript /nologo configure.js --enable-snapshot-build --disable-isapi --enable-debug-pack --disable-isapi --without-mssql --without-pdo-mssql --without-pi3web --with-pdo-oci=D:\php-sdk\oracle\instantclient10\sdk,shared --with-oci8=D:\php-sdk\oracle\instantclient10\sdk,shared --with-oci8-11g=D:\php-sdk\oracle\instantclient11\sdk,shared --enable-object-out-dir=../obj/ --enable-com-dotnet --with-mcrypt=static Server API Apache 2.0 Handler Virtual Directory Support enabled Configuration File (php.ini) Path C:\WIN.0 Loaded Configuration File C:\Progs\Internet\Servidor\PHP\php.ini Scan this dir for additional .ini files (none) Additional .ini files parsed(none) PHP API 20090626 PHP Extension 20090626 Zend Extension 220090626 Zend Extension BuildAPI220090626,TS,VC6 PHP Extension Build API20090626,TS,VC6 Debug Build no Thread Safety enabled Zend Memory Manager enabled Zend Multibyte Support disabled IPv6 Supportenabled Registered PHP Streams php, file, glob, data, http, ftp, zip, compress.zlib, compress.bzip2, phar Registered Stream Socket Transports tcp, udp Registered Stream Filters convert.iconv.*, mcrypt.*, mdecrypt.*, string.rot13, string.toupper, string.tolower, string.strip_tags, convert.*, consumed, dechunk, zlib.*, bzip2.* Configuration apache2handler Apache Version Apache/2.2.15 (Win32) PHP/5.3.3 Apache API Version 20051115 Server Administrator[...] Hostname:Port crjt.PCC:0 Max RequestsPer Child: 0 - Keep Alive: on - Max Per Connection: 100 TimeoutsConnection: 300 - Keep-Alive: 5 Virtual Server Yes Server Root C:/Progs/Internet/Servidor/Apache Loaded Modules core mod_win32 mpm_winnt http_core mod_so mod_actions mod_alias mod_asis mod_auth_basic mod_authn_default mod_authn_file mod_authz_default mod_authz_groupfile mod_authz_host mod_authz_user mod_autoindex mod_cgi mod_dir mod_env mod_include mod_isapi mod_log_config mod_mime mod_negotiation mod_setenvif mod_php5 Directive Local Value Master Value engine 1 1 last_modified 0 0 xbithack0 0 Apache Environment VariableValue HTTP_HOST crjt.pcc HTTP_USER_AGENT Mozilla/5.0 (Windows; U; Windows NT 5.1; es-ES; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3 ( .NET CLR 3.5.30729) HTTP_ACCEPT text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 HTTP_ACCEPT_LANGUAGEes-es,es;q=0.8,en-us;q=0.5,en;q=0.3 HTTP_ACCEPT_ENCODINGgzip,deflate HTTP_ACCEPT_CHARSET ISO-8859-1,utf-8;q=0.7,*;q=0.7 HTTP_KEEP_ALIVE 115 HTTP_CONNECTION keep-alive PATH C:\WIN.0\system32;C:\WIN.0;C:\WIN.0\System32\Wbem;C:\Progs\Ãtil\doxygen\bin SystemRoot C:\WIN.0 COMSPEC C:\WIN.0\system32\cmd.exe PATHEXT .COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH WINDIR C:\WIN.0 SERVER_SIGNATUREno value SERVER_SOFTWARE Apache/2.2.15 (Win32) PHP/5.3.3 SERVER_NAME crjt.pcc SERVER_ADDR 127.0.0.1 SERVER_PORT 80 REMOTE_ADDR 127.0.0.1 DOCUMENT_ROOT C:/Usuarios/Reloj.PCC/Mis documentos/My Dropbox/CRJT/nuevo SERVER_ADMIN[...] SCRIPT_FILENAME C:/Usuarios/Reloj.PCC/Mis documentos/My Dropbox/CRJT/nuevo/phpinfo.php REMOTE_PORT 3794 GATEWAY_INTERFACE CGI/1.1 SERVER_PROTOCOL HTTP/1.1 REQUEST_METHOD GET QUERY_STRINGno value REQUEST_URI /phpinfo.php SCRIPT_NAME /phpinfo.php HTTP Headers Information HTTP Request Headers HTTP RequestGET /phpinfo.php HTTP/1.1 Hostcrjt.pcc User-Agent Mozilla/5.0 (Windows; U; Windows NT 5.1; es-ES; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3 ( .NET CLR 3.5.30729) Accept text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language es-es,es;q=0.8,en-us;q=0.5,en;q=0.3 Accept-Encoding gzip,deflate Accept-Charset ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive 115 Connection keep-alive HTTP Response Headers X-Powered-ByPHP/5.3.3 Keep-Alive timeout=5, max=100 Connection Keep-Alive Transfer-Encoding chunked Content-Typetext/html bcmath BCMath support enabled Directive Local Value Master Value bcmath.scale0 0
Bug #52587 [Opn-Asn]: Clearstatcache() has no effect
Edit report at http://bugs.php.net/bug.php?id=52587edit=1
ID: 52587
Updated by: paj...@php.net
Reported by:a-krcrai at microsoft dot com
Summary:Clearstatcache() has no effect
-Status: Open
+Status: Assigned
Type: Bug
Package:*Directory/Filesystem functions
Operating System: Windows
PHP Version:5.3.3
-Assigned To:
+Assigned To:pajoye
Block user comment: N
New Comment:
Will double check that with Kris once I'm back.
Previous Comments:
[2010-08-12 04:54:37] a-krcrai at microsoft dot com
Oh, and this was reproduced on both VC6 and VC9 I'm pretty sure.
[2010-08-12 04:53:30] a-krcrai at microsoft dot com
If you're getting all true dumps, then that means that either you're
using 5.2.x (which I'm assuming you're not), or it means that the
directory/file exists but that the permissions aren't being successfully
applied (or some other weird ACL issue on your system).
This is because, even if you couldn't reproduce the bug, you should
still be getting false for the first two results, since full access is
being denied (meaning the file should be neither readable nor
writable).
Fortunately, debugging this is pretty simple. I'd like you to do two
things for me, if you don't mind:
1. Pipe the exec calls to an array (see php.net/exec for details on how
to do this), then do a print_r() of said array and paste the output of
that here. This will show us if SetACL is having trouble setting the
permissions on your system.
2. *Either*:
After the first pair of var_dumps, go ahead and temporarily toss in a
die() statement and re-run the script. Then, from the command-line,
type notepad testdir/testfile. If the SetACL calls executed properly,
this should pop-up a Notepad window with an Access Denied popup
message. If, on the other hand, Notepad loads your file just fine, then
that means the file is readable and thus the ACL permissions were never
applied.
*Or*:
If you have Powershell installed, open that and CD to whatever directory
your PHP script is in. Then type get-acl testdir/testfile |
format-list and paste the output here.
[2010-08-12 04:42:25] ka...@php.net
Just did a test following the steps from your comment, my results are so
far:
php-trunk, VC9, x86, ZTS/NTS:
bool(true)
bool(true)
bool(true)
bool(true)
php-53, VC9, x86, ZTS/NTS:
bool(true)
bool(true)
bool(true)
bool(true)
I interpreted your steps as:
1) mkdir testdir
2) php -r file_put_contents('./testdir/testfile', 'PHP on Windows');
3) Make a php file with the above code inside
4) php bug52587.php
About ACL:
C:\phpsetacl -help
SetACL by Helge Klein
Homepage:http://setacl.sourceforge.net
Version: 2.0.3.0
Copyright: Helge Klein
License: GPL
Did you use VC6 or VC9 binaries for your testing?
[2010-08-12 03:20:14] a-krcrai at microsoft dot com
Description:
The results of is_readable() and is_writable() are being cached from the
first result on a filesystem object regardless of whether or not
clearstatcache() is used or in what form (arguments supplied, etc).
This has only been tested on the Windows build of PHP 5.3.3 via the CLI.
It's possible that other functions are being improperly cached as well,
but I haven't had time to test for all of them as of yet.
This does *not*, however, occur in the corresponding Windows builds of
PHP 5.3.2. In that version, no caching took place on either of those
functions at all.
You can easily reproduce this issue if you're running Windows
ACL-related tests on the filesystem in PHP 5.3.3. The sample script I
put together requires the use of SetACL (better cross-Windows version
portability; http://setacl.sourceforge.net) to alter the file
permissions. Relative to the test script, create a directory named
testdir, then touch a file within that directory and name it
testfile. We will be using that file for our test.
This bug occurs on the ZIP-build of PHP 5.3.3 (both nts and zts) run via
CLI without any extensions loaded. It has been successfully reproduced
in Windows XP, Windows 2003, Windows 2003 R2, Windows Vista/7, Windows
2008, and Windows 2008 R2. Has not been tested on Linux.
Test script:
---
?php
exec( setacl.exe -on testdir -ot file -actn setprot -op
\dacl:p_nc;sacl:p_nc\ -rec cont_obj ); //Isolate from any perms
inherited from parent.
exec( setacl.exe -on testdir -ot file -actn clear -clr DACL -rec
cont_obj ); //Clear any remaining perms.
exec( setacl.exe -on testdir -ot file -actn ace -ace
\n:Everyone;m:grant;p:full\ ); //Ensures that the parent dir
[PHP-BUG] Bug #52591 [NEW]: possibility of calling protected static methods in not inherited classes
From:
Operating system: any
PHP version: 5.2.14
Package: Scripting Engine problem
Bug Type: Bug
Bug description:possibility of calling protected static methods in not
inherited classes
Description:
PHP allows to call protected static method in classes not inherited from
class,
that defines this method. See test script. We have two classes inherited
from
basic abstract class and we can call protected functions (defined abstract)
of
first class from second. Note, call_user_func caused error (works as
expected).
Test script:
---
?php
abstract class A {
abstract protected static function test();
}
class B extends A {
protected static function test()
{
return abc;
}
}
abstract class C extends A {
public static function do1()
{
return B::test();// Expected Fatal error: Call to protected
method...
}
}
echo C::do1(); // returns 'abc'
Expected result:
Fatal error: Call to protected method B::test() from context 'C'
Actual result:
--
abc
--
Edit bug report at http://bugs.php.net/bug.php?id=52591edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=52591r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=52591r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=52591r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=52591r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=52591r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=52591r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=52591r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=52591r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=52591r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=52591r=support
Expected behavior:
http://bugs.php.net/fix.php?id=52591r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=52591r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=52591r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=52591r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52591r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=52591r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=52591r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=52591r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=52591r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=52591r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=52591r=mysqlcfg
Bug #35090 [Com]: file i/o is not buffered
Edit report at http://bugs.php.net/bug.php?id=35090edit=1
ID: 35090
Comment by: surfchen at gmail dot com
Reported by:askalski at gmail dot com
Summary:file i/o is not buffered
Status: Bogus
Type: Bug
Package:Filesystem function related
Operating System: linux
PHP Version:5CVS-2005-11-03 (snap)
Block user comment: N
New Comment:
So we need to add a note on the documentation say that this function not
supported
with filesystem wrapper, right?
Previous Comments:
[2005-11-03 23:40:24] askalski at gmail dot com
instead it uses the system's file io buffering function
to set the buffer.
Assuming you're talking about setvbuf() and not kernel
level write-behind caching, this statement is false.
The file is opened by _php_stream_fopen():
fd = open(realpath, open_flags, 0666);
(It is never subsequently wrapped with fdopen())
At this point, the stream is not buffered at all.
When I later call stream_set_write_buffer(), it hits
php_stdiop_set_option():
case PHP_STREAM_OPTION_WRITE_BUFFER:
if (data-file == NULL) {
return -1;
}
/* setvbuf happens down here */
Because there is no FILE* handle (data-file), setvbuf()
is never called for the stream.
One of either the documentation
(http://us3.php.net/stream_set_write_buffer)
or the PHP source is wrong.
[2005-11-03 21:34:16] il...@php.net
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
PHP does not do any buffering itself, instead it uses the system's file
io buffering function to set the buffer.
There is already a feature request open to enable in-php buffering.
[2005-11-03 21:29:08] der...@php.net
Can you please answer why this is not a bug Wez? I forgot the reason :)
[2005-11-03 19:16:09] askalski at gmail dot com
Description:
The documentation for stream_set_write_buffer() says that fwrite()s are
buffered at 8K by default. In reality, it does not buffer at all. Any
attempt to call stream_set_write_buffer() on a regular file handle
results in failure.
Reproduce code:
---
$fh = fopen(asdf, w);
// write some data using the default buffering
for ($i = 0; $i 5; $i++)
fwrite($fh, test);
// demonstrate that stream_set_write_buffer fails
$n = stream_set_write_buffer($fh, 8192);
if ($n != 0)
echo stream_set_write_buffer failed\n;
// write some more data to demonstrate the failure
for ($i = 0; $i 5; $i++)
fwrite($fh, again);
fclose($fh);
Expected result:
PHP should buffer its I/O, and strace should log a single write().
stream_set_write_buffer() should not fail on regular files.
Actual result:
--
Output:
stream_set_write_buffer failed
Abridged strace output:
open(/tmp/php5-200511031730/asdf, O_WRONLY|O_CREAT|O_TRUNC, 0666) = 3
fstat64(3, {st_mode=S_IFREG|0600, st_size=0, ...}) = 0
lseek(3, 0, SEEK_CUR) = 0
write(3, test, 4) = 4
write(3, test, 4) = 4
write(3, test, 4) = 4
write(3, test, 4) = 4
write(3, test, 4) = 4
write(1, stream_set_write_buffer failed\n, 31) = 31
write(3, again, 5)= 5
write(3, again, 5)= 5
write(3, again, 5)= 5
write(3, again, 5)= 5
write(3, again, 5)= 5
close(3)= 0
--
Edit this bug report at http://bugs.php.net/bug.php?id=35090edit=1
Bug #52591 [Opn-Bgs]: possibility of calling protected static methods in not inherited classes
Edit report at http://bugs.php.net/bug.php?id=52591edit=1
ID: 52591
Updated by: johan...@php.net
Reported by:v dot kholoshenko at gmail dot com
Summary:possibility of calling protected static methods in
not inherited classes
-Status: Open
+Status: Bogus
Type: Bug
Package:Scripting Engine problem
Operating System: any
PHP Version:5.2.14
Block user comment: N
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
That is exactly what protected means.
Previous Comments:
[2010-08-12 12:52:32] v dot kholoshenko at gmail dot com
Description:
PHP allows to call protected static method in classes not inherited from
class,
that defines this method. See test script. We have two classes inherited
from
basic abstract class and we can call protected functions (defined
abstract) of
first class from second. Note, call_user_func caused error (works as
expected).
Test script:
---
?php
abstract class A {
abstract protected static function test();
}
class B extends A {
protected static function test()
{
return abc;
}
}
abstract class C extends A {
public static function do1()
{
return B::test();// Expected Fatal error: Call to protected
method...
}
}
echo C::do1(); // returns 'abc'
Expected result:
Fatal error: Call to protected method B::test() from context 'C'
Actual result:
--
abc
--
Edit this bug report at http://bugs.php.net/bug.php?id=52591edit=1
Bug #52591 [Bgs]: possibility of calling protected static methods in not inherited classes
Edit report at http://bugs.php.net/bug.php?id=52591edit=1
ID: 52591
User updated by:v dot kholoshenko at gmail dot com
Reported by:v dot kholoshenko at gmail dot com
Summary:possibility of calling protected static methods in
not inherited classes
Status: Bogus
Type: Bug
Package:Scripting Engine problem
Operating System: any
PHP Version:5.2.14
Block user comment: N
New Comment:
ok, so why call_user_func doesn't works in such way?
Previous Comments:
[2010-08-12 13:34:54] johan...@php.net
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
That is exactly what protected means.
[2010-08-12 12:52:32] v dot kholoshenko at gmail dot com
Description:
PHP allows to call protected static method in classes not inherited from
class,
that defines this method. See test script. We have two classes inherited
from
basic abstract class and we can call protected functions (defined
abstract) of
first class from second. Note, call_user_func caused error (works as
expected).
Test script:
---
?php
abstract class A {
abstract protected static function test();
}
class B extends A {
protected static function test()
{
return abc;
}
}
abstract class C extends A {
public static function do1()
{
return B::test();// Expected Fatal error: Call to protected
method...
}
}
echo C::do1(); // returns 'abc'
Expected result:
Fatal error: Call to protected method B::test() from context 'C'
Actual result:
--
abc
--
Edit this bug report at http://bugs.php.net/bug.php?id=52591edit=1
Req #30473 [Com]: in_array not working correctly
Edit report at http://bugs.php.net/bug.php?id=30473edit=1
ID: 30473
Comment by: alpust at gmail dot com
Reported by:lenar at city dot ee
Summary:in_array not working correctly
Status: Open
Type: Feature/Change Request
Package:Feature/Change Request
Operating System: Debian
PHP Version:4.3.9
Block user comment: N
New Comment:
So,
$array_symbols = array(0, '1', '5', 'abc', '', 'hello');
print in_array('z', $array_symbols);
Result: 1
does it normal?
Previous Comments:
[2004-10-19 13:38:18] lenar at city dot ee
Trying this as feature request to get review...
[2004-10-19 13:36:14] lenar at city dot ee
One more comment.
What I want to say is that comparisons in array functions should happen
like 'eq' operator does it in perl.
That would be intuitive. You can't change this, I presume, but that
would be the correct way IMHO.
[2004-10-19 11:56:05] lenar at city dot ee
I don't know then. All I'm sure the logic behind string and int
comparison isn't as one would expect from language doing automatic type
conversions.
You should cast (string) to (int) or (float) only if (string) is
numeric. Otherwise it's only logical to cast (int)/(float) operand to
string before comparing. That's how I would expect automatic type
conversion behave. Currently it's not intuitive.
(test == 0) evaluating to true just doesn't seem right.
Just my $0.02 (which I do not have).
[2004-10-19 09:13:42] der...@php.net
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
There is no BC here, I tried a couple of versions (4.0.0, 4.0.7, 4.1.2,
4.2.3, 4.3.5-4.3.9) and all do this:
der...@tequila:/dat/dev/php/php-4.0.0$ ./php
?php
var_dump(in_array(test, array(0)));
?
X-Powered-By: PHP/4.0.0
Content-type: text/html
bool(true)
[2004-10-18 18:46:24] lenar at city dot ee
Description:
function in_array() returns wrong result.
No way (string) test is equal to (int) 0.
It is not right to cast needle to the type of array value.
The same problem manifests itself with array_search().
You will say propably that you've added third parameter to in_array() to
take care of this, but in reality this isn't solution. The problem is
you can't blindly cast needle.
And manual says: If needle is a string, the comparison is done in a
case-sensitive manner.
Now tell me how you can compare a string you cast to (int) in
case-sensitive manner?
And this is all bad because I discovered this by accident after a
customer complained their stuff didn't work anymore.
That code used to work. I can swear. So you have broken BC it seems.
Reproduce code:
---
var_dump(in_array(test, array(0))
Expected result:
bool(false)
Actual result:
--
bool(true)
--
Edit this bug report at http://bugs.php.net/bug.php?id=30473edit=1
[PHP-BUG] Bug #52592 [NEW]: mb_ereg_replace and the Greek capital Pi
From:
Operating system: Centos 5.5 x64
PHP version: 5.2.14
Package: mbstring related
Bug Type: Bug
Bug description:mb_ereg_replace and the Greek capital Pi
Description:
PHP: 5.2.14, Apache 2.2.15, mod_php
While \s is supposed to match all whitespace, the greek unicode letter Pi
(Î ) whose code is 0xCEA0 is matched too and if replaced with something,
it's stripped of its second byte (0xA0).
Test script:
---
?php
mb_internal_encoding('UTF-8');
$testStr = 'Î Î Î !';
$newStr = mb_ereg_replace('\s+','_',$testStr);
echo $testStr;
echo $newStr;
echo urlencode($testStr);
echo urlencode($newStr);
?
Expected result:
Î Î Î !
Î __Î __Î !
%CE%A0++%CE%A0++%CE%A0%21
%CE%A0__%CE%A0__%CE%A0%21
Actual result:
--
Î Î Î !
[non printable character]_[non printable character]_[non printable
character]!
%CE%A0++%CE%A0++%CE%A0%21
%CE_%CE_%CE_%21
--
Edit bug report at http://bugs.php.net/bug.php?id=52592edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=52592r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=52592r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=52592r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=52592r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=52592r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=52592r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=52592r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=52592r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=52592r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=52592r=support
Expected behavior:
http://bugs.php.net/fix.php?id=52592r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=52592r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=52592r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=52592r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52592r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=52592r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=52592r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=52592r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=52592r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=52592r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=52592r=mysqlcfg
Req #30473 [Opn-Bgs]: in_array not working correctly
Edit report at http://bugs.php.net/bug.php?id=30473edit=1
ID: 30473
Updated by: johan...@php.net
Reported by:lenar at city dot ee
Summary:in_array not working correctly
-Status: Open
+Status: Bogus
Type: Feature/Change Request
-Package:Feature/Change Request
+Package:*General Issues
Operating System: Debian
PHP Version:4.3.9
Block user comment: N
New Comment:
in_array has a third parameter to be strict since PHP 4.2.0.
Previous Comments:
[2010-08-12 14:27:24] alpust at gmail dot com
So,
$array_symbols = array(0, '1', '5', 'abc', '', 'hello');
print in_array('z', $array_symbols);
Result: 1
does it normal?
[2004-10-19 13:38:18] lenar at city dot ee
Trying this as feature request to get review...
[2004-10-19 13:36:14] lenar at city dot ee
One more comment.
What I want to say is that comparisons in array functions should happen
like 'eq' operator does it in perl.
That would be intuitive. You can't change this, I presume, but that
would be the correct way IMHO.
[2004-10-19 11:56:05] lenar at city dot ee
I don't know then. All I'm sure the logic behind string and int
comparison isn't as one would expect from language doing automatic type
conversions.
You should cast (string) to (int) or (float) only if (string) is
numeric. Otherwise it's only logical to cast (int)/(float) operand to
string before comparing. That's how I would expect automatic type
conversion behave. Currently it's not intuitive.
(test == 0) evaluating to true just doesn't seem right.
Just my $0.02 (which I do not have).
[2004-10-19 09:13:42] der...@php.net
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
There is no BC here, I tried a couple of versions (4.0.0, 4.0.7, 4.1.2,
4.2.3, 4.3.5-4.3.9) and all do this:
der...@tequila:/dat/dev/php/php-4.0.0$ ./php
?php
var_dump(in_array(test, array(0)));
?
X-Powered-By: PHP/4.0.0
Content-type: text/html
bool(true)
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/bug.php?id=30473
--
Edit this bug report at http://bugs.php.net/bug.php?id=30473edit=1
[PHP-BUG] Req #52593 [NEW]: Getting scope variables of the caller function
From:
Operating system:
PHP version: 5.2.14
Package: *General Issues
Bug Type: Feature/Change Request
Bug description:Getting scope variables of the caller function
Description:
In bug #48290 was the function get_caller_vars() suggested. But in that
case it was irrelevant. However do I seek such a function.
get_defined_vars() returns the vars in the current scope. As do i like to
get the variables of the caller routine.
This would allow me to use parameters from a subroutine without having to
refactor another parameter being get_defined_vars() as this would obviously
uglify my code, which would impeach the reason to refactor in the first
place.
Test script:
---
function a() {
$test = 'A';
b();
}
function b() {
$test = 'B';
$vars_local = get_defined_vars();
$vars_caller = get_caller_vars();
echo $vars_caller['test']; // Expexted: A
echo $vars_local['test']; // Expected: B
}
a();
Expected result:
A
B
Actual result:
--
such a function does not exist
--
Edit bug report at http://bugs.php.net/bug.php?id=52593edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=52593r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=52593r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=52593r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=52593r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=52593r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=52593r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=52593r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=52593r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=52593r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=52593r=support
Expected behavior:
http://bugs.php.net/fix.php?id=52593r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=52593r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=52593r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=52593r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52593r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=52593r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=52593r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=52593r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=52593r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=52593r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=52593r=mysqlcfg
Req #52593 [Com]: Getting scope variables of the caller function
Edit report at http://bugs.php.net/bug.php?id=52593edit=1
ID: 52593
Comment by: dragoo...@php.net
Reported by:hpolthof at gmail dot com
Summary:Getting scope variables of the caller function
Status: Open
Type: Feature/Change Request
Package:*General Issues
PHP Version:5.2.14
Block user comment: N
New Comment:
Please elaborate on such a function does not exist with an exact error
message.
Previous Comments:
[2010-08-12 14:45:51] hpolthof at gmail dot com
Description:
In bug #48290 was the function get_caller_vars() suggested. But in that
case it was irrelevant. However do I seek such a function.
get_defined_vars() returns the vars in the current scope. As do i like
to get the variables of the caller routine.
This would allow me to use parameters from a subroutine without having
to refactor another parameter being get_defined_vars() as this would
obviously uglify my code, which would impeach the reason to refactor in
the first place.
Test script:
---
function a() {
$test = 'A';
b();
}
function b() {
$test = 'B';
$vars_local = get_defined_vars();
$vars_caller = get_caller_vars();
echo $vars_caller['test']; // Expexted: A
echo $vars_local['test']; // Expected: B
}
a();
Expected result:
A
B
Actual result:
--
such a function does not exist
--
Edit this bug report at http://bugs.php.net/bug.php?id=52593edit=1
Req #52593 [Opn]: Getting scope variables of the caller function
Edit report at http://bugs.php.net/bug.php?id=52593edit=1
ID: 52593
Updated by: johan...@php.net
Reported by:hpolthof at gmail dot com
Summary:Getting scope variables of the caller function
Status: Open
Type: Feature/Change Request
Package:*General Issues
PHP Version:5.2.14
Block user comment: N
New Comment:
Then you also need get_callers_caller_vars() and
get_callers_callers_caller_vars() but by definition a function shall be
independent from the caller's scope. All required information shall be
passed as parameter.
Previous Comments:
[2010-08-12 15:05:21] dragoo...@php.net
Please elaborate on such a function does not exist with an exact error
message.
[2010-08-12 14:45:51] hpolthof at gmail dot com
Description:
In bug #48290 was the function get_caller_vars() suggested. But in that
case it was irrelevant. However do I seek such a function.
get_defined_vars() returns the vars in the current scope. As do i like
to get the variables of the caller routine.
This would allow me to use parameters from a subroutine without having
to refactor another parameter being get_defined_vars() as this would
obviously uglify my code, which would impeach the reason to refactor in
the first place.
Test script:
---
function a() {
$test = 'A';
b();
}
function b() {
$test = 'B';
$vars_local = get_defined_vars();
$vars_caller = get_caller_vars();
echo $vars_caller['test']; // Expexted: A
echo $vars_local['test']; // Expected: B
}
a();
Expected result:
A
B
Actual result:
--
such a function does not exist
--
Edit this bug report at http://bugs.php.net/bug.php?id=52593edit=1
Bug #50921 [Com]: '200 OK' HTTP status despite PHP error
Edit report at http://bugs.php.net/bug.php?id=50921edit=1
ID: 50921
Comment by: tyra3l at gmail dot com
Reported by:phpbug at starurl dot com
Summary:'200 OK' HTTP status despite PHP error
Status: Bogus
Type: Bug
Package:HTTP related
Operating System: *
PHP Version:5.2.12
Block user comment: N
New Comment:
I can reproduce the problem.
I found out, that if I enable xdebug, then I get header 200, if I
disable it, then
it's 500.
Will report it to Derick.
Tyrael
Previous Comments:
[2010-03-12 08:37:24] anzenews at volja dot net
I am also having huge problems with this - haproxy health checks do not
work reliably because of this bug. Please consider reopening it - it is
not bogus.
PHP doesn't return HTTP error code, even if display_errors is set to 0.
One example:
?
ini_set('display_errors',0);
this_function_does_not_exist();
echo ok;
?
This returns an empty page with status code 200:
-
HTTP/1.1 200 OK
DateFri, 12 Mar 2010 07:27:15 GMT
Server Apache/2.2.9 (Debian) PHP/5.2.6-1+lenny6 with Suhosin-Patch
X-Powered-ByPHP/5.2.6-1+lenny6
VaryAccept-Encoding
Content-Encodinggzip
Content-Length 20
Keep-Alive timeout=15, max=100
Connection Keep-Alive
Content-Typetext/html
-
Content-Length is 20, probably because of gzip? There are no spaces
around PHP block in source code.
I have checked phpinfo() and display_errors is set to Off, so there is
no error there. Also, I have tried setting it in php.ini - no change.
Another problem: parse errors are also not handled correctly (even if
display_errors is set to 0 in php.ini). See previous poster's example.
Thanks!
[2010-02-03 19:03:56] der...@php.net
The reason why display errors needs to be turned of, is because
displayed errors generate output, and output causes the headers to be
send out. I'm afraid we can't do much about this.
[2010-02-03 18:01:37] phpbug at starurl dot com
Thank you for the swift response Jani.
I can confirm that the 500 status code works for the following (runtime
error):
?
ini_set('display_errors', 0);
$x = y();
?
But fails for parse errors (because the disply_errors line doesn't get
executed):
?
ini_set('display_errors', 0);
x = y;
?
Firstly, is this dependency really necessary? Just because we have
'display_errors' enabled doesn't mean we want fatal errors to go
unlogged and unnoticed because a 200 OK status is incorrectly
returned.
Secondly, the majority of PHP developers out there use shared hosting,
on which 'display_errors' is normally true and is impossible to change
globally - are we saying they're stuck with incorrect HTTP status codes
when parse errors occur?
The restriction that headers must not already have been sent is of
course understandable as it is unavoidable. Not overriding an explicitly
set HTTP status code also makes sense.
But why not set the status code as 500 Internal Server Error when any
fatal parse/runtime error occurs, regardless of the value of
'display_errors'? This would be consistent with the HTTP spec, which
recommends a 5XX response if an error occurs, and is followed by just
about every other web server language out there (e.g., ASP, .NET).
Many thanks, BJ
[2010-02-03 10:06:27] j...@php.net
It does happen. It requires that:
1) display_errors = off
2) No headers have been sent yet by the time the error happens
3) Status is 200 at that time.
[2010-02-03 04:23:42] phpbug at starurl dot com
Description:
My host runs PHP v5.2.12 (confirmed via phpversion) on IIS6 (Windows
Server, unknown version). When a PHP error occurs (parse error, runtime
error, etc), a 200 OK HTTP status is returned, instead of the correct
500 Internal Server Error.
This is despite claims in the change history for v5.2.4 that this issue
was fixed: Changed error handler to send HTTP 500 instead of blank
page on PHP errors. (Dmitry, Andrei Nigmatulin). This doesn't appear to
be the case on IIS6 (monitored remotely via HTTP Spy).
Reproduce code:
---
?
x = y; // cause parse error
?
Expected result:
Parse error mesage and 500 Internal Server Error HTTP status code.
Actual result:
--
Parse error mesage and 200 OK HTTP status code
--
Edit this bug report at http://bugs.php.net/bug.php?id=50921edit=1
Req #52593 [Opn]: Getting scope variables of the caller function
Edit report at http://bugs.php.net/bug.php?id=52593edit=1
ID: 52593
User updated by:hpolthof at gmail dot com
Reported by:hpolthof at gmail dot com
Summary:Getting scope variables of the caller function
Status: Open
Type: Feature/Change Request
Package:*General Issues
PHP Version:5.2.14
Block user comment: N
New Comment:
Multiple levels are in my opinion not necessary, neighter the way of
implementation.
The scope variables could also be made available thru the backtrace()
function. And still have no official support.
@dragoonis: I don't know how more specific it can get. get_caller_vars()
is a non-existent function. Hence this feature request!
Previous Comments:
[2010-08-12 15:10:27] johan...@php.net
Then you also need get_callers_caller_vars() and
get_callers_callers_caller_vars() but by definition a function shall be
independent from the caller's scope. All required information shall be
passed as parameter.
[2010-08-12 15:05:21] dragoo...@php.net
Please elaborate on such a function does not exist with an exact error
message.
[2010-08-12 14:45:51] hpolthof at gmail dot com
Description:
In bug #48290 was the function get_caller_vars() suggested. But in that
case it was irrelevant. However do I seek such a function.
get_defined_vars() returns the vars in the current scope. As do i like
to get the variables of the caller routine.
This would allow me to use parameters from a subroutine without having
to refactor another parameter being get_defined_vars() as this would
obviously uglify my code, which would impeach the reason to refactor in
the first place.
Test script:
---
function a() {
$test = 'A';
b();
}
function b() {
$test = 'B';
$vars_local = get_defined_vars();
$vars_caller = get_caller_vars();
echo $vars_caller['test']; // Expexted: A
echo $vars_local['test']; // Expected: B
}
a();
Expected result:
A
B
Actual result:
--
such a function does not exist
--
Edit this bug report at http://bugs.php.net/bug.php?id=52593edit=1
Bug #50921 [Com]: '200 OK' HTTP status despite PHP error
Edit report at http://bugs.php.net/bug.php?id=50921edit=1
ID: 50921
Comment by: tyra3l at gmail dot com
Reported by:phpbug at starurl dot com
Summary:'200 OK' HTTP status despite PHP error
Status: Bogus
Type: Bug
Package:HTTP related
Operating System: *
PHP Version:5.2.12
Block user comment: N
New Comment:
It's seems that this is a known bug in the xdebug, see:
http://bugs.xdebug.org/view.php?id=587
but couldn't fix it without making some changes in php itself:
Before I can address this, there need to be some changes in PHP itself.
It
doesn't expose some required information to extensions yet that I will
need.
I hope this get fixed soon.
Tyrael
Previous Comments:
[2010-08-12 15:35:41] tyra3l at gmail dot com
I can reproduce the problem.
I found out, that if I enable xdebug, then I get header 200, if I
disable it, then
it's 500.
Will report it to Derick.
Tyrael
[2010-03-12 08:37:24] anzenews at volja dot net
I am also having huge problems with this - haproxy health checks do not
work reliably because of this bug. Please consider reopening it - it is
not bogus.
PHP doesn't return HTTP error code, even if display_errors is set to 0.
One example:
?
ini_set('display_errors',0);
this_function_does_not_exist();
echo ok;
?
This returns an empty page with status code 200:
-
HTTP/1.1 200 OK
DateFri, 12 Mar 2010 07:27:15 GMT
Server Apache/2.2.9 (Debian) PHP/5.2.6-1+lenny6 with Suhosin-Patch
X-Powered-ByPHP/5.2.6-1+lenny6
VaryAccept-Encoding
Content-Encodinggzip
Content-Length 20
Keep-Alive timeout=15, max=100
Connection Keep-Alive
Content-Typetext/html
-
Content-Length is 20, probably because of gzip? There are no spaces
around PHP block in source code.
I have checked phpinfo() and display_errors is set to Off, so there is
no error there. Also, I have tried setting it in php.ini - no change.
Another problem: parse errors are also not handled correctly (even if
display_errors is set to 0 in php.ini). See previous poster's example.
Thanks!
[2010-02-03 19:03:56] der...@php.net
The reason why display errors needs to be turned of, is because
displayed errors generate output, and output causes the headers to be
send out. I'm afraid we can't do much about this.
[2010-02-03 18:01:37] phpbug at starurl dot com
Thank you for the swift response Jani.
I can confirm that the 500 status code works for the following (runtime
error):
?
ini_set('display_errors', 0);
$x = y();
?
But fails for parse errors (because the disply_errors line doesn't get
executed):
?
ini_set('display_errors', 0);
x = y;
?
Firstly, is this dependency really necessary? Just because we have
'display_errors' enabled doesn't mean we want fatal errors to go
unlogged and unnoticed because a 200 OK status is incorrectly
returned.
Secondly, the majority of PHP developers out there use shared hosting,
on which 'display_errors' is normally true and is impossible to change
globally - are we saying they're stuck with incorrect HTTP status codes
when parse errors occur?
The restriction that headers must not already have been sent is of
course understandable as it is unavoidable. Not overriding an explicitly
set HTTP status code also makes sense.
But why not set the status code as 500 Internal Server Error when any
fatal parse/runtime error occurs, regardless of the value of
'display_errors'? This would be consistent with the HTTP spec, which
recommends a 5XX response if an error occurs, and is followed by just
about every other web server language out there (e.g., ASP, .NET).
Many thanks, BJ
[2010-02-03 10:06:27] j...@php.net
It does happen. It requires that:
1) display_errors = off
2) No headers have been sent yet by the time the error happens
3) Status is 200 at that time.
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/bug.php?id=50921
--
Edit this bug report at http://bugs.php.net/bug.php?id=50921edit=1
Bug #49383 [Com]: Lots of empty fstat() calls slow performance
Edit report at http://bugs.php.net/bug.php?id=49383edit=1 ID: 49383 Comment by: a dot rogge at solvention dot de Reported by:olga at metacafe dot com Summary:Lots of empty fstat() calls slow performance Status: Bogus Type: Bug Package:Performance problem Operating System: Red Hat 3.4.6-10 PHP Version:5.3, 6 Block user comment: N New Comment: First of all: No, we don't use open_basedir or safe_mode or stuff like that. But I still do not understand what this has to do with the issue. The redundant fstat() calls are obviously *not* from open_basedir, because the fstat() calls are done after the file was opened. I run 5.1.6, 5.2.14 and 5.3.2 with the same configuration. For 5.1.6 and 5.2.14 everything looks normally, in 5.3.2 there are suddenly three instead of one fstat() call after opening the file. The calls are identical and adjacent with no other syscalls in between. The two successive calls do not provide any more information than the first one and thus are redundant and useless. This is obviously a performance regression. Do you want to tell me that this is a new feature? Previous Comments: [2010-08-12 01:24:32] ras...@php.net Do you have openbase_dir enabled? If so, for security reasons we can't use the stat cache which is going to cause a lot of stats. For a setup with slow stats, I suggest chroot/jail or something along those lines rather than open_basedir to keep users separated. [2010-08-11 20:10:56] a dot rogge at solvention dot de Nobody cares wether or not APC works around the problem. There is obviously a regression from 5.2 to 5.3. Somebody maanged to triple the number of fstat() calls that are done for an include(). Yesterday I reproduced the issue on our webcluster. Running the Red Hat provided PHP 5.1.6 (from RHEL 5.5) the loadavg was around 8 for all boxes. Upgrading to PHP 5.3.2 made the loadavg raised to values of 30 or higher. Page load time went from 1 second to around 30 seconds. The best part is: we did install and configure apc for 5.3.2, but not for 5.1.6 So eventually 5.3.2 *with* APC produces 3 times more load and needs 30 times longer than our ancient 5.1.6 *without* APC. However, I must admit that we have our PHP-files on GFS2 where stat() is traditionally a bit slow. [2010-01-21 23:16:42] ras...@php.net Unable to reproduce under apc. [2009-10-14 11:28:06] olga at metacafe dot com The problem persists. We upgraded APC to the latest version (3.1.3p1). Cache full count is 0, hit ratio is 99.9%. I understand that this shouldn't happen, but there are still 3 fstat() calls per file opened. Here's our APC configuration - maybe you can see if anything is wrong with it? Do you have other versions? apc.cache_by_default1 apc.canonicalize1 apc.coredump_unmap 0 apc.enable_cli 1 apc.enabled 1 apc.file_md50 apc.file_update_protection 2 apc.filters apc.gc_ttl 3600 apc.include_once_override 1 apc.lazy_classes0 apc.lazy_functions 0 apc.max_file_size 1M apc.mmap_file_mask /tmp/apc.IR76ZW apc.num_files_hint 1024 apc.preload_path apc.report_autofilter 0 apc.rfc1867 0 apc.rfc1867_freq0 apc.rfc1867_nameAPC_UPLOAD_PROGRESS apc.rfc1867_prefix upload_ apc.rfc1867_ttl 3600 apc.shm_segments1 apc.shm_size128 apc.stat0 apc.stat_ctime 0 apc.ttl 7200 apc.use_request_time1 apc.user_entries_hint 4096 apc.user_ttl7200 apc.write_lock 1 [2009-09-03 16:49:18] ras...@php.net The only time this code is executed if you are running APC is if the script is not cached. So, either your APC setup is not working, you are constantly trashing your cache (check apc.php and look at the cache-full counter), or something else weird is going on. These fstats are coming from compiler which reads the script from disk and compiles it down to opcodes. It is impossible for this code to execute on an APC-cached script because we point the executor directly at the already compiled opcodes in shared memory. 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/bug.php?id=49383 -- Edit this bug report at http://bugs.php.net/bug.php?id=49383edit=1
Bug #1 [Bgs-Opn]: Apache 1.3b3 + mod_php3 is slow
Edit report at http://bugs.php.net/bug.php?id=1edit=1 ID: 1 Updated by: johan...@php.net Reported by:rasmus at lerdorf dot on dot ca Summary:Apache 1.3b3 + mod_php3 is slow -Status: Bogus +Status: Open Type: Bug Package:Performance problem Operating System: Solaris 2.5.1 PHP Version:3.0b3 -Block user comment: Y +Block user comment: N New Comment: test Previous Comments: [2010-07-26 03:09:03] fel...@php.net test [2010-07-26 03:06:49] fel...@php.net testing [2010-07-25 21:00:15] fel...@php.net . [2010-07-21 17:35:09] ahar...@php.net Test comment. Sorry about the noise. [2010-07-21 17:34:17] paj...@php.net unassigned 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/bug.php?id=1 -- Edit this bug report at http://bugs.php.net/bug.php?id=1edit=1
Bug #1 [Opn-Bgs]: Apache 1.3b3 + mod_php3 is slow
Edit report at http://bugs.php.net/bug.php?id=1edit=1 ID: 1 Updated by: johan...@php.net Reported by:rasmus at lerdorf dot on dot ca Summary:Apache 1.3b3 + mod_php3 is slow -Status: Open +Status: Bogus Type: Bug Package:Performance problem Operating System: Solaris 2.5.1 PHP Version:3.0b3 Block user comment: N New Comment: test2 Previous Comments: [2010-08-12 16:04:04] johan...@php.net test [2010-07-26 03:09:03] fel...@php.net test [2010-07-26 03:06:49] fel...@php.net testing [2010-07-25 21:00:15] fel...@php.net . [2010-07-21 17:35:09] ahar...@php.net Test comment. Sorry about the noise. 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/bug.php?id=1 -- Edit this bug report at http://bugs.php.net/bug.php?id=1edit=1
Req #52593 [Opn-Bgs]: Getting scope variables of the caller function
Edit report at http://bugs.php.net/bug.php?id=52593edit=1
ID: 52593
Updated by: der...@php.net
Reported by:hpolthof at gmail dot com
Summary:Getting scope variables of the caller function
-Status: Open
+Status: Bogus
Type: Feature/Change Request
Package:*General Issues
PHP Version:5.2.14
Block user comment: N
New Comment:
.
Previous Comments:
[2010-08-12 15:36:33] hpolthof at gmail dot com
Multiple levels are in my opinion not necessary, neighter the way of
implementation.
The scope variables could also be made available thru the backtrace()
function. And still have no official support.
@dragoonis: I don't know how more specific it can get. get_caller_vars()
is a non-existent function. Hence this feature request!
[2010-08-12 15:10:27] johan...@php.net
Then you also need get_callers_caller_vars() and
get_callers_callers_caller_vars() but by definition a function shall be
independent from the caller's scope. All required information shall be
passed as parameter.
[2010-08-12 15:05:21] dragoo...@php.net
Please elaborate on such a function does not exist with an exact error
message.
[2010-08-12 14:45:51] hpolthof at gmail dot com
Description:
In bug #48290 was the function get_caller_vars() suggested. But in that
case it was irrelevant. However do I seek such a function.
get_defined_vars() returns the vars in the current scope. As do i like
to get the variables of the caller routine.
This would allow me to use parameters from a subroutine without having
to refactor another parameter being get_defined_vars() as this would
obviously uglify my code, which would impeach the reason to refactor in
the first place.
Test script:
---
function a() {
$test = 'A';
b();
}
function b() {
$test = 'B';
$vars_local = get_defined_vars();
$vars_caller = get_caller_vars();
echo $vars_caller['test']; // Expexted: A
echo $vars_local['test']; // Expected: B
}
a();
Expected result:
A
B
Actual result:
--
such a function does not exist
--
Edit this bug report at http://bugs.php.net/bug.php?id=52593edit=1
Bug #49383 [Bgs]: Lots of empty fstat() calls slow performance
Edit report at http://bugs.php.net/bug.php?id=49383edit=1 ID: 49383 Updated by: ras...@php.net Reported by:olga at metacafe dot com Summary:Lots of empty fstat() calls slow performance Status: Bogus Type: Bug Package:Performance problem Operating System: Red Hat 3.4.6-10 PHP Version:5.3, 6 Block user comment: N New Comment: The reason open_basedir affects this is because for security reasons we can't enable the stat cache when open_basedir is enabled which will also affect stats after the file is opened since it isn't the open_basedir check itself causing the stat but the fact that the open_basedir feature forces the stat cache to be disabled. The main thing that changed between 5.2.x and 5.3.x with respect to stats is that we rewrote the stat cache to be more efficient. It now does intra-path caching of realpath() lookups as opposed to just caching the return of the realpath() call, but it doesn't sound like this is the issue here. One thing you can try is to compile PHP without phar support. ./configure -- disable-phar and see if that changes things. Beyond that you would need to set a gdb breakpoint and get a backtrace of those calls. Generally we are not too concerned about fstat calls since they tend to be extremely fast in most environments. It is the full stat/lstat calls that need to hit the disk that tend to be slow. Previous Comments: [2010-08-12 15:58:41] a dot rogge at solvention dot de First of all: No, we don't use open_basedir or safe_mode or stuff like that. But I still do not understand what this has to do with the issue. The redundant fstat() calls are obviously *not* from open_basedir, because the fstat() calls are done after the file was opened. I run 5.1.6, 5.2.14 and 5.3.2 with the same configuration. For 5.1.6 and 5.2.14 everything looks normally, in 5.3.2 there are suddenly three instead of one fstat() call after opening the file. The calls are identical and adjacent with no other syscalls in between. The two successive calls do not provide any more information than the first one and thus are redundant and useless. This is obviously a performance regression. Do you want to tell me that this is a new feature? [2010-08-12 01:24:32] ras...@php.net Do you have openbase_dir enabled? If so, for security reasons we can't use the stat cache which is going to cause a lot of stats. For a setup with slow stats, I suggest chroot/jail or something along those lines rather than open_basedir to keep users separated. [2010-08-11 20:10:56] a dot rogge at solvention dot de Nobody cares wether or not APC works around the problem. There is obviously a regression from 5.2 to 5.3. Somebody maanged to triple the number of fstat() calls that are done for an include(). Yesterday I reproduced the issue on our webcluster. Running the Red Hat provided PHP 5.1.6 (from RHEL 5.5) the loadavg was around 8 for all boxes. Upgrading to PHP 5.3.2 made the loadavg raised to values of 30 or higher. Page load time went from 1 second to around 30 seconds. The best part is: we did install and configure apc for 5.3.2, but not for 5.1.6 So eventually 5.3.2 *with* APC produces 3 times more load and needs 30 times longer than our ancient 5.1.6 *without* APC. However, I must admit that we have our PHP-files on GFS2 where stat() is traditionally a bit slow. [2010-01-21 23:16:42] ras...@php.net Unable to reproduce under apc. [2009-10-14 11:28:06] olga at metacafe dot com The problem persists. We upgraded APC to the latest version (3.1.3p1). Cache full count is 0, hit ratio is 99.9%. I understand that this shouldn't happen, but there are still 3 fstat() calls per file opened. Here's our APC configuration - maybe you can see if anything is wrong with it? Do you have other versions? apc.cache_by_default1 apc.canonicalize1 apc.coredump_unmap 0 apc.enable_cli 1 apc.enabled 1 apc.file_md50 apc.file_update_protection 2 apc.filters apc.gc_ttl 3600 apc.include_once_override 1 apc.lazy_classes0 apc.lazy_functions 0 apc.max_file_size 1M apc.mmap_file_mask /tmp/apc.IR76ZW apc.num_files_hint 1024 apc.preload_path apc.report_autofilter 0 apc.rfc1867 0 apc.rfc1867_freq0 apc.rfc1867_nameAPC_UPLOAD_PROGRESS apc.rfc1867_prefix upload_ apc.rfc1867_ttl 3600 apc.shm_segments1 apc.shm_size128 apc.stat0 apc.stat_ctime 0 apc.ttl 7200
[PHP-BUG] Bug #52594 [NEW]: option -c in php cli
From: Operating system: Feebsd PHP version: 5.3.3 Package: CGI related Bug Type: Bug Bug description:option -c in php cli Description: in php 5.2 php -c option could include a space out-ceo name. ini file, already in PHP 5.3 does not work. php 5.2 php -c teste.ini or php -cteste.ini Loaded Configuration File = teste.ini php 5.3 php -cteste.ini Loaded Configuration File = teste.ini php -c teste.ini Loaded Configuration File = (none) -- Edit bug report at http://bugs.php.net/bug.php?id=52594edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=52594r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=52594r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=52594r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=52594r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=52594r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=52594r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=52594r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=52594r=needscript Try newer version: http://bugs.php.net/fix.php?id=52594r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=52594r=support Expected behavior: http://bugs.php.net/fix.php?id=52594r=notwrong Not enough info: http://bugs.php.net/fix.php?id=52594r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=52594r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=52594r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52594r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=52594r=dst IIS Stability: http://bugs.php.net/fix.php?id=52594r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=52594r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=52594r=float No Zend Extensions: http://bugs.php.net/fix.php?id=52594r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=52594r=mysqlcfg
Bug #52594 [Opn-Fbk]: option -c in php cli
Edit report at http://bugs.php.net/bug.php?id=52594edit=1 ID: 52594 Updated by: johan...@php.net Reported by:bernardo at datamex dot com dot br Summary:option -c in php cli -Status: Open +Status: Feedback Type: Bug Package:CGI related Operating System: Feebsd PHP Version:5.3.3 Block user comment: N New Comment: Please try using this snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ I can't reproduce it. Are you using our sources or patches from FreeBSD? Previous Comments: [2010-08-12 17:59:06] bernardo at datamex dot com dot br Description: in php 5.2 php -c option could include a space out-ceo name. ini file, already in PHP 5.3 does not work. php 5.2 php -c teste.ini or php -cteste.ini Loaded Configuration File = teste.ini php 5.3 php -cteste.ini Loaded Configuration File = teste.ini php -c teste.ini Loaded Configuration File = (none) -- Edit this bug report at http://bugs.php.net/bug.php?id=52594edit=1
Bug #35090 [Bgs]: file i/o is not buffered
Edit report at http://bugs.php.net/bug.php?id=35090edit=1
ID: 35090
User updated by:askalski at gmail dot com
Reported by:askalski at gmail dot com
Summary:file i/o is not buffered
Status: Bogus
Type: Bug
Package:Filesystem function related
Operating System: linux
-PHP Version:5CVS-2005-11-03 (snap)
+PHP Version:5.3.3
Block user comment: N
New Comment:
I guess that's one way to deal with it. At least then it would be clear
to PHP developers that each fwrite() makes a separate system call.
Even better would be for PHP to use the C stdio library for file i/o,
and take advantage of the buffering it offers by default. Even back in
the 1970's when C was created, they had already figured out that
buffered I/O was a good thing, and consequently built it into stdio...
(I'm surprised to see feedback on a bug ticket that was closed as
Bogus almost five years ago. Ultimately, this is pretty low on my
list of reasons PHP execution is so painfully slow; it's just
something I spotted when doing an strace to troubleshoot an unrelated
issue. That's why I never bothered to pursue it further.)
Previous Comments:
[2010-08-12 12:59:41] surfchen at gmail dot com
So we need to add a note on the documentation say that this function not
supported
with filesystem wrapper, right?
[2005-11-03 23:40:24] askalski at gmail dot com
instead it uses the system's file io buffering function
to set the buffer.
Assuming you're talking about setvbuf() and not kernel
level write-behind caching, this statement is false.
The file is opened by _php_stream_fopen():
fd = open(realpath, open_flags, 0666);
(It is never subsequently wrapped with fdopen())
At this point, the stream is not buffered at all.
When I later call stream_set_write_buffer(), it hits
php_stdiop_set_option():
case PHP_STREAM_OPTION_WRITE_BUFFER:
if (data-file == NULL) {
return -1;
}
/* setvbuf happens down here */
Because there is no FILE* handle (data-file), setvbuf()
is never called for the stream.
One of either the documentation
(http://us3.php.net/stream_set_write_buffer)
or the PHP source is wrong.
[2005-11-03 21:34:16] il...@php.net
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
PHP does not do any buffering itself, instead it uses the system's file
io buffering function to set the buffer.
There is already a feature request open to enable in-php buffering.
[2005-11-03 21:29:08] der...@php.net
Can you please answer why this is not a bug Wez? I forgot the reason :)
[2005-11-03 19:16:09] askalski at gmail dot com
Description:
The documentation for stream_set_write_buffer() says that fwrite()s are
buffered at 8K by default. In reality, it does not buffer at all. Any
attempt to call stream_set_write_buffer() on a regular file handle
results in failure.
Reproduce code:
---
$fh = fopen(asdf, w);
// write some data using the default buffering
for ($i = 0; $i 5; $i++)
fwrite($fh, test);
// demonstrate that stream_set_write_buffer fails
$n = stream_set_write_buffer($fh, 8192);
if ($n != 0)
echo stream_set_write_buffer failed\n;
// write some more data to demonstrate the failure
for ($i = 0; $i 5; $i++)
fwrite($fh, again);
fclose($fh);
Expected result:
PHP should buffer its I/O, and strace should log a single write().
stream_set_write_buffer() should not fail on regular files.
Actual result:
--
Output:
stream_set_write_buffer failed
Abridged strace output:
open(/tmp/php5-200511031730/asdf, O_WRONLY|O_CREAT|O_TRUNC, 0666) = 3
fstat64(3, {st_mode=S_IFREG|0600, st_size=0, ...}) = 0
lseek(3, 0, SEEK_CUR) = 0
write(3, test, 4) = 4
write(3, test, 4) = 4
write(3, test, 4) = 4
write(3, test, 4) = 4
write(3, test, 4) = 4
write(1, stream_set_write_buffer failed\n, 31) = 31
write(3, again, 5)= 5
write(3, again, 5)= 5
write(3, again, 5)= 5
write(3, again, 5)= 5
write(3, again, 5)= 5
close(3)= 0
Bug #49867 [Com]: spl_autoload crashes when called in write function of custom sessionSaveHandler
Edit report at http://bugs.php.net/bug.php?id=49867edit=1
ID: 49867
Comment by: iamcraigcampbell at gmail dot com
Reported by:nicolas dot lepage at yahoo dot fr
Summary:spl_autoload crashes when called in write function
of custom sessionSaveHandler
Status: No Feedback
Type: Bug
Package:SPL related
Operating System: *
PHP Version:5.3.0
Block user comment: N
New Comment:
Just experienced this issue after upgrading to PHP 5.3.3, APC 3.1.4 on
Debian
GNU/Linux 4.0.
When using the session handler from an instance of a class it would give
a fatal
error: Fatal error: Undefined class constant...
After switching to use static session handler methods there was no
longer a
fatal error, but it caused a segfault which was traced back to
spl_autoload_register().
Tried a bunch of stuff but was able to fix the issue by registering a
shutdown
function similar to this:
register_shutdown_function('shutdown');
function shutdown()
{
session_write_close();
}
Previous Comments:
[2010-06-12 23:39:43] zapparov at member dot fsf dot org
And one more interesting thing. This Fatal error is thrown (!) after all
operations were completed - so Im receiving exactly what I was expecting
to
receive but with Fatal Error and it's trace appended to it. o_O
[2010-06-12 23:34:44] zapparov at member dot fsf dot org
Unfortunately not for me.
Also, by some reason this problem occurs only on some requests. I'll try
to
prepare a simple test which will reproduce this issue soonly.
[2010-06-12 15:48:06] ras...@php.net
Doesn't calling session_write_close() completely solve this issue?
[2010-06-12 12:23:24] zapparov at member dot fsf dot org
Forgot to say - error occurs wonly when APC is enabled.
[2010-06-12 11:24:11] zapparov at member dot fsf dot org
Hello,
Have exactly the same problem with Zend Framework + Doctrine (they both
register
own autoloaders). So when APC is enabled - it reproduces same fatal
error. I'll
try to gather more information about what happens little bit later.
My PHP version is 5.3.2
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/bug.php?id=49867
--
Edit this bug report at http://bugs.php.net/bug.php?id=49867edit=1
Bug #52368 [Com]: crash in preg_replace_impl
Edit report at http://bugs.php.net/bug.php?id=52368edit=1
ID: 52368
Comment by: cobexer at gmail dot com
Reported by:cobexer at gmail dot com
Summary:crash in preg_replace_impl
Status: Feedback
Type: Bug
Package:PCRE related
Operating System: Debian Lenny (5.0.5)
PHP Version:5.2.13
Block user comment: N
New Comment:
I did a quick test today
using http://snaps.php.net/php5.3-latest.tar.gz (from yesterday) does
not crash(as expected since the problem didn't exist there anyway).
however using http://snaps.php.net/php5.2-latest.tar.gz (from yesterday)
still crashes on the same line as before.
(tested on i586 openSuSE 11.4(Factory))
regards cobexer
Previous Comments:
[2010-08-09 03:19:31] fel...@php.net
Please try using this snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
[2010-07-30 21:24:40] cobexer at gmail dot com
hmm that crash is hard to nail down,
it doesn't crash on all of my computers, therefore i did the following:
* created crashing test script (currently ~150 Lines)
* compiled php 5.2.14 (with -O0) (in /php) on a i586 openSUSE Factory(a
bit newer than 11.3)
* created a core dump
* tar'gz ed it together
and uploaded that to http://gomorrah-online.de/php-5.2.14-crash.tar.gz
important contents:
scrash.php : the php script with the code to crash (run with php -e)
scrash.php.log : the output of the script till it crashed
php-bt.txt : output of bt and bt full
core : the coredump itself
maybe that helps already,
regards cobexer
[2010-07-18 19:39:03] fel...@php.net
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ?php and ends with ?,
is max. 10-20 lines long and does not require any external
resources such as databases, etc. If the script requires a
database to demonstrate the issue, please make sure it creates
all necessary tables, stored procedures etc.
Please avoid embedding huge scripts into the report.
[2010-07-17 23:48:30] cobexer at gmail dot com
Description:
the crash occuring is most likely related to very high integer/double
values(10M) being inserted in a long string(~20K).
the problem does not occur on PHP5.3.something so it might be a simple
backport :). unless somebody can tell me how i get more information out
of the crashing process this is all i have (trying to print local
variables of the crashing function results in:
(gdb) p **regex
Cannot access memory at address 0x686f72393438343e
os similar
the regular expression involved is most likely:
'/\{([A-Z0-9_]*)(?:\|(?Pescaper[A-Z0-9_]+))?\}/'
executed by preg_replace_callback, where the callback is an
array('class_name', 'some_private_function')
if required i try to build a small test script and attach that - but i
guess its not required.
probably related to http://bugs.php.net/bug.php?id=39016
reproducible: always
Test script:
---
?php
//no test script currently available
?
Expected result:
no php crash correctly replaced string
Actual result:
--
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7f877c078750 (LWP 6259)]
preg_replace_impl (ht=5, return_value=0x12a8a90,
return_value_ptr=0x137c970, this_ptr=0xb9e82fb02f28a27c,
return_value_used=0, is_callable_replace=0 '\0')
at /usr/src/php5/source/php5-5.2.13/Zend/zend_variables.h:32
warning: Source file is more recent than executable.
32 if (zvalue-type = IS_BOOL) {
(gdb) bt
#0 preg_replace_impl (ht=5, return_value=0x12a8a90,
return_value_ptr=0x137c970, this_ptr=0xb9e82fb02f28a27c,
return_value_used=0,
is_callable_replace=0 '\0') at
/usr/src/php5/source/php5-5.2.13/Zend/zend_variables.h:32
#1 0x7f8774cef3cd in zend_do_fcall_common_helper_SPEC
(execute_data=0x7fff5410) at
/usr/src/php5/source/php5-5.2.13/Zend/zend_vm_execute.h:200
#2 0x7f8774cd8134 in execute (op_array=0xf02040) at
/usr/src/php5/source/php5-5.2.13/Zend/zend_vm_execute.h:92
#3 0x7f8774ceecde in zend_do_fcall_common_helper_SPEC
(execute_data=0x7fff5760) at
/usr/src/php5/source/php5-5.2.13/Zend/zend_vm_execute.h:234
#4 0x7f8774cd8134 in execute (op_array=0xef48b0) at
/usr/src/php5/source/php5-5.2.13/Zend/zend_vm_execute.h:92
#5 0x7f8774ceecde in zend_do_fcall_common_helper_SPEC
(execute_data=0x7fff5e70) at
/usr/src/php5/source/php5-5.2.13/Zend/zend_vm_execute.h:234
#6 0x7f8774cd8134 in execute
[PHP-BUG] Bug #52596 [NEW]: SOAP result empty NULL lastResponse filled
From: Operating system: Linux PHP version: 5.2.14 Package: SOAP related Bug Type: Bug Bug description:SOAP result empty NULL lastResponse filled Description: I have a script which makes a WSDL SOAP call and the result is empty. No error. The __getLastResponse() is filled. Test script: --- please take a look at: http://files.it-gnoth.de/software/source/php/soap_sample/wsdl-native.php this directory you can browse: http://files.it-gnoth.de/software/source/php/soap_sample with right mouse click it should be possible to download the file. auth token: 49fb1f08bfd34d2b92949af0f9b9bb61 client id: 225 method: get status: active -- Edit bug report at http://bugs.php.net/bug.php?id=52596edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=52596r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=52596r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=52596r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=52596r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=52596r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=52596r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=52596r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=52596r=needscript Try newer version: http://bugs.php.net/fix.php?id=52596r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=52596r=support Expected behavior: http://bugs.php.net/fix.php?id=52596r=notwrong Not enough info: http://bugs.php.net/fix.php?id=52596r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=52596r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=52596r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52596r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=52596r=dst IIS Stability: http://bugs.php.net/fix.php?id=52596r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=52596r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=52596r=float No Zend Extensions: http://bugs.php.net/fix.php?id=52596r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=52596r=mysqlcfg
Bug #49177 [Ver-Bgs]: include() causes strict erros when including overloading methods (PHP_5_2 only!)
Edit report at http://bugs.php.net/bug.php?id=49177edit=1
ID: 49177
Updated by: s...@php.net
Reported by:ss at zornig dot dk
Summary:include() causes strict erros when including
overloading methods (PHP_5_2 only!)
-Status: Verified
+Status: Bogus
Type: Bug
Package:Scripting Engine problem
Operating System: *
PHP Version:5.*
Block user comment: N
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 example restricts first parameter from ObjParent to ObjChild. making
child function accept only subset of arguments that parent function
accepts. This is a violation of LSP, of which the warning warns.
Previous Comments:
[2010-04-20 13:40:29] ss at zornig dot dk
I have found a similar error in 5.3.2
[2010-04-20 13:39:38] ss at zornig dot dk
Description:
This works in 5.3.2 however, I have found a similar error.
Reproduce code:
---
test.php:
?php
error_reporting(E_ALL | E_STRICT);
abstract class ObjParent {
public function set(ObjParent $param1, $param2){ }
}
require_once('obj.php');
?
obj.php:
?php
class ObjChild extends ObjParent {
public function set(ObjChild $param1, $param2=true){ }
}
?
Expected result:
This should be without any errors as i would if the test.php looks like
this:
?php
error_reporting(E_ALL | E_STRICT);
abstract class ObjParent {
public function set(ObjParent $param1, $param2){ }
}
class ObjChild extends ObjParent {
public function set(ObjChild $param1, $param2){ }
}
?
Actual result:
--
Strict Standards: Declaration of ObjChild::set() should be compatible
with that of ObjParent::set() in /usr/home/webroot/dumpsite/bug/obj.php
on line 4
[2009-08-06 12:03:08] ss at zornig dot dk
Description:
When overloading a method, changing a parameter to accept a default
value E_STRICT error is triggered. This however only happens if the
object declaration is loading using include, not if the declaration is
in the file called.
Reproduce code:
---
test.php:
?php
error_reporting(E_ALL | E_STRICT);
abstract class ObjParent {
public function set($param1, $param2){ }
}
require_once('obj.php');
?
obj.php:
?php
class ObjChild extends ObjParent {
public function set($param1, $param2=true){ }
}
?
Expected result:
This should be without any errors as i would if the test.php looks like
this:
?php
error_reporting(E_ALL | E_STRICT);
abstract class ObjParent {
public function set($param1, $param2){ }
}
class ObjChild extends ObjParent {
public function set($param1, $param2=true){ }
}
?
Actual result:
--
Strict Standards: Declaration of ObjChild::set() should be compatible
with that of ObjParent::set() in /home/webroot/dumpsite/obj.php on line
8
--
Edit this bug report at http://bugs.php.net/bug.php?id=49177edit=1
Req #47383 [Opn-Bgs]: override declaration with non type hinted params should allow type hinting
Edit report at http://bugs.php.net/bug.php?id=47383edit=1
ID: 47383
Updated by: s...@php.net
Reported by:info at netmosfera dot it
Summary:override declaration with non type hinted params
should allow type hinting
-Status: Open
+Status: Bogus
Type: Feature/Change Request
-Package:Feature/Change Request
+Package:*General Issues
Operating System: *
PHP Version:5.3.0beta1
Block user comment: N
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
Method arguments are supposed to be contravariant, see:
http://en.wikipedia.org/wiki/Liskov_substitution_principle
http://en.wikipedia.org/wiki/Covariance_and_contravariance_%28computer_science%29#Need_for_covariant_argument_types.3F
Previous Comments:
[2009-02-13 21:15:49] info at netmosfera dot it
better explanation:
class a
{
function a(File $x){echo get_class($x);}
}
class b extends a
{
function a(ImageFile $x){echo get_class($x);}
}
this obviously works!
now, if mixed means accepts everything
class a
{
function a(Mixed $x){echo get_class($x);}
}
i should be able to override it:
class b extends a
{
function a(File $x){echo get_class($x);}
}
no?
[2009-02-13 20:45:43] info at netmosfera dot it
Description:
hello
i think that non-type-hinted arguments (mixed values):
class a
{
function test([mixed] $argument){}
}
should allow type hinting in child classes
class b extends a
{
function test(ImageFile $argument){}
}
Reproduce code:
---
mixed is a general type... means everything
but if i want to build an ArrayObject object with one-only type
i cannot do this
[internal]
class ArrayObject implements ArrayAccess
{
function offsetSet($o, [mixed] $value)
{}
}
class ImageList extends ArrayObject
{
function offsetSet($o, Image $imageObject) // fatal error!
{}
}
Actual result:
--
Fatal error: Declaration of ImageList::offsetSet() must be compatible
with that of ArrayAccess::offsetSet() in xx on line 8
thank you
--
Edit this bug report at http://bugs.php.net/bug.php?id=47383edit=1
Bug #52592 [Opn-Bgs]: mb_ereg_replace and the Greek capital Pi
Edit report at http://bugs.php.net/bug.php?id=52592edit=1
ID: 52592
Updated by: ahar...@php.net
Reported by:pj at ezgr dot net
Summary:mb_ereg_replace and the Greek capital Pi
-Status: Open
+Status: Bogus
Type: Bug
Package:mbstring related
Operating System: Centos 5.5 x64
PHP Version:5.2.14
Block user comment: N
New Comment:
You need to also call mb_regex_encoding('UTF-8'); before using a UTF-8
regular expression.
Previous Comments:
[2010-08-12 14:36:15] pj at ezgr dot net
Description:
PHP: 5.2.14, Apache 2.2.15, mod_php
While \s is supposed to match all whitespace, the greek unicode letter
Pi (Î ) whose code is 0xCEA0 is matched too and if replaced with
something, it's stripped of its second byte (0xA0).
Test script:
---
?php
mb_internal_encoding('UTF-8');
$testStr = 'Î Î Î !';
$newStr = mb_ereg_replace('\s+','_',$testStr);
echo $testStr;
echo $newStr;
echo urlencode($testStr);
echo urlencode($newStr);
?
Expected result:
Î Î Î !
Î __Î __Î !
%CE%A0++%CE%A0++%CE%A0%21
%CE%A0__%CE%A0__%CE%A0%21
Actual result:
--
Î Î Î !
[non printable character]_[non printable character]_[non printable
character]!
%CE%A0++%CE%A0++%CE%A0%21
%CE_%CE_%CE_%21
--
Edit this bug report at http://bugs.php.net/bug.php?id=52592edit=1
Bug #52590 [Opn-Fbk]: Hang on
Edit report at http://bugs.php.net/bug.php?id=52590edit=1 ID: 52590 Updated by: ahar...@php.net Reported by:qiq9 at eloy dot serralaban dot com dot ar Summary:Hang on -Status: Open +Status: Feedback Type: Bug Package:MySQL related Operating System: Windows NT 5.1 b. 2600 SP3 i586 PHP Version:5.3.3 Block user comment: N New Comment: Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with ?php and ends with ?, is max. 10-20 lines long and does not require any external resources such as databases, etc. If the script requires a database to demonstrate the issue, please make sure it creates all necessary tables, stored procedures etc. Please avoid embedding huge scripts into the report. Previous Comments: [2010-08-12 09:41:26] qiq9 at eloy dot serralaban dot com dot ar Description: When can't connect to server (example: firewall) it hangs on. Do not returns of mysql_connect() or others functions (but returns from mysql_error(), mysql_get_client_info() and others). mysql_get_client_info() returns: mysqlnd 5.0.7-dev - 091210 - $Revision: 300533 $ php_info() returns: System Windows NT PCC 5.1 build 2600 (Windows XP Professional Service Pack 3) i586 Build Date Jul 21 2010 20:00:47 CompilerMSVC6 (Visual C++ 6.0) Architecturex86 Configure Command cscript /nologo configure.js --enable-snapshot-build --disable-isapi --enable-debug-pack --disable-isapi --without-mssql --without-pdo-mssql --without-pi3web --with-pdo-oci=D:\php-sdk\oracle\instantclient10\sdk,shared --with-oci8=D:\php-sdk\oracle\instantclient10\sdk,shared --with-oci8-11g=D:\php-sdk\oracle\instantclient11\sdk,shared --enable-object-out-dir=../obj/ --enable-com-dotnet --with-mcrypt=static Server API Apache 2.0 Handler Virtual Directory Support enabled Configuration File (php.ini) Path C:\WIN.0 Loaded Configuration File C:\Progs\Internet\Servidor\PHP\php.ini Scan this dir for additional .ini files (none) Additional .ini files parsed(none) PHP API 20090626 PHP Extension 20090626 Zend Extension 220090626 Zend Extension BuildAPI220090626,TS,VC6 PHP Extension Build API20090626,TS,VC6 Debug Build no Thread Safety enabled Zend Memory Manager enabled Zend Multibyte Support disabled IPv6 Supportenabled Registered PHP Streams php, file, glob, data, http, ftp, zip, compress.zlib, compress.bzip2, phar Registered Stream Socket Transports tcp, udp Registered Stream Filters convert.iconv.*, mcrypt.*, mdecrypt.*, string.rot13, string.toupper, string.tolower, string.strip_tags, convert.*, consumed, dechunk, zlib.*, bzip2.* Configuration apache2handler Apache Version Apache/2.2.15 (Win32) PHP/5.3.3 Apache API Version 20051115 Server Administrator[...] Hostname:Port crjt.PCC:0 Max RequestsPer Child: 0 - Keep Alive: on - Max Per Connection: 100 TimeoutsConnection: 300 - Keep-Alive: 5 Virtual Server Yes Server Root C:/Progs/Internet/Servidor/Apache Loaded Modules core mod_win32 mpm_winnt http_core mod_so mod_actions mod_alias mod_asis mod_auth_basic mod_authn_default mod_authn_file mod_authz_default mod_authz_groupfile mod_authz_host mod_authz_user mod_autoindex mod_cgi mod_dir mod_env mod_include mod_isapi mod_log_config mod_mime mod_negotiation mod_setenvif mod_php5 Directive Local Value Master Value engine 1 1 last_modified 0 0 xbithack0 0 Apache Environment VariableValue HTTP_HOST crjt.pcc HTTP_USER_AGENT Mozilla/5.0 (Windows; U; Windows NT 5.1; es-ES; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3 ( .NET CLR 3.5.30729) HTTP_ACCEPT text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 HTTP_ACCEPT_LANGUAGEes-es,es;q=0.8,en-us;q=0.5,en;q=0.3 HTTP_ACCEPT_ENCODINGgzip,deflate HTTP_ACCEPT_CHARSET ISO-8859-1,utf-8;q=0.7,*;q=0.7 HTTP_KEEP_ALIVE 115 HTTP_CONNECTION keep-alive PATH C:\WIN.0\system32;C:\WIN.0;C:\WIN.0\System32\Wbem;C:\Progs\Ãtil\doxygen\bin SystemRoot C:\WIN.0 COMSPEC C:\WIN.0\system32\cmd.exe PATHEXT .COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH WINDIR C:\WIN.0 SERVER_SIGNATUREno value SERVER_SOFTWARE Apache/2.2.15 (Win32) PHP/5.3.3 SERVER_NAME crjt.pcc SERVER_ADDR 127.0.0.1 SERVER_PORT 80 REMOTE_ADDR 127.0.0.1 DOCUMENT_ROOT C:/Usuarios/Reloj.PCC/Mis documentos/My Dropbox/CRJT/nuevo SERVER_ADMIN[...] SCRIPT_FILENAME C:/Usuarios/Reloj.PCC/Mis documentos/My Dropbox/CRJT/nuevo/phpinfo.php REMOTE_PORT 3794 GATEWAY_INTERFACE
[PHP-BUG] Bug #52597 [NEW]: exif is placed before mbstring in php.ini
From: Operating system: Windows Vista 64-bit PHP version: 5.3.3 Package: *Configuration Issues Bug Type: Bug Bug description:exif is placed before mbstring in php.ini Description: php_exif.dll extension can't be loaded, because it depends on php_mbstring.dll. Just uncomminting the corresponding php.ini lines to load both extensions does not work, because in php.ini php_exif.dll is listed earlier than php_mbstring.dll. Simply moving the line that loads php_mbstring.dll before php_exif.dll solves the problem. This affects Windows zip distributions: php-5.3.3-Win32-VC9-x86.zip php-5.3.3-Win32-VC6-x86.zip (Both php.ini-development and php.ini-production are affected). I could find that this bug was reported multiple times before: #29919, #32552, #32541, #43970. Also #43606 might be related. The impact of this bug: Simply unpacking the PHP zip package on windows and enabling the exif and mbstring extensions does NOT work. Instead it takes half a day of digging through docs and searching internet to find that the order of extensions in php.ini has to be changed. I hope it's easy to fix, and I'm puzzled why this problem is still present after being reported so many times before. -- Edit bug report at http://bugs.php.net/bug.php?id=52597edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=52597r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=52597r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=52597r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=52597r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=52597r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=52597r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=52597r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=52597r=needscript Try newer version: http://bugs.php.net/fix.php?id=52597r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=52597r=support Expected behavior: http://bugs.php.net/fix.php?id=52597r=notwrong Not enough info: http://bugs.php.net/fix.php?id=52597r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=52597r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=52597r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52597r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=52597r=dst IIS Stability: http://bugs.php.net/fix.php?id=52597r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=52597r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=52597r=float No Zend Extensions: http://bugs.php.net/fix.php?id=52597r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=52597r=mysqlcfg
