[PHP-BUG] Bug #54312 [NEW]: soap_version logic bug
From:
Operating system: CentOS 4
PHP version: 5.3.6
Package: SOAP related
Bug Type: Bug
Bug description:soap_version logic bug
Description:
This code in soap.c:
if (zend_hash_find(ht, "soap_version", sizeof("soap_version"),
(void**)&tmp) == SUCCESS) {
if (Z_TYPE_PP(tmp) == IS_LONG ||
(Z_LVAL_PP(tmp) == SOAP_1_1 && Z_LVAL_PP(tmp) == SOAP_1_2)) {
version = Z_LVAL_PP(tmp);
}
}
has a problem with the second line of the inner if statement.
Z_LVAL_PP(tmp) can't be both equal to SOAP_1_1 and SOAP_1_2, so this part
will always be false.
Plus, the "||" logic seems wrong too. It appears that if the type is
IS_LONG, then any value is accepted.
Patch is attached.
It looks like the logic is inverted. || should && and && should be ||:
if (zend_hash_find(ht, "soap_version", sizeof("soap_version"),
(void**)&tmp) == SUCCESS) {
if (Z_TYPE_PP(tmp) == IS_LONG &&
(Z_LVAL_PP(tmp) == SOAP_1_1 || Z_LVAL_PP(tmp) == SOAP_1_2)) {
version = Z_LVAL_PP(tmp);
}
}
--
Edit bug report at http://bugs.php.net/bug.php?id=54312&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=54312&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=54312&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=54312&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=54312&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=54312&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=54312&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=54312&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=54312&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=54312&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=54312&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=54312&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=54312&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=54312&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=54312&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54312&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=54312&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=54312&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=54312&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=54312&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=54312&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=54312&r=mysqlcfg
[PHP-BUG] Req #54311 [NEW]: Implicit variable scope declaration
From:
Operating system: Windows 7 x64
PHP version: Irrelevant
Package: *Programming Data Structures
Bug Type: Feature/Change Request
Bug description:Implicit variable scope declaration
Description:
Feature request for 'use implicit', or semantically similar syntax.
Anonymous functions with the use implicit directive inherit all variables
from parent scope in which they are declared, not called;
$foo = 'hello';
call_user_func(function() use implicit{
echo $foo; // hello
});
--
Edit bug report at http://bugs.php.net/bug.php?id=54311&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=54311&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=54311&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=54311&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=54311&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=54311&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=54311&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=54311&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=54311&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=54311&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=54311&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=54311&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=54311&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=54311&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=54311&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54311&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=54311&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=54311&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=54311&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=54311&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=54311&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=54311&r=mysqlcfg
[PHP-BUG] Bug #54310 [NEW]: Class Method & Function Arguments are allowed to be named the same
From:
Operating system: ANY
PHP version: 5.3.6
Package: *Compile Issues
Bug Type: Bug
Bug description:Class Method & Function Arguments are allowed to be named the
same
Description:
When writing class method and function declarations, php allows multiple
parameters with the same name. This seems like something that should
produce a
warning or notice.
Test script:
---
class Foo
{
public function bar($param, $param) {
echo $param;
}
}
$foo = new Foo();
$foo->bar('param1', 'param2');
Expected result:
I feel as though this should produce a warning or notice.
Actual result:
--
Runs without any issues and echos 'param2'
--
Edit bug report at http://bugs.php.net/bug.php?id=54310&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=54310&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=54310&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=54310&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=54310&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=54310&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=54310&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=54310&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=54310&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=54310&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=54310&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=54310&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=54310&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=54310&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=54310&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54310&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=54310&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=54310&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=54310&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=54310&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=54310&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=54310&r=mysqlcfg
Bug #52102 [Dup]: PHP5 under Apache2 on 64 bit system is not completely 64 bit
Edit report at http://bugs.php.net/bug.php?id=52102&edit=1
ID: 52102
Updated by: geiss...@php.net
Reported by:peter at ubuntu dot com
Summary:PHP5 under Apache2 on 64 bit system is not
completely 64 bit
Status: Duplicate
Type: Bug
Package:Apache related
Operating System: Ubuntu 10.04
PHP Version:5.3.2
Block user comment: N
Private report: N
New Comment:
> doesn't seem to be related to variable types
Oops, let's pretend I didn't actually say that.
Previous Comments:
[2011-03-18 20:37:46] geiss...@php.net
Adam, this bug report is related to sending files to the client and
doesn't seem
to be related to variable types. I don't think this is a dup of #44522.
The interesting stuff can be found at
https://bugs.launchpad.net/ubuntu/+source/php5/+bug/564920 (message #18
and
followups)
[2010-06-17 04:44:11] ahar...@php.net
Dupe of bug #44522.
[2010-06-16 19:39:56] peter at ubuntu dot com
Description:
Something in PHP5 running under apache2 under Ubuntu 9.10 is not fully
64 bit
aware on a 64 bit system. PHP scripts run under Apache correctly under
Ubuntu
8.04 (PHP 5.2.4). Under Ubuntu 9.10 (PHP 5.2.10) and 10.04 (PHP 5.3.2),
some
place a value is being treated as 32 bits on a 64 bit system and is
wrapping
instead of using full 64 bits. Related to sending large data (> 4G) in
response
to an HTTP post request.
Did not test with Ubuntu 8.10 or 9.04 - both PHP 5.2.6.
What happens: Data aborts based on wrap. Calculated number of bytes to
be served
are correct (>4G) as listed in the HTTP length header. Actual bytes
served are
(size) && 0x instead of (size) && 0x on 64 bit
system.
Most of data is being transfered via fpassthru($openFileHandle) call,
providing
>4G bytes of data.
Test script:
---
http://cdimage.debian.org/debian-cd/5.0.4/amd64/iso-dvd/debian-504-amd64-DVD-1.iso
$name = "/var/www/test.txt";
$fs = filesize($name);
$fp = fopen($name,'rb');
$httpByteLen = $fs;
header("Connection: close");
header("Content-Type: application/octet-stream");
header("Content-Length: " . $httpByteLen);
header("HTTP/1.1 200 OK");
set_time_limit(0);
fpassthru($fp);
exit;
?>
Expected result:
The entire ISO file to be downloaded.
Actual result:
--
Tested using the test script (attached), and using the suggested debian
dvd .iso
image as the input file. The ISO is 4,697,126,912 bytes. Download
socket is
closed after 402,159,616 bytes, which again is the file size &
0x.
--
Edit this bug report at http://bugs.php.net/bug.php?id=52102&edit=1
Bug #54204 [Com]: Can't set a value with a PATH section in php.ini
Edit report at http://bugs.php.net/bug.php?id=54204&edit=1 ID: 54204 Comment by: whistl0r+php at googlemail dot com Reported by:carsten_sttgt at gmx dot de Summary:Can't set a value with a PATH section in php.ini Status: Open Type: Bug Package:CGI related Operating System: Windows PHP Version:5.3.6RC3 Block user comment: N Private report: N New Comment: I can confirm this bug in the final 5.3.6 release. Previous Comments: [2011-03-11 09:26:39] carsten_sttgt at gmx dot de Still exists in 5.3.6RC3 [2011-03-09 16:22:36] carsten_sttgt at gmx dot de Description: I can't set a value inside a PATH section. The PATH section is for the current script. This only happens with Windows. With *nix it's working as expected. Additionally this only happens with PHP5.3.6RC2, but not with 5.3.5. Test script: --- adding this to "php.ini": [PATH=C:/Users/Public/Documents/htdocs/] upload_max_filesize = 5M And then accessing a phpinfo.php through CGI. Expected result: upload_max_filesize 5M 2M Actual result: -- upload_max_filesize 2M 2M -- Edit this bug report at http://bugs.php.net/bug.php?id=54204&edit=1
Bug #52102 [Com]: PHP5 under Apache2 on 64 bit system is not completely 64 bit
Edit report at http://bugs.php.net/bug.php?id=52102&edit=1
ID: 52102
Comment by: geiss...@php.net
Reported by:peter at ubuntu dot com
Summary:PHP5 under Apache2 on 64 bit system is not
completely 64 bit
Status: Duplicate
Type: Bug
Package:Apache related
Operating System: Ubuntu 10.04
PHP Version:5.3.2
Block user comment: N
Private report: N
New Comment:
Adam, this bug report is related to sending files to the client and
doesn't seem
to be related to variable types. I don't think this is a dup of #44522.
The interesting stuff can be found at
https://bugs.launchpad.net/ubuntu/+source/php5/+bug/564920 (message #18
and
followups)
Previous Comments:
[2010-06-17 04:44:11] ahar...@php.net
Dupe of bug #44522.
[2010-06-16 19:39:56] peter at ubuntu dot com
Description:
Something in PHP5 running under apache2 under Ubuntu 9.10 is not fully
64 bit
aware on a 64 bit system. PHP scripts run under Apache correctly under
Ubuntu
8.04 (PHP 5.2.4). Under Ubuntu 9.10 (PHP 5.2.10) and 10.04 (PHP 5.3.2),
some
place a value is being treated as 32 bits on a 64 bit system and is
wrapping
instead of using full 64 bits. Related to sending large data (> 4G) in
response
to an HTTP post request.
Did not test with Ubuntu 8.10 or 9.04 - both PHP 5.2.6.
What happens: Data aborts based on wrap. Calculated number of bytes to
be served
are correct (>4G) as listed in the HTTP length header. Actual bytes
served are
(size) && 0x instead of (size) && 0x on 64 bit
system.
Most of data is being transfered via fpassthru($openFileHandle) call,
providing
>4G bytes of data.
Test script:
---
http://cdimage.debian.org/debian-cd/5.0.4/amd64/iso-dvd/debian-504-amd64-DVD-1.iso
$name = "/var/www/test.txt";
$fs = filesize($name);
$fp = fopen($name,'rb');
$httpByteLen = $fs;
header("Connection: close");
header("Content-Type: application/octet-stream");
header("Content-Length: " . $httpByteLen);
header("HTTP/1.1 200 OK");
set_time_limit(0);
fpassthru($fp);
exit;
?>
Expected result:
The entire ISO file to be downloaded.
Actual result:
--
Tested using the test script (attached), and using the suggested debian
dvd .iso
image as the input file. The ISO is 4,697,126,912 bytes. Download
socket is
closed after 402,159,616 bytes, which again is the file size &
0x.
--
Edit this bug report at http://bugs.php.net/bug.php?id=52102&edit=1
Bug #53339 [Opn->Csd]: Fails to build LDAP module when compilng with gcc 4.5 and DSO libraries
Edit report at http://bugs.php.net/bug.php?id=53339&edit=1 ID: 53339 Updated by: geiss...@php.net Reported by:clint at ubuntu dot com Summary:Fails to build LDAP module when compilng with gcc 4.5 and DSO libraries -Status: Open +Status: Closed Type: Bug Package:Compile Failure Operating System: Ubuntu Linux (natty) PHP Version:5.3.3 -Assigned To: +Assigned To:geissert Block user comment: N Private report: N New Comment: This bug has been fixed in SVN. 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: [2011-03-18 19:47:11] geiss...@php.net Automatic comment from SVN on behalf of geissert Revision: http://svn.php.net/viewvc/?view=revision&revision=309398 Log: Add the libraries we actually test and need for LDAP and OpenSSL, fixes bug #53339 Patch by Clint Byrum [2010-11-18 09:32:42] clint at ubuntu dot com This is tracked in Ubuntu under this bug report: https://bugs.launchpad.net/ubuntu/+source/php5/+bug/676672 [2010-11-18 09:28:40] clint at ubuntu dot com Description: The currenty Ubuntu development release (natty) has updated the toolchain to gcc 4.5 and uses DSO libs. Because of this, there are stricter restrictions on using symbols without directly linking to the library containing them. This patch fixes these issues, and compiles correctly on natty and the current stable release (Ubuntu 10.10). Test script: --- ./configure --with-ldap --with-openssl Fails because sasl2 is not linked directly. If that is fixed, make Fails because libssl does not contain X509_new (libcrypto does). Expected result: configure and build should complete Actual result: -- checking for sasl_version in -lldap... no configure: error: LDAP SASL check failed. Please check config.log for more information. make: *** [configure-apache2-stamp] Error 1 dpkg-buildpackage: error: debian/rules build gave error exit status 2 ext/zip/lib/.libs/zip_dirent.o: In function `_zip_dirent_read': /home/clint/pkg/php5/bzr/build-area/php5-5.3.3/ext/zip/lib/zip_dirent.c:478: warning: memset used with constant zero length parameter; this could be due to transposed parameters /home/clint/pkg/php5/bzr/build-area/php5-5.3.3/ext/zip/lib/zip_dirent.c:478: warning: memset used with constant zero length parameter; this could be due to transposed parameters /usr/bin/ld.bfd.real: ext/openssl/.libs/openssl.o: undefined reference to symbol 'X509_free@@OPENSSL_0.9.8' /usr/bin/ld.bfd.real: note: 'X509_free@@OPENSSL_0.9.8' is defined in DSO /lib64/libcrypto.so.0.9.8 so try adding it to the linker command line /lib64/libcrypto.so.0.9.8: could not read symbols: Invalid operation collect2: ld returned 1 exit status -- Edit this bug report at http://bugs.php.net/bug.php?id=53339&edit=1
Bug #30073 [Com]: Exception handling not work for selectable procedures
Edit report at http://bugs.php.net/bug.php?id=30073&edit=1
ID: 30073
Comment by: george dot benjamin at gmail dot com
Reported by:almad at dracidoupe dot cz
Summary:Exception handling not work for selectable
procedures
Status: No Feedback
Type: Bug
Package:InterBase related
Operating System: Gentoo Linux
PHP Version:5.0.1
Block user comment: N
Private report: N
New Comment:
I have the same problem, both on linux (CentOS 5.2) and on windows
(Windows7) with
interbase etension version 5.3.1.0
(php_interbase.dll/php_interbase.so).
If I use "select * from procedure_name" in ibase_query() and the
procedure raises
an exception, ibase_errmsg() and ibase_errcode() will return null
instead of the
exception message and number.
Previous Comments:
[2009-11-13 20:42:32] tonne1 at s8zehn dot net
On Debian:
selectable SP does never return an error:
test case:
create procedure test
returns (status integer)
as
begin
status = 1 / 0;
suspend;
end;
calling
select * from test
will not raise an error.
[2005-03-03 01:00:10] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
[2005-02-23 21:31:26] ab...@php.net
Please try using this CVS snapshot:
http://snaps.php.net/php5-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.0-win32-latest.zip
[2004-09-13 14:31:55] almad at dracidoupe dot cz
Description:
When calling executable procedure, php works good, that means that
ibase_query returns FALSE and IBase_Errmsg() contains code and text of
exception returned by stored procedure.
However, when calling selectable procedure ("select a, b from
procedure_name"), ibase_query returns TRUE and exception is returned as
unhandlingable php warning when calling ibase_fetch_row/assoc/object.
Reproduce code:
---
$s = ibase_query ("select var from procedure_name");
If(!$s){
echo "FireBird returned error: ".IBase_Errmsg();
}
Else{
while($d=ibase_fetch_row($s)){
echo $d[0];
}
}
Expected result:
FireBird returned error: Some exception returned by procedure_name
Actual result:
--
Warning: ibase_fetch_assoc() [function.ibase-fetch-assoc]: exception 1
Some exception returned by procedure_name in /var/.../script.php on line
xx
--
Edit this bug report at http://bugs.php.net/bug.php?id=30073&edit=1
[PHP-BUG] Bug #54309 [NEW]: Multiple environment variables for PHP_ADMIN_VALUE only accepts last value
From: Operating system: Linux PHP version: 5.3.6 Package: FPM related Bug Type: Bug Bug description:Multiple environment variables for PHP_ADMIN_VALUE only accepts last value Description: If you wanted to specify multiple PHP_ADMIN_VALUE environment variables, such as (nginx config): fastcgi_param PHP_ADMIN_VALUE "sendmail_from=Me"; fastcgi_param PHP_ADMIN_VALUE "sendmail_path=/usr/sbin/sendmail -f m...@me.com"; then only the second one gets picked up (probably because as an environment variable, the last one is clobbering over the first one(s)). Expected result: Respect multiple PHP_ADMIN_VALUE variables, or perhaps read in environment variables like PHP_ADMIN_VALUE[variable_name], so that this would work: fastcgi_param PHP_ADMIN_VALUE[sendmail_from] "me"; fastcgi_param PHP_ADMIN_VALUE[sendmail_path] "/usr/sbin/sendmail -f m...@me.com"; -- Edit bug report at http://bugs.php.net/bug.php?id=54309&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=54309&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=54309&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=54309&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=54309&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=54309&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=54309&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=54309&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=54309&r=needscript Try newer version: http://bugs.php.net/fix.php?id=54309&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=54309&r=support Expected behavior: http://bugs.php.net/fix.php?id=54309&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=54309&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=54309&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=54309&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54309&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=54309&r=dst IIS Stability: http://bugs.php.net/fix.php?id=54309&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=54309&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=54309&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=54309&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=54309&r=mysqlcfg
Bug #54301 [Com]: phpinfo not working
Edit report at http://bugs.php.net/bug.php?id=54301&edit=1 ID: 54301 Comment by: carsten_sttgt at gmx dot de Reported by:wapinet at mail dot ru Summary:phpinfo not working Status: Bogus Type: Bug Package:Reproducible crash Operating System: Windows XP SP3 32 PHP Version:5.3.6 Block user comment: N Private report: N New Comment: > I'm reasonably happy to leave this closed, > even if it does turn out to be another manifestation of bug #54200: That's ok (isn't a dub not also bogus?). But now I can add this (zend_extension) to #54200. > the third party extension is more likely to be at fault. Always good if a 3rd party extension is involved... ;-) But I've just tested this: PHP 5.3.6-nts together with ea (5.3.5) is not crashing. Just a message "ea can't be loaded" or no message with "display_startup_errors = Off". BTW: which other problems (then [zend_]extension=) are hidden with "display_startup_errors = Off"? Previous Comments: [2011-03-18 14:15:34] ahar...@php.net If PHP crashes with a third party extension, and doesn't crash without the third party extension, I'm reasonably happy to leave this closed, even if it does turn out to be another manifestation of bug #54200: on the evidence in this bug, the third party extension is more likely to be at fault. [2011-03-18 12:50:49] wapinet at mail dot ru a) I using thread safe version b) display_startup_errors = On [2011-03-18 11:00:26] carsten_sttgt at gmx dot de @wapinet Can you tell me: a) You are using the thread safe or non thread safe version of PHP? b) What's the value of display_startup_errors? @aharvey Even PHP 5.3.6 can't load an eAccelerator build for 5.3.5, there should no core dump (Access violation). I guess this report is also a dup for bug #54200. [2011-03-18 09:49:53] wapinet at mail dot ru I apologize. The problem was that eAccelerator has been compiled for php version 5.3.5 Disable eAccelerator solved the problem. [2011-03-18 09:36:55] ahar...@php.net Is this happening under a Web server or using the CLI version of PHP? If it's a Web server, what are you getting in the Web server's error log? 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=54301 -- Edit this bug report at http://bugs.php.net/bug.php?id=54301&edit=1
Bug #41528 [Com]: Classes extending ArrayObject do not serialize correctly
Edit report at http://bugs.php.net/bug.php?id=41528&edit=1
ID: 41528
Comment by: jachym dot tousek at gmail dot com
Reported by:m dot stach at ewerk dot com
Summary:Classes extending ArrayObject do not serialize
correctly
Status: Closed
Type: Bug
Package:SPL related
Operating System: *
PHP Version:5.2.*
Assigned To:davidc
Block user comment: N
Private report: N
New Comment:
I've the same problem in PHP 5.3.5 / Windows 7.
Previous Comments:
[2007-12-17 15:16:11] dav...@php.net
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.
[2007-12-06 16:06:49] he...@php.net
There is a fix for it in 5.3.0 that needs a few tweaks, you can test it
for your usage already though. Assigning to david to do the tweaking.
[2007-08-05 15:31:25] pcdinh at gmail dot com
This bug remain still on PHP 5.2.4RC1
[2007-05-29 10:48:09] m dot stach at ewerk dot com
Description:
If a class extends ArrayObject, serializing does not work correctly. All
properties are missing after unserializing, only the array contents are
remain.
ArrayObjects (un)serializes without problems and does not implement the
Serializable interface, so there seems no need to change the
implementation of that interface.
The documentation mentions that it is not possible to serialize objects
of internal class. Since ArrayObject itself serializes fine, I regard
ArrayObject as "non-internal".
May be this is a documentation bug. But this would IMHO limit the broad
use of the ArrayObject class.
Reproduce code:
---
class a extends ArrayObject {
public $a = 2;
}
$a = new a();
$a->a = 1;
var_dump($a);
var_dump($a->a);
$a = unserialize(serialize($a));
var_dump($a);
var_dump($a->a);
Expected result:
object(a)#1 (1) { ["a"]=> int(1) }
int(1)
object(a)#1 (1) { ["a"]=> int(1) }
int(1)
Actual result:
--
object(a)#1 (0) { }
int(1)
object(a)#2 (0) { }
int(2)
--
Edit this bug report at http://bugs.php.net/bug.php?id=41528&edit=1
Req #53264 [Com]: Add fputcsv method to SplFileObject
Edit report at http://bugs.php.net/bug.php?id=53264&edit=1 ID: 53264 Comment by: jinmoku at hotmail dot com Reported by:jinmoku at hotmail dot com Summary:Add fputcsv method to SplFileObject Status: Closed Type: Feature/Change Request Package:SPL related PHP Version:5.3.3 Assigned To:aharvey Block user comment: N Private report: N New Comment: not yet in the 5.3 branch ? Previous Comments: [2010-11-09 16:08:24] ahar...@php.net This bug has been fixed in SVN. 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. Implemented on trunk. [2010-11-09 16:07:52] ahar...@php.net Automatic comment from SVN on behalf of aharvey Revision: http://svn.php.net/viewvc/?view=revision&revision=305229 Log: Implemented FR #53264 (Add fputcsv method to SplFileObject). [2010-11-08 14:22:36] jinmoku at hotmail dot com Description: It's not in the orginal SPL, but why not... ;) -- Edit this bug report at http://bugs.php.net/bug.php?id=53264&edit=1
Bug #54301 [Bgs]: phpinfo not working
Edit report at http://bugs.php.net/bug.php?id=54301&edit=1 ID: 54301 Updated by: ahar...@php.net Reported by:wapinet at mail dot ru Summary:phpinfo not working Status: Bogus Type: Bug Package:Reproducible crash Operating System: Windows XP SP3 32 PHP Version:5.3.6 Block user comment: N Private report: N New Comment: If PHP crashes with a third party extension, and doesn't crash without the third party extension, I'm reasonably happy to leave this closed, even if it does turn out to be another manifestation of bug #54200: on the evidence in this bug, the third party extension is more likely to be at fault. Previous Comments: [2011-03-18 12:50:49] wapinet at mail dot ru a) I using thread safe version b) display_startup_errors = On [2011-03-18 11:00:26] carsten_sttgt at gmx dot de @wapinet Can you tell me: a) You are using the thread safe or non thread safe version of PHP? b) What's the value of display_startup_errors? @aharvey Even PHP 5.3.6 can't load an eAccelerator build for 5.3.5, there should no core dump (Access violation). I guess this report is also a dup for bug #54200. [2011-03-18 09:49:53] wapinet at mail dot ru I apologize. The problem was that eAccelerator has been compiled for php version 5.3.5 Disable eAccelerator solved the problem. [2011-03-18 09:36:55] ahar...@php.net Is this happening under a Web server or using the CLI version of PHP? If it's a Web server, what are you getting in the Web server's error log? [2011-03-18 09:28:31] wapinet at mail dot ru OS 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=54301 -- Edit this bug report at http://bugs.php.net/bug.php?id=54301&edit=1
Bug #54157 [Com]: Destruction of some global variables before session write handler callback
Edit report at http://bugs.php.net/bug.php?id=54157&edit=1
ID: 54157
Comment by: nicolas dot grekas+php at gmail dot com
Reported by:tstarling at wikimedia dot org
Summary:Destruction of some global variables before session
write handler callback
Status: Wont fix
Type: Bug
Package:Scripting Engine problem
Operating System: Linux
PHP Version:5.3SVN-2011-03-03 (SVN)
Block user comment: N
Private report: N
New Comment:
@tstarling: read your patch. My code above has one more thing you maybe
didn't notice: I call register_shutdown_function twice. First to
register shutdown_session, then inside shutdown_session to register
session_write_close. This way, I push the session_write_close call after
other shutdown registered functions.
So I would change your memsess_write_close function definition at
http://www.mediawiki.org/wiki/Special:Code/MediaWiki/83147 with :
function memsess_write_close() {
- session_write_close();
+ register_shutdown_function('session_write_close');
}
Previous Comments:
[2011-03-17 23:03:45] tstarling at wikimedia dot org
@nicolas: Yes, I know, I did it before I reported this bug. I linked to
the revision in my internals post.
http://marc.info/?l=php-internals&m=130025049301140&w=2
[2011-03-17 14:53:49] nicolas dot grekas+php at gmail dot com
If you add this to your code, it works around the problem, while still
closing the session as late as possible I think :
[2011-03-04 10:19:49] johan...@php.net
This is a hen and egg problem. First issue which comes to mind is: What
happens if a destructor wants to log it's state or such in the session?
We have tuned the order multiple times and the current behaviour is the
best of the bad choices we have.
[2011-03-04 01:29:20] tstarling at wikimedia dot org
Here's another argument in favour of adding a new hook to
php_request_shutdown(): the point of session_set_save_handler() is to
allow userspace code to implement alternative methods of session
storage. Writing to alternate storage will typically involve calling
some other PHP module. But how can we safely call other PHP modules when
half of them will have had their RSHUTDOWN functions called? There is
the potential for subtle bugs dependent on module load order: dangling
pointers, memory corruption, etc.
[2011-03-04 00:54:47] tstarling at wikimedia dot org
Description:
The request function of the session module calls custom session save
handlers. Because modules are shut down after zend_call_destructors() is
called, this exposes the weird and apparently broken behaviour of
zend_call_destructors() to the user space.
Its effect is to delete all global variables with a reference count of
1, but only if they hold an object. Global variables which are
referenced from anywhere, including other global variables, are not
deleted.
Ideally, I would like session save handlers to have reliable access to
global variables. That probably means calling them before the
user-defined __destruct() functions, say with an extra hook into
php_request_shutdown().
Failing that, I would like the behaviour to be consistent and
predictable, so that we don't end up with strange regressions like the
one observed here:
http://www.mediawiki.org/wiki/Special:Code/MediaWiki/83140#c14601
Test script:
---
http://bugs.php.net/bug.php?id=54157&edit=1
Bug #54306 [Com]: Parsing bug if a pattern looking like closing ASP tag appears in comment
Edit report at http://bugs.php.net/bug.php?id=54306&edit=1
ID: 54306
Comment by: carsten_sttgt at gmx dot de
Reported by:gingko at gingko dot homeip dot net
Summary:Parsing bug if a pattern looking like closing ASP
tag appears in comment
Status: Open
Type: Bug
Package:Scripting Engine problem
Operating System: Linux Debian 5 'Lenny'
PHP Version:5.2.17
Block user comment: N
Private report: N
New Comment:
> Ok, so why ONLY in comments?
This also happens outside a comment.
|
| }
| ?>
Of course, in your case:
| echo "Line 2";
"%>" is inside a string and not parsed.
> Why only in LINE comments?
Because that's how the manual is describing comments:
| The "one-line" comment styles only comment to the end of the line
| or the current block of PHP code, whichever comes first.
(And a block is ending at "?>" or "%>".)
vs.:
| 'C' style comments end at the first */ encountered.
> Shouldn't the "?>" and "%>" tags be only able to close
> the corresponding "" and "%>" tags be only able to close the corresponding
"" accidental
pattern is not completely unlikely to happen (for at least as long as
HTML will tolerate to have this kind of attribute's values not enclosed
in quotes).
I think that the time that I needed for finding that problem could be by
itself a good reason for changing something there.
[2011-03-18 12:26:21] carsten_sttgt at gmx dot de
That's the normal behavior. See:
http://de.php.net/manual/en/language.basic-syntax.comments.php
"%>" is returning to HTML mode. But at this point the opened "{" from
the if is not closed, and it's not closed till the end of the file.
That's the error message.
[2011-03-18 12:04:42] gingko at gingko dot homeip dot net
Description:
A parsing error occurs if a pattern looking like a closing ASP tag
appears inside a line comment (beginning by '//'), in a PHP engine
having 'asp_tags = On' in the 'php.ini' file.
If I remove the "//" comment, I have a big "Line 2" visible, and there
is no bug.
If I use a "/* */" style comment instead, there is no bug.
If I put quotes around "140%" in the "size" attribute, there is no bug.
If I set the "asp_tags" options to "Off", or if I remove it, there is no
bug.
Removing the 'if' condition around the comment results in another kind
of problem (no error, but part of HTML code visible).
I found this because I was trying to install the latest version of OCS
Inventory (http://www.ocsinventory-ng.org/), and I didn't understand why
I got a white page and a PHP parse error after the first step of
installation: I have 'asp_tags = On' in 'php.ini', and there is
effectively a commented out '%>' pattern in their code.
Looks like a little to Bug #4879 (more than 10 years old).
Test script:
---
Asp tag bug
Line 1
Line 2";
}
?>
Line 3
Expected result:
Two text lines in browsers's Window :
"Line 1"
"Line 3"
Actual result:
--
A white page, and the following error in Apache log :
PHP Parse error: syntax error, unexpected $end in
/var/www/[...]/asp_tag_bug.php on line 13
--
Edit this bug report at http://bugs.php.net/bug.php?id=54306&edit=1
Req #54308 [Bgs]: You named the new version 5.3.6 and not 5.4.0
Edit report at http://bugs.php.net/bug.php?id=54308&edit=1 ID: 54308 Updated by: paj...@php.net Reported by:stevenmartin99 at gmail dot com Summary:You named the new version 5.3.6 and not 5.4.0 Status: Bogus Type: Feature/Change Request Package:*General Issues Operating System: Windows PHP Version:5.3.6 Block user comment: N Private report: N New Comment: That's the reply from the Apache Organisation as well. They do NOT provide official binaries but as a convenience, using VC6/mingw. But they are by no mean official builds. We stop to support VC6 for security and maintainability reasons. Use a VC9 build of apache and get over it. Previous Comments: [2011-03-18 13:41:11] stevenmartin99 at gmail dot com I did mention this...Its not Offical. Who is ApacheLounge? Who is Steffen Land? You are now making the Security of People Servers rest on one person by telling everyone , to be secure use the latest PHP version but you must use it with an unoffical version of Apache built by one person.. (Doesnt sound so secure to me) Please reopen open my issue as you failed to understand it correctly. This was not my bug issue you replied about. My issue is with the number versioning to let people know of the SERIOUS UPDATE. You changed the numbering by 0.0.1 which people will see as a security update.. When in fact they will be creating an extremly unstable Server if you update PHP to 5.3.6. And if you follow PHP'S recommendation by using ApacheLounges(Steffen Land) VC9 Apache build you are saying this is safe. [2011-03-18 13:19:44] der...@php.net We support Apache on Windows just fine. Just not with the antiquated Visual Studio 6 builds that apache.org provides. You can use Apache from ApacheLounge just fine. [2011-03-18 13:13:26] stevenmartin99 at gmail dot com Sorry but this is not BOGUS.. Where else can this issue be brought up? Please provide a link to somewhere else or change the status back to open [2011-03-18 13:03:53] paj...@php.net . [2011-03-18 12:57:26] stevenmartin99 at gmail dot com Description: You have released the new version of php as PHP5.3.6 from PHP5.3.5 To a windows user this means a small security update... When in fact you have rendered every single Apache sever useless if they upgrade. How can this kind of update be in the n.n.X class of number versioning when if should be AT LEAST in the n.X.n Range. Telling people in a small note that you no longer support APACHE ON WINDOWS is not acceptable when you only change the version number by 0.0.1 Telling people to use an unoffical build of Apache when previously a PHP X.X.-1 compatiable official Build was ok is not Acceptable. You really need to think about this very carefully, 5.4.0 should have been released. Expected result: change the version number to PHP5.4.0 -- Edit this bug report at http://bugs.php.net/bug.php?id=54308&edit=1
Bug #51307 [Fbk->Asn]: php.exe error on command line
Edit report at http://bugs.php.net/bug.php?id=51307&edit=1 ID: 51307 User updated by:joerg dot klein at ifsam dot lu Reported by:joerg dot klein at ifsam dot lu Summary:php.exe error on command line -Status: Feedback +Status: Assigned Type: Bug Package:Reproducible crash Operating System: win32 only - Windows Server 2003 PHP Version:5.3.6 Assigned To:pajoye Block user comment: N Private report: N New Comment: Thread 0 - System ID 736 Entry point php_cgi!mainCRTStartup Create time 18.03.2011 12:18:32 Time spent in user mode 0 Days 0:0:0.31 Time spent in kernel mode 0 Days 0:0:0.156 Function Arg 1 Arg 2 Arg 3 Source php5ts!zend_register_internal_class_ex+ba7 003f5098 100e1075 01864590 php5ts!_efree+2e 01864590 003f2918 1021e045 php5ts!closelog+55 101d7ba4 0001 0013 php5ts!zm_deactivate_syslog+5 0001 0013 003f2918 php5ts!zm_deactivate_basic+e4 0001 0013 003f2918 php5ts!module_registry_cleanup+1b 0198d1b8 003f2918 003f2918 php5ts!zend_hash_reverse_apply+3f 1058b280 10006640 003f2918 php5ts!zend_deactivate_modules+61 003f2918 0002 003f2918 php5ts!php_request_shutdown+235 0040a4c8 0001 php_cgi!main+e89 0002 003f3f30 003f2f80 php_cgi!memset+160 7ffdd000 kernel32!ProcessIdToSessionId+209 00406a7a PHP5TS!ZEND_REGISTER_INTERNAL_CLASS_EX+BA7In php-cgi__PID__932__Date__03_18_2011__Time_12_18_35PM__387__Second_Chance_Exception_C005.dmp the assembly instruction at php5ts!zend_register_internal_class_ex+ba7 in C:\php\php5ts.dll from The PHP Group has caused an access violation exception (0xC005) when trying to read from memory location 0x6aebadf8 on thread 0 Module Information Image Name: C:\php\php5ts.dll Symbol Type: PDB Base address: 0x1000 Time Stamp: Thu Mar 17 11:41:09 2011 Checksum: 0x005a6b72 Comments: COM DLL: False Company Name: The PHP Group ISAPIExtension: False File Description: PHP Script Interpreter ISAPIFilter: False File Version: 5.3.6 Managed DLL: False Internal Name: PHP Script Interpreter VB DLL: False Legal Copyright: Copyright © 1997-2010 The PHP Group Loaded Image Name: php5ts.dll Legal Trademarks: PHP Mapped Image Name: Original filename: php5ts.dll Module name: php5ts Private Build: Single Threaded: False Product Name: PHP Module Size: 5,75 MBytes Product Version: 5.3.6 Symbol File Name: C:\php\php5ts.pdb Special Build: & Previous Comments: [2011-03-18 10:14:18] paj...@php.net Please provide a new backtrace then, if it crashes somewhere else. But I still have little clue about what's happening :) [2011-03-18 10:11:41] joerg dot klein at ifsam dot lu I tested 5.3.6 VC9 today. The crash is still there, but it occurs in another file. I just removed one comment line and the file works without a problem! As I Stated in my last post, it is impossible to write a short reproduceable script. Even when it crashes on my site, it won't do on your site. [2010-08-18 14:41:40] paj...@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 , 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-08-18 14:27:30] joerg dot klein at ifsam dot lu I tried again with 5.3.3 final. The same script which produces the error in 5.3.2 works fine, but with some minimal changes (e.g. remove a comment line) the error occured again. A small reproduce script seems to be impossible. I also tried some different configurations. The result: adding just a comment line in the php.ini let the error disappear. [2010-08-08 16:22:01] paj...@php.net Please try using 5.3.3 final. If it still crashes, please provide a small (really small w/o external dependencies) reproduce script. The remainder of the comments for this report are too long. To view the rest of the commen
Req #54308 [Com]: You named the new version 5.3.6 and not 5.4.0
Edit report at http://bugs.php.net/bug.php?id=54308&edit=1 ID: 54308 Comment by: stevenmartin99 at gmail dot com Reported by:stevenmartin99 at gmail dot com Summary:You named the new version 5.3.6 and not 5.4.0 Status: Bogus Type: Feature/Change Request Package:*General Issues Operating System: Windows PHP Version:5.3.6 Block user comment: N Private report: N New Comment: I did mention this...Its not Offical. Who is ApacheLounge? Who is Steffen Land? You are now making the Security of People Servers rest on one person by telling everyone , to be secure use the latest PHP version but you must use it with an unoffical version of Apache built by one person.. (Doesnt sound so secure to me) Please reopen open my issue as you failed to understand it correctly. This was not my bug issue you replied about. My issue is with the number versioning to let people know of the SERIOUS UPDATE. You changed the numbering by 0.0.1 which people will see as a security update.. When in fact they will be creating an extremly unstable Server if you update PHP to 5.3.6. And if you follow PHP'S recommendation by using ApacheLounges(Steffen Land) VC9 Apache build you are saying this is safe. Previous Comments: [2011-03-18 13:19:44] der...@php.net We support Apache on Windows just fine. Just not with the antiquated Visual Studio 6 builds that apache.org provides. You can use Apache from ApacheLounge just fine. [2011-03-18 13:13:26] stevenmartin99 at gmail dot com Sorry but this is not BOGUS.. Where else can this issue be brought up? Please provide a link to somewhere else or change the status back to open [2011-03-18 13:03:53] paj...@php.net . [2011-03-18 12:57:26] stevenmartin99 at gmail dot com Description: You have released the new version of php as PHP5.3.6 from PHP5.3.5 To a windows user this means a small security update... When in fact you have rendered every single Apache sever useless if they upgrade. How can this kind of update be in the n.n.X class of number versioning when if should be AT LEAST in the n.X.n Range. Telling people in a small note that you no longer support APACHE ON WINDOWS is not acceptable when you only change the version number by 0.0.1 Telling people to use an unoffical build of Apache when previously a PHP X.X.-1 compatiable official Build was ok is not Acceptable. You really need to think about this very carefully, 5.4.0 should have been released. Expected result: change the version number to PHP5.4.0 -- Edit this bug report at http://bugs.php.net/bug.php?id=54308&edit=1
Req #54308 [Bgs]: You named the new version 5.3.6 and not 5.4.0
Edit report at http://bugs.php.net/bug.php?id=54308&edit=1 ID: 54308 Updated by: der...@php.net Reported by:stevenmartin99 at gmail dot com Summary:You named the new version 5.3.6 and not 5.4.0 Status: Bogus Type: Feature/Change Request Package:*General Issues Operating System: Windows PHP Version:5.3.6 Block user comment: N Private report: N New Comment: We support Apache on Windows just fine. Just not with the antiquated Visual Studio 6 builds that apache.org provides. You can use Apache from ApacheLounge just fine. Previous Comments: [2011-03-18 13:13:26] stevenmartin99 at gmail dot com Sorry but this is not BOGUS.. Where else can this issue be brought up? Please provide a link to somewhere else or change the status back to open [2011-03-18 13:03:53] paj...@php.net . [2011-03-18 12:57:26] stevenmartin99 at gmail dot com Description: You have released the new version of php as PHP5.3.6 from PHP5.3.5 To a windows user this means a small security update... When in fact you have rendered every single Apache sever useless if they upgrade. How can this kind of update be in the n.n.X class of number versioning when if should be AT LEAST in the n.X.n Range. Telling people in a small note that you no longer support APACHE ON WINDOWS is not acceptable when you only change the version number by 0.0.1 Telling people to use an unoffical build of Apache when previously a PHP X.X.-1 compatiable official Build was ok is not Acceptable. You really need to think about this very carefully, 5.4.0 should have been released. Expected result: change the version number to PHP5.4.0 -- Edit this bug report at http://bugs.php.net/bug.php?id=54308&edit=1
Bug #54306 [Opn]: Parsing bug if a pattern looking like closing ASP tag appears in comment
Edit report at http://bugs.php.net/bug.php?id=54306&edit=1
ID: 54306
User updated by:gingko at gingko dot homeip dot net
Reported by:gingko at gingko dot homeip dot net
Summary:Parsing bug if a pattern looking like closing ASP
tag appears in comment
Status: Open
Type: Bug
Package:Scripting Engine problem
Operating System: Linux Debian 5 'Lenny'
PHP Version:5.2.17
Block user comment: N
Private report: N
New Comment:
Ok, so why ONLY in comments?
Why only in LINE comments?
And more, does it really make sense to allow closing PHP mode with an
ASP tag that is not even matching an opening "<%" ASP tag, but rather
only matching a "" and "%>" tags be only able to close the corresponding
"" accidental
pattern is not completely unlikely to happen (for at least as long as
HTML will tolerate to have this kind of attribute's values not enclosed
in quotes).
I think that the time that I needed for finding that problem could be by
itself a good reason for changing something there.
Previous Comments:
[2011-03-18 12:26:21] carsten_sttgt at gmx dot de
That's the normal behavior. See:
http://de.php.net/manual/en/language.basic-syntax.comments.php
"%>" is returning to HTML mode. But at this point the opened "{" from
the if is not closed, and it's not closed till the end of the file.
That's the error message.
[2011-03-18 12:04:42] gingko at gingko dot homeip dot net
Description:
A parsing error occurs if a pattern looking like a closing ASP tag
appears inside a line comment (beginning by '//'), in a PHP engine
having 'asp_tags = On' in the 'php.ini' file.
If I remove the "//" comment, I have a big "Line 2" visible, and there
is no bug.
If I use a "/* */" style comment instead, there is no bug.
If I put quotes around "140%" in the "size" attribute, there is no bug.
If I set the "asp_tags" options to "Off", or if I remove it, there is no
bug.
Removing the 'if' condition around the comment results in another kind
of problem (no error, but part of HTML code visible).
I found this because I was trying to install the latest version of OCS
Inventory (http://www.ocsinventory-ng.org/), and I didn't understand why
I got a white page and a PHP parse error after the first step of
installation: I have 'asp_tags = On' in 'php.ini', and there is
effectively a commented out '%>' pattern in their code.
Looks like a little to Bug #4879 (more than 10 years old).
Test script:
---
Asp tag bug
Line 1
Line 2";
}
?>
Line 3
Expected result:
Two text lines in browsers's Window :
"Line 1"
"Line 3"
Actual result:
--
A white page, and the following error in Apache log :
PHP Parse error: syntax error, unexpected $end in
/var/www/[...]/asp_tag_bug.php on line 13
--
Edit this bug report at http://bugs.php.net/bug.php?id=54306&edit=1
Req #54308 [Com]: You named the new version 5.3.6 and not 5.4.0
Edit report at http://bugs.php.net/bug.php?id=54308&edit=1 ID: 54308 Comment by: stevenmartin99 at gmail dot com Reported by:stevenmartin99 at gmail dot com Summary:You named the new version 5.3.6 and not 5.4.0 Status: Bogus Type: Feature/Change Request Package:*General Issues Operating System: Windows PHP Version:5.3.6 Block user comment: N Private report: N New Comment: Sorry but this is not BOGUS.. Where else can this issue be brought up? Please provide a link to somewhere else or change the status back to open Previous Comments: [2011-03-18 13:03:53] paj...@php.net . [2011-03-18 12:57:26] stevenmartin99 at gmail dot com Description: You have released the new version of php as PHP5.3.6 from PHP5.3.5 To a windows user this means a small security update... When in fact you have rendered every single Apache sever useless if they upgrade. How can this kind of update be in the n.n.X class of number versioning when if should be AT LEAST in the n.X.n Range. Telling people in a small note that you no longer support APACHE ON WINDOWS is not acceptable when you only change the version number by 0.0.1 Telling people to use an unoffical build of Apache when previously a PHP X.X.-1 compatiable official Build was ok is not Acceptable. You really need to think about this very carefully, 5.4.0 should have been released. Expected result: change the version number to PHP5.4.0 -- Edit this bug report at http://bugs.php.net/bug.php?id=54308&edit=1
Req #54308 [Opn->Bgs]: You named the new version 5.3.6 and not 5.4.0
Edit report at http://bugs.php.net/bug.php?id=54308&edit=1 ID: 54308 Updated by: paj...@php.net Reported by:stevenmartin99 at gmail dot com Summary:You named the new version 5.3.6 and not 5.4.0 -Status: Open +Status: Bogus Type: Feature/Change Request Package:*General Issues Operating System: Windows PHP Version:5.3.6 Block user comment: N Private report: N New Comment: . Previous Comments: [2011-03-18 12:57:26] stevenmartin99 at gmail dot com Description: You have released the new version of php as PHP5.3.6 from PHP5.3.5 To a windows user this means a small security update... When in fact you have rendered every single Apache sever useless if they upgrade. How can this kind of update be in the n.n.X class of number versioning when if should be AT LEAST in the n.X.n Range. Telling people in a small note that you no longer support APACHE ON WINDOWS is not acceptable when you only change the version number by 0.0.1 Telling people to use an unoffical build of Apache when previously a PHP X.X.-1 compatiable official Build was ok is not Acceptable. You really need to think about this very carefully, 5.4.0 should have been released. Expected result: change the version number to PHP5.4.0 -- Edit this bug report at http://bugs.php.net/bug.php?id=54308&edit=1
[PHP-BUG] Req #54308 [NEW]: You named the new version 5.3.6 and not 5.4.0
From: Operating system: Windows PHP version: 5.3.6 Package: *General Issues Bug Type: Feature/Change Request Bug description:You named the new version 5.3.6 and not 5.4.0 Description: You have released the new version of php as PHP5.3.6 from PHP5.3.5 To a windows user this means a small security update... When in fact you have rendered every single Apache sever useless if they upgrade. How can this kind of update be in the n.n.X class of number versioning when if should be AT LEAST in the n.X.n Range. Telling people in a small note that you no longer support APACHE ON WINDOWS is not acceptable when you only change the version number by 0.0.1 Telling people to use an unoffical build of Apache when previously a PHP X.X.-1 compatiable official Build was ok is not Acceptable. You really need to think about this very carefully, 5.4.0 should have been released. Expected result: change the version number to PHP5.4.0 -- Edit bug report at http://bugs.php.net/bug.php?id=54308&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=54308&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=54308&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=54308&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=54308&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=54308&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=54308&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=54308&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=54308&r=needscript Try newer version: http://bugs.php.net/fix.php?id=54308&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=54308&r=support Expected behavior: http://bugs.php.net/fix.php?id=54308&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=54308&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=54308&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=54308&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54308&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=54308&r=dst IIS Stability: http://bugs.php.net/fix.php?id=54308&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=54308&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=54308&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=54308&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=54308&r=mysqlcfg
Bug #54301 [Com]: phpinfo not working
Edit report at http://bugs.php.net/bug.php?id=54301&edit=1 ID: 54301 Comment by: wapinet at mail dot ru Reported by:wapinet at mail dot ru Summary:phpinfo not working Status: Bogus Type: Bug Package:Reproducible crash Operating System: Windows XP SP3 32 PHP Version:5.3.6 Block user comment: N Private report: N New Comment: a) I using thread safe version b) display_startup_errors = On Previous Comments: [2011-03-18 11:00:26] carsten_sttgt at gmx dot de @wapinet Can you tell me: a) You are using the thread safe or non thread safe version of PHP? b) What's the value of display_startup_errors? @aharvey Even PHP 5.3.6 can't load an eAccelerator build for 5.3.5, there should no core dump (Access violation). I guess this report is also a dup for bug #54200. [2011-03-18 09:49:53] wapinet at mail dot ru I apologize. The problem was that eAccelerator has been compiled for php version 5.3.5 Disable eAccelerator solved the problem. [2011-03-18 09:36:55] ahar...@php.net Is this happening under a Web server or using the CLI version of PHP? If it's a Web server, what are you getting in the Web server's error log? [2011-03-18 09:28:31] wapinet at mail dot ru OS [2011-03-18 09:27:44] wapinet at mail dot ru Description: this code crashes php. Test script: --- -- Edit this bug report at http://bugs.php.net/bug.php?id=54301&edit=1
Bug #54297 [Com]: different outputs of the same script
Edit report at http://bugs.php.net/bug.php?id=54297&edit=1 ID: 54297 Comment by: carsten_sttgt at gmx dot de Reported by:valentiny510 at yahoo dot es Summary:different outputs of the same script Status: Open Type: Bug Package:Filesystem function related Operating System: win xp sp 2 PHP Version:5.3.5 Block user comment: N Private report: N New Comment: That's just a curios behavior of "cmd.exe" if it's executed with forward slashs (just try it in the shell). Previous Comments: [2011-03-17 15:58:39] valentiny510 at yahoo dot es Description: I'm not sure it's really a bug but did not find any explanation or on the web or php page.. here I go .. I run the same script with different slashes and got 2 results Test script: --- $output = `C:\\WINDOWS\\system32\\cmd.exe /?`; echo "$output"; ... $output = `C:/WINDOWS/system32/cmd.exe /?`; echo "$output"; Expected result: CMD [/A | /U] [/Q] [/D] [/E:ON | /E:OFF] [/F:ON | /F:OFF] [/V:ON | /V:OFF] [[/S] [/C | /K] cadena] /C Ejecuta el comando especificado en cadena y luego finaliza /K Ejecuta el comando especificado en cadena pero sigue activo /S Modifica el tratamiento de cadena despu�s de /C o /K (consultar m�s abajo) /Q Deshabilita el eco /D Deshabilita le ejecuci�n de los comandos de AutoRun del registro (consultar m�s abajo) ...ETC Actual result: -- 1 example return: CMD [/A | /U] [/Q] [/D] [/E:ON | /E:OFF] [/F:ON | /F:OFF] [/V:ON | /V:OFF] [[/S] [/C | /K] cadena] /C Ejecuta el comando especificado en cadena y luego finaliza /K Ejecuta el comando especificado en cadena pero sigue activo /S Modifica el tratamiento de cadena despu�s de /C o /K (consultar m�s abajo) /Q Deshabilita el eco /D Deshabilita le ejecuci�n de los comandos de AutoRun del registro (consultar m�s abajo) ... 2 example return this: MKDIR [unidad:]ruta MD [unidad:]ruta Si las extensiones de comandos est�n habilitadas, MKDIR cambia as�: MKDIR crea cualquier directorio intermedio de la ruta de acceso siempre que sea necesario. Por ejemplo, si \a no existe: mkdir \a\b\c\d es lo mismo que: mkdir \a chdir \a mkdir b chdir b mkdir c chdir c mkdir d -- Edit this bug report at http://bugs.php.net/bug.php?id=54297&edit=1
[PHP-BUG] Req #54307 [NEW]: isset && is_numeric
From: Operating system: *nix & windows PHP version: 5.3.6 Package: Output Control Bug Type: Feature/Change Request Bug description:isset && is_numeric Description: I would kill for a way to do isset && check if the value is s specific data type such as numeric. My code is loaded with if(isset($a) && is_numeric($a)). It would be nice to do that in a single function (isset($a,[is_numeric])). Thank you taking the time to read my request. Expected result: $var = isset($a,[is_numeric]); $var = true,false Actual result: -- $var = isset($a,[is_numeric]); $var = true,false -- Edit bug report at http://bugs.php.net/bug.php?id=54307&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=54307&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=54307&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=54307&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=54307&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=54307&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=54307&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=54307&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=54307&r=needscript Try newer version: http://bugs.php.net/fix.php?id=54307&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=54307&r=support Expected behavior: http://bugs.php.net/fix.php?id=54307&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=54307&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=54307&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=54307&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54307&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=54307&r=dst IIS Stability: http://bugs.php.net/fix.php?id=54307&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=54307&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=54307&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=54307&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=54307&r=mysqlcfg
Bug #54306 [Com]: Parsing bug if a pattern looking like closing ASP tag appears in comment
Edit report at http://bugs.php.net/bug.php?id=54306&edit=1
ID: 54306
Comment by: carsten_sttgt at gmx dot de
Reported by:gingko at gingko dot homeip dot net
Summary:Parsing bug if a pattern looking like closing ASP
tag appears in comment
Status: Open
Type: Bug
Package:Scripting Engine problem
Operating System: Linux Debian 5 'Lenny'
PHP Version:5.2.17
Block user comment: N
Private report: N
New Comment:
That's the normal behavior. See:
http://de.php.net/manual/en/language.basic-syntax.comments.php
"%>" is returning to HTML mode. But at this point the opened "{" from
the if is not closed, and it's not closed till the end of the file.
That's the error message.
Previous Comments:
[2011-03-18 12:04:42] gingko at gingko dot homeip dot net
Description:
A parsing error occurs if a pattern looking like a closing ASP tag
appears inside a line comment (beginning by '//'), in a PHP engine
having 'asp_tags = On' in the 'php.ini' file.
If I remove the "//" comment, I have a big "Line 2" visible, and there
is no bug.
If I use a "/* */" style comment instead, there is no bug.
If I put quotes around "140%" in the "size" attribute, there is no bug.
If I set the "asp_tags" options to "Off", or if I remove it, there is no
bug.
Removing the 'if' condition around the comment results in another kind
of problem (no error, but part of HTML code visible).
I found this because I was trying to install the latest version of OCS
Inventory (http://www.ocsinventory-ng.org/), and I didn't understand why
I got a white page and a PHP parse error after the first step of
installation: I have 'asp_tags = On' in 'php.ini', and there is
effectively a commented out '%>' pattern in their code.
Looks like a little to Bug #4879 (more than 10 years old).
Test script:
---
Asp tag bug
Line 1
Line 2";
}
?>
Line 3
Expected result:
Two text lines in browsers's Window :
"Line 1"
"Line 3"
Actual result:
--
A white page, and the following error in Apache log :
PHP Parse error: syntax error, unexpected $end in
/var/www/[...]/asp_tag_bug.php on line 13
--
Edit this bug report at http://bugs.php.net/bug.php?id=54306&edit=1
Bug #52349 [Com]: "zend_mm_heap corrupted" error
Edit report at http://bugs.php.net/bug.php?id=52349&edit=1
ID: 52349
Comment by: jan-php at kantert dot net
Reported by:mbecc...@php.net
Summary:"zend_mm_heap corrupted" error
Status: Feedback
Type: Bug
Package:Reproducible crash
Operating System: FreeBSD 6.2
PHP Version:5.3.3RC3
Assigned To:dmitry
Block user comment: N
Private report: N
New Comment:
Same bug on Ubuntu 10.04 LTS x86_64
PHP 5.3.2-1ubuntu4.7 with Suhosin-Patch (cli) (built: Jan 12 2011
18:36:55)
Also happens only 30% of the time. Some times "just" segfaults without
error. Sometimes with this error. Happens when running the archive.sh in
piwik.
strace /usr/bin/php5 -q /home/XXX/misc/cron/../../index.php
We did an strace on the process and noticed some things. If it segfaults
(only then) there are a lot brk lines:
brk(0x805a000) = 0x805a000
brk(0x809a000) = 0x809a000
brk(0x80da000) = 0x80da000
brk(0x811a000) = 0x811a000
brk(0x815a000) = 0x815a000
brk(0x819a000) = 0x819a000
brk(0x81da000) = 0x81da000
brk(0x821a000) = 0x821a000
brk(0x825a000) = 0x825a000
brk(0x829a000) = 0x829a000
brk(0x82da000) = 0x82da000
brk(0x831a000) = 0x831a000
brk(0x835a000) = 0x835a000
brk(0x839a000) = 0x839a000
brk(0x83da000) = 0x83da000
At the end:
close(5)= 0
close(4)= 0
munmap(0x7fcae32e3000, 528384) = 0
write(3, "\1\0\0\0\1", 5) = 5
shutdown(3, 2 /* send and receive */) = 0
close(3)= 0
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++
Segmentation fault
Previous Comments:
[2010-07-16 08:23:30] dmi...@php.net
Sorry, but I need a script to reproduce and fix this the bug. In case
it's a big application, I can try to debug it on your system if you give
me SSH access, but it's more difficult.
[2010-07-15 18:19:34] mbecc...@php.net
Assigning to dmitry, per IRC chat.
[2010-07-15 18:12:40] mbecc...@php.net
Description:
A few things:
* It happens when running a specific "simpletest" integration test
* It doesn't always happen, roughly 33-50% of the times
* Never happened with 5.3.2, I got a report from Bamboo as soon as I
upgraded to 5.3.3RC3
Of course I can't get a simple reproduce script as the aforementioned
test does tons of things, but of course I can provide more information,
SSH access, or try anything I'm asked to.
Test script:
---
n/a
Expected result:
No failure
Actual result:
--
zend_mm_heap corrupted exit message, with the following backtrace
#0 0x0079f25b in zval_scan (pz=0x3b31970) at
/array1/compile/php-5.3.3RC3-fcgi/Zend/zend_gc.c:485
p = (Bucket *) 0x3661108
#1 0x0079f6b9 in gc_collect_cycles () at
/array1/compile/php-5.3.3RC3-fcgi/Zend/zend_gc.c:535
p = (zval_gc_info *) 0xee5ee0
q = (zval_gc_info *) 0x0
orig_free_list = (zval_gc_info *) 0x7fffc6e0
orig_next_to_free = (zval_gc_info *) 0x211ef18
count = 0
#2 0x0079fbd8 in gc_zval_possible_root (zv=0x33588b0) at
/array1/compile/php-5.3.3RC3-fcgi/Zend/zend_gc.c:166
newRoot = (gc_root_buffer *) 0x3627830
#3 0x007a4fde in zend_assign_to_object (result=0x211ef18,
object_ptr=0xe567a0, property_name=0x211ef60, value_op=0x211efb0,
Ts=0x113b228, opcode=136) at
/array1/compile/php-5.3.3RC3-fcgi/Zend/zend_execute.c:602
object = (zval *) 0x3632b70
free_value = {var = 0x113b701}
value = (zval *) 0x33588b0
retval = (zval **) 0x113b6e0
#4 0x007e2796 in ZEND_ASSIGN_OBJ_SPEC_UNUSED_CONST_HANDLER
(execute_data=0x113b190) at zend_vm_execute.h:17645
opline = (zend_op *) 0x0
#5 0x007a65f9 in execute (op_array=0x2119968) at
zend_vm_execute.h:107
ret = 0
execute_data = (zend_execute_data *) 0x113b190
nested = 1 '\001'
original_in_execution = 1 '\001'
#6 0x00777d94 in zend_call_function (fci=0x7fffc970,
fci_cache=0x0) at
/array1/compile/php-5.3.3RC3-fcgi/Zend/zend_execute_API.c:963
call_via_handler = 34934168
i = 18062328
original_return_value = (zval **) 0x1139bf8
calling_symbol_table = (HashTable *) 0x0
original_op
[PHP-BUG] Bug #54306 [NEW]: Parsing bug if a pattern looking like closing ASP tag appears in comment
From: Operating system: Linux Debian 5 'Lenny' PHP version: 5.2.17 Package: Scripting Engine problem Bug Type: Bug Bug description:Parsing bug if a pattern looking like closing ASP tag appears in comment Description: A parsing error occurs if a pattern looking like a closing ASP tag appears inside a line comment (beginning by '//'), in a PHP engine having 'asp_tags = On' in the 'php.ini' file. If I remove the "//" comment, I have a big "Line 2" visible, and there is no bug. If I use a "/* */" style comment instead, there is no bug. If I put quotes around "140%" in the "size" attribute, there is no bug. If I set the "asp_tags" options to "Off", or if I remove it, there is no bug. Removing the 'if' condition around the comment results in another kind of problem (no error, but part of HTML code visible). I found this because I was trying to install the latest version of OCS Inventory (http://www.ocsinventory-ng.org/), and I didn't understand why I got a white page and a PHP parse error after the first step of installation: I have 'asp_tags = On' in 'php.ini', and there is effectively a commented out '%>' pattern in their code. Looks like a little to Bug #4879 (more than 10 years old). Test script: --- Asp tag bug Line 1 Line 2"; } ?> Line 3 Expected result: Two text lines in browsers's Window : "Line 1" "Line 3" Actual result: -- A white page, and the following error in Apache log : PHP Parse error: syntax error, unexpected $end in /var/www/[...]/asp_tag_bug.php on line 13 -- Edit bug report at http://bugs.php.net/bug.php?id=54306&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=54306&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=54306&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=54306&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=54306&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=54306&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=54306&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=54306&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=54306&r=needscript Try newer version: http://bugs.php.net/fix.php?id=54306&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=54306&r=support Expected behavior: http://bugs.php.net/fix.php?id=54306&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=54306&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=54306&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=54306&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54306&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=54306&r=dst IIS Stability: http://bugs.php.net/fix.php?id=54306&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=54306&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=54306&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=54306&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=54306&r=mysqlcfg
Bug #54301 [Com]: phpinfo not working
Edit report at http://bugs.php.net/bug.php?id=54301&edit=1 ID: 54301 Comment by: carsten_sttgt at gmx dot de Reported by:wapinet at mail dot ru Summary:phpinfo not working Status: Bogus Type: Bug Package:Reproducible crash Operating System: Windows XP SP3 32 PHP Version:5.3.6 Block user comment: N Private report: N New Comment: @wapinet Can you tell me: a) You are using the thread safe or non thread safe version of PHP? b) What's the value of display_startup_errors? @aharvey Even PHP 5.3.6 can't load an eAccelerator build for 5.3.5, there should no core dump (Access violation). I guess this report is also a dup for bug #54200. Previous Comments: [2011-03-18 09:49:53] wapinet at mail dot ru I apologize. The problem was that eAccelerator has been compiled for php version 5.3.5 Disable eAccelerator solved the problem. [2011-03-18 09:36:55] ahar...@php.net Is this happening under a Web server or using the CLI version of PHP? If it's a Web server, what are you getting in the Web server's error log? [2011-03-18 09:28:31] wapinet at mail dot ru OS [2011-03-18 09:27:44] wapinet at mail dot ru Description: this code crashes php. Test script: --- -- Edit this bug report at http://bugs.php.net/bug.php?id=54301&edit=1
Bug #54301 [Csd->Bgs]: phpinfo not working
Edit report at http://bugs.php.net/bug.php?id=54301&edit=1 ID: 54301 Updated by: cataphr...@php.net Reported by:wapinet at mail dot ru Summary:phpinfo not working -Status: Closed +Status: Bogus Type: Bug Package:Reproducible crash Operating System: Windows XP SP3 32 PHP Version:5.3.6 Block user comment: N Private report: N Previous Comments: [2011-03-18 09:49:53] wapinet at mail dot ru I apologize. The problem was that eAccelerator has been compiled for php version 5.3.5 Disable eAccelerator solved the problem. [2011-03-18 09:36:55] ahar...@php.net Is this happening under a Web server or using the CLI version of PHP? If it's a Web server, what are you getting in the Web server's error log? [2011-03-18 09:28:31] wapinet at mail dot ru OS [2011-03-18 09:27:44] wapinet at mail dot ru Description: this code crashes php. Test script: --- -- Edit this bug report at http://bugs.php.net/bug.php?id=54301&edit=1
Bug #46685 [Dup]: SSL code should use select
Edit report at http://bugs.php.net/bug.php?id=46685&edit=1
ID: 46685
Updated by: cataphr...@php.net
Reported by:scott dot php at scottrix dot co dot uk
Summary:SSL code should use select
Status: Duplicate
Type: Bug
Package:OpenSSL related
Operating System: *
PHP Version:5.*, 6
Block user comment: N
Private report: N
New Comment:
This was fixed in 5.3.6 (see bug #53592)
Previous Comments:
[2011-03-18 10:41:17] cataphr...@php.net
This was fixed in 5.3.6 (see bug #53592)
[2010-07-21 22:53:31] voltara at gmail dot com
I have a patch against 5.3.2, but cannot post it because of the error
message "Please do not SPAM our bug system." It's the same code, but in
the form of a diff applies cleanly.
[2010-07-21 22:19:21] askalski at gmail dot com
I made a somewhat different patch. As far as I can tell, the
busy-waiting only happens during the call to php_openssl_enable_crypto,
where the socket is forced nonblocking to support the connect timeout.
My patch exposes the WANT_READ/WANT_WRITE error code through the return
value of handle_ssl_error(), and adds a select() to the SSL_connect
loop, using a deadline-based timeout calculation.
The diff is against 5.2.9, which is the version I need to fix. It seems
to apply cleanly against 5.2.13, but I haven't tested it. (I would need
to create a separate patch for 5.3, though.)
diff --git a/ext/openssl/xp_ssl.c b/ext/openssl/xp_ssl.c
index c31a505..e0a72b1 100644
--- a/ext/openssl/xp_ssl.c
+++ b/ext/openssl/xp_ssl.c
@@ -92,19 +92,25 @@ static int handle_ssl_error(php_stream *stream, int
nr_bytes, zend_bool is_init
char *ebuf = NULL, *wptr = NULL;
size_t ebuf_size = 0;
unsigned long code, ecode;
- int retry = 1;
+ int retry = 0;
switch(err) {
case SSL_ERROR_ZERO_RETURN:
/* SSL terminated (but socket may still be active) */
- retry = 0;
break;
case SSL_ERROR_WANT_READ:
case SSL_ERROR_WANT_WRITE:
/* re-negotiation, or perhaps the SSL layer needs more
* packets: retry in next iteration */
errno = EAGAIN;
- retry = is_init ? 1 : sslsock->s.is_blocked;
+ if (is_init || sslsock->s.is_blocked) {
+ /* Return the actual error code, rather than
just "1". The
SSL_connect
+* call is non-blocking for connect_timeout
support ("blocking with
timeout"
+* from the outside perspective.) The caller
needs to know whether
to
+* 'select' on read or write.
+*/
+ retry = err;
+ }
break;
case SSL_ERROR_SYSCALL:
if (ERR_peek_error() == 0) {
@@ -115,7 +121,6 @@ static int handle_ssl_error(php_stream *stream, int
nr_bytes, zend_bool is_init
}
SSL_set_shutdown(sslsock->ssl_handle,
SSL_SENT_SHUTDOWN|SSL_RECEIVED_SHUTDOWN);
stream->eof = 1;
- retry = 0;
} else {
char *estr =
php_socket_strerror(php_socket_errno(), NULL, 0);
@@ -123,7 +128,6 @@ static int handle_ssl_error(php_stream *stream, int
nr_bytes, zend_bool is_init
"SSL: %s", estr);
efree(estr);
- retry = 0;
}
break;
}
@@ -137,7 +141,6 @@ static int handle_ssl_error(php_stream *stream, int
nr_bytes, zend_bool is_init
switch (ERR_GET_REASON(ecode)) {
case SSL_R_NO_SHARED_CIPHER:
php_error_docref(NULL TSRMLS_CC,
E_WARNING,
"SSL_R_NO_SHARED_CIPHER: no suitable shared cipher could be used. This
could be because the server is missing an SSL certificate (local_cert
context option)");
- retry = 0;
break;
default:
@@ -175,7 +178,6 @@ static int handle_ssl_error(php_stream *stream, int
nr_bytes, zend_bool is_init
}
Bug #46685 [Asn->Dup]: SSL code should use select
Edit report at http://bugs.php.net/bug.php?id=46685&edit=1
ID: 46685
Updated by: cataphr...@php.net
Reported by:scott dot php at scottrix dot co dot uk
Summary:SSL code should use select
-Status: Assigned
+Status: Duplicate
Type: Bug
Package:OpenSSL related
Operating System: *
PHP Version:5.*, 6
-Assigned To:rasmus
+Assigned To:
Block user comment: N
Private report: N
New Comment:
This was fixed in 5.3.6 (see bug #53592)
Previous Comments:
[2010-07-21 22:53:31] voltara at gmail dot com
I have a patch against 5.3.2, but cannot post it because of the error
message "Please do not SPAM our bug system." It's the same code, but in
the form of a diff applies cleanly.
[2010-07-21 22:19:21] askalski at gmail dot com
I made a somewhat different patch. As far as I can tell, the
busy-waiting only happens during the call to php_openssl_enable_crypto,
where the socket is forced nonblocking to support the connect timeout.
My patch exposes the WANT_READ/WANT_WRITE error code through the return
value of handle_ssl_error(), and adds a select() to the SSL_connect
loop, using a deadline-based timeout calculation.
The diff is against 5.2.9, which is the version I need to fix. It seems
to apply cleanly against 5.2.13, but I haven't tested it. (I would need
to create a separate patch for 5.3, though.)
diff --git a/ext/openssl/xp_ssl.c b/ext/openssl/xp_ssl.c
index c31a505..e0a72b1 100644
--- a/ext/openssl/xp_ssl.c
+++ b/ext/openssl/xp_ssl.c
@@ -92,19 +92,25 @@ static int handle_ssl_error(php_stream *stream, int
nr_bytes, zend_bool is_init
char *ebuf = NULL, *wptr = NULL;
size_t ebuf_size = 0;
unsigned long code, ecode;
- int retry = 1;
+ int retry = 0;
switch(err) {
case SSL_ERROR_ZERO_RETURN:
/* SSL terminated (but socket may still be active) */
- retry = 0;
break;
case SSL_ERROR_WANT_READ:
case SSL_ERROR_WANT_WRITE:
/* re-negotiation, or perhaps the SSL layer needs more
* packets: retry in next iteration */
errno = EAGAIN;
- retry = is_init ? 1 : sslsock->s.is_blocked;
+ if (is_init || sslsock->s.is_blocked) {
+ /* Return the actual error code, rather than
just "1". The
SSL_connect
+* call is non-blocking for connect_timeout
support ("blocking with
timeout"
+* from the outside perspective.) The caller
needs to know whether
to
+* 'select' on read or write.
+*/
+ retry = err;
+ }
break;
case SSL_ERROR_SYSCALL:
if (ERR_peek_error() == 0) {
@@ -115,7 +121,6 @@ static int handle_ssl_error(php_stream *stream, int
nr_bytes, zend_bool is_init
}
SSL_set_shutdown(sslsock->ssl_handle,
SSL_SENT_SHUTDOWN|SSL_RECEIVED_SHUTDOWN);
stream->eof = 1;
- retry = 0;
} else {
char *estr =
php_socket_strerror(php_socket_errno(), NULL, 0);
@@ -123,7 +128,6 @@ static int handle_ssl_error(php_stream *stream, int
nr_bytes, zend_bool is_init
"SSL: %s", estr);
efree(estr);
- retry = 0;
}
break;
}
@@ -137,7 +141,6 @@ static int handle_ssl_error(php_stream *stream, int
nr_bytes, zend_bool is_init
switch (ERR_GET_REASON(ecode)) {
case SSL_R_NO_SHARED_CIPHER:
php_error_docref(NULL TSRMLS_CC,
E_WARNING,
"SSL_R_NO_SHARED_CIPHER: no suitable shared cipher could be used. This
could be because the server is missing an SSL certificate (local_cert
context option)");
- retry = 0;
break;
default:
@@ -175,7 +178,6 @@ static int handle_ssl_error(php_stream *stream, int
nr_bytes, zend_bool is_init
}
}
-
Bug #51307 [Asn->Fbk]: php.exe error on command line
Edit report at http://bugs.php.net/bug.php?id=51307&edit=1 ID: 51307 Updated by: paj...@php.net Reported by:joerg dot klein at ifsam dot lu Summary:php.exe error on command line -Status: Assigned +Status: Feedback Type: Bug Package:Reproducible crash Operating System: win32 only - Windows Server 2003 PHP Version:5.3.6 Assigned To:pajoye Block user comment: N Private report: N New Comment: Please provide a new backtrace then, if it crashes somewhere else. But I still have little clue about what's happening :) Previous Comments: [2011-03-18 10:11:41] joerg dot klein at ifsam dot lu I tested 5.3.6 VC9 today. The crash is still there, but it occurs in another file. I just removed one comment line and the file works without a problem! As I Stated in my last post, it is impossible to write a short reproduceable script. Even when it crashes on my site, it won't do on your site. [2010-08-18 14:41:40] paj...@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 , 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-08-18 14:27:30] joerg dot klein at ifsam dot lu I tried again with 5.3.3 final. The same script which produces the error in 5.3.2 works fine, but with some minimal changes (e.g. remove a comment line) the error occured again. A small reproduce script seems to be impossible. I also tried some different configurations. The result: adding just a comment line in the php.ini let the error disappear. [2010-08-08 16:22:01] paj...@php.net Please try using 5.3.3 final. If it still crashes, please provide a small (really small w/o external dependencies) reproduce script. [2010-06-21 13:44:56] joerg dot klein at ifsam dot lu The error occurs every time. I tried again to shorten the code for a reproducible script without success. I don't think it is an extension error. For example one way to run the script without error is to execute the file from a different directory: error: F:\daten\dir1234567890>"C:\Program Files\Apache Group\Apache\php-bin\php.exe" "f:\daten\dir1234567890\upload_pending.php" no error: F:\daten\dir>"C:\Program Files\Apache Group\Apache\php-bin\php.exe" "f:\daten\dir1234567890\upload_pending.php" Another possibility is to remove a bunch of lines or only change the path of a single require statement. After hours of research again I was not able to find some similarities. It's very strange. I have found bug #47766 where the reporter had pretty much the same problem. 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=51307 -- Edit this bug report at http://bugs.php.net/bug.php?id=51307&edit=1
Bug #51307 [Fbk->Asn]: php.exe error on command line
Edit report at http://bugs.php.net/bug.php?id=51307&edit=1 ID: 51307 User updated by:joerg dot klein at ifsam dot lu Reported by:joerg dot klein at ifsam dot lu Summary:php.exe error on command line -Status: Feedback +Status: Assigned Type: Bug Package:Reproducible crash Operating System: win32 only - Windows Server 2003 -PHP Version:5.3.3 +PHP Version:5.3.6 Assigned To:pajoye Block user comment: N Private report: N New Comment: I tested 5.3.6 VC9 today. The crash is still there, but it occurs in another file. I just removed one comment line and the file works without a problem! As I Stated in my last post, it is impossible to write a short reproduceable script. Even when it crashes on my site, it won't do on your site. Previous Comments: [2010-08-18 14:41:40] paj...@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 , 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-08-18 14:27:30] joerg dot klein at ifsam dot lu I tried again with 5.3.3 final. The same script which produces the error in 5.3.2 works fine, but with some minimal changes (e.g. remove a comment line) the error occured again. A small reproduce script seems to be impossible. I also tried some different configurations. The result: adding just a comment line in the php.ini let the error disappear. [2010-08-08 16:22:01] paj...@php.net Please try using 5.3.3 final. If it still crashes, please provide a small (really small w/o external dependencies) reproduce script. [2010-06-21 13:44:56] joerg dot klein at ifsam dot lu The error occurs every time. I tried again to shorten the code for a reproducible script without success. I don't think it is an extension error. For example one way to run the script without error is to execute the file from a different directory: error: F:\daten\dir1234567890>"C:\Program Files\Apache Group\Apache\php-bin\php.exe" "f:\daten\dir1234567890\upload_pending.php" no error: F:\daten\dir>"C:\Program Files\Apache Group\Apache\php-bin\php.exe" "f:\daten\dir1234567890\upload_pending.php" Another possibility is to remove a bunch of lines or only change the path of a single require statement. After hours of research again I was not able to find some similarities. It's very strange. I have found bug #47766 where the reporter had pretty much the same problem. [2010-06-21 10:14:25] paj...@php.net ok, disable GD and mysql and try again. Then enable mysql alone, try again, same with GD (without mysql). 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=51307 -- Edit this bug report at http://bugs.php.net/bug.php?id=51307&edit=1
Req #54302 [Opn->Bgs]: var_dump truncates values with no option to output all values
Edit report at http://bugs.php.net/bug.php?id=54302&edit=1
ID: 54302
Updated by: ahar...@php.net
Reported by:php at falconfour dot com
Summary:var_dump truncates values with no option to output
all values
-Status: Open
+Status: Bogus
Type: Feature/Change Request
Package:Variables related
Operating System: All
PHP Version:5.3.6
Block user comment: N
Private report: N
New Comment:
This is something XDebug does, not PHP. I'd suggest reporting it on the
XDebug issue tracker.
Previous Comments:
[2011-03-18 09:57:08] php at falconfour dot com
Description:
Simple as that... after var_dump() decides "enough is enough", it just
arbitrarily
cuts off the rest of the value with ellipses.
Seriously annoying when trying to debug a script (the only time I use
var_dump -
what other purpose does it serve in production?)... it produces a nice
HTML
output, but
Test script:
---
$test = array('foo');
$test['foo'] = array('bar');
$test['foo']['this'] = array('that');
$test['foo']['this']['where'] = array('there');
$test['foo']['this']['where']['your'] = array('face');
$test['foo']['this']['where']['your']['mom'] = array('fat');
var_dump($test);
Expected result:
array
0 => string 'foo' (length=3)
'foo' =>
array
0 => string 'bar' (length=3)
'this' =>
array
0 => string
'that' (length=4)
'where' =>
array
0 => string
'there' (length=5)
'your' =>
array
0 =>
string
'face' (length=4)
'mom' =>
array
0 =>
string
'fat' (length=3)
Actual result:
--
array
0 => string 'foo' (length=3)
'foo' =>
array
0 => string 'bar' (length=3)
'this' =>
array
0 => string
'that' (length=4)
'where' =>
array
...
--
Edit this bug report at http://bugs.php.net/bug.php?id=54302&edit=1
[PHP-BUG] Req #54302 [NEW]: var_dump truncates values with no option to output all values
From:
Operating system: All
PHP version: 5.3.6
Package: Variables related
Bug Type: Feature/Change Request
Bug description:var_dump truncates values with no option to output all values
Description:
Simple as that... after var_dump() decides "enough is enough", it just
arbitrarily
cuts off the rest of the value with ellipses.
Seriously annoying when trying to debug a script (the only time I use
var_dump -
what other purpose does it serve in production?)... it produces a nice HTML
output, but
Test script:
---
$test = array('foo');
$test['foo'] = array('bar');
$test['foo']['this'] = array('that');
$test['foo']['this']['where'] = array('there');
$test['foo']['this']['where']['your'] = array('face');
$test['foo']['this']['where']['your']['mom'] = array('fat');
var_dump($test);
Expected result:
array
0 => string 'foo' (length=3)
'foo' =>
array
0 => string 'bar' (length=3)
'this' =>
array
0 => string 'that' (length=4)
'where' =>
array
0 => string
'there' (length=5)
'your' =>
array
0 =>
string
'face' (length=4)
'mom' =>
array
0 =>
string
'fat' (length=3)
Actual result:
--
array
0 => string 'foo' (length=3)
'foo' =>
array
0 => string 'bar' (length=3)
'this' =>
array
0 => string 'that' (length=4)
'where' =>
array
...
--
Edit bug report at http://bugs.php.net/bug.php?id=54302&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=54302&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=54302&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=54302&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=54302&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=54302&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=54302&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=54302&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=54302&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=54302&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=54302&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=54302&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=54302&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=54302&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=54302&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54302&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=54302&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=54302&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=54302&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=54302&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=54302&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=54302&r=mysqlcfg
Bug #54301 [Fbk->Csd]: phpinfo not working
Edit report at http://bugs.php.net/bug.php?id=54301&edit=1 ID: 54301 User updated by:wapinet at mail dot ru Reported by:wapinet at mail dot ru Summary:phpinfo not working -Status: Feedback +Status: Closed Type: Bug Package:Reproducible crash Operating System: Windows XP SP3 32 PHP Version:5.3.6 Block user comment: N Private report: N New Comment: I apologize. The problem was that eAccelerator has been compiled for php version 5.3.5 Disable eAccelerator solved the problem. Previous Comments: [2011-03-18 09:36:55] ahar...@php.net Is this happening under a Web server or using the CLI version of PHP? If it's a Web server, what are you getting in the Web server's error log? [2011-03-18 09:28:31] wapinet at mail dot ru OS [2011-03-18 09:27:44] wapinet at mail dot ru Description: this code crashes php. Test script: --- -- Edit this bug report at http://bugs.php.net/bug.php?id=54301&edit=1
Bug #54301 [Opn->Fbk]: phpinfo not working
Edit report at http://bugs.php.net/bug.php?id=54301&edit=1 ID: 54301 Updated by: ahar...@php.net Reported by:wapinet at mail dot ru Summary:phpinfo not working -Status: Open +Status: Feedback Type: Bug -Package:PHP options/info functions +Package:Reproducible crash Operating System: Windows XP SP3 32 PHP Version:5.3.6 Block user comment: N Private report: N New Comment: Is this happening under a Web server or using the CLI version of PHP? If it's a Web server, what are you getting in the Web server's error log? Previous Comments: [2011-03-18 09:28:31] wapinet at mail dot ru OS [2011-03-18 09:27:44] wapinet at mail dot ru Description: this code crashes php. Test script: --- -- Edit this bug report at http://bugs.php.net/bug.php?id=54301&edit=1
Bug #54301 [Opn]: phpinfo not working
Edit report at http://bugs.php.net/bug.php?id=54301&edit=1 ID: 54301 User updated by:wapinet at mail dot ru Reported by:wapinet at mail dot ru Summary:phpinfo not working Status: Open Type: Bug Package:PHP options/info functions -Operating System: +Operating System: Windows XP SP3 32 PHP Version:5.3.6 Block user comment: N Private report: N New Comment: OS Previous Comments: [2011-03-18 09:27:44] wapinet at mail dot ru Description: this code crashes php. Test script: --- -- Edit this bug report at http://bugs.php.net/bug.php?id=54301&edit=1
[PHP-BUG] Bug #54301 [NEW]: phpinfo not working
From: Operating system: PHP version: 5.3.6 Package: PHP options/info functions Bug Type: Bug Bug description:phpinfo not working Description: this code crashes php. Test script: --- -- Edit bug report at http://bugs.php.net/bug.php?id=54301&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=54301&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=54301&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=54301&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=54301&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=54301&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=54301&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=54301&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=54301&r=needscript Try newer version: http://bugs.php.net/fix.php?id=54301&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=54301&r=support Expected behavior: http://bugs.php.net/fix.php?id=54301&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=54301&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=54301&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=54301&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54301&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=54301&r=dst IIS Stability: http://bugs.php.net/fix.php?id=54301&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=54301&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=54301&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=54301&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=54301&r=mysqlcfg
