Bug #64578 [Ver->Csd]: debug_backtrace in set_error_handler corrupts zend heap: segfault
Edit report at https://bugs.php.net/bug.php?id=64578&edit=1 ID: 64578 Updated by: larue...@php.net Reported by:emiel dot mols at gmail dot com Summary:debug_backtrace in set_error_handler corrupts zend heap: segfault -Status: Verified +Status: Closed Type: Bug Package:Reproducible crash Operating System: Irrelevant PHP Version:5.5Git-2013-04-03 (snap) Block user comment: N Private report: N New Comment: Automatic comment on behalf of laruence Revision: http://git.php.net/?p=php-src.git;a=commit;h=c96a5bc6be99ff8a4c5dbc1ea3c04d8144bc47a9 Log: Fixed bug #64578 (debug_backtrace in set_error_handler corrupts zend heap: segfault) Previous Comments: [2013-04-04 05:39:10] larue...@php.net this is actually non-debug-backtrace related issue. a more simple reproduce script (5.3 also); https://bugs.php.net/patch-display.php?bug=64578&patch=bug64578.patch&revision=1365053756 [2013-04-04 03:03:02] larue...@php.net confirmed, I can reproduce this. looking into it now.. [2013-04-03 19:44:37] emiel dot mols at gmail dot com Description: So I thought the other day it might be convenient to grab a stack trace in, you know, the place errors are handled. Apparently, PHP thinks this is a terrible idea. The exact cause is unclear, but I've managed to create a decently small test case that segfaults both on Debian PHP 5.4.4 and Darwin PHP 5.5 nightly. In the attached test script, the call to x() should generate an error, because accessing a string as associative array is forbidden. - the segfault occurs in native _zend_mm_free_int - only able to replicate when there's a function call on the PHP stack - it appears debug_backtrace is only corrupting the stack -- the call to print_r() initiates the segfault. - i've seen $y change every access (eg containing random other variables, or just random heap garbage). - in narrowing down the specific case, I've also often seen messages along the lines of "mm stack corrupt" Core dumps can be found at: - Debian: http://db.tt/aA5wAx7a (16MB) - Darwin: http://db.tt/gxZrP8Pa (400MB) Test script: --- https://bugs.php.net/bug.php?id=64578&edit=1
Bug #64578 [Ver]: debug_backtrace in set_error_handler corrupts zend heap: segfault
Edit report at https://bugs.php.net/bug.php?id=64578&edit=1 ID: 64578 Updated by: larue...@php.net Reported by:emiel dot mols at gmail dot com Summary:debug_backtrace in set_error_handler corrupts zend heap: segfault Status: Verified Type: Bug Package:Reproducible crash Operating System: Irrelevant PHP Version:5.5Git-2013-04-03 (snap) Block user comment: N Private report: N New Comment: this is actually non-debug-backtrace related issue. a more simple reproduce script (5.3 also); https://bugs.php.net/patch-display.php?bug=64578&patch=bug64578.patch&revision=1365053756 [2013-04-04 03:03:02] larue...@php.net confirmed, I can reproduce this. looking into it now.. [2013-04-03 19:44:37] emiel dot mols at gmail dot com Description: So I thought the other day it might be convenient to grab a stack trace in, you know, the place errors are handled. Apparently, PHP thinks this is a terrible idea. The exact cause is unclear, but I've managed to create a decently small test case that segfaults both on Debian PHP 5.4.4 and Darwin PHP 5.5 nightly. In the attached test script, the call to x() should generate an error, because accessing a string as associative array is forbidden. - the segfault occurs in native _zend_mm_free_int - only able to replicate when there's a function call on the PHP stack - it appears debug_backtrace is only corrupting the stack -- the call to print_r() initiates the segfault. - i've seen $y change every access (eg containing random other variables, or just random heap garbage). - in narrowing down the specific case, I've also often seen messages along the lines of "mm stack corrupt" Core dumps can be found at: - Debian: http://db.tt/aA5wAx7a (16MB) - Darwin: http://db.tt/gxZrP8Pa (400MB) Test script: --- https://bugs.php.net/bug.php?id=64578&edit=1
Bug #64578 [PATCH]: debug_backtrace in set_error_handler corrupts zend heap: segfault
Edit report at https://bugs.php.net/bug.php?id=64578&edit=1 ID: 64578 Patch added by: larue...@php.net Reported by:emiel dot mols at gmail dot com Summary:debug_backtrace in set_error_handler corrupts zend heap: segfault Status: Verified Type: Bug Package:Reproducible crash Operating System: Irrelevant PHP Version:5.5Git-2013-04-03 (snap) Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: bug64578.patch Revision: 1365053756 URL: https://bugs.php.net/patch-display.php?bug=64578&patch=bug64578.patch&revision=1365053756 Previous Comments: [2013-04-04 03:03:02] larue...@php.net confirmed, I can reproduce this. looking into it now.. [2013-04-03 19:44:37] emiel dot mols at gmail dot com Description: So I thought the other day it might be convenient to grab a stack trace in, you know, the place errors are handled. Apparently, PHP thinks this is a terrible idea. The exact cause is unclear, but I've managed to create a decently small test case that segfaults both on Debian PHP 5.4.4 and Darwin PHP 5.5 nightly. In the attached test script, the call to x() should generate an error, because accessing a string as associative array is forbidden. - the segfault occurs in native _zend_mm_free_int - only able to replicate when there's a function call on the PHP stack - it appears debug_backtrace is only corrupting the stack -- the call to print_r() initiates the segfault. - i've seen $y change every access (eg containing random other variables, or just random heap garbage). - in narrowing down the specific case, I've also often seen messages along the lines of "mm stack corrupt" Core dumps can be found at: - Debian: http://db.tt/aA5wAx7a (16MB) - Darwin: http://db.tt/gxZrP8Pa (400MB) Test script: --- https://bugs.php.net/bug.php?id=64578&edit=1
Bug #64578 [Opn->Ver]: debug_backtrace in set_error_handler corrupts zend heap: segfault
Edit report at https://bugs.php.net/bug.php?id=64578&edit=1 ID: 64578 Updated by: larue...@php.net Reported by:emiel dot mols at gmail dot com Summary:debug_backtrace in set_error_handler corrupts zend heap: segfault -Status: Open +Status: Verified Type: Bug Package:Reproducible crash Operating System: Irrelevant PHP Version:5.5Git-2013-04-03 (snap) Block user comment: N Private report: N New Comment: confirmed, I can reproduce this. looking into it now.. Previous Comments: [2013-04-03 19:44:37] emiel dot mols at gmail dot com Description: So I thought the other day it might be convenient to grab a stack trace in, you know, the place errors are handled. Apparently, PHP thinks this is a terrible idea. The exact cause is unclear, but I've managed to create a decently small test case that segfaults both on Debian PHP 5.4.4 and Darwin PHP 5.5 nightly. In the attached test script, the call to x() should generate an error, because accessing a string as associative array is forbidden. - the segfault occurs in native _zend_mm_free_int - only able to replicate when there's a function call on the PHP stack - it appears debug_backtrace is only corrupting the stack -- the call to print_r() initiates the segfault. - i've seen $y change every access (eg containing random other variables, or just random heap garbage). - in narrowing down the specific case, I've also often seen messages along the lines of "mm stack corrupt" Core dumps can be found at: - Debian: http://db.tt/aA5wAx7a (16MB) - Darwin: http://db.tt/gxZrP8Pa (400MB) Test script: --- https://bugs.php.net/bug.php?id=64578&edit=1
Bug #63709 [Com]: flock() doesn't trigger mandatory locks on linux
Edit report at https://bugs.php.net/bug.php?id=63709&edit=1 ID: 63709 Comment by: mi+php at aldan dot algebra dot com Reported by:eric dot saintetienne at gmail dot com Summary:flock() doesn't trigger mandatory locks on linux Status: Analyzed Type: Bug Package:Filesystem function related Operating System: Linux PHP Version:5.3.19 Block user comment: N Private report: N New Comment: This is my test case: Running TWO of the above in parallel: % ( php t.php < /dev/null & php t.php < /dev/null ) >& l I see BOTH of them claim to have "successfully" gotten the lock: % cat l [1] 26815 t.php: 26815 21:48:34 /tmp/distd.pid successfully locked t.php: 26814 21:48:34 /tmp/distd.pid successfully locked t.php: 26815 21:48:37 exiting in peace t.php: 26814 21:48:37 exiting in peace Previous Comments: [2013-04-02 07:58:42] eric dot saintetienne at gmail dot com I hope we're still speaking of MANDATORY locks (the ones provided by "mount -o mand") and not standard file locks? Other locks (advisory) behave as expected. So what's the solution you chose to allow locking a file with a MANDATORY lock using PHP? [2013-04-01 23:01:23] mi+php at aldan dot algebra dot com I am puzzled, what can the current behavior be possibly used for? If the lock is not really locking (and it does not -- neither on Linux nor on FreeBSD), then why bother with it at all? And if nobody bothers, then why not fix it properly? BTW, at least, on BSD the different locking mechanisms create compatible locks: The flock(), fcntl(2), and lockf(3) locks are compatible. Processes using different locking interfaces can cooperate over the same file safely. However, only one of such interfaces should be used within the same process. If a file is locked by a process through flock(), any record within the file will be seen as locked from the viewpoint of another process using fcntl(2) or lockf(3), and vice versa. [2012-12-07 09:43:12] eric dot saintetienne at gmail dot com You're right, Python is smart and the trick is simple: fnctl module functions are coded such that they detect the type of the object they're given as argument. If it's an integer they assume it is a file descriptor otherwise they call its fileno() method to retrieve the file descriptor integer. So it's a matter of adding your own fileno() method to the PHP standard file object and making the dio_* routines calling it, when not provided with an integer. Does that makes sense to you? It's a suggestion, at the end of the day it's your decision of how to handle this issue, even though it seems to, I'm actually not pushing to get direct io integrated at any cost (I don't have any stake) but I just feel it's the way to go. [2012-12-07 09:08:01] ahar...@php.net That's true, but they're still somewhat interchangeable in Python â higher level file objects returned by open() work with fcntl methods. That wouldn't be the case if we bundled dio without further work. [2012-12-07 08:55:27] eric dot saintetienne at gmail dot com You're right, dio is a plain inteface to the underlying C function hence exposing real file descriptors (integers). That's also what Python does: it exposes two different types of file objects: standard file objects via the builtin open() and file descriptors via os.open() Is that is feasible with 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=63709 -- Edit this bug report at https://bugs.php.net/bug.php?id=63709&edit=1
Bug #53611 [Com]: fastcgi_param PHP_VALUE pollutes other sites
Edit report at https://bugs.php.net/bug.php?id=53611&edit=1
ID: 53611
Comment by: steven at flechamobile dot com
Reported by:jraxis at gmail dot com
Summary:fastcgi_param PHP_VALUE pollutes other sites
Status: Closed
Type: Bug
Package:FPM related
Operating System: Linux
PHP Version:5.3.4
Assigned To:fat
Block user comment: N
Private report: N
New Comment:
Hi,
I can confirm the bug, I have the same issue.
I have Nginx with php5-fpm as multi vhost (using sites-enabled &
sites-available structure)
for one of my sites I have:
location ~ \.php$ {
try_files $uri =404;
fastcgi_split_path_info ^(.+\.php)(/.+)$;
include fastcgi_params;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME
$document_root$fastcgi_script_name;
fastcgi_param PHP_VALUE "include_path=/path/to/includes";
fastcgi_pass 127.0.0.1:9000;
}
Now my other vhost website (other url) with the same conf setup but minus the
fastcgi_param PHP_VALUE "include_path=/path/to/includes";
line is searching for includes at the exact same place instead of locally.
I'm running Debian 6, nginx + php5-fpm + xcache (+ memcache + memcached).
What files do you need for further investigation?
fpm conf:
;
; FPM Configuration ;
;
; All relative paths in this configuration file are relative to PHP's install
; prefix (/usr). This prefix can be dynamicaly changed by using the
; '-p' argument from the command line.
; Include one or more files. If glob(3) exists, it is used to include a bunch of
; files from a glob(3) pattern. This directive can be used everywhere in the
; file.
; Relative path can also be used. They will be prefixed by:
; - the global prefix if it's been set (-p arguement)
; - /usr otherwise
;include=/etc/php5/fpm/*.conf
;;
; Global Options ;
;;
[global]
; Pid file
; Note: the default prefix is /var
; Default Value: none
pid = /var/run/php5-fpm.pid
; Error log file
; If it's set to "syslog", log is sent to syslogd instead of being written
; in a local file.
; Note: the default prefix is /var
; Default Value: log/php-fpm.log
error_log = /var/log/php5-fpm.log
; syslog_facility is used to specify what type of program is logging the
; message. This lets syslogd specify that messages from different facilities
; will be handled differently.
; See syslog(3) for possible values (ex daemon equiv LOG_DAEMON)
; Default Value: daemon
;syslog.facility = daemon
; syslog_ident is prepended to every message. If you have multiple FPM
; instances running on the same server, you can change the default value
; which must suit common needs.
; Default Value: php-fpm
;syslog.ident = php-fpm
; Log level
; Possible Values: alert, error, warning, notice, debug
; Default Value: notice
;log_level = notice
; If this number of child processes exit with SIGSEGV or SIGBUS within the time
; interval set by emergency_restart_interval then FPM will restart. A value
; of '0' means 'Off'.
; Default Value: 0
emergency_restart_threshold = 10
; Interval of time used by emergency_restart_interval to determine when
; a graceful restart will be initiated. This can be useful to work around
; accidental corruptions in an accelerator's shared memory.
; Available Units: s(econds), m(inutes), h(ours), or d(ays)
; Default Unit: seconds
; Default Value: 0
emergency_restart_interval = 1m
; Time limit for child processes to wait for a reaction on signals from master.
; Available units: s(econds), m(inutes), h(ours), or d(ays)
; Default Unit: seconds
; Default Value: 0
process_control_timeout = 10s
; The maximum number of processes FPM will fork. This has been design to control
; the global number of processes when using dynamic PM within a lot of pools.
; Use it with caution.
; Note: A value of 0 indicates no limit
; Default Value: 0
; process.max = 128
; Specify the nice(2) priority to apply to the master process (only if set)
; The value can vary from -19 (highest priority) to 20 (lower priority)
; Note: - It will only work if the FPM master process is launched as root
; - The pool process will inherit the master process priority
; unless it specified otherwise
; Default Value: no set
; process.priority = -19
; Send FPM to background. Set to 'no' to keep FPM in foreground for debugging.
; Default Value: yes
;daemonize = yes
; Set open file descriptor rlimit for the master process.
; Default Value: system defined value
;rlimit_files = 1024
; Set max core size rlimit for the master process.
; Possible Values: 'unlimited' or an integer greater or equal to 0
; Default Value: system defined value
;rlimit_core = 0
; Specify the event mechanism FPM will use. The following is available:
; - select (any POSIX os)
; - poll (any POSIX os)
; -
Req #38685 [Com]: ER: Allow str_replace with string subject, array replace
Edit report at https://bugs.php.net/bug.php?id=38685&edit=1
ID: 38685
Comment by: jeff at lxvi dot net
Reported by:paulschreiber at gmail dot com
Summary:ER: Allow str_replace with string subject, array
replace
Status: Analyzed
Type: Feature/Change Request
Package:*General Issues
Operating System: any
PHP Version:4.4.4
Block user comment: N
Private report: N
New Comment:
I agree with the OP. There are many possible applications for cycling through
an array of replacements for a single search string. A simple example would be
alternating colors for successive tr tags. There are all kinds of unforeseen
creative ways to utilize this feature, and it should not be necessary to supply
you with an exhaustive list along with a doctoral dissertation.
Previous Comments:
[2013-03-17 16:44:57] paulschreiber at gmail dot com
1. When this bug was written, PDO and other similar libraries did not exist.
2. Prepared statements are only one possible use case.
3. If you are not going to fix this bug, just close it as WONTFIX.
[2013-03-17 16:13:34] ras...@php.net
It is a feature request, not a bug, and one that is rather iffy as far as I am
concerned. It is likely to sit here another 7 years unless accompanied by a
solid
implementation and some better rationale on why we should encourage people to
use
something like this over the native prepare/execute syntax provided by the
databases or even the emulated prepare/execute we provide via PDO.
[2013-03-17 03:57:58] valentiny510 at yahoo dot es
For Paul: The syntax is incorrect.
For PHP Team: 7 years and is still open ???
[2006-09-01 22:46:52] paulschreiber at gmail dot com
Description:
The PHP docs for str_replace say:
"If search and replace are arrays, then str_replace() takes a value from each
array and uses them to do search and replace on subject. If replace has fewer
values than search, then an empty string is used for the rest of replacement
values. If search is an array and replace is a string, then this replacement
string is used for every value of search. The converse would not make sense,
though."
I think the converse makes sense in some cases. Here is an example:
$result = str_replace("?", array("Joe", "Smith"), "SELECT * FROM people WHERE
first = ? AND last = ?");
(Yes, if you were doing real database work, you'd need to escape everything.)
It would be nice if PHP supported this.
Reproduce code:
---
$result = str_replace("?", array("'Joe'", "'Smith'"), "SELECT * FROM people
WHERE first = ? AND last = ?");
print $result;
Expected result:
SELECT * FROM people WHERE first = 'Joe' AND last = 'Smith'
Actual result:
--
PHP Notice: Array to string conversion in /Users/paul/- on line 2
Notice: Array to string conversion in /Users/paul/- on line 2
SELECT * FROM people WHERE first = Array AND last = Array
--
Edit this bug report at https://bugs.php.net/bug.php?id=38685&edit=1
Bug #55737 [Com]: LOAD DATA LOCAL INFILE - The used command is not allowed with this MySQL versio
Edit report at https://bugs.php.net/bug.php?id=55737&edit=1
ID: 55737
Comment by: haertl dot mike at gmail dot com
Reported by:stefan dot kaifer at hartmann dot info
Summary:LOAD DATA LOCAL INFILE - The used command is not
allowed with this MySQL versio
Status: Not a bug
Type: Bug
Package:MySQL related
Operating System: opensuse 11.0
PHP Version:5.3.8
Assigned To:mysql
Block user comment: N
Private report: N
New Comment:
On a client machine this issue went away, when i replaced the MySQL clients
with
those from MariaDB.
Previous Comments:
[2013-03-31 08:57:28] mamm at ya dot ru
I have same problem, ubuntu 12, and load data cant be enabled, works only from
mysql
[2013-03-22 12:27:03] haertl dot mike at gmail dot com
The bug still doesn't seem to be solved. I'm on Ubuntu 12.10 with php-fpm 5.4.6-
1ubuntu1.2 amd64 and still can call "LOAD DATA LOCAL INFILE" through PDO. It's
still the same error:
#1148 - The used command is not allowed with this MySQL version
I've also tried to set "local-infile" in the [client] and [mysql] section of
MySQL`s my.cnf without success. LOAD DATA LOCAL INFILE works fine with the
mysql
client on console though.
[2012-11-22 03:10:32] major_sheisskopf at hotmail dot com
Guys. The answer to this is very easy if you are using the deprecated mysql
functions.
mysql_connect(HOST,USER,PASS,false,128);
Usually, you use mysql_connect without the last 2 optional arguments. But check
out the manual page for it and you'll see that 128 enables LOAD DATA INFILE.
I don't know what the solution is for PDO, as I have not switched over to using
it yet.
[2012-05-06 00:36:40] denis_truffaut at hotmail dot com
To : u...@php.net
This bug appears when you use both PDO (pdo_mysql) and mysqlnd (the php mysql
native driver).
The last time I tested PHP 5.4, it was not solved so i tricked the sources to
make it work, before compiling php.
A dirty fix is :
sudo sed -i -e 's/if (mysql_options(H->server,
MYSQL_OPT_LOCAL_INFILE/local_infile = 1;if (mysql_options(H->server,
MYSQL_OPT_LOCAL_INFILE/g' ext/pdo_mysql/mysql_driver.c
[2012-05-04 13:46:45] u...@php.net
So, what is this report about? If it's on ext/mysql, I call it not a bug. Thus,
closing. If config is correct, things work just fine.
--
$host = "localhost:/var/run/mysql/mysql.sock";
$user = "root";
$pass = "";
$flags = 128;
$db = "test";
printf("PHP %s\n", PHP_VERSION);
$file = getcwd() . DIRECTORY_SEPARATOR . "foo.txt";
if (!($fp = fopen($file, "w")))
die(sprintf("Failed to open '%s' for writing\n", $file));
if (!fwrite($fp, "1;a\n") || !fwrite($fp, "2;b\n"))
die(sprintf("Failed to write to '%s'\n", $file));
fclose($fp);
$sql = sprintf("LOAD DATA LOCAL INFILE '%s' INTO TABLE test FIELDS TERMINATED
BY ';'", $file);
if (!($mysql = mysql_connect($host, $user, $pass, true, $flags)))
die(sprintf("Failed to connect to MySQL\n"));
printf("MySQL %s\n", mysql_get_server_info($mysql));
mysql_select_db($db);
mysql_query("DROP TABLE IF EXISTS test", $mysql);
mysql_query("CREATE TABLE test(id INT, col_a VARCHAR(255))", $mysql);
mysql_close($mysql);
if (!($mysql = mysql_connect($host, $user, $pass, true, $flags)))
die(sprintf("Failed to connect to MySQL\n"));
if (!mysql_db_query($db, $sql, $mysql))
die(sprintf("LOAD DATA failed: %s\n", mysql_error($mysql)));
$res = mysql_query("SELECT * FROM test", $mysql);
while ($row = mysql_fetch_row($res))
var_dump($row);
gives -
PHP 5.3.12-dev
MySQL 5.5.16-log
array(2) {
[0]=>
string(1) "1"
[1]=>
Bug #64577 [Opn]: die or exit on solaris leaves open file descriptors
Edit report at https://bugs.php.net/bug.php?id=64577&edit=1
ID: 64577
User updated by:davek at gamehouse dot com
Reported by:davek at gamehouse dot com
Summary:die or exit on solaris leaves open file descriptors
Status: Open
Type: Bug
Package:Apache2 related
Operating System: solaris 11
PHP Version:5.3.23
Block user comment: N
Private report: N
New Comment:
I build php 5.4.13 and re-ran the test. Same result: open FD's accumulate.
Previous Comments:
[2013-04-03 19:02:20] davek at gamehouse dot com
this may be related to https://bugs.php.net/bug.php?id=47675
and https://bugs.php.net/bug.php?id=60978
I'll verify that I can reproduce the issue with php 5.4
[2013-04-03 18:59:08] davek at gamehouse dot com
Description:
apache 2.4.3 : mod_prefork, keepAlive = Off
php 5.3.23 : ../php-5.3.23/configure'
'--prefix=/opt/ghc/services/php/php5.3.23'
'--with-apxs2=/opt/ghc/services/apache/apache2.4.3-php/bin/apxs' '--with-config-
file-path=/opt/ghc/services/php/php5.3.23/lib' '--disable-all'
phpinfo.php:
./bin/httpd -X &
server> pfiles $(pgrep httpd) |awk '{print $1}' |grep ^[[:digit:]] |wc -l
12
server> pfiles $(pgrep httpd)
25087: ./bin/httpd -X -f /opt/ghc/conf/php_conf/conf/httpd.conf
Current rlimit: 1024 file descriptors
0: S_IFCHR mode:0620 dev:533,11 ino:920560006 uid:0 gid:7 rdev:6,1
O_RDWR|O_NOCTTY|O_LARGEFILE
/dev/pts/1
offset:320891
1: S_IFCHR mode:0620 dev:533,11 ino:920560006 uid:0 gid:7 rdev:6,1
O_RDWR|O_NOCTTY|O_LARGEFILE
/dev/pts/1
offset:320891
2: S_IFREG mode:0644 dev:90,65567 ino:99347 uid:0 gid:0 size:5322
O_WRONLY|O_APPEND|O_CREAT|O_LARGEFILE
/opt/ghc/conf/php_conf/logs/error_log
offset:5322
3: S_IFSOCK mode:0666 dev:540,0 ino:10 uid:0 gid:0 size:0
O_RDWR FD_CLOEXEC
SOCK_STREAM
SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(128000)
sockname: AF_INET 192.168.27.57 port: 80
4: S_IFDOOR mode:0444 dev:542,0 ino:90 uid:0 gid:0 size:0
O_RDONLY|O_LARGEFILE FD_CLOEXEC door to nscd[9126]
/var/run/name_service_door
5: S_IFIFO mode: dev:530,0 ino:21648220 uid:0 gid:0 size:0
O_RDWR|O_NONBLOCK FD_CLOEXEC
6: S_IFIFO mode: dev:530,0 ino:21648220 uid:0 gid:0 size:0
O_RDWR FD_CLOEXEC
7: S_IFREG mode:0644 dev:90,65567 ino:97687 uid:0 gid:0 size:0
O_WRONLY|O_APPEND|O_CREAT|O_LARGEFILE FD_CLOEXEC
/opt/ghc/conf/php_conf/logs/access_log
offset:0
8: S_IFIFO mode: dev:530,0 ino:21648221 uid:0 gid:0 size:0
O_RDWR FD_CLOEXEC
9: S_IFPORT mode: dev:543,0 uid:103 gid:1 size:0
10: S_IFIFO mode: dev:530,0 ino:21648222 uid:0 gid:0 size:0
O_RDWR
client> curl http://server/phpinfo.php
server> pfiles $(pgrep httpd) |awk '{print $1}' |grep ^[[:digit:]] |wc -l
13
server> pfiles $(pgrep httpd)
25087: ./bin/httpd -X -f /opt/ghc/conf/php_conf/conf/httpd.conf
Current rlimit: 1024 file descriptors
0: S_IFCHR mode:0620 dev:533,11 ino:920560006 uid:0 gid:7 rdev:6,1
O_RDWR|O_NOCTTY|O_LARGEFILE
/dev/pts/1
offset:324283
1: S_IFCHR mode:0620 dev:533,11 ino:920560006 uid:0 gid:7 rdev:6,1
O_RDWR|O_NOCTTY|O_LARGEFILE
/dev/pts/1
offset:324283
2: S_IFREG mode:0644 dev:90,65567 ino:99347 uid:0 gid:0 size:5322
O_WRONLY|O_APPEND|O_CREAT|O_LARGEFILE
/opt/ghc/conf/php_conf/logs/error_log
offset:5322
3: S_IFSOCK mode:0666 dev:540,0 ino:10 uid:0 gid:0 size:0
O_RDWR FD_CLOEXEC
SOCK_STREAM
SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(128000)
sockname: AF_INET 192.168.27.57 port: 80
4: S_IFDOOR mode:0444 dev:542,0 ino:90 uid:0 gid:0 size:0
O_RDONLY|O_LARGEFILE FD_CLOEXEC door to nscd[9126]
/var/run/name_service_door
5: S_IFIFO mode: dev:530,0 ino:21648220 uid:0 gid:0 size:0
O_RDWR|O_NONBLOCK FD_CLOEXEC
6: S_IFIFO mode: dev:530,0 ino:21648220 uid:0 gid:0 size:0
O_RDWR FD_CLOEXEC
7: S_IFREG mode:0644 dev:90,65567 ino:97687 uid:0 gid:0 size:0
O_WRONLY|O_APPEND|O_CREAT|O_LARGEFILE FD_CLOEXEC
/opt/ghc/conf/php_conf/logs/access_log
offset:0
8: S_IFIFO mode: dev:530,0 ino:21648221 uid:0 gid:0 size:0
O_RDWR FD_CLOEXEC
9: S_IFPORT mode: dev:543,0 uid:103 gid:1 size:0
10: S_IFIFO mode: dev:530,0 ino:21648222 uid:0 gid:0 size:0
O_RDWR
13: S_IFDIR mode:0755 dev:90,65567 ino:21918 uid:0 gid:0 size:22
O_RDONLY
/opt/ghc/services/apache/apache2.4.3-php
offset:0
client> curl http://server/phpinfo.php
server> pfiles $(pgrep httpd) |awk '{print $1}' |grep ^[[:digit:]] |wc -l
14
server> pfiles $(pgrep httpd)
25087: ./bin/httpd -X -f /opt/ghc/conf/php_conf/conf/httpd.conf
Curr
Bug #53742 [Com]: Late static binding does not work via reflection
Edit report at https://bugs.php.net/bug.php?id=53742&edit=1
ID: 53742
Comment by: david at orlandophp dot org
Reported by:blue-tidus159 at hotmail dot com
Summary:Late static binding does not work via reflection
Status: Closed
Type: Bug
Package:Scripting Engine problem
Operating System: Windows 7 x64
PHP Version:Irrelevant
Assigned To:laruence
Block user comment: N
Private report: N
New Comment:
Any chance this will get back-ported into older versions? It's still broken in
PHP 5.3.x up until 5.3.8, which represents a widely distributed range of
versions.
Previous Comments:
[2011-12-21 07:13:42] larue...@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/.
For Windows:
http://windows.php.net/snapshots/
Thank you for the report, and for helping us make PHP better.
dup to #60367
[2011-12-21 07:02:47] will dot fitch at gmail dot com
This is fixed in 5.4 and HEAD:
Fatal error: Class A contains 1 abstract method and must therefore be declared
abstract or implement the remaining methods (A::callLate)
[2011-08-04 19:13:37] josh at joshbutts dot com
Still exists in PHP 5.3.5. Reproducible with the script above.
[2011-05-12 20:06:23] phdaemon at gmail dot com
I experienced this bug when building a new automation framework using PHPUnit +
selenium.
IT seems that PHPUnit uses reflection to instantiate a static function called
suite which handles an array of browsers and duplicating a testcase to run in
each one.
I was on the latest ubuntu package: PHP 5.3.3-1ubuntu9.5 with Suhosin-Patch
(cli) (built: May 3 2011 00:49:55)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
I got around it by switching the reflection to call_user_func but this should
probably be fixed as PHPUnit is very popular.
[2011-01-13 21:22:52] blue-tidus159 at hotmail dot com
Description:
When a static method is called through reflection, late static binding does not
work. Probably because the getMethod() returns the method associated to the
parent class.
Test script:
---
class A{
public static function call(){
static::callLate();
}
public static abstract function callLate();
}
class B{
public static function callLate(){
echo 'Late static binding';
}
}
B::call();
$class = new ReflectionClass('B');
$class->getMethod('call')->invoke(null);
Expected result:
Late static binding
Late static binding
Actual result:
--
Late static binding
Cannot call abstract method B::callLate()
--
Edit this bug report at https://bugs.php.net/bug.php?id=53742&edit=1
Bug #60367 [Com]: Reflection and Late Static Binding
Edit report at https://bugs.php.net/bug.php?id=60367&edit=1
ID: 60367
Comment by: david at orlandophp dot org
Reported by:woody dot gilk at kohanaframework dot org
Summary:Reflection and Late Static Binding
Status: Closed
Type: Bug
Package:Scripting Engine problem
Operating System: OSX 10.6.8
PHP Version:5.3.8
Assigned To:laruence
Block user comment: N
Private report: N
New Comment:
Any chance this will be back-ported to older versions of PHP? This bug affects
the Reflection API in all versions of PHP from 5.3 to 5.3.8, which is widely
distributed. A patch release would be appreciated.
Previous Comments:
[2012-07-24 23:38:29] ras...@php.net
Automatic comment on behalf of laruence
Revision:
http://git.php.net/?p=php-src.git;a=commit;h=e0137255164d3eb544efd9737ebb5f76477e7f33
Log: Fixed bug #60367 (Reflection and Late Static Binding)
[2012-04-18 09:47:22] larue...@php.net
Automatic comment on behalf of laruence
Revision:
http://git.php.net/?p=php-src.git;a=commit;h=e0137255164d3eb544efd9737ebb5f76477e7f33
Log: Fixed bug #60367 (Reflection and Late Static Binding)
[2011-11-24 09:18:10] larue...@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/.
For Windows:
http://windows.php.net/snapshots/
Thank you for the report, and for helping us make PHP better.
[2011-11-24 09:15:59] larue...@php.net
Automatic comment from SVN on behalf of laruence
Revision: http://svn.php.net/viewvc/?view=revision&revision=319745
Log: Fixed bug #60367 (Reflection and Late Static Binding)
[2011-11-23 16:57:44] woody dot gilk at kohanaframework dot org
Description:
When calling a method that exists only in the parent class with Reflection, the
incorrect class is used.
This bug is highly related to #53742, but has a different test case. The root
cause may be exactly the same.
Test script:
---
abstract class A {
const WHAT = 'wrong';
public static function call() {
echo static::WHAT;
}
}
class B extends A {
const WHAT = 'correct';
}
B::call();
$class = new ReflectionClass('B');
$class->getMethod('call')->invoke(null);
Expected result:
"correct"
Actual result:
--
"wrong"
--
Edit this bug report at https://bugs.php.net/bug.php?id=60367&edit=1
Bug #64573 [Com]: Confusing open_basedir errors when parent folders are inaccessible
Edit report at https://bugs.php.net/bug.php?id=64573&edit=1
ID: 64573
Comment by: mail+php at requinix dot net
Reported by:bradley dot will at gmail dot com
Summary:Confusing open_basedir errors when parent folders
are inaccessible
Status: Open
Type: Bug
Package:Filesystem function related
Operating System: Windows 2008
PHP Version:5.3.23
Block user comment: N
Private report: N
New Comment:
Ah, I remember this bug. The overall problem is that the file access fails and
calling code assumes the reason is an open_basedir restriction.
See also:
- bug 44901 (file does not exist)
- bug 52065 and bug 53041 (accessing "foo/bar" where foo is an existing *file*)
Previous Comments:
[2013-04-03 03:11:41] bradley dot will at gmail dot com
Description:
Tested on Windows; Linux's behavior is as expected. I'm using a Plesk
install but I think this will happen with any similar folder structure.
Basically, open_basedir or require_once give confusing error messages when
multiple parent folders to the open_basedir have security settings which
prevent
access.
The confusing error messages are pasted under Actual Result; "open_basedir
restriction in effect. File() is not within the allowed path(s)" is the first
error seen, which is an incorrect error; the file IS within the allowed path.
Only the second error message, Operation not permitted, is somewhat accurate.
However it is still suboptimal compared to the other error condition:
When only the open_basedir itself (and not its parent folder) has security
settings which prevent access, the error message is what I would expect.
The expected error message is pasted under Expected Result; "Permission denied"
is the appropriate error to use when file/folder permissions are preventing
access to a file or folder, not "operation not permitted."
Test script:
---
";
echo shell_exec("whoami")."---\n";
echo htmlentities(shell_exec("cd C:\Program Files (x86)\Parallels\ &&
dir"))."---\n";
echo htmlentities(shell_exec("cd C:\Program Files (x86)\Parallels\Plesk\ &&
dir"))."---\n";
echo htmlentities(shell_exec("cd C:\Program Files
(x86)\Parallels\Plesk\Additional\ &&
dir"))."---\n";
echo htmlentities(shell_exec("cd C:\Program Files
(x86)\Parallels\Plesk\Additional\PleskPHP5\ &&
dir"))."---\n";
echo htmlentities(shell_exec("cd C:\Program Files
(x86)\Parallels\Plesk\Additional\PleskPHP5\PEAR\ &&
dir"))."---\n";
if(isset($_GET["open"])){
if(require_once('C:\Program Files
(x86)\Parallels\Plesk\Additional\PleskPHP5\PEAR\MDB2.php')){
echo "OPENED\n"; }
else {echo "FAILED TO OPEN\n"; } }
echo 'Try opening file';
echo "";
Expected result:
When any file/folder security setting causes the file to be inaccessible:
PHP Warning: require_once(C:\Program Files
(x86)\Parallels\Plesk\Additional\PleskPHP5\PEAR\MDB2.php): failed to open
stream:
Permission denied in
C:\inetpub\vhosts\server.example.net\site.example.net\siteControllerCommon\test.p
hp on line 16
PHP Fatal error: require_once(): Failed opening required 'C:\Program Files
(x86)\Parallels\Plesk\Additional\PleskPHP5\PEAR\MDB2.php'
(include_path='.;./includes;./pear') in
C:\inetpub\vhosts\server.example.net\site.example.net\siteControllerCommon\test.p
hp on line 16
Actual result:
--
When the Additional (including PleskPHP5 folder by inheritance) AND PEAR
folders
are inaccessible to the user:
PHP Warning: require_once(): open_basedir restriction in effect.
File(C:/Program Files (x86)/Parallels/Plesk/Additional/PleskPHP5/PEAR/MDB2.php)
is not within the allowed path(s):
(C:/Inetpub/vhosts/server.example.net\;C:\Windows\Temp\;C:\Program Files
(x86)\Parallels\Plesk\Additional\PleskPHP5\PEAR\) in
C:\inetpub\vhosts\server.example.net\site.example.net\test.php on line 2
PHP Warning: require_once(C:/Program Files
(x86)/Parallels/Plesk/Additional/PleskPHP5/PEAR/MDB2.php): failed to open
stream: Operation not permitted in
C:\inetpub\vhosts\server.example.net\site.example.net\test.php on line 2
PHP Fatal error: require_once(): Failed opening required 'C:/Program Files
(x86)/Parallels/Plesk/Additional/PleskPHP5/PEAR/MDB2.php'
(include_path='.;./includes;./pear') in
C:\inetpub\vhosts\server.example.net\site.example.net\test.php on line 2
When only the PEAR folder is inaccessible to the user:
PHP Warning: require_once(C:\Program Files
(x86)\Parallels\Plesk\Additional\PleskPHP5\PEAR\MDB2.php): failed to open
stream: Permission denied in
C:\inetpub\vhosts\server.example.net\s
[PHP-BUG] Bug #64578 [NEW]: debug_backtrace in set_error_handler corrupts zend heap: segfault
From: emiel dot mols at gmail dot com Operating system: Irrelevant PHP version: 5.5Git-2013-04-03 (snap) Package: Reproducible crash Bug Type: Bug Bug description:debug_backtrace in set_error_handler corrupts zend heap: segfault Description: So I thought the other day it might be convenient to grab a stack trace in, you know, the place errors are handled. Apparently, PHP thinks this is a terrible idea. The exact cause is unclear, but I've managed to create a decently small test case that segfaults both on Debian PHP 5.4.4 and Darwin PHP 5.5 nightly. In the attached test script, the call to x() should generate an error, because accessing a string as associative array is forbidden. - the segfault occurs in native _zend_mm_free_int - only able to replicate when there's a function call on the PHP stack - it appears debug_backtrace is only corrupting the stack -- the call to print_r() initiates the segfault. - i've seen $y change every access (eg containing random other variables, or just random heap garbage). - in narrowing down the specific case, I've also often seen messages along the lines of "mm stack corrupt" Core dumps can be found at: - Debian: http://db.tt/aA5wAx7a (16MB) - Darwin: http://db.tt/gxZrP8Pa (400MB) Test script: --- https://bugs.php.net/bug.php?id=64578&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=64578&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=64578&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=64578&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=64578&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=64578&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=64578&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=64578&r=needscript Try newer version: https://bugs.php.net/fix.php?id=64578&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=64578&r=support Expected behavior: https://bugs.php.net/fix.php?id=64578&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=64578&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=64578&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=64578&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=64578&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=64578&r=dst IIS Stability: https://bugs.php.net/fix.php?id=64578&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=64578&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=64578&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=64578&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=64578&r=mysqlcfg
Bug #64577 [Opn]: die or exit on solaris leaves open file descriptors
Edit report at https://bugs.php.net/bug.php?id=64577&edit=1
ID: 64577
User updated by:davek at gamehouse dot com
Reported by:davek at gamehouse dot com
Summary:die or exit on solaris leaves open file descriptors
Status: Open
Type: Bug
Package:Apache2 related
Operating System: solaris 11
PHP Version:5.3.23
Block user comment: N
Private report: N
New Comment:
this may be related to https://bugs.php.net/bug.php?id=47675
and https://bugs.php.net/bug.php?id=60978
I'll verify that I can reproduce the issue with php 5.4
Previous Comments:
[2013-04-03 18:59:08] davek at gamehouse dot com
Description:
apache 2.4.3 : mod_prefork, keepAlive = Off
php 5.3.23 : ../php-5.3.23/configure'
'--prefix=/opt/ghc/services/php/php5.3.23'
'--with-apxs2=/opt/ghc/services/apache/apache2.4.3-php/bin/apxs' '--with-config-
file-path=/opt/ghc/services/php/php5.3.23/lib' '--disable-all'
phpinfo.php:
./bin/httpd -X &
server> pfiles $(pgrep httpd) |awk '{print $1}' |grep ^[[:digit:]] |wc -l
12
server> pfiles $(pgrep httpd)
25087: ./bin/httpd -X -f /opt/ghc/conf/php_conf/conf/httpd.conf
Current rlimit: 1024 file descriptors
0: S_IFCHR mode:0620 dev:533,11 ino:920560006 uid:0 gid:7 rdev:6,1
O_RDWR|O_NOCTTY|O_LARGEFILE
/dev/pts/1
offset:320891
1: S_IFCHR mode:0620 dev:533,11 ino:920560006 uid:0 gid:7 rdev:6,1
O_RDWR|O_NOCTTY|O_LARGEFILE
/dev/pts/1
offset:320891
2: S_IFREG mode:0644 dev:90,65567 ino:99347 uid:0 gid:0 size:5322
O_WRONLY|O_APPEND|O_CREAT|O_LARGEFILE
/opt/ghc/conf/php_conf/logs/error_log
offset:5322
3: S_IFSOCK mode:0666 dev:540,0 ino:10 uid:0 gid:0 size:0
O_RDWR FD_CLOEXEC
SOCK_STREAM
SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(128000)
sockname: AF_INET 192.168.27.57 port: 80
4: S_IFDOOR mode:0444 dev:542,0 ino:90 uid:0 gid:0 size:0
O_RDONLY|O_LARGEFILE FD_CLOEXEC door to nscd[9126]
/var/run/name_service_door
5: S_IFIFO mode: dev:530,0 ino:21648220 uid:0 gid:0 size:0
O_RDWR|O_NONBLOCK FD_CLOEXEC
6: S_IFIFO mode: dev:530,0 ino:21648220 uid:0 gid:0 size:0
O_RDWR FD_CLOEXEC
7: S_IFREG mode:0644 dev:90,65567 ino:97687 uid:0 gid:0 size:0
O_WRONLY|O_APPEND|O_CREAT|O_LARGEFILE FD_CLOEXEC
/opt/ghc/conf/php_conf/logs/access_log
offset:0
8: S_IFIFO mode: dev:530,0 ino:21648221 uid:0 gid:0 size:0
O_RDWR FD_CLOEXEC
9: S_IFPORT mode: dev:543,0 uid:103 gid:1 size:0
10: S_IFIFO mode: dev:530,0 ino:21648222 uid:0 gid:0 size:0
O_RDWR
client> curl http://server/phpinfo.php
server> pfiles $(pgrep httpd) |awk '{print $1}' |grep ^[[:digit:]] |wc -l
13
server> pfiles $(pgrep httpd)
25087: ./bin/httpd -X -f /opt/ghc/conf/php_conf/conf/httpd.conf
Current rlimit: 1024 file descriptors
0: S_IFCHR mode:0620 dev:533,11 ino:920560006 uid:0 gid:7 rdev:6,1
O_RDWR|O_NOCTTY|O_LARGEFILE
/dev/pts/1
offset:324283
1: S_IFCHR mode:0620 dev:533,11 ino:920560006 uid:0 gid:7 rdev:6,1
O_RDWR|O_NOCTTY|O_LARGEFILE
/dev/pts/1
offset:324283
2: S_IFREG mode:0644 dev:90,65567 ino:99347 uid:0 gid:0 size:5322
O_WRONLY|O_APPEND|O_CREAT|O_LARGEFILE
/opt/ghc/conf/php_conf/logs/error_log
offset:5322
3: S_IFSOCK mode:0666 dev:540,0 ino:10 uid:0 gid:0 size:0
O_RDWR FD_CLOEXEC
SOCK_STREAM
SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(128000)
sockname: AF_INET 192.168.27.57 port: 80
4: S_IFDOOR mode:0444 dev:542,0 ino:90 uid:0 gid:0 size:0
O_RDONLY|O_LARGEFILE FD_CLOEXEC door to nscd[9126]
/var/run/name_service_door
5: S_IFIFO mode: dev:530,0 ino:21648220 uid:0 gid:0 size:0
O_RDWR|O_NONBLOCK FD_CLOEXEC
6: S_IFIFO mode: dev:530,0 ino:21648220 uid:0 gid:0 size:0
O_RDWR FD_CLOEXEC
7: S_IFREG mode:0644 dev:90,65567 ino:97687 uid:0 gid:0 size:0
O_WRONLY|O_APPEND|O_CREAT|O_LARGEFILE FD_CLOEXEC
/opt/ghc/conf/php_conf/logs/access_log
offset:0
8: S_IFIFO mode: dev:530,0 ino:21648221 uid:0 gid:0 size:0
O_RDWR FD_CLOEXEC
9: S_IFPORT mode: dev:543,0 uid:103 gid:1 size:0
10: S_IFIFO mode: dev:530,0 ino:21648222 uid:0 gid:0 size:0
O_RDWR
13: S_IFDIR mode:0755 dev:90,65567 ino:21918 uid:0 gid:0 size:22
O_RDONLY
/opt/ghc/services/apache/apache2.4.3-php
offset:0
client> curl http://server/phpinfo.php
server> pfiles $(pgrep httpd) |awk '{print $1}' |grep ^[[:digit:]] |wc -l
14
server> pfiles $(pgrep httpd)
25087: ./bin/httpd -X -f /opt/ghc/conf/php_conf/conf/httpd.conf
Current rlimit: 1024 file descriptors
0: S_IFCHR mode:0620 dev:533,11 ino:920560006 uid:0 gid:7 rdev:6,1
O_RDWR|O_NOCTTY|O_LARGEFILE
/dev/pts/1
offset:327991
1: S_IFCHR mode:0620 d
[PHP-BUG] Bug #64577 [NEW]: die or exit on solaris leaves open file descriptors
From: davek at gamehouse dot com
Operating system: solaris 11
PHP version: 5.3.23
Package: Apache2 related
Bug Type: Bug
Bug description:die or exit on solaris leaves open file descriptors
Description:
apache 2.4.3 : mod_prefork, keepAlive = Off
php 5.3.23 : ../php-5.3.23/configure'
'--prefix=/opt/ghc/services/php/php5.3.23'
'--with-apxs2=/opt/ghc/services/apache/apache2.4.3-php/bin/apxs'
'--with-config-
file-path=/opt/ghc/services/php/php5.3.23/lib' '--disable-all'
phpinfo.php:
./bin/httpd -X &
server> pfiles $(pgrep httpd) |awk '{print $1}' |grep ^[[:digit:]] |wc -l
12
server> pfiles $(pgrep httpd)
25087: ./bin/httpd -X -f /opt/ghc/conf/php_conf/conf/httpd.conf
Current rlimit: 1024 file descriptors
0: S_IFCHR mode:0620 dev:533,11 ino:920560006 uid:0 gid:7 rdev:6,1
O_RDWR|O_NOCTTY|O_LARGEFILE
/dev/pts/1
offset:320891
1: S_IFCHR mode:0620 dev:533,11 ino:920560006 uid:0 gid:7 rdev:6,1
O_RDWR|O_NOCTTY|O_LARGEFILE
/dev/pts/1
offset:320891
2: S_IFREG mode:0644 dev:90,65567 ino:99347 uid:0 gid:0 size:5322
O_WRONLY|O_APPEND|O_CREAT|O_LARGEFILE
/opt/ghc/conf/php_conf/logs/error_log
offset:5322
3: S_IFSOCK mode:0666 dev:540,0 ino:10 uid:0 gid:0 size:0
O_RDWR FD_CLOEXEC
SOCK_STREAM
SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(128000)
sockname: AF_INET 192.168.27.57 port: 80
4: S_IFDOOR mode:0444 dev:542,0 ino:90 uid:0 gid:0 size:0
O_RDONLY|O_LARGEFILE FD_CLOEXEC door to nscd[9126]
/var/run/name_service_door
5: S_IFIFO mode: dev:530,0 ino:21648220 uid:0 gid:0 size:0
O_RDWR|O_NONBLOCK FD_CLOEXEC
6: S_IFIFO mode: dev:530,0 ino:21648220 uid:0 gid:0 size:0
O_RDWR FD_CLOEXEC
7: S_IFREG mode:0644 dev:90,65567 ino:97687 uid:0 gid:0 size:0
O_WRONLY|O_APPEND|O_CREAT|O_LARGEFILE FD_CLOEXEC
/opt/ghc/conf/php_conf/logs/access_log
offset:0
8: S_IFIFO mode: dev:530,0 ino:21648221 uid:0 gid:0 size:0
O_RDWR FD_CLOEXEC
9: S_IFPORT mode: dev:543,0 uid:103 gid:1 size:0
10: S_IFIFO mode: dev:530,0 ino:21648222 uid:0 gid:0 size:0
O_RDWR
client> curl http://server/phpinfo.php
server> pfiles $(pgrep httpd) |awk '{print $1}' |grep ^[[:digit:]] |wc -l
13
server> pfiles $(pgrep httpd)
25087: ./bin/httpd -X -f /opt/ghc/conf/php_conf/conf/httpd.conf
Current rlimit: 1024 file descriptors
0: S_IFCHR mode:0620 dev:533,11 ino:920560006 uid:0 gid:7 rdev:6,1
O_RDWR|O_NOCTTY|O_LARGEFILE
/dev/pts/1
offset:324283
1: S_IFCHR mode:0620 dev:533,11 ino:920560006 uid:0 gid:7 rdev:6,1
O_RDWR|O_NOCTTY|O_LARGEFILE
/dev/pts/1
offset:324283
2: S_IFREG mode:0644 dev:90,65567 ino:99347 uid:0 gid:0 size:5322
O_WRONLY|O_APPEND|O_CREAT|O_LARGEFILE
/opt/ghc/conf/php_conf/logs/error_log
offset:5322
3: S_IFSOCK mode:0666 dev:540,0 ino:10 uid:0 gid:0 size:0
O_RDWR FD_CLOEXEC
SOCK_STREAM
SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(128000)
sockname: AF_INET 192.168.27.57 port: 80
4: S_IFDOOR mode:0444 dev:542,0 ino:90 uid:0 gid:0 size:0
O_RDONLY|O_LARGEFILE FD_CLOEXEC door to nscd[9126]
/var/run/name_service_door
5: S_IFIFO mode: dev:530,0 ino:21648220 uid:0 gid:0 size:0
O_RDWR|O_NONBLOCK FD_CLOEXEC
6: S_IFIFO mode: dev:530,0 ino:21648220 uid:0 gid:0 size:0
O_RDWR FD_CLOEXEC
7: S_IFREG mode:0644 dev:90,65567 ino:97687 uid:0 gid:0 size:0
O_WRONLY|O_APPEND|O_CREAT|O_LARGEFILE FD_CLOEXEC
/opt/ghc/conf/php_conf/logs/access_log
offset:0
8: S_IFIFO mode: dev:530,0 ino:21648221 uid:0 gid:0 size:0
O_RDWR FD_CLOEXEC
9: S_IFPORT mode: dev:543,0 uid:103 gid:1 size:0
10: S_IFIFO mode: dev:530,0 ino:21648222 uid:0 gid:0 size:0
O_RDWR
13: S_IFDIR mode:0755 dev:90,65567 ino:21918 uid:0 gid:0 size:22
O_RDONLY
/opt/ghc/services/apache/apache2.4.3-php
offset:0
client> curl http://server/phpinfo.php
server> pfiles $(pgrep httpd) |awk '{print $1}' |grep ^[[:digit:]] |wc -l
14
server> pfiles $(pgrep httpd)
25087: ./bin/httpd -X -f /opt/ghc/conf/php_conf/conf/httpd.conf
Current rlimit: 1024 file descriptors
0: S_IFCHR mode:0620 dev:533,11 ino:920560006 uid:0 gid:7 rdev:6,1
O_RDWR|O_NOCTTY|O_LARGEFILE
/dev/pts/1
offset:327991
1: S_IFCHR mode:0620 dev:533,11 ino:920560006 uid:0 gid:7 rdev:6,1
O_RDWR|O_NOCTTY|O_LARGEFILE
/dev/pts/1
offset:327991
2: S_IFREG mode:0644 dev:90,65567 ino:99347 uid:0 gid:0 size:5322
O_WRONLY|O_APPEND|O_CREAT|O_LARGEFILE
/opt/ghc/conf/php_conf/logs/error_log
offset:5322
3: S_IFSOCK mode:0666 dev:540,0 ino:10 uid:0 gid:0 size:0
O_RDWR FD_CLOEXEC
SOCK_STREAM
SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(128000)
sockname: AF_INET 192.168.27.57 port: 80
4: S_IFDOOR mode:0444 dev:542,0
Req #26338 [Opn->Csd]: Add function for fetching column from an array
Edit report at https://bugs.php.net/bug.php?id=26338&edit=1
ID: 26338
Updated by: ni...@php.net
Reported by:Xuefer at 21cn dot com
Summary:Add function for fetching column from an array
-Status: Open
+Status: Closed
Type: Feature/Change Request
Package:*General Issues
Operating System: all
PHP Version:4.3.4
-Assigned To:
+Assigned To:nikic
Block user comment: N
Private report: N
New Comment:
array_column has been merged for PHP 5.5.
Previous Comments:
[2013-03-15 14:56:22] ni...@php.net
RFC for this feature was accepted, but not yet merged:
https://wiki.php.net/rfc/array_column
[2003-11-24 22:30:34] Xuefer at 21cn dot com
if anyone think we should not modify array_values
i have anohter suggested name:
array_column($array, $whichColumn)
because it's mostly used to get all fields(foreah row) in one column
[2003-11-20 22:51:27] Xuefer at 21cn dot com
Description:
old:
Usage: array array_values ( array input )
Purpose: Return all the values of an array
new suggestion:
Usage: array array_values ( array input, [mixed key] )
Purpose: Return all the values of an array
key default to null, which is same as old array_values
if key is_int or is_string
it act like this:
function array_values($input, $key)
{
$ret = array();
foreach ($input as $value) {
$ret[] = $value[$key];
}
return $ret;
}
this is very useful to collect ids
e.g.:
$idrows = db_query_all_rows("select id from table1");
$ids = implode(',', array_values($idrows, 'id'));
$myrows = db_query_all_rows("select from table2 where id IN($ids)");
(db_query_all_rows is custom function which fetch all rows of query result)
thanks
--
Edit this bug report at https://bugs.php.net/bug.php?id=26338&edit=1
Bug #64555 [Com]: foreach no longer copies keys if they seem to be interned
Edit report at https://bugs.php.net/bug.php?id=64555&edit=1
ID: 64555
Comment by: ni...@php.net
Reported by:ar...@php.net
Summary:foreach no longer copies keys if they seem to be
interned
Status: Closed
Type: Bug
Package:Scripting Engine problem
PHP Version:5.5.0beta1
Assigned To:nikic
Block user comment: N
Private report: N
New Comment:
I went with always copying the key for now. Doing the copy in get_object_vars
might be better, but would require a more thorough review of where else this
could go wrong.
Previous Comments:
[2013-04-03 18:33:42] ni...@php.net
Automatic comment on behalf of nikic
Revision:
http://git.php.net/?p=php-src.git;a=commit;h=1f34ccbe34783f5671bc2a68e7299cea7493c82b
Log: Fix bug #64555: foreach no longer copies keys if they are interned
[2013-03-31 11:24:50] ar...@php.net
N.B. This indirectly causes a fatal error when using ZF1 forms so the impact is
very high.
[2013-03-31 11:21:13] ar...@php.net
Description:
Foreach used to always copy string keys:
key_type = zend_hash_get_current_key_ex(fe_ht, &str_key, &str_key_len,
&int_key, 1, NULL);
Since fcc6611de9054327441786e52444b5f8eecdd525 it instead uses:
zend_hash_get_current_key_zval(fe_ht, key);
This only copies string keys if IS_INTERNED(), however in some cases (at least
in get_object_vars() like in the test script) the key name is an unmangled
property name which is *within* an interned string. So IS_INTERNED is true but
INTERNED_LEN and INTERNED_HASH are nonsense.
The later unset and assignment in the test script use the nonsense
INTERNED_HASH.
The simple fix is to make get_object_vars() copy the property names (as in the
attached patch) but it's quite possible that other code has been broken in the
same way, so the safer fix might be to force the copy again.
Test script:
---
https://gist.github.com/arraypad/5280321
Expected result:
Unsetting: unsetme
Changing: keepme
array(1) {
["keepme"]=>
int(43)
}
array(1) {
[0]=>
string(6) "keepme"
}
Actual result:
--
Unsetting: unsetme
Changing: keepme
array(3) {
["unsetme"]=>
int(1)
["keepme"]=>
int(43)
["keepme"]=>
int(42)
}
array(3) {
[0]=>
string(7) "unsetme"
[1]=>
string(6) "keepme"
[2]=>
string(6) "keepme"
}
--
Edit this bug report at https://bugs.php.net/bug.php?id=64555&edit=1
Bug #64555 [Asn->Csd]: foreach no longer copies keys if they seem to be interned
Edit report at https://bugs.php.net/bug.php?id=64555&edit=1
ID: 64555
Updated by: ni...@php.net
Reported by:ar...@php.net
Summary:foreach no longer copies keys if they seem to be
interned
-Status: Assigned
+Status: Closed
Type: Bug
Package:Scripting Engine problem
PHP Version:5.5.0beta1
Assigned To:nikic
Block user comment: N
Private report: N
New Comment:
Automatic comment on behalf of nikic
Revision:
http://git.php.net/?p=php-src.git;a=commit;h=1f34ccbe34783f5671bc2a68e7299cea7493c82b
Log: Fix bug #64555: foreach no longer copies keys if they are interned
Previous Comments:
[2013-03-31 11:24:50] ar...@php.net
N.B. This indirectly causes a fatal error when using ZF1 forms so the impact is
very high.
[2013-03-31 11:21:13] ar...@php.net
Description:
Foreach used to always copy string keys:
key_type = zend_hash_get_current_key_ex(fe_ht, &str_key, &str_key_len,
&int_key, 1, NULL);
Since fcc6611de9054327441786e52444b5f8eecdd525 it instead uses:
zend_hash_get_current_key_zval(fe_ht, key);
This only copies string keys if IS_INTERNED(), however in some cases (at least
in get_object_vars() like in the test script) the key name is an unmangled
property name which is *within* an interned string. So IS_INTERNED is true but
INTERNED_LEN and INTERNED_HASH are nonsense.
The later unset and assignment in the test script use the nonsense
INTERNED_HASH.
The simple fix is to make get_object_vars() copy the property names (as in the
attached patch) but it's quite possible that other code has been broken in the
same way, so the safer fix might be to force the copy again.
Test script:
---
https://gist.github.com/arraypad/5280321
Expected result:
Unsetting: unsetme
Changing: keepme
array(1) {
["keepme"]=>
int(43)
}
array(1) {
[0]=>
string(6) "keepme"
}
Actual result:
--
Unsetting: unsetme
Changing: keepme
array(3) {
["unsetme"]=>
int(1)
["keepme"]=>
int(43)
["keepme"]=>
int(42)
}
array(3) {
[0]=>
string(7) "unsetme"
[1]=>
string(6) "keepme"
[2]=>
string(6) "keepme"
}
--
Edit this bug report at https://bugs.php.net/bug.php?id=64555&edit=1
[PHP-BUG] Bug #64576 [NEW]: stream_notification_callback doesn't seem to work
From: zelnaga at gmail dot com Operating system: Windows 7 PHP version: 5.4.13 Package: Streams related Bug Type: Bug Bug description:stream_notification_callback doesn't seem to work Description: http://www.php.net/manual/en/function.stream-notification-callback.php Per that I'd wouldn't expect the following test scripts to produce errors but they do. Test script: --- 'callback')); ?> 'callback')); ?> Expected result: (blank) Actual result: -- Warning: stream_context_create(): options should have the form ["wrappername"] ["optionname"] = $value in /path/to/file.php on line 2 -- Edit bug report at https://bugs.php.net/bug.php?id=64576&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=64576&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=64576&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=64576&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=64576&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=64576&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=64576&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=64576&r=needscript Try newer version: https://bugs.php.net/fix.php?id=64576&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=64576&r=support Expected behavior: https://bugs.php.net/fix.php?id=64576&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=64576&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=64576&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=64576&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=64576&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=64576&r=dst IIS Stability: https://bugs.php.net/fix.php?id=64576&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=64576&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=64576&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=64576&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=64576&r=mysqlcfg
Bug #64568 [Fbk->Nab]: opcache no loadable
Edit report at https://bugs.php.net/bug.php?id=64568&edit=1
ID: 64568
Updated by: johan...@php.net
Reported by:bugzilla77 at gmail dot com
Summary:opcache no loadable
-Status: Feedback
+Status: Not a bug
Type: Bug
Package:opcache
Operating System: windows
PHP Version:5.5.0beta1
Block user comment: N
Private report: N
New Comment:
There are a few differences, many you won'T really notice (load order,
available internal hooks, ...) and some user notable (you can't use dl() on
Zend Extensions, there's different reflection, ...) which won't allow easy
unification. Especially as there are logical differences (Zend Extensions are
loaded by and into the engine, and the engine is more or less independent from
"PHP" where PHP extensions (modules) are loaded.
We'll most likely improve the error reporting in this situation:
http://news.php.net/php.internals/66909 everything else require major
refactoring.
Closing this issue.
Previous Comments:
[2013-04-03 11:00:21] bugzilla77 at gmail dot com
Add dll automatic detection (extension / Zend extension) for syntax unification.
>From the user point view there is no difference.
[2013-04-03 08:23:55] johan...@php.net
"extension" loads PHP modules, "zend_extension" loads Zend extensions. Those
are different things so there are different directives.
[2013-04-03 06:42:48] bugzilla77 at gmail dot com
Works,
but ini syntax for dlls is: extension=
not
zend_extension=
[2013-04-02 21:22:51] s...@php.net
Try Beta 2 and use zend_extension=php_opcache.dll
[2013-04-02 19:48:14] bugzilla77 at gmail dot com
Description:
opcache no loadable
Test script:
---
php.ini add: extension=php_opcache.dll
Expected result:
opcache in phpinfo()
extension_loaded('opcache') returns true
Actual result:
--
no opcache in phpinfo()
extension_loaded('opcache') returns false
--
Edit this bug report at https://bugs.php.net/bug.php?id=64568&edit=1
Bug #64568 [Com]: opcache no loadable
Edit report at https://bugs.php.net/bug.php?id=64568&edit=1
ID: 64568
Comment by: bugzilla77 at gmail dot com
Reported by:bugzilla77 at gmail dot com
Summary:opcache no loadable
Status: Feedback
Type: Bug
Package:opcache
Operating System: windows
PHP Version:5.5.0beta1
Block user comment: N
Private report: N
New Comment:
Add dll automatic detection (extension / Zend extension) for syntax unification.
>From the user point view there is no difference.
Previous Comments:
[2013-04-03 08:23:55] johan...@php.net
"extension" loads PHP modules, "zend_extension" loads Zend extensions. Those
are different things so there are different directives.
[2013-04-03 06:42:48] bugzilla77 at gmail dot com
Works,
but ini syntax for dlls is: extension=
not
zend_extension=
[2013-04-02 21:22:51] s...@php.net
Try Beta 2 and use zend_extension=php_opcache.dll
[2013-04-02 19:48:14] bugzilla77 at gmail dot com
Description:
opcache no loadable
Test script:
---
php.ini add: extension=php_opcache.dll
Expected result:
opcache in phpinfo()
extension_loaded('opcache') returns true
Actual result:
--
no opcache in phpinfo()
extension_loaded('opcache') returns false
--
Edit this bug report at https://bugs.php.net/bug.php?id=64568&edit=1
Bug #64572 [Opn->Csd]: Tests leave junk around
Edit report at https://bugs.php.net/bug.php?id=64572&edit=1 ID: 64572 Updated by: larue...@php.net Reported by:php at paulisageek dot com Summary:Tests leave junk around -Status: Open +Status: Closed Type: Bug Package:Testing related Operating System: all PHP Version:5.5.0beta1 Block user comment: N Private report: N New Comment: Automatic comment on behalf of ptar...@fb.com Revision: http://git.php.net/?p=php-src.git;a=commit;h=99ad08f9a5e696654676e9db8872e4198b738936 Log: Fix #64572: Clean up after the test Previous Comments: [2013-04-03 04:20:53] larue...@php.net I saw you made a PR at github could you please also connected them with this entry? thanks [2013-04-03 02:23:27] php at paulisageek dot com Description: Tests should clean up after themselves. Most of them do, but many don't. I'll be attaching many diffs to this task cleaning them up as I import them to HHVM. -- Edit this bug report at https://bugs.php.net/bug.php?id=64572&edit=1
Req #61931 [Com]: Built-in web server should have a seperate log file
Edit report at https://bugs.php.net/bug.php?id=61931&edit=1 ID: 61931 Comment by: clavie dot b at gmail dot com Reported by:roberts at x0 dot lv Summary:Built-in web server should have a seperate log file Status: Open Type: Feature/Change Request Package:Built-in web server Operating System: Windows PHP Version:5.4.2 Block user comment: N Private report: N New Comment: Hi, I agree that it should be possible to redirect the log to a separate file. But I would see that as an option to the built-in server command rather than a new ini configuration option. Previous Comments: [2012-05-03 20:46:19] roberts at x0 dot lv Description: All PHP version 5.4.+ built-in web servers does log errors only in STDOUT with no option to redirect this output to file via command line option. Command line redirect would not be a option here, as because one needs to stop PHP web server instance before output gets written to the file. There should be .ini option added - server_log or similar, to configure log output to file or to STDOUT. -- Edit this bug report at https://bugs.php.net/bug.php?id=61931&edit=1
Bug #64568 [Fbk]: opcache no loadable
Edit report at https://bugs.php.net/bug.php?id=64568&edit=1
ID: 64568
Updated by: johan...@php.net
Reported by:bugzilla77 at gmail dot com
Summary:opcache no loadable
Status: Feedback
Type: Bug
Package:opcache
Operating System: windows
PHP Version:5.5.0beta1
Block user comment: N
Private report: N
New Comment:
"extension" loads PHP modules, "zend_extension" loads Zend extensions. Those
are different things so there are different directives.
Previous Comments:
[2013-04-03 06:42:48] bugzilla77 at gmail dot com
Works,
but ini syntax for dlls is: extension=
not
zend_extension=
[2013-04-02 21:22:51] s...@php.net
Try Beta 2 and use zend_extension=php_opcache.dll
[2013-04-02 19:48:14] bugzilla77 at gmail dot com
Description:
opcache no loadable
Test script:
---
php.ini add: extension=php_opcache.dll
Expected result:
opcache in phpinfo()
extension_loaded('opcache') returns true
Actual result:
--
no opcache in phpinfo()
extension_loaded('opcache') returns false
--
Edit this bug report at https://bugs.php.net/bug.php?id=64568&edit=1
Bug #64561 [Opn]: new GD ext functions missing from gd_compat.h
Edit report at https://bugs.php.net/bug.php?id=64561&edit=1 ID: 64561 Updated by: paj...@php.net Reported by:ond...@php.net Summary:new GD ext functions missing from gd_compat.h Status: Open Type: Bug Package:GD related Operating System: Any PHP Version:5.5.0beta1 Block user comment: N Private report: N New Comment: Quick note, only the generic functions (affine, rotate, scale and set interpolation method) will be added to userland. Previous Comments: [2013-04-03 06:44:58] ond...@php.net Same applies for gdImageRotateInterpolated and probably many other new functions added. [2013-04-02 07:02:15] ond...@php.net Description: php5 fails to load gd extension due to using symbol only available from bundled libgd. libgd/gd_compat.h misses the definition of gdImagePaletteToTrueColor and the function needs to be moved from gd.c to gd_color.c. (Or something like that.) And it definitely needs a test in the test suite (or you can finally take over the libgd2 and release a new version for everyone, pretty please). Expected result: # php5 # Actual result: -- # php5 PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib/php5/20121212+lfs/gd.so' - /usr/lib/php5/20121212+lfs/gd.so: undefined symbol: gdImagePaletteToTrueColor in Unknown on line 0 # -- Edit this bug report at https://bugs.php.net/bug.php?id=64561&edit=1
