[PHP-BUG] Bug #65556 [NEW]: Wrong error thrown
From: ante dot drnasin at wirecard dot com
Operating system: Win7 Pro x64
PHP version: 5.5.3
Package: *General Issues
Bug Type: Bug
Bug description:Wrong error thrown
Description:
Just a small issue.
When (ab)using return empty(null);
you get T_PAAMAYIM_NEKUDOTAYIM error (unexpected ) expecting ::) which
is not true...
is it per design or a bug?
Test script:
---
function test() {
return empty(null);
}
Expected result:
Null is not a valid value for empty
Actual result:
--
T_PAAMAYIM_NEKUDOTAYIM error
--
Edit bug report at https://bugs.php.net/bug.php?id=65556edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=65556r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=65556r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=65556r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=65556r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=65556r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=65556r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=65556r=needscript
Try newer version: https://bugs.php.net/fix.php?id=65556r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=65556r=support
Expected behavior: https://bugs.php.net/fix.php?id=65556r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=65556r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=65556r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=65556r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=65556r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=65556r=dst
IIS Stability: https://bugs.php.net/fix.php?id=65556r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=65556r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=65556r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=65556r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=65556r=mysqlcfg
Bug #65556 [Opn-Nab]: Wrong error thrown
Edit report at https://bugs.php.net/bug.php?id=65556edit=1
ID: 65556
Updated by: johan...@php.net
Reported by:ante dot drnasin at wirecard dot com
Summary:Wrong error thrown
-Status: Open
+Status: Not a bug
Type: Bug
Package:*General Issues
Operating System: Win7 Pro x64
PHP Version:5.5.3
Block user comment: N
Private report: N
New Comment:
The parser looks for something starting with a $ sign (to check for an
variable, property, array offset etc.) or some literal followed by :: in order
to check for static properties, it doesn't check whether the literal is a valid
class name at that stage and null is no conflicting parser token.
Previous Comments:
[2013-08-26 08:18:52] ante dot drnasin at wirecard dot com
Description:
Just a small issue.
When (ab)using return empty(null);
you get T_PAAMAYIM_NEKUDOTAYIM error (unexpected ) expecting ::) which is
not true...
is it per design or a bug?
Test script:
---
function test() {
return empty(null);
}
Expected result:
Null is not a valid value for empty
Actual result:
--
T_PAAMAYIM_NEKUDOTAYIM error
--
Edit this bug report at https://bugs.php.net/bug.php?id=65556edit=1
Bug #65556 [Nab]: Wrong error thrown
Edit report at https://bugs.php.net/bug.php?id=65556edit=1
ID: 65556
User updated by:ante dot drnasin at wirecard dot com
Reported by:ante dot drnasin at wirecard dot com
Summary:Wrong error thrown
Status: Not a bug
Type: Bug
Package:*General Issues
Operating System: Win7 Pro x64
PHP Version:5.5.3
Block user comment: N
Private report: N
New Comment:
ok thank you for the clarification Johannes and I appologize for false bug
report...
Previous Comments:
[2013-08-26 08:45:58] johan...@php.net
The parser looks for something starting with a $ sign (to check for an
variable, property, array offset etc.) or some literal followed by :: in order
to check for static properties, it doesn't check whether the literal is a valid
class name at that stage and null is no conflicting parser token.
[2013-08-26 08:18:52] ante dot drnasin at wirecard dot com
Description:
Just a small issue.
When (ab)using return empty(null);
you get T_PAAMAYIM_NEKUDOTAYIM error (unexpected ) expecting ::) which is
not true...
is it per design or a bug?
Test script:
---
function test() {
return empty(null);
}
Expected result:
Null is not a valid value for empty
Actual result:
--
T_PAAMAYIM_NEKUDOTAYIM error
--
Edit this bug report at https://bugs.php.net/bug.php?id=65556edit=1
[PHP-BUG] Bug #65557 [NEW]: Constants from Core are not defined with inline scripts
From: Laurent dot Lyaudet at gmail dot com
Operating system: Debian Linux
PHP version: 5.4.19
Package: CGI/CLI related
Bug Type: Bug
Bug description:Constants from Core are not defined with inline scripts
Description:
Hi,
I found a bug affecting PHP 5.3.3-7+squeeze15 and PHP 5.4.4-14+deb7u3 (cli)
(latest debian package for current stable).
The constant STDERR is not defined for inline scripts.
I mean it isn't defined when you type #php and then you type ?php
myscriptcontent ?, Ctrl+D.
But it works if you use php -r 'myscriptcontent'.
I join test script below.
I didn't tested it but I assume it is not specifically STDERR which is
impacted.
It is probably the same for all Core constants.
Best regards,
Laurent Lyaudet
Test script:
---
php -r 'fwrite(STDERR, stderr\n);'
works but
root@wheezyDEVLaurent:~# php
?php
fwrite(STDERR, stderr\n);
?
doesn't.
Expected result:
stderr
Actual result:
--
PHP Notice: Use of undefined constant STDERR - assumed 'STDERR' in - on
line 3
PHP Stack trace:
PHP 1. {main}() -:0
Notice: Use of undefined constant STDERR - assumed 'STDERR' in - on line 3
Call Stack:
10.9477 215280 1. {main}() -:0
PHP Warning: fwrite() expects parameter 1 to be resource, string given in
- on line 3
PHP Stack trace:
PHP 1. {main}() -:0
PHP 2. fwrite() -:3
Warning: fwrite() expects parameter 1 to be resource, string given in - on
line 3
Call Stack:
10.9477 215280 1. {main}() -:0
10.9479 216048 2. fwrite() -:3
--
Edit bug report at https://bugs.php.net/bug.php?id=65557edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=65557r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=65557r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=65557r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=65557r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=65557r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=65557r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=65557r=needscript
Try newer version: https://bugs.php.net/fix.php?id=65557r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=65557r=support
Expected behavior: https://bugs.php.net/fix.php?id=65557r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=65557r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=65557r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=65557r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=65557r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=65557r=dst
IIS Stability: https://bugs.php.net/fix.php?id=65557r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=65557r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=65557r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=65557r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=65557r=mysqlcfg
Bug #65557 [Com]: Constants from Core are not defined with inline scripts
Edit report at https://bugs.php.net/bug.php?id=65557edit=1
ID: 65557
Comment by: Laurent dot Lyaudet at gmail dot com
Reported by:Laurent dot Lyaudet at gmail dot com
Summary:Constants from Core are not defined with inline
scripts
Status: Open
Type: Bug
Package:CGI/CLI related
Operating System: Debian Linux
PHP Version:5.4.19
Block user comment: N
Private report: N
New Comment:
Additionally I noted that
#echo '?php fwrite(STDERR, stderr\n); ?' test
#php test
works.
Is is somehow surprising since I would have thought that the only difference
between php test and php ?php fwrite(STDERR, stderr\n); ? was the input
stream for php code.
Previous Comments:
[2013-08-26 08:49:43] Laurent dot Lyaudet at gmail dot com
Description:
Hi,
I found a bug affecting PHP 5.3.3-7+squeeze15 and PHP 5.4.4-14+deb7u3 (cli)
(latest debian package for current stable).
The constant STDERR is not defined for inline scripts.
I mean it isn't defined when you type #php and then you type ?php
myscriptcontent ?, Ctrl+D.
But it works if you use php -r 'myscriptcontent'.
I join test script below.
I didn't tested it but I assume it is not specifically STDERR which is impacted.
It is probably the same for all Core constants.
Best regards,
Laurent Lyaudet
Test script:
---
php -r 'fwrite(STDERR, stderr\n);'
works but
root@wheezyDEVLaurent:~# php
?php
fwrite(STDERR, stderr\n);
?
doesn't.
Expected result:
stderr
Actual result:
--
PHP Notice: Use of undefined constant STDERR - assumed 'STDERR' in - on line 3
PHP Stack trace:
PHP 1. {main}() -:0
Notice: Use of undefined constant STDERR - assumed 'STDERR' in - on line 3
Call Stack:
10.9477 215280 1. {main}() -:0
PHP Warning: fwrite() expects parameter 1 to be resource, string given in - on
line 3
PHP Stack trace:
PHP 1. {main}() -:0
PHP 2. fwrite() -:3
Warning: fwrite() expects parameter 1 to be resource, string given in - on line
3
Call Stack:
10.9477 215280 1. {main}() -:0
10.9479 216048 2. fwrite() -:3
--
Edit this bug report at https://bugs.php.net/bug.php?id=65557edit=1
Bug #65557 [Opn-Ver]: Constants from Core are not defined with inline scripts
Edit report at https://bugs.php.net/bug.php?id=65557edit=1
ID: 65557
Updated by: yohg...@php.net
Reported by:Laurent dot Lyaudet at gmail dot com
Summary:Constants from Core are not defined with inline
scripts
-Status: Open
+Status: Verified
Type: Bug
Package:CGI/CLI related
-Operating System: Debian Linux
+Operating System: Linux
-PHP Version:5.4.19
+PHP Version:5.4 and later
Block user comment: N
Private report: N
New Comment:
[yohgaki@dev PHP-5.5]$ echo '?php fwrite(STDERR, stderr\n); ' |
./sapi/cli/php
Warning: fwrite() expects parameter 1 to be resource, string given in - on line
1
Previous Comments:
[2013-08-26 09:06:21] Laurent dot Lyaudet at gmail dot com
Additionally I noted that
#echo '?php fwrite(STDERR, stderr\n); ?' test
#php test
works.
Is is somehow surprising since I would have thought that the only difference
between php test and php ?php fwrite(STDERR, stderr\n); ? was the input
stream for php code.
[2013-08-26 08:49:43] Laurent dot Lyaudet at gmail dot com
Description:
Hi,
I found a bug affecting PHP 5.3.3-7+squeeze15 and PHP 5.4.4-14+deb7u3 (cli)
(latest debian package for current stable).
The constant STDERR is not defined for inline scripts.
I mean it isn't defined when you type #php and then you type ?php
myscriptcontent ?, Ctrl+D.
But it works if you use php -r 'myscriptcontent'.
I join test script below.
I didn't tested it but I assume it is not specifically STDERR which is impacted.
It is probably the same for all Core constants.
Best regards,
Laurent Lyaudet
Test script:
---
php -r 'fwrite(STDERR, stderr\n);'
works but
root@wheezyDEVLaurent:~# php
?php
fwrite(STDERR, stderr\n);
?
doesn't.
Expected result:
stderr
Actual result:
--
PHP Notice: Use of undefined constant STDERR - assumed 'STDERR' in - on line 3
PHP Stack trace:
PHP 1. {main}() -:0
Notice: Use of undefined constant STDERR - assumed 'STDERR' in - on line 3
Call Stack:
10.9477 215280 1. {main}() -:0
PHP Warning: fwrite() expects parameter 1 to be resource, string given in - on
line 3
PHP Stack trace:
PHP 1. {main}() -:0
PHP 2. fwrite() -:3
Warning: fwrite() expects parameter 1 to be resource, string given in - on line
3
Call Stack:
10.9477 215280 1. {main}() -:0
10.9479 216048 2. fwrite() -:3
--
Edit this bug report at https://bugs.php.net/bug.php?id=65557edit=1
Bug #55204 [Com]: ICONV iconv_strlen() causing apache to crash/segmentation fault(11)
Edit report at https://bugs.php.net/bug.php?id=55204edit=1
ID: 55204
Comment by: skrueger at europe dot com
Reported by:michel02 at hotmail dot com
Summary:ICONV iconv_strlen() causing apache to
crash/segmentation fault(11)
Status: No Feedback
Type: Bug
Package:ICONV related
Operating System: Solaris 10
PHP Version:5.3.6
Block user comment: N
Private report: N
New Comment:
Ah this is so stupid, I was missing the
pkg://solaris/system/library/iconv/unicode-core package...
To check if you're missing it too (only works on Solaris 11.1):
$ iconv -l
Failed to open the directory /usr/lib/iconv/geniconvtbl/binarytables/.
When you get that, you need to install the unicode-core pkg and everything
(including php's iconv_strlen) will be fine after that.
Previous Comments:
[2013-08-25 22:04:15] skrueger at europe dot com
I see the same error on Solaris 11.1:
root@www:/tmp# /usr/php/5.3/bin/php -v
PHP 5.3.14 (cli) (built: Aug 30 2012 01:52:21)
root@www:/tmp# /usr/php/5.3/bin/php /tmp/iconv_strlen.php
PHP Notice: iconv_strlen(): Unknown error (22) in /tmp/iconv_strlen.php on
line
5
PHP Stack trace:
PHP 1. {main}() /tmp/iconv_strlen.php:0
PHP 2. iconv_strlen() /tmp/iconv_strlen.php:5
Notice: iconv_strlen(): Unknown error (22) in /tmp/iconv_strlen.php on line 5
Call Stack:
0.0002 315392 1. {main}() /tmp/iconv_strlen.php:0
0.0002 315568 2. iconv_strlen() /tmp/iconv_strlen.php:5
And also on PHP 5.5.3:
root@www:/tmp# /opt/php5/bin/php -v
PHP 5.5.3 (cli) (built: Aug 25 2013 19:41:00)
root@www:/tmp# /opt/php5/bin/php /tmp/iconv_strlen.php
PHP Notice: iconv_strlen(): Unknown error (22) in /tmp/iconv_strlen.php on
line
5
Notice: iconv_strlen(): Unknown error (22) in /tmp/iconv_strlen.php on line 5
[2013-02-18 00:34:56] php-bugs at lists dot php dot net
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to Open. Thank you.
[2012-06-21 14:44:52] gabriel dot rota at gmail dot com
this LD_PRELOAD fixed my issue
export LD_PRELOAD=/usr/local/lib/preloadable_libiconv.so
[2011-07-15 17:42:10] fel...@php.net
Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php for *NIX and
http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32
Once you have generated a backtrace, please submit it to this bug
report and change the status back to Open. Thank you for helping
us make PHP better.
[2011-07-14 03:48:15] michel02 at hotmail dot com
Description:
After successfully compiling PHP 5.3.6 on (patched) Solaris 10 with all
required GNU packages from sunfreeware.com, iconv_strlen($var) causes Apache2
extension to crash. Only error apache shows is [notice] child pid 34232 exit
signal Segmentation fault (11). No output to browser was generated.
configure command for compiling PHP was:
./configure --verbose --with-gnu-ld --prefix=/usr/local/php --without-gd
--disable-pdo --without-pdo-sqlite --without-sqlite
--with-config-file-path=/usr/local/php/lib
--with-oci8=/export/home/oracle/product/11.1.0/pweb
--with-apxs2=/usr/local/apache2/bin/apxs --enable-bcmath
--with-openssl=/usr/local/ssl --with-ldap=/usr/local --with-bz2
--enable-calendar --enable-ctype --with-curl=/usr/local/curl
--with-curlwrappers --enable-exif --enable-ftp --with-zlib=/usr/local
--with-gettext --with-gmp --enable-hash --enable-json --enable-mbstring
--enable-mbregex --enable-pcntl --with-libedit=no --with-readline
--enable-session --enable-shmop --enable-simplexml --enable-soap
--enable-sockets --enable-sysvmsg --enable-sysvsem --enable-sysvshm
--enable-tokenizer --enable-wddx --with-libexpat-dir=/usr/local --enable-xml
--enable-xmlreader --with-xmlrpc --enable-xmlwriter --with-xsl --enable-zip
--disable-static --enable-pcntl --enable-magic-quotes
--with-pcre-dir=/usr/local --with-pcre-regex --
with-pear
Test script:
---
print iconv_strlen(test,UTF-8);
Expected result:
generate some output
Actual result:
--
apache thread killed, error [notice] child pid 34232 exit signal Segmentation
fault (11) in errorlog and no output for browser.
Bug #61577 [Com]: php5ts.dll crashes when specific extensions are loaded
Edit report at https://bugs.php.net/bug.php?id=61577edit=1 ID: 61577 Comment by: pirabid at gmail dot com Reported by:uniflare at gmail dot com Summary:php5ts.dll crashes when specific extensions are loaded Status: Assigned Type: Bug Package:Reproducible crash Operating System: Windows7 Ultimate x86 PHP Version:5.4.0 Assigned To:mattficken Block user comment: N Private report: N New Comment: I have the same problem on windows 7 (64-bit) using PHP 5.4.0 Apache crashes if I use the following two extension parallely: extension=php_curl.dll extension=php_gd2.dll If I comment any one of these, Apache works okay. Please fix this. Previous Comments: [2012-05-04 14:56:50] zane at zanezane dot net For me, problem is fixed since 5.4.1. I tried seconds ago with 5.4.2 and is still ok. [2012-05-04 12:44:07] george dot gruber at emailourfamily dot com A new note to this issue. I have updated PHP to 5.4.1 and Apache from ApacheLounge to the 32-bit, openSSL 0.9.8v version and the problem still exists. I was hoping the PHP 5.4.1 would resolve the issue. [2012-04-17 19:57:38] george dot gruber at emailourfamily dot com I experiencing the same crash on two different Windows 7 Ultimate x64 machines. Apache and PHP come up and run fine and occasionally I get the message in error.log: [mpm_winnt:notice] [pid 2200:tid 512] AH00428: Parent: child process exited with status 255 -- Restarting. At nearly the same time there are three entries in to the application event log indicating the same error reported in bug: Faulting application name: httpd.exe, version: 2.4.2.0, time stamp: 0x4f7ed6c4 Faulting module name: php5ts.dll, version: 5.4.0.0, time stamp: 0x4f4e7f05 Exception code: 0xc005 Fault offset: 0x0004c563 Faulting process id: 0x3870 Faulting application start time: 0x01cd1cb269ad9f3a Faulting application path: C:\Apache24\bin\httpd.exe Faulting module path: C:\PHP5\php5ts.dll I have removed as many extensions as possible that still allows the system to run properly. I had even gone as far as to remove php_mbstring and it didn't change the results. Having removed some of the other extensions seem to reduce it but this is not definitive. This is the list of what I had removed just for reference: php_gettext php_ldap php_pdo_mysql php_pgsql php_soap php_sockets php_tidy php_xsl I had verified that nothing required them although if that was the case you would think that they wouldn't be doing anything to cause an error. Interestingly enough as far as I can tell the pages are rendered properly and that the only indication of any problem is the error.log (Apache) and Windows events. I am running PHP 5.4.0 and Apache 2.4.2 (ApacheLounge including php5apache2_4.dll) and MySQL 5.6.5m8 on Windows 7 Ultimate x64 with SP1. I have my own log file pertaining to processing of the pages and some functions (MySQL requests are always captured) and I am trying to correlate the crash to a particular event but so far nothing specific. It is somewhat disconcerting and I do not know if there are any side issues being created by this occurring. If anyone would like additional information please let me know and I would be happy to submit it. [2012-04-15 12:34:16] paj...@php.net no, it does not. [2012-04-15 12:29:17] o6asan at yahoo dot de I have still the issue. I feel that the number of crushes is increasing on my server. I compared PHP5.4.0 to PHP5.4.0RC8. I found A difference in the configure command options. Like this. 5.4.0 configure.js --enable-snapshot-build --disable-isapi --enable-debug-pack --disable-nsapi 5.4.0RC8 configure.js --enable-snapshot-build --disable-isapi --enable-debug-pack --disable-isapi Does it have any effects on this issue? 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 https://bugs.php.net/bug.php?id=61577 -- Edit this bug report at https://bugs.php.net/bug.php?id=61577edit=1
Bug #65530 [Opn-Ver]: Anonymous functions not callable directly when part of a static class
Edit report at https://bugs.php.net/bug.php?id=65530edit=1
ID: 65530
Updated by: yohg...@php.net
Reported by:matt dot minix at gmail dot com
Summary:Anonymous functions not callable directly when part
of a static class
-Status: Open
+Status: Verified
Type: Bug
-Package:Variables related
+Package:Scripting Engine problem
Operating System: Linux
-PHP Version:5.4.18
+PHP Version:5.4 and later
Block user comment: N
Private report: N
New Comment:
PHP behaves as reported. It does not work 5.5 also.
[yohgaki@dev PHP-5.5]$ ./sapi/cli/php
?php
class a {
public static $b;
}
a::$b = static function($c) { echo $c; };
a::$b('Test')
?
Fatal error: Function name must be a string in - on line 7
Previous Comments:
[2013-08-22 21:19:27] matt dot minix at gmail dot com
Description:
An anonymous function doesn't seem like it can be called directly when in a
static
class.
Test script:
---
class a {
public static $b;
}
a::$b = static function($c) { echo $c; };
a::$b('Test');
I am however able to do
class a {
public static $b;
}
a::$b = static function($c) { echo $c; };
$Temp = a::$b;
$Temp('Test');
Expected result:
Test
Actual result:
--
Fatal error: Function name must be a string
--
Edit this bug report at https://bugs.php.net/bug.php?id=65530edit=1
Bug #61577 [Asn-Fbk]: php5ts.dll crashes when specific extensions are loaded
Edit report at https://bugs.php.net/bug.php?id=61577edit=1 ID: 61577 Updated by: paj...@php.net Reported by:uniflare at gmail dot com Summary:php5ts.dll crashes when specific extensions are loaded -Status: Assigned +Status: Feedback Type: Bug Package:Reproducible crash Operating System: Windows7 Ultimate x86 PHP Version:5.4.0 Assigned To:mattficken Block user comment: N Private report: N New Comment: try under CLI and see what is the actual error is, I very much doubt there is actually a crash but missing DLLs in the path. Previous Comments: [2013-08-26 09:34:03] pirabid at gmail dot com I have the same problem on windows 7 (64-bit) using PHP 5.4.0 Apache crashes if I use the following two extension parallely: extension=php_curl.dll extension=php_gd2.dll If I comment any one of these, Apache works okay. Please fix this. [2012-05-04 14:56:50] zane at zanezane dot net For me, problem is fixed since 5.4.1. I tried seconds ago with 5.4.2 and is still ok. [2012-05-04 12:44:07] george dot gruber at emailourfamily dot com A new note to this issue. I have updated PHP to 5.4.1 and Apache from ApacheLounge to the 32-bit, openSSL 0.9.8v version and the problem still exists. I was hoping the PHP 5.4.1 would resolve the issue. [2012-04-17 19:57:38] george dot gruber at emailourfamily dot com I experiencing the same crash on two different Windows 7 Ultimate x64 machines. Apache and PHP come up and run fine and occasionally I get the message in error.log: [mpm_winnt:notice] [pid 2200:tid 512] AH00428: Parent: child process exited with status 255 -- Restarting. At nearly the same time there are three entries in to the application event log indicating the same error reported in bug: Faulting application name: httpd.exe, version: 2.4.2.0, time stamp: 0x4f7ed6c4 Faulting module name: php5ts.dll, version: 5.4.0.0, time stamp: 0x4f4e7f05 Exception code: 0xc005 Fault offset: 0x0004c563 Faulting process id: 0x3870 Faulting application start time: 0x01cd1cb269ad9f3a Faulting application path: C:\Apache24\bin\httpd.exe Faulting module path: C:\PHP5\php5ts.dll I have removed as many extensions as possible that still allows the system to run properly. I had even gone as far as to remove php_mbstring and it didn't change the results. Having removed some of the other extensions seem to reduce it but this is not definitive. This is the list of what I had removed just for reference: php_gettext php_ldap php_pdo_mysql php_pgsql php_soap php_sockets php_tidy php_xsl I had verified that nothing required them although if that was the case you would think that they wouldn't be doing anything to cause an error. Interestingly enough as far as I can tell the pages are rendered properly and that the only indication of any problem is the error.log (Apache) and Windows events. I am running PHP 5.4.0 and Apache 2.4.2 (ApacheLounge including php5apache2_4.dll) and MySQL 5.6.5m8 on Windows 7 Ultimate x64 with SP1. I have my own log file pertaining to processing of the pages and some functions (MySQL requests are always captured) and I am trying to correlate the crash to a particular event but so far nothing specific. It is somewhat disconcerting and I do not know if there are any side issues being created by this occurring. If anyone would like additional information please let me know and I would be happy to submit it. [2012-04-15 12:34:16] paj...@php.net no, it does not. 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 https://bugs.php.net/bug.php?id=61577 -- Edit this bug report at https://bugs.php.net/bug.php?id=61577edit=1
Bug #65557 [Ver]: Constants from Core are not defined with inline scripts
Edit report at https://bugs.php.net/bug.php?id=65557edit=1
ID: 65557
Updated by: johan...@php.net
Reported by:Laurent dot Lyaudet at gmail dot com
Summary:Constants from Core are not defined with inline
scripts
Status: Verified
Type: Bug
Package:CGI/CLI related
Operating System: Linux
PHP Version:5.4 and later
Block user comment: N
Private report: N
New Comment:
This is done by purpose: We can't easily provide STDIN as that's bound to the
script input and we either provide all three (STDIN, STDOUT, STERR) or none.
Maybe this can be improved to rebind STDIN (and then providing all three) after
the full script has been passed.
Maybe this trinity can be relaxed.
This requires some more analysis of the consequences.
Previous Comments:
[2013-08-26 09:09:30] yohg...@php.net
[yohgaki@dev PHP-5.5]$ echo '?php fwrite(STDERR, stderr\n); ' |
./sapi/cli/php
Warning: fwrite() expects parameter 1 to be resource, string given in - on line
1
[2013-08-26 09:06:21] Laurent dot Lyaudet at gmail dot com
Additionally I noted that
#echo '?php fwrite(STDERR, stderr\n); ?' test
#php test
works.
Is is somehow surprising since I would have thought that the only difference
between php test and php ?php fwrite(STDERR, stderr\n); ? was the input
stream for php code.
[2013-08-26 08:49:43] Laurent dot Lyaudet at gmail dot com
Description:
Hi,
I found a bug affecting PHP 5.3.3-7+squeeze15 and PHP 5.4.4-14+deb7u3 (cli)
(latest debian package for current stable).
The constant STDERR is not defined for inline scripts.
I mean it isn't defined when you type #php and then you type ?php
myscriptcontent ?, Ctrl+D.
But it works if you use php -r 'myscriptcontent'.
I join test script below.
I didn't tested it but I assume it is not specifically STDERR which is impacted.
It is probably the same for all Core constants.
Best regards,
Laurent Lyaudet
Test script:
---
php -r 'fwrite(STDERR, stderr\n);'
works but
root@wheezyDEVLaurent:~# php
?php
fwrite(STDERR, stderr\n);
?
doesn't.
Expected result:
stderr
Actual result:
--
PHP Notice: Use of undefined constant STDERR - assumed 'STDERR' in - on line 3
PHP Stack trace:
PHP 1. {main}() -:0
Notice: Use of undefined constant STDERR - assumed 'STDERR' in - on line 3
Call Stack:
10.9477 215280 1. {main}() -:0
PHP Warning: fwrite() expects parameter 1 to be resource, string given in - on
line 3
PHP Stack trace:
PHP 1. {main}() -:0
PHP 2. fwrite() -:3
Warning: fwrite() expects parameter 1 to be resource, string given in - on line
3
Call Stack:
10.9477 215280 1. {main}() -:0
10.9479 216048 2. fwrite() -:3
--
Edit this bug report at https://bugs.php.net/bug.php?id=65557edit=1
[PHP-BUG] Bug #65559 [NEW]: Opcache: cache not cleared if changes occur while running
From: zoeslam at gmail dot com Operating system: Ubuntu PHP version: 5.5.3 Package: opcache Bug Type: Bug Bug description:Opcache: cache not cleared if changes occur while running Description: The new Zend OPcache doesn't clear the cache if a file is changed on the fly. Instead the test script works well with opcache turned off (opcache.enable=0). Test script: --- ?php $file = __DIR__.'/file.txt'; file_put_contents($file, '?php return 1;'); $var = include $file; file_put_contents($file, '?php return 2;'); $var = include $file; var_dump($var); Expected result: int(2) Actual result: -- int(1) -- Edit bug report at https://bugs.php.net/bug.php?id=65559edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=65559r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=65559r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=65559r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=65559r=fixed Fixed in release: https://bugs.php.net/fix.php?id=65559r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=65559r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=65559r=needscript Try newer version: https://bugs.php.net/fix.php?id=65559r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=65559r=support Expected behavior: https://bugs.php.net/fix.php?id=65559r=notwrong Not enough info: https://bugs.php.net/fix.php?id=65559r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=65559r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=65559r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=65559r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=65559r=dst IIS Stability: https://bugs.php.net/fix.php?id=65559r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=65559r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=65559r=float No Zend Extensions: https://bugs.php.net/fix.php?id=65559r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=65559r=mysqlcfg
[PHP-BUG] Bug #65560 [NEW]: defined and constant does not resolve use aliases
From: codronm+circlecode at gmail dot com
Operating system: linux
PHP version: 5.5.3
Package: Scripting Engine problem
Bug Type: Bug
Bug description:defined and constant does not resolve use aliases
Description:
while var_dump resolves correctly aliases defines by the use keyword,
defined and constant functions does not resolve it.
Test script:
---
?php
namespace Foo;
class Bar {
const baz = 'baz';
}
function test($const){
if(defined($const)){
echo $const value is . constant($const) . \n;
} else {
echo $const is not defined . \n;
}
}
use \Foo\Bar as Bar;
var_dump(\Foo\Bar::baz);
test(\Foo\Bar::baz);
var_dump(Bar::baz);
test(Bar::baz);
Expected result:
string(3) baz
\Foo\Bar::baz value is baz
string(3) baz
Bar::baz is not defined
Actual result:
--
string(3) baz
\Foo\Bar::baz value is baz
string(3) baz
Bar::baz value is baz
--
Edit bug report at https://bugs.php.net/bug.php?id=65560edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=65560r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=65560r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=65560r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=65560r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=65560r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=65560r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=65560r=needscript
Try newer version: https://bugs.php.net/fix.php?id=65560r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=65560r=support
Expected behavior: https://bugs.php.net/fix.php?id=65560r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=65560r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=65560r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=65560r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=65560r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=65560r=dst
IIS Stability: https://bugs.php.net/fix.php?id=65560r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=65560r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=65560r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=65560r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=65560r=mysqlcfg
Bug #65560 [Opn-Nab]: defined and constant does not resolve use aliases
Edit report at https://bugs.php.net/bug.php?id=65560edit=1
ID: 65560
Updated by: ni...@php.net
Reported by:codronm+circlecode at gmail dot com
Summary:defined and constant does not resolve use aliases
-Status: Open
+Status: Not a bug
Type: Bug
Package:Scripting Engine problem
Operating System: linux
PHP Version:5.5.3
Block user comment: N
Private report: N
New Comment:
Names in strings always need to be fully qualified. Aliases do not apply to
them. (And they can't, because aliases are local to the file, but the string
with the name can be used completely elsewhere.)
Previous Comments:
[2013-08-26 14:09:11] codronm+circlecode at gmail dot com
Sorry, I have inverted Expected result and actual result⦠I don't know how to
edit this
[2013-08-26 13:56:49] codronm+circlecode at gmail dot com
Description:
while var_dump resolves correctly aliases defines by the use keyword, defined
and constant functions does not resolve it.
Test script:
---
?php
namespace Foo;
class Bar {
const baz = 'baz';
}
function test($const){
if(defined($const)){
echo $const value is . constant($const) . \n;
} else {
echo $const is not defined . \n;
}
}
use \Foo\Bar as Bar;
var_dump(\Foo\Bar::baz);
test(\Foo\Bar::baz);
var_dump(Bar::baz);
test(Bar::baz);
Expected result:
string(3) baz
\Foo\Bar::baz value is baz
string(3) baz
Bar::baz is not defined
Actual result:
--
string(3) baz
\Foo\Bar::baz value is baz
string(3) baz
Bar::baz value is baz
--
Edit this bug report at https://bugs.php.net/bug.php?id=65560edit=1
Bug #65560 [Opn]: defined and constant does not resolve use aliases
Edit report at https://bugs.php.net/bug.php?id=65560edit=1
ID: 65560
User updated by:codronm+circlecode at gmail dot com
Reported by:codronm+circlecode at gmail dot com
Summary:defined and constant does not resolve use aliases
Status: Open
Type: Bug
Package:Scripting Engine problem
Operating System: linux
PHP Version:5.5.3
Block user comment: N
Private report: N
New Comment:
Sorry, I have inverted Expected result and actual result⦠I don't know how to
edit this
Previous Comments:
[2013-08-26 13:56:49] codronm+circlecode at gmail dot com
Description:
while var_dump resolves correctly aliases defines by the use keyword, defined
and constant functions does not resolve it.
Test script:
---
?php
namespace Foo;
class Bar {
const baz = 'baz';
}
function test($const){
if(defined($const)){
echo $const value is . constant($const) . \n;
} else {
echo $const is not defined . \n;
}
}
use \Foo\Bar as Bar;
var_dump(\Foo\Bar::baz);
test(\Foo\Bar::baz);
var_dump(Bar::baz);
test(Bar::baz);
Expected result:
string(3) baz
\Foo\Bar::baz value is baz
string(3) baz
Bar::baz is not defined
Actual result:
--
string(3) baz
\Foo\Bar::baz value is baz
string(3) baz
Bar::baz value is baz
--
Edit this bug report at https://bugs.php.net/bug.php?id=65560edit=1
Bug #65560 [Nab]: defined and constant does not resolve use aliases
Edit report at https://bugs.php.net/bug.php?id=65560edit=1
ID: 65560
User updated by:codronm+circlecode at gmail dot com
Reported by:codronm+circlecode at gmail dot com
Summary:defined and constant does not resolve use aliases
Status: Not a bug
Type: Bug
Package:Scripting Engine problem
Operating System: linux
PHP Version:5.5.3
Block user comment: N
Private report: N
New Comment:
So thanks for the point, and sorry for the noise.
Previous Comments:
[2013-08-26 14:09:14] ni...@php.net
Names in strings always need to be fully qualified. Aliases do not apply to
them. (And they can't, because aliases are local to the file, but the string
with the name can be used completely elsewhere.)
[2013-08-26 14:09:11] codronm+circlecode at gmail dot com
Sorry, I have inverted Expected result and actual result⦠I don't know how to
edit this
[2013-08-26 13:56:49] codronm+circlecode at gmail dot com
Description:
while var_dump resolves correctly aliases defines by the use keyword, defined
and constant functions does not resolve it.
Test script:
---
?php
namespace Foo;
class Bar {
const baz = 'baz';
}
function test($const){
if(defined($const)){
echo $const value is . constant($const) . \n;
} else {
echo $const is not defined . \n;
}
}
use \Foo\Bar as Bar;
var_dump(\Foo\Bar::baz);
test(\Foo\Bar::baz);
var_dump(Bar::baz);
test(Bar::baz);
Expected result:
string(3) baz
\Foo\Bar::baz value is baz
string(3) baz
Bar::baz is not defined
Actual result:
--
string(3) baz
\Foo\Bar::baz value is baz
string(3) baz
Bar::baz value is baz
--
Edit this bug report at https://bugs.php.net/bug.php?id=65560edit=1
Req #61759 [Com]: class_alias() should accept classes with leading backslashes
Edit report at https://bugs.php.net/bug.php?id=61759edit=1
ID: 61759
Comment by: contact at jubianchi dot fr
Reported by:ahar...@php.net
Summary:class_alias() should accept classes with leading
backslashes
Status: Open
Type: Feature/Change Request
Package:Class/Object related
Operating System: Irrelevant
PHP Version:master-Git-2012-04-18 (Git)
Block user comment: N
Private report: N
New Comment:
I experienced the exact same issue on PHP 5.4.17 on OS X 10.9 (Mavericks DP6).
I wrote a simple test case, here it is :
Test script:
---
namespace jubianchi\Alias {
class A {}
var_dump(class_alias('\\jubianchi\\Alias\\A', 'C'));
$reflector = new \ReflectionClass('C');
var_dump($reflector-getName());
var_dump(class_alias('\\jubianchi\\Alias\\A', '\\jubianchi\\Alias\\B'));
try {
$reflector = new \ReflectionClass('\\jubianchi\\Alias\\B');
var_dump($reflector-getName());
} catch(\Exception $e) {
var_dump(get_class($e) . ': ' . $e-getMessage());
}
var_dump(class_alias('\\jubianchi\\Alias\\A', 'jubianchi\\Alias\\B'));
$reflector = new \ReflectionClass('\\jubianchi\\Alias\\B');
var_dump($reflector-getName());
}
Expected result:
bool(true)
string(17) jubianchi\Alias\A
bool(true)
string(17) jubianchi\Alias\A
bool(true)
string(17) jubianchi\Alias\A
Or:
bool(true)
string(17) jubianchi\Alias\A
bool(false)
string(60) ReflectionException: Class \jubianchi\Alias\B does not exist
bool(true)
string(17) jubianchi\Alias\A
Actual result:
bool(true)
string(1) A
bool(true)
string(17) jubianchi\Alias\A
bool(true)
string(60) ReflectionException: Class \jubianchi\Alias\B does not exist
bool(true)
string(17) jubianchi\Alias\A
As you can see, class_alias returns bool(true) as if everything went fine, so
we
expect the alias to be available but a reflection on the latter throws an
exception.
I think class_alias should be able to handle the leading backslashes or return
bool(false) if it can't.
Previous Comments:
[2012-04-18 06:11:21] ahar...@php.net
Description:
Aliasing namespaced classes currently expects that class names will be given in
the same form as the ZE uses internally; ie without a leading backslash. Since
that's inconsistent with the absolute form in PHP, it would be good if
class_alias() could also ignore a leading backslash.
Test script:
---
?php
namespace A;
class C { function foo() { echo 42\n; } }
namespace B;
class_alias('\A\C', '\B\C');
$c = new C;
$c-foo();
Expected result:
42
Actual result:
--
Fatal error: Class 'B\C' not found in /private/tmp/test.php on line 7
--
Edit this bug report at https://bugs.php.net/bug.php?id=61759edit=1
Req #61759 [Opn]: class_alias() should accept classes with leading backslashes
Edit report at https://bugs.php.net/bug.php?id=61759edit=1
ID: 61759
Updated by: johan...@php.net
Reported by:ahar...@php.net
Summary:class_alias() should accept classes with leading
backslashes
Status: Open
Type: Feature/Change Request
Package:Class/Object related
Operating System: Irrelevant
PHP Version:master-Git-2012-04-18 (Git)
Block user comment: N
Private report: N
New Comment:
Note: The bug report is too restrictive. A proper patch would have to work on
all places where classnames come from string context. This at first means
verifying that all places go via zend_lookup_class() and related functions, not
EG(class_table) / CG(class_table)
Previous Comments:
[2013-08-26 18:13:08] contact at jubianchi dot fr
I experienced the exact same issue on PHP 5.4.17 on OS X 10.9 (Mavericks DP6).
I wrote a simple test case, here it is :
Test script:
---
namespace jubianchi\Alias {
class A {}
var_dump(class_alias('\\jubianchi\\Alias\\A', 'C'));
$reflector = new \ReflectionClass('C');
var_dump($reflector-getName());
var_dump(class_alias('\\jubianchi\\Alias\\A', '\\jubianchi\\Alias\\B'));
try {
$reflector = new \ReflectionClass('\\jubianchi\\Alias\\B');
var_dump($reflector-getName());
} catch(\Exception $e) {
var_dump(get_class($e) . ': ' . $e-getMessage());
}
var_dump(class_alias('\\jubianchi\\Alias\\A', 'jubianchi\\Alias\\B'));
$reflector = new \ReflectionClass('\\jubianchi\\Alias\\B');
var_dump($reflector-getName());
}
Expected result:
bool(true)
string(17) jubianchi\Alias\A
bool(true)
string(17) jubianchi\Alias\A
bool(true)
string(17) jubianchi\Alias\A
Or:
bool(true)
string(17) jubianchi\Alias\A
bool(false)
string(60) ReflectionException: Class \jubianchi\Alias\B does not exist
bool(true)
string(17) jubianchi\Alias\A
Actual result:
bool(true)
string(1) A
bool(true)
string(17) jubianchi\Alias\A
bool(true)
string(60) ReflectionException: Class \jubianchi\Alias\B does not exist
bool(true)
string(17) jubianchi\Alias\A
As you can see, class_alias returns bool(true) as if everything went fine, so
we
expect the alias to be available but a reflection on the latter throws an
exception.
I think class_alias should be able to handle the leading backslashes or return
bool(false) if it can't.
[2012-04-18 06:11:21] ahar...@php.net
Description:
Aliasing namespaced classes currently expects that class names will be given in
the same form as the ZE uses internally; ie without a leading backslash. Since
that's inconsistent with the absolute form in PHP, it would be good if
class_alias() could also ignore a leading backslash.
Test script:
---
?php
namespace A;
class C { function foo() { echo 42\n; } }
namespace B;
class_alias('\A\C', '\B\C');
$c = new C;
$c-foo();
Expected result:
42
Actual result:
--
Fatal error: Class 'B\C' not found in /private/tmp/test.php on line 7
--
Edit this bug report at https://bugs.php.net/bug.php?id=61759edit=1
[PHP-BUG] Bug #65561 [NEW]: Zend Opcache on Solaris 11 x86 needs ZEND_MM_ALIGNMENT=4
From: craig dot mohrman at oracle dot com
Operating system: Solaris 11
PHP version: Irrelevant
Package: opcache
Bug Type: Bug
Bug description:Zend Opcache on Solaris 11 x86 needs ZEND_MM_ALIGNMENT=4
Description:
This is a place holder bug for anyone working with Solaris and php 5.3.27
I haven't tried the latest version of PHP so maybe this just goes away.
I've documented this in a thread here:
https://github.com/zendtech/ZendOptimizerPlus/issues/122
But the problem appears to be in php itself.
This is compiling the Zend Opcache 7.0.2 from:
http://pecl.php.net/package/ZendOpcache
When compiling ZendOpcache with php 5.3.27 on Solaris 11 x86 with
the Solaris Studio compiler (12.1) I'm seeing Overflown errors even with
the
most trivial of php programs.
This is all being done in 32-bit.
Sparc has no such issue. Works out of the box.
As a workaround I'm patching ZEND_MM_ALIGNMENT:
#define ZEND_MM_ALIGNMENT 8
#define ZEND_MM_ALIGNMENT_LOG2 3
to
#define ZEND_MM_ALIGNMENT 4
#define ZEND_MM_ALIGNMENT_LOG2 2
over in PHP/Zend/Zend.m4
and everything works fine.
I got this 4 when compiling php 5.3.27 with gcc 4.5.
That comes up with ZEND_MM_ALIGNMENT=4 but when compiling
with Solaris Studio I get ZEND_MM_ALIGNMENT=8.
Oddly on Solaris sparc both Solaris Studio and gcc 4.5 come up with:
ZEND_MM_ALIGNMENT=8
but that works fine.
So see the actual patch below.
This is not the solution but gets Zend Opcache working on Solaris x86.
Test script:
---
$ cat simple.php
?php
function m_x_plus_b($m, $x, $b) {
return $m*$x+$b;
}
$slope=1.5;
$x=2;
$b=3;
echo y = .m_x_plus_b($slope,$x,$b).\nbr;
?
Expected result:
$ php -v
PHP 5.3.27 (cli) (built: Aug 20 2013 11:05:05)
Copyright (c) 1997-2013 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2013 Zend Technologies
with Zend OPcache v7.0.2, Copyright (c) 1999-2013, by Zend
Technologies
with Xdebug v2.2.0, Copyright (c) 2002-2012, by Derick Rethans
with Suhosin v0.9.33, Copyright (c) 2007-2012, by SektionEins GmbH
$ php -f simple.php
y = 6
br
Actual result:
--
$ php -f simple.php
File /home/cmohrman/Public/PHP/simple.php func m_x_plus_b
Block: 0-5 (6) unused
Block: 6-6 (1)
T0: 0
T1: 0
Opt Block: 0-5 (6)
T0: 0
T1: 0
Opt Block: 0-5 (6)
T0: 0
T1: 0
Opt Block: 0-5 (6)
T0: 0
T1: 0
Out Block: 0-5 (6)
File /home/cmohrman/Public/PHP/simple.php func main
Block: 0-11 (12) unused
T0: 0
T1: 0
T2: 0
T3: 0
T4: 0
T5: 0
[Fri Aug 9 11:10:45 2013] Script:
'/home/cmohrman/Public/PHP/simple.php'
---
./Optimizer/block_pass.c(2053) : Block 0x0935e970 status:
Beginning: OK (allocated on ./Optimizer/block_pass.c:1911, 6 bytes)
Start: OK
End: Overflown (magic=0x instead of 0x530646BC)
1 byte(s) overflown
---
Opt Block: 0-11 (12)
[Fri Aug 9 11:10:45 2013] Script:
'/home/cmohrman/Public/PHP/simple.php'
---
./Optimizer/block_pass.c(1220) : Block 0x0935fa70 status:
Beginning: OK (allocated on ./Optimizer/block_pass.c:631, 24 bytes)
Start: OK
End: Overflown (magic=0xFFB4 instead of 0x530646BC)
At least 4 bytes overflown
---
T0: 0
T1: 0
T2: 0
T3: 0
T4: 0
T5: 0
[Fri Aug 9 11:10:45 2013] Script:
'/home/cmohrman/Public/PHP/simple.php'
---
./Optimizer/block_pass.c(2053) : Block 0x0935e9a8 status:
Beginning: OK (allocated on ./Optimizer/block_pass.c:1911, 6 bytes)
Start: OK
End: Overflown (magic=0x instead of 0x530646BC)
1 byte(s) overflown
---
Opt Block: 1-11 (11)
[Fri Aug 9 11:10:45 2013] Script:
'/home/cmohrman/Public/PHP/simple.php'
---
./Optimizer/block_pass.c(1220) : Block 0x0935fc80 status:
Beginning: OK (allocated on ./Optimizer/block_pass.c:631, 24 bytes)
Start: OK
End: Overflown (magic=0xFFB4 instead of 0x530646BC)
At least 4 bytes overflown
---
T0: 0
T1: 0
T2: 0
T3: 0
T4: 0
T5: 0
[Fri Aug 9 11:10:45 2013] Script:
'/home/cmohrman/Public/PHP/simple.php'
---
./Optimizer/block_pass.c(2053) : Block 0x0935e9e0 status:
Beginning: OK (allocated on ./Optimizer/block_pass.c:1911, 6 bytes)
Start: OK
End: Overflown (magic=0x instead of 0x530646BC)
1 byte(s) overflown
---
Opt Block: 1-11 (11)
[Fri Aug 9 11:10:45 2013] Script:
'/home/cmohrman/Public/PHP/simple.php'
---
./Optimizer/block_pass.c(1220) : Block 0x0935ea50 status:
Beginning: OK (allocated on ./Optimizer/block_pass.c:631, 24 bytes)
Start:
Bug #65530 [Ver]: Anonymous functions not callable directly when part of a static class
Edit report at https://bugs.php.net/bug.php?id=65530edit=1
ID: 65530
Updated by: requi...@php.net
Reported by:matt dot minix at gmail dot com
Summary:Anonymous functions not callable directly when part
of a static class
Status: Verified
Type: Bug
Package:Scripting Engine problem
Operating System: Linux
PHP Version:5.4 and later
Block user comment: N
Private report: N
New Comment:
It's ambiguous at compile time: Does Class::$foo()
1. As requested: execute the function stored in/referenced by Class::$foo
2. As currently: execute the static method in Class named according to the
local
$foo
3. Another possibility: evaluate the static property of Class whose name is
returned by $foo()
The only way I see to support more than one would be to resolve it at runtime,
but
even then it's still possible to write something that is legal all three ways:
?php
class Ambiguous {
public static $one;
public static function two() { echo two; }
public static $three = 3;
}
Ambiguous::$one = function() { echo one; };
function two() {
echo three;
return three;
}
$one = two;
// 1. call_user_func(Ambiguous::$one)
// 2. call_user_func(Ambiguous:: . $one)
// 3. Ambiguous::${$one()}
Ambiguous::$one();
?
Looking at just the last line I'm not even sure what *I* would expect it to
do...
Previous Comments:
[2013-08-26 09:51:28] yohg...@php.net
PHP behaves as reported. It does not work 5.5 also.
[yohgaki@dev PHP-5.5]$ ./sapi/cli/php
?php
class a {
public static $b;
}
a::$b = static function($c) { echo $c; };
a::$b('Test')
?
Fatal error: Function name must be a string in - on line 7
[2013-08-22 21:19:27] matt dot minix at gmail dot com
Description:
An anonymous function doesn't seem like it can be called directly when in a
static
class.
Test script:
---
class a {
public static $b;
}
a::$b = static function($c) { echo $c; };
a::$b('Test');
I am however able to do
class a {
public static $b;
}
a::$b = static function($c) { echo $c; };
$Temp = a::$b;
$Temp('Test');
Expected result:
Test
Actual result:
--
Fatal error: Function name must be a string
--
Edit this bug report at https://bugs.php.net/bug.php?id=65530edit=1
[PHP-BUG] Bug #65562 [NEW]: memory leak in zend_parse_arg
From: rrh at newrelic dot com Operating system: all PHP version: 5.5.3 Package: Performance problem Bug Type: Bug Bug description:memory leak in zend_parse_arg Description: Function zend_parse_arg leaks memory, as discovered when I ran valgrind with php test cases designed to exercise a module we wrote. zend_parse_arg calls zend_parse_arg_impl. Unfortunately, not all control flow paths to the return in zend_parse_arg call efree to free up the memory allocated by zend_parse_arg_impl to hold the error string. In my case, quiet != 0, so the lone efree (which has 2 additional guards) is not called. -- Edit bug report at https://bugs.php.net/bug.php?id=65562edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=65562r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=65562r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=65562r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=65562r=fixed Fixed in release: https://bugs.php.net/fix.php?id=65562r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=65562r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=65562r=needscript Try newer version: https://bugs.php.net/fix.php?id=65562r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=65562r=support Expected behavior: https://bugs.php.net/fix.php?id=65562r=notwrong Not enough info: https://bugs.php.net/fix.php?id=65562r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=65562r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=65562r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=65562r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=65562r=dst IIS Stability: https://bugs.php.net/fix.php?id=65562r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=65562r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=65562r=float No Zend Extensions: https://bugs.php.net/fix.php?id=65562r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=65562r=mysqlcfg
Bug #65562 [Opn-Fbk]: memory leak in zend_parse_arg
Edit report at https://bugs.php.net/bug.php?id=65562edit=1 ID: 65562 Updated by: johan...@php.net Reported by:rrh at newrelic dot com Summary:memory leak in zend_parse_arg -Status: Open +Status: Feedback Type: Bug Package:Performance problem Operating System: all PHP Version:5.5.3 Block user comment: N Private report: N New Comment: Please provide compilable code showing the issue. In general: We don't consider issues which can't be triggered by userspace code as bug but expect extension authors to provide patches to improve PHP. Previous Comments: [2013-08-26 20:23:12] rrh at newrelic dot com Description: Function zend_parse_arg leaks memory, as discovered when I ran valgrind with php test cases designed to exercise a module we wrote. zend_parse_arg calls zend_parse_arg_impl. Unfortunately, not all control flow paths to the return in zend_parse_arg call efree to free up the memory allocated by zend_parse_arg_impl to hold the error string. In my case, quiet != 0, so the lone efree (which has 2 additional guards) is not called. -- Edit this bug report at https://bugs.php.net/bug.php?id=65562edit=1
Bug #65562 [Fbk-Opn]: memory leak in zend_parse_arg
Edit report at https://bugs.php.net/bug.php?id=65562edit=1 ID: 65562 User updated by:rrh at newrelic dot com Reported by:rrh at newrelic dot com Summary:memory leak in zend_parse_arg -Status: Feedback +Status: Open Type: Bug Package:Performance problem Operating System: all PHP Version:5.5.3 Block user comment: N Private report: N New Comment: I didn't provide code to show the issue because the issue is almost certainly independent of my module extension, and a quick inspection of the code looking at the control flow paths would show that efree isn't called on all paths leading to a return from the function. Previous Comments: [2013-08-26 20:53:04] johan...@php.net Please provide compilable code showing the issue. In general: We don't consider issues which can't be triggered by userspace code as bug but expect extension authors to provide patches to improve PHP. [2013-08-26 20:23:12] rrh at newrelic dot com Description: Function zend_parse_arg leaks memory, as discovered when I ran valgrind with php test cases designed to exercise a module we wrote. zend_parse_arg calls zend_parse_arg_impl. Unfortunately, not all control flow paths to the return in zend_parse_arg call efree to free up the memory allocated by zend_parse_arg_impl to hold the error string. In my case, quiet != 0, so the lone efree (which has 2 additional guards) is not called. -- Edit this bug report at https://bugs.php.net/bug.php?id=65562edit=1
Bug #65416 [Nab]: output buffering autostart setting php.ini
Edit report at https://bugs.php.net/bug.php?id=65416edit=1
ID: 65416
User updated by:jwestbrook at gmail dot com
Reported by:jwestbrook at gmail dot com
Summary:output buffering autostart setting php.ini
Status: Not a bug
Type: Bug
Package:Output Control
Operating System: linux 64bit AWS ami
PHP Version:5.4.17
Block user comment: N
Private report: N
New Comment:
@mike at php.net Yes that is the bug I'm reporting - the php.ini setting does
not
start the output buffer on every request.
Previous Comments:
[2013-08-19 22:19:57] m...@php.net
Looks like when this is logged, there actually is no output buffer active, so
ob_get_length() returns false.
[2013-08-19 22:07:01] jwestbrook at gmail dot com
I also tried the settings of On and 1.
I also understand that #!/usr/bin/php means nothing to output buffering but is
output that
I want to capture if the php file is being run from a browser and discard.
From what I understand that is not how the output buffering works. The way I
understand it
the output buffer fills then dumps everything when it is full. In this instance
before the
output buffer fills I want to discard the first 15 characters because it will
corrupt any
binary files that the browser is trying to download.
Based on the test script attached ob_get_length() should ALWAYS return 15
characters -
however at least 12 times a day PHP fails to start the output buffer and I get
the error
shown.
[2013-08-18 06:52:49] yohg...@php.net
#! does not have special meaning for Web server SAPI.
I think you are sending data larger than output buffer size. Then this is the
way supposed to be.
output_buffering=On or 1 is special. It enables unlimited buffering. Anything
other values set buffer chunk size and PHP tries to send data larger than chunk
size.
Check your buffer size (i.e. output_buffering setting of php.ini file)
I guess you have very small output_buffering. Old output buffer increases size
automatically, IIRC. New output buffer does not increase buffer size.
[2013-08-07 19:47:35] jwestbrook at gmail dot com
Description:
We recently upgraded from php 5.3 to php 5.4 and when the php.ini
output_buffering
setting is set to ON or anything greater than zero the output buffering does
not
always reliably start.
This is a problem for some scripts that have a shebang as the first line to
make
the script easily executable. But if you send a header or anything else after
that
first line it will fail.
based on the script attached the contents of the error log are
buffer statues : Array\n(\n)\n
Test script:
---
#!/usr/bin/php
?php
$buffer_length = ob_get_length();
if($buffer_length != 15)
{
error_log('buffer statues : '.print_r(ob_get_status(TRUE),1));
exit;
}
//this header call will not always be successful
header(Content-type: application/pdf);
?
--
Edit this bug report at https://bugs.php.net/bug.php?id=65416edit=1
Bug #61577 [Com]: php5ts.dll crashes when specific extensions are loaded
Edit report at https://bugs.php.net/bug.php?id=61577edit=1 ID: 61577 Comment by: mattfic...@php.net Reported by:uniflare at gmail dot com Summary:php5ts.dll crashes when specific extensions are loaded Status: Feedback Type: Bug Package:Reproducible crash Operating System: Windows7 Ultimate x86 PHP Version:5.4.0 Assigned To:mattficken Block user comment: N Private report: N New Comment: You may have DLLs mixed up from a different PHP version. Instead, download the 5.4.19-ts ZIP file from windows.php.net/downloads and decompress it to c:\php-sdk\php-5.4.19-win32-vc9-x86 When reconfiguring Apache and your PHP.ini make sure that extension_dir=c:\php-sdk\php-5.4.19-win32-vc9-x86\ext If that still fails, run php on command line without an INI file in case its loading extensions from the INI file or registry. Run this command: `php -n -d extension_dir=c:\php-sdk\php-5.4.19-win32-vc9-ext\ext -d extension=php_gd2.dll -d extension=php_curl.dll -d extension=php_mbstring.dll` Send us the output from that. Is this ApacheLounge-2.4.2-OpenSSL-0.9.8-VC9? If you're able to run phpinfo() but nothing else, send the output of that. If you're only able to run phpinfo() if you disable one of those extensions, do that too, so we can see what's going on. Also, run `systeminfo` on command line and send us the output. Previous Comments: [2013-08-26 10:08:13] paj...@php.net try under CLI and see what is the actual error is, I very much doubt there is actually a crash but missing DLLs in the path. [2013-08-26 09:34:03] pirabid at gmail dot com I have the same problem on windows 7 (64-bit) using PHP 5.4.0 Apache crashes if I use the following two extension parallely: extension=php_curl.dll extension=php_gd2.dll If I comment any one of these, Apache works okay. Please fix this. [2012-05-04 14:56:50] zane at zanezane dot net For me, problem is fixed since 5.4.1. I tried seconds ago with 5.4.2 and is still ok. [2012-05-04 12:44:07] george dot gruber at emailourfamily dot com A new note to this issue. I have updated PHP to 5.4.1 and Apache from ApacheLounge to the 32-bit, openSSL 0.9.8v version and the problem still exists. I was hoping the PHP 5.4.1 would resolve the issue. [2012-04-17 19:57:38] george dot gruber at emailourfamily dot com I experiencing the same crash on two different Windows 7 Ultimate x64 machines. Apache and PHP come up and run fine and occasionally I get the message in error.log: [mpm_winnt:notice] [pid 2200:tid 512] AH00428: Parent: child process exited with status 255 -- Restarting. At nearly the same time there are three entries in to the application event log indicating the same error reported in bug: Faulting application name: httpd.exe, version: 2.4.2.0, time stamp: 0x4f7ed6c4 Faulting module name: php5ts.dll, version: 5.4.0.0, time stamp: 0x4f4e7f05 Exception code: 0xc005 Fault offset: 0x0004c563 Faulting process id: 0x3870 Faulting application start time: 0x01cd1cb269ad9f3a Faulting application path: C:\Apache24\bin\httpd.exe Faulting module path: C:\PHP5\php5ts.dll I have removed as many extensions as possible that still allows the system to run properly. I had even gone as far as to remove php_mbstring and it didn't change the results. Having removed some of the other extensions seem to reduce it but this is not definitive. This is the list of what I had removed just for reference: php_gettext php_ldap php_pdo_mysql php_pgsql php_soap php_sockets php_tidy php_xsl I had verified that nothing required them although if that was the case you would think that they wouldn't be doing anything to cause an error. Interestingly enough as far as I can tell the pages are rendered properly and that the only indication of any problem is the error.log (Apache) and Windows events. I am running PHP 5.4.0 and Apache 2.4.2 (ApacheLounge including php5apache2_4.dll) and MySQL 5.6.5m8 on Windows 7 Ultimate x64 with SP1. I have my own log file pertaining to processing of the pages and some functions (MySQL requests are always captured) and I am trying to correlate the crash to a particular event but so far nothing specific. It is somewhat disconcerting and I do not know if there are any side issues being created by this occurring. If anyone would like additional information please let me know and I would be happy to submit it. The remainder of the comments for this report are too long. To
Bug #64571 [Com]: PDO CREATE TRIGGER
Edit report at https://bugs.php.net/bug.php?id=64571edit=1
ID: 64571
Comment by: email at philsturgeon dot co dot uk
Reported by:jehoshua02 at gmail dot com
Summary:PDO CREATE TRIGGER
Status: Not a bug
Type: Bug
Package:PDO related
Operating System: Ubuntu 12.10 Desktop 64bit
PHP Version:5.4.13
Block user comment: N
Private report: N
New Comment:
This should actually be $pdo-exec('CREATE TRIGGER...');
Previous Comments:
[2013-04-06 15:43:25] fel...@php.net
DELIMITER is not a mysql statement, but a mysql client command.
Use a separated statement for create trigger part. e.g. $pdo-query(CREATE
TRIGGER ...);
[2013-04-03 00:28:44] jehoshua02 at gmail dot com
Could the root of this problem be somehow related to the multiple-query problem?
[2013-04-03 00:09:02] jehoshua02 at gmail dot com
Description:
I'm using PDO in some simple script to do database migrations and realized that
my triggers weren't being created. I checked to make sure the triggers were
correct by first copying and pasting them into mysql interactive console, then
by using `SOURCE ...`, then by passing the file name into mysql command, each
time verifying the trigger was created by using SHOW TRIGGERS WHERE `Trigger`
= :trigger. I concluded that the problem was not with my trigger statements,
or with mysql, but with PDO.
The actual PHP version is 5.4.6-1ubuntu1.2 so I chose the closest one.
Test script:
---
https://gist.github.com/jehoshua02/5297332
Expected result:
I would expect to see the trigger printed as an associative array.
Actual result:
--
The trigger is not created even though the script completes without any errors
or exceptions.
--
Edit this bug report at https://bugs.php.net/bug.php?id=64571edit=1
Bug #65416 [Nab-Fbk]: output buffering autostart setting php.ini
Edit report at https://bugs.php.net/bug.php?id=65416edit=1
ID: 65416
Updated by: yohg...@php.net
Reported by:jwestbrook at gmail dot com
Summary:output buffering autostart setting php.ini
-Status: Not a bug
+Status: Feedback
Type: Bug
Package:Output Control
Operating System: linux 64bit AWS ami
PHP Version:5.4.17
Block user comment: N
Private report: N
New Comment:
I guess there is some kind of memory problem.
What modules are loaded in your web server and SAPI?
?php
var_dump(get_loaded_extensions(), php_sapi_name());
?
or paste phpinfo() output.
at least 12 times a day PHP fails to start the output buffer and I get the
error shown.
How many requests a day you have?
Previous Comments:
[2013-08-26 21:35:48] jwestbrook at gmail dot com
@mike at php.net Yes that is the bug I'm reporting - the php.ini setting does
not
start the output buffer on every request.
[2013-08-19 22:19:57] m...@php.net
Looks like when this is logged, there actually is no output buffer active, so
ob_get_length() returns false.
[2013-08-19 22:07:01] jwestbrook at gmail dot com
I also tried the settings of On and 1.
I also understand that #!/usr/bin/php means nothing to output buffering but is
output that
I want to capture if the php file is being run from a browser and discard.
From what I understand that is not how the output buffering works. The way I
understand it
the output buffer fills then dumps everything when it is full. In this instance
before the
output buffer fills I want to discard the first 15 characters because it will
corrupt any
binary files that the browser is trying to download.
Based on the test script attached ob_get_length() should ALWAYS return 15
characters -
however at least 12 times a day PHP fails to start the output buffer and I get
the error
shown.
[2013-08-18 06:52:49] yohg...@php.net
#! does not have special meaning for Web server SAPI.
I think you are sending data larger than output buffer size. Then this is the
way supposed to be.
output_buffering=On or 1 is special. It enables unlimited buffering. Anything
other values set buffer chunk size and PHP tries to send data larger than chunk
size.
Check your buffer size (i.e. output_buffering setting of php.ini file)
I guess you have very small output_buffering. Old output buffer increases size
automatically, IIRC. New output buffer does not increase buffer size.
[2013-08-07 19:47:35] jwestbrook at gmail dot com
Description:
We recently upgraded from php 5.3 to php 5.4 and when the php.ini
output_buffering
setting is set to ON or anything greater than zero the output buffering does
not
always reliably start.
This is a problem for some scripts that have a shebang as the first line to
make
the script easily executable. But if you send a header or anything else after
that
first line it will fail.
based on the script attached the contents of the error log are
buffer statues : Array\n(\n)\n
Test script:
---
#!/usr/bin/php
?php
$buffer_length = ob_get_length();
if($buffer_length != 15)
{
error_log('buffer statues : '.print_r(ob_get_status(TRUE),1));
exit;
}
//this header call will not always be successful
header(Content-type: application/pdf);
?
--
Edit this bug report at https://bugs.php.net/bug.php?id=65416edit=1
Bug #65562 [Opn]: memory leak in zend_parse_arg
Edit report at https://bugs.php.net/bug.php?id=65562edit=1 ID: 65562 Updated by: yohg...@php.net Reported by:rrh at newrelic dot com Summary:memory leak in zend_parse_arg Status: Open Type: Bug Package:Performance problem Operating System: all PHP Version:5.5.3 Block user comment: N Private report: N New Comment: If you are certain, please provide short and complete module code that leaks memory. (i.e. full module code that compiles as module) It should be by using ext_skel shell script. Previous Comments: [2013-08-26 21:21:52] rrh at newrelic dot com I didn't provide code to show the issue because the issue is almost certainly independent of my module extension, and a quick inspection of the code looking at the control flow paths would show that efree isn't called on all paths leading to a return from the function. [2013-08-26 20:53:04] johan...@php.net Please provide compilable code showing the issue. In general: We don't consider issues which can't be triggered by userspace code as bug but expect extension authors to provide patches to improve PHP. [2013-08-26 20:23:12] rrh at newrelic dot com Description: Function zend_parse_arg leaks memory, as discovered when I ran valgrind with php test cases designed to exercise a module we wrote. zend_parse_arg calls zend_parse_arg_impl. Unfortunately, not all control flow paths to the return in zend_parse_arg call efree to free up the memory allocated by zend_parse_arg_impl to hold the error string. In my case, quiet != 0, so the lone efree (which has 2 additional guards) is not called. -- Edit this bug report at https://bugs.php.net/bug.php?id=65562edit=1
Bug #65562 [Opn-Fbk]: memory leak in zend_parse_arg
Edit report at https://bugs.php.net/bug.php?id=65562edit=1 ID: 65562 Updated by: yohg...@php.net Reported by:rrh at newrelic dot com Summary:memory leak in zend_parse_arg -Status: Open +Status: Feedback Type: Bug Package:Performance problem Operating System: all PHP Version:5.5.3 Block user comment: N Private report: N New Comment: It should be by using ext_skel shell script. It should be easy by using ext_skel shell script. Previous Comments: [2013-08-26 22:54:27] yohg...@php.net If you are certain, please provide short and complete module code that leaks memory. (i.e. full module code that compiles as module) It should be by using ext_skel shell script. [2013-08-26 21:21:52] rrh at newrelic dot com I didn't provide code to show the issue because the issue is almost certainly independent of my module extension, and a quick inspection of the code looking at the control flow paths would show that efree isn't called on all paths leading to a return from the function. [2013-08-26 20:53:04] johan...@php.net Please provide compilable code showing the issue. In general: We don't consider issues which can't be triggered by userspace code as bug but expect extension authors to provide patches to improve PHP. [2013-08-26 20:23:12] rrh at newrelic dot com Description: Function zend_parse_arg leaks memory, as discovered when I ran valgrind with php test cases designed to exercise a module we wrote. zend_parse_arg calls zend_parse_arg_impl. Unfortunately, not all control flow paths to the return in zend_parse_arg call efree to free up the memory allocated by zend_parse_arg_impl to hold the error string. In my case, quiet != 0, so the lone efree (which has 2 additional guards) is not called. -- Edit this bug report at https://bugs.php.net/bug.php?id=65562edit=1
Bug #65562 [Fbk]: memory leak in zend_parse_arg
Edit report at https://bugs.php.net/bug.php?id=65562edit=1 ID: 65562 Updated by: johan...@php.net Reported by:rrh at newrelic dot com Summary:memory leak in zend_parse_arg Status: Feedback Type: Bug Package:Performance problem Operating System: all PHP Version:5.5.3 Block user comment: N Private report: N New Comment: https://github.com/johannes/php-src/commit/3bfe148c83d6c9b4134ac4fc5f6e0ae36f3f2c42 This might fix your issue. As you won't be telling whether this is our problem I can't properly test it. I'd welcome if you could test it and in future help providing patches. Previous Comments: [2013-08-26 22:55:31] yohg...@php.net It should be by using ext_skel shell script. It should be easy by using ext_skel shell script. [2013-08-26 22:54:27] yohg...@php.net If you are certain, please provide short and complete module code that leaks memory. (i.e. full module code that compiles as module) It should be by using ext_skel shell script. [2013-08-26 21:21:52] rrh at newrelic dot com I didn't provide code to show the issue because the issue is almost certainly independent of my module extension, and a quick inspection of the code looking at the control flow paths would show that efree isn't called on all paths leading to a return from the function. [2013-08-26 20:53:04] johan...@php.net Please provide compilable code showing the issue. In general: We don't consider issues which can't be triggered by userspace code as bug but expect extension authors to provide patches to improve PHP. [2013-08-26 20:23:12] rrh at newrelic dot com Description: Function zend_parse_arg leaks memory, as discovered when I ran valgrind with php test cases designed to exercise a module we wrote. zend_parse_arg calls zend_parse_arg_impl. Unfortunately, not all control flow paths to the return in zend_parse_arg call efree to free up the memory allocated by zend_parse_arg_impl to hold the error string. In my case, quiet != 0, so the lone efree (which has 2 additional guards) is not called. -- Edit this bug report at https://bugs.php.net/bug.php?id=65562edit=1
Bug #65562 [Fbk]: memory leak in zend_parse_arg
Edit report at https://bugs.php.net/bug.php?id=65562edit=1 ID: 65562 Updated by: johan...@php.net Reported by:rrh at newrelic dot com Summary:memory leak in zend_parse_arg Status: Feedback Type: Bug Package:Performance problem Operating System: all PHP Version:5.5.3 Block user comment: N Private report: N New Comment: meant to write your problem :-) Previous Comments: [2013-08-26 23:01:42] johan...@php.net https://github.com/johannes/php-src/commit/3bfe148c83d6c9b4134ac4fc5f6e0ae36f3f2c42 This might fix your issue. As you won't be telling whether this is our problem I can't properly test it. I'd welcome if you could test it and in future help providing patches. [2013-08-26 22:55:31] yohg...@php.net It should be by using ext_skel shell script. It should be easy by using ext_skel shell script. [2013-08-26 22:54:27] yohg...@php.net If you are certain, please provide short and complete module code that leaks memory. (i.e. full module code that compiles as module) It should be by using ext_skel shell script. [2013-08-26 21:21:52] rrh at newrelic dot com I didn't provide code to show the issue because the issue is almost certainly independent of my module extension, and a quick inspection of the code looking at the control flow paths would show that efree isn't called on all paths leading to a return from the function. [2013-08-26 20:53:04] johan...@php.net Please provide compilable code showing the issue. In general: We don't consider issues which can't be triggered by userspace code as bug but expect extension authors to provide patches to improve PHP. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=65562 -- Edit this bug report at https://bugs.php.net/bug.php?id=65562edit=1
Bug #65562 [Fbk]: memory leak in zend_parse_arg
Edit report at https://bugs.php.net/bug.php?id=65562edit=1 ID: 65562 Updated by: yohg...@php.net Reported by:rrh at newrelic dot com Summary:memory leak in zend_parse_arg Status: Feedback Type: Bug Package:Performance problem Operating System: all PHP Version:5.5.3 Block user comment: N Private report: N New Comment: I suspect you have pointer issue. Valgrind does not handle ***(pointer to pointer to pointer) well. Check your hash handling code carefully, it may help. Previous Comments: [2013-08-26 23:02:10] johan...@php.net meant to write your problem :-) [2013-08-26 23:01:42] johan...@php.net https://github.com/johannes/php-src/commit/3bfe148c83d6c9b4134ac4fc5f6e0ae36f3f2c42 This might fix your issue. As you won't be telling whether this is our problem I can't properly test it. I'd welcome if you could test it and in future help providing patches. [2013-08-26 22:55:31] yohg...@php.net It should be by using ext_skel shell script. It should be easy by using ext_skel shell script. [2013-08-26 22:54:27] yohg...@php.net If you are certain, please provide short and complete module code that leaks memory. (i.e. full module code that compiles as module) It should be by using ext_skel shell script. [2013-08-26 21:21:52] rrh at newrelic dot com I didn't provide code to show the issue because the issue is almost certainly independent of my module extension, and a quick inspection of the code looking at the control flow paths would show that efree isn't called on all paths leading to a return from the function. 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 https://bugs.php.net/bug.php?id=65562 -- Edit this bug report at https://bugs.php.net/bug.php?id=65562edit=1
Bug #65562 [Fbk-Opn]: memory leak in zend_parse_arg
Edit report at https://bugs.php.net/bug.php?id=65562edit=1 ID: 65562 User updated by:rrh at newrelic dot com Reported by:rrh at newrelic dot com Summary:memory leak in zend_parse_arg -Status: Feedback +Status: Open Type: Bug Package:Performance problem Operating System: all PHP Version:5.5.3 Block user comment: N Private report: N New Comment: I will test the patch, and in the future come up with patches for your review. Previous Comments: [2013-08-26 23:02:38] yohg...@php.net I suspect you have pointer issue. Valgrind does not handle ***(pointer to pointer to pointer) well. Check your hash handling code carefully, it may help. [2013-08-26 23:02:10] johan...@php.net meant to write your problem :-) [2013-08-26 23:01:42] johan...@php.net https://github.com/johannes/php-src/commit/3bfe148c83d6c9b4134ac4fc5f6e0ae36f3f2c42 This might fix your issue. As you won't be telling whether this is our problem I can't properly test it. I'd welcome if you could test it and in future help providing patches. [2013-08-26 22:55:31] yohg...@php.net It should be by using ext_skel shell script. It should be easy by using ext_skel shell script. [2013-08-26 22:54:27] yohg...@php.net If you are certain, please provide short and complete module code that leaks memory. (i.e. full module code that compiles as module) It should be by using ext_skel shell script. 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 https://bugs.php.net/bug.php?id=65562 -- Edit this bug report at https://bugs.php.net/bug.php?id=65562edit=1
Bug #65562 [Opn-Fbk]: memory leak in zend_parse_arg
Edit report at https://bugs.php.net/bug.php?id=65562edit=1 ID: 65562 Updated by: s...@php.net Reported by:rrh at newrelic dot com Summary:memory leak in zend_parse_arg -Status: Open +Status: Feedback Type: Bug Package:Performance problem Operating System: all PHP Version:5.5.3 Block user comment: N Private report: N New Comment: Waiting feedback on the patch Previous Comments: [2013-08-26 23:07:33] rrh at newrelic dot com I will test the patch, and in the future come up with patches for your review. [2013-08-26 23:02:38] yohg...@php.net I suspect you have pointer issue. Valgrind does not handle ***(pointer to pointer to pointer) well. Check your hash handling code carefully, it may help. [2013-08-26 23:02:10] johan...@php.net meant to write your problem :-) [2013-08-26 23:01:42] johan...@php.net https://github.com/johannes/php-src/commit/3bfe148c83d6c9b4134ac4fc5f6e0ae36f3f2c42 This might fix your issue. As you won't be telling whether this is our problem I can't properly test it. I'd welcome if you could test it and in future help providing patches. [2013-08-26 22:55:31] yohg...@php.net It should be by using ext_skel shell script. It should be easy by using ext_skel shell script. 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 https://bugs.php.net/bug.php?id=65562 -- Edit this bug report at https://bugs.php.net/bug.php?id=65562edit=1
Bug #65562 [Fbk-Opn]: memory leak in zend_parse_arg
Edit report at https://bugs.php.net/bug.php?id=65562edit=1 ID: 65562 Updated by: johan...@php.net Reported by:rrh at newrelic dot com Summary:memory leak in zend_parse_arg -Status: Feedback +Status: Open Type: Bug Package:Performance problem Operating System: all PHP Version:5.5.3 Block user comment: N Private report: N New Comment: A cleaner patch might pass the quiet argument to zend_parse_arg_impl, this would safe the allocation in there. This also seems to be limited to C and f modifiers which, in PHP itself, aren't used in combination with ZEND_PARSE_PARAMS_QUIET. So for adding a test we might need a deug-build-only functionin zend_builtin_functions.c. This might need coordination with docs and their function detection scripts. And sorry if I'm a bit harsh, but 99% of the internal API bugs we get are user errors and this bug was sparse on information. Previous Comments: [2013-08-26 23:14:26] s...@php.net Waiting feedback on the patch [2013-08-26 23:07:33] rrh at newrelic dot com I will test the patch, and in the future come up with patches for your review. [2013-08-26 23:02:38] yohg...@php.net I suspect you have pointer issue. Valgrind does not handle ***(pointer to pointer to pointer) well. Check your hash handling code carefully, it may help. [2013-08-26 23:02:10] johan...@php.net meant to write your problem :-) [2013-08-26 23:01:42] johan...@php.net https://github.com/johannes/php-src/commit/3bfe148c83d6c9b4134ac4fc5f6e0ae36f3f2c42 This might fix your issue. As you won't be telling whether this is our problem I can't properly test it. I'd welcome if you could test it and in future help providing patches. 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 https://bugs.php.net/bug.php?id=65562 -- Edit this bug report at https://bugs.php.net/bug.php?id=65562edit=1
Bug #65416 [Fbk-Opn]: output buffering autostart setting php.ini
Edit report at https://bugs.php.net/bug.php?id=65416edit=1 ID: 65416 User updated by:jwestbrook at gmail dot com Reported by:jwestbrook at gmail dot com Summary:output buffering autostart setting php.ini -Status: Feedback +Status: Open Type: Bug Package:Output Control Operating System: linux 64bit AWS ami PHP Version:5.4.17 Block user comment: N Private report: N New Comment: Extensions string(4) Core [1]= string(4) date [2]= string(4) ereg [3]= string(6) libxml [4]= string(7) openssl [5]= string(4) pcre [6]= string(4) zlib [7]= string(3) bz2 [8]= string(8) calendar [9]= string(5) ctype [10]= string(4) hash [11]= string(6) filter [12]= string(3) ftp [13]= string(7) gettext [14]= string(3) gmp [15]= string(3) SPL [16]= string(5) iconv [17]= string(10) Reflection [18]= string(7) session [19]= string(8) standard [20]= string(5) shmop [21]= string(9) SimpleXML [22]= string(7) sockets [23]= string(8) mbstring [24]= string(9) tokenizer [25]= string(3) xml [26]= string(14) apache2handler [27]= string(7) gearman [28]= string(4) http [29]= string(4) ssh2 [30]= string(4) curl [31]= string(3) dom [32]= string(8) fileinfo [33]= string(2) gd [34]= string(8) igbinary [35]= string(4) json [36]= string(4) exif [37]= string(6) mcrypt [38]= string(9) memcached [39]= string(7) mysqlnd [40]= string(5) mysql [41]= string(6) mysqli [42]= string(8) newrelic [43]= string(3) PDO [44]= string(9) pdo_mysql [45]= string(10) pdo_sqlite [46]= string(4) Phar [47]= string(5) posix [48]= string(4) snmp [49]= string(4) soap [50]= string(7) sqlite3 [51]= string(7) sysvmsg [52]= string(7) sysvsem [53]= string(7) sysvshm [54]= string(4) wddx [55]= string(9) xmlreader [56]= string(9) xmlwriter [57]= string(3) xsl [58]= string(3) zip [59]= string(5) mhash [60]= string(12) Zend OPcache } string(14) apache2handler 12 requests where I was able to note that the output buffer failed out of 142 requests to that specific script. As a whole I average 150,000 PHP requests per day Previous Comments: [2013-08-26 22:45:23] yohg...@php.net I guess there is some kind of memory problem. What modules are loaded in your web server and SAPI? ?php var_dump(get_loaded_extensions(), php_sapi_name()); ? or paste phpinfo() output. at least 12 times a day PHP fails to start the output buffer and I get the error shown. How many requests a day you have? [2013-08-26 21:35:48] jwestbrook at gmail dot com @mike at php.net Yes that is the bug I'm reporting - the php.ini setting does not start the output buffer on every request. [2013-08-19 22:19:57] m...@php.net Looks like when this is logged, there actually is no output buffer active, so ob_get_length() returns false. [2013-08-19 22:07:01] jwestbrook at gmail dot com I also tried the settings of On and 1. I also understand that #!/usr/bin/php means nothing to output buffering but is output that I want to capture if the php file is being run from a browser and discard. From what I understand that is not how the output buffering works. The way I understand it the output buffer fills then dumps everything when it is full. In this instance before the output buffer fills I want to discard the first 15 characters because it will corrupt any binary files that the browser is trying to download. Based on the test script attached ob_get_length() should ALWAYS return 15 characters - however at least 12 times a day PHP fails to start the output buffer and I get the error shown. [2013-08-18 06:52:49] yohg...@php.net #! does not have special meaning for Web server SAPI. I think you are sending data larger than output buffer size. Then this is the way supposed to be. output_buffering=On or 1 is special. It enables unlimited buffering. Anything other values set buffer chunk size and PHP tries to send data larger than chunk size. Check your buffer size (i.e. output_buffering setting of php.ini file) I guess you have very small output_buffering. Old output buffer increases size automatically, IIRC. New output buffer does not increase buffer size. The remainder of the comments for this report are too long. To view the rest of the comments,
[PHP-BUG] Bug #65564 [NEW]: stack-buffer-overflow in DateTimeZone stuff caught by AddressSanitizer
From: dhiru dot kholia at gmail dot com Operating system: Fedora 19 PHP version: 5.5.3 Package: Reproducible crash Bug Type: Bug Bug description:stack-buffer-overflow in DateTimeZone stuff caught by AddressSanitizer Description: Summary : stack-buffer-overflow exists in DateTimeZone stuff which was caught by AddressSanitizer. I am using Fedora 19's GCC which supports AddressSanitizer. 1. Download and extract php-5.5.3.tar.xz 2. Configure build flags, export CFLAGS=-fsanitize=address -O2 -ggdb export LDFLAGS=-fsanitize=address 3. Build PHP as usual using make. 4. Running ./sapi/cli/php ext/date/tests/DateTimeZone_clone_basic1.php crashes with, *** Testing clone on DateTime objects *** = ==4551== ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7fff0209a9d7 ... READ of size 1 at 0x7fff0209a9d7 thread T0 #0 0xba7a1d in _zend_hash_add_or_update /scratch/php-5.5.3/Zend/zend_hash.c:261 #1 0x43bcb8 in date_object_get_properties_timezone /scratch/php-5.5.3/ext/date/php_date.c:2308 #2 0x9d8594 in php_var_dump /scratch/php-5.5.3/ext/standard/var.c:129 (discriminator 1) #3 0x9d8f1b in zif_var_dump /scratch/php-5.5.3/ext/standard/var.c:183 (discriminator 2) #4 0xdf048c in zend_do_fcall_common_helper_SPEC /scratch/php-5.5.3/Zend/zend_vm_execute.h:543 #5 0xc01a9f in execute_ex /scratch/php-5.5.3/Zend/zend_vm_execute.h:356 #6 0xb8394e in zend_execute_scripts /scratch/php-5.5.3/Zend/zend.c:1316 #7 0xa5b2d4 in php_execute_script /scratch/php-5.5.3/main/main.c:2484 #8 0xdf4ff1 in do_cli /scratch/php-5.5.3/sapi/cli/php_cli.c:994 #9 0x434deb in main /scratch/php-5.5.3/sapi/cli/php_cli.c:1378 #10 0x386b021b74 in ?? ??:0 #11 0x435388 in _start ??:? Test script: --- $ ./sapi/cli/php ext/date/tests/DateTimeZone_clone_basic1.php -- Edit bug report at https://bugs.php.net/bug.php?id=65564edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=65564r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=65564r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=65564r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=65564r=fixed Fixed in release: https://bugs.php.net/fix.php?id=65564r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=65564r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=65564r=needscript Try newer version: https://bugs.php.net/fix.php?id=65564r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=65564r=support Expected behavior: https://bugs.php.net/fix.php?id=65564r=notwrong Not enough info: https://bugs.php.net/fix.php?id=65564r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=65564r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=65564r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=65564r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=65564r=dst IIS Stability: https://bugs.php.net/fix.php?id=65564r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=65564r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=65564r=float No Zend Extensions: https://bugs.php.net/fix.php?id=65564r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=65564r=mysqlcfg
