[PHP-BUG] Req #62994 [NEW]: Disallow some magic methods been generators
From: reeze dot xia at gmail dot com
Operating system:
PHP version: master-Git-2012-09-02 (Git)
Package: Scripting Engine problem
Bug Type: Feature/Change Request
Bug description:Disallow some magic methods been generators
Description:
magic method are called in a special way, if those methods
was defined as generator, most of them will not work as expected.
We could disallow them when compiling.
Test script:
---
class A {
public function __construct(array $data) {
$this-initData = $data;
// maybe more initialization...
var_dump($this-initData);
foreach$(this-initData as $v) {
yield $v;
}
}
}
$a = new A(array(1, 2)); // constructor didn't get called.
so does the that magic methods:
http://www.php.net/manual/en/language.oop5.magic.php
most of them are meanning less if they are generators.
*some of them* maybe useful if they return value but not void.
Those could be allowed: __call(), __callStatic(), __get(), __invoke()
but those seems meaningless to be generators
__construct(), __destruct(), __set(), __isset(), __unset(), __sleep(),
__wakeup(), __toString(), __set_state() and __clone(),
--
Edit bug report at https://bugs.php.net/bug.php?id=62994edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=62994r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=62994r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=62994r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=62994r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=62994r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=62994r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=62994r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=62994r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=62994r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=62994r=support
Expected behavior:
https://bugs.php.net/fix.php?id=62994r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=62994r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=62994r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=62994r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=62994r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=62994r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=62994r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=62994r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=62994r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=62994r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=62994r=mysqlcfg
Req #62994 [Com]: Disallow some magic methods been generators
Edit report at https://bugs.php.net/bug.php?id=62994edit=1
ID: 62994
Comment by: larue...@php.net
Reported by:reeze dot xia at gmail dot com
Summary:Disallow some magic methods been generators
Status: Assigned
Type: Feature/Change Request
Package:Scripting Engine problem
PHP Version:master-Git-2012-09-02 (Git)
Assigned To:nikic
Block user comment: N
Private report: N
New Comment:
it's not about magic methods, it's about the calling to user function in
internal
should be changed properly.
I don't think disallow is a good solution.
nikic, cannot yield simply be considered as return in such situation ?
Previous Comments:
[2012-09-02 07:46:53] reeze dot xia at gmail dot com
Description:
magic method are called in a special way, if those methods
was defined as generator, most of them will not work as expected.
We could disallow them when compiling.
Test script:
---
class A {
public function __construct(array $data) {
$this-initData = $data;
// maybe more initialization...
var_dump($this-initData);
foreach$(this-initData as $v) {
yield $v;
}
}
}
$a = new A(array(1, 2)); // constructor didn't get called.
so does the that magic methods:
http://www.php.net/manual/en/language.oop5.magic.php
most of them are meanning less if they are generators.
*some of them* maybe useful if they return value but not void.
Those could be allowed: __call(), __callStatic(), __get(), __invoke()
but those seems meaningless to be generators
__construct(), __destruct(), __set(), __isset(), __unset(), __sleep(),
__wakeup(), __toString(), __set_state() and __clone(),
--
Edit this bug report at https://bugs.php.net/bug.php?id=62994edit=1
Req #62994 [Asn-Nab]: Disallow some magic methods been generators
Edit report at https://bugs.php.net/bug.php?id=62994edit=1
ID: 62994
Updated by: larue...@php.net
Reported by:reeze dot xia at gmail dot com
Summary:Disallow some magic methods been generators
-Status: Assigned
+Status: Not a bug
Type: Feature/Change Request
Package:Scripting Engine problem
PHP Version:master-Git-2012-09-02 (Git)
-Assigned To:nikic
+Assigned To:
Block user comment: N
Private report: N
New Comment:
hmm, after a test, I found I misunderstood your mean about not work as
expected.
I think this is definitely a wrong usage...
there is nothing wrong with generators. disallowing make no sense at all.
Previous Comments:
[2012-09-02 07:55:23] larue...@php.net
it's not about magic methods, it's about the calling to user function in
internal
should be changed properly.
I don't think disallow is a good solution.
nikic, cannot yield simply be considered as return in such situation ?
[2012-09-02 07:46:53] reeze dot xia at gmail dot com
Description:
magic method are called in a special way, if those methods
was defined as generator, most of them will not work as expected.
We could disallow them when compiling.
Test script:
---
class A {
public function __construct(array $data) {
$this-initData = $data;
// maybe more initialization...
var_dump($this-initData);
foreach$(this-initData as $v) {
yield $v;
}
}
}
$a = new A(array(1, 2)); // constructor didn't get called.
so does the that magic methods:
http://www.php.net/manual/en/language.oop5.magic.php
most of them are meanning less if they are generators.
*some of them* maybe useful if they return value but not void.
Those could be allowed: __call(), __callStatic(), __get(), __invoke()
but those seems meaningless to be generators
__construct(), __destruct(), __set(), __isset(), __unset(), __sleep(),
__wakeup(), __toString(), __set_state() and __clone(),
--
Edit this bug report at https://bugs.php.net/bug.php?id=62994edit=1
Req #62994 [Nab]: Disallow some magic methods been generators
Edit report at https://bugs.php.net/bug.php?id=62994edit=1
ID: 62994
Updated by: larue...@php.net
Reported by:reeze dot xia at gmail dot com
Summary:Disallow some magic methods been generators
Status: Not a bug
Type: Feature/Change Request
Package:Scripting Engine problem
PHP Version:master-Git-2012-09-02 (Git)
Block user comment: N
Private report: N
New Comment:
like:
$a = new A;
foreach ($a-__construct() as $v) {
}
since we don't disallow call to __construct(magic methods) directly(although I
don't like this).
Previous Comments:
[2012-09-02 08:00:39] larue...@php.net
hmm, after a test, I found I misunderstood your mean about not work as
expected.
I think this is definitely a wrong usage...
there is nothing wrong with generators. disallowing make no sense at all.
[2012-09-02 07:55:23] larue...@php.net
it's not about magic methods, it's about the calling to user function in
internal
should be changed properly.
I don't think disallow is a good solution.
nikic, cannot yield simply be considered as return in such situation ?
[2012-09-02 07:46:53] reeze dot xia at gmail dot com
Description:
magic method are called in a special way, if those methods
was defined as generator, most of them will not work as expected.
We could disallow them when compiling.
Test script:
---
class A {
public function __construct(array $data) {
$this-initData = $data;
// maybe more initialization...
var_dump($this-initData);
foreach$(this-initData as $v) {
yield $v;
}
}
}
$a = new A(array(1, 2)); // constructor didn't get called.
so does the that magic methods:
http://www.php.net/manual/en/language.oop5.magic.php
most of them are meanning less if they are generators.
*some of them* maybe useful if they return value but not void.
Those could be allowed: __call(), __callStatic(), __get(), __invoke()
but those seems meaningless to be generators
__construct(), __destruct(), __set(), __isset(), __unset(), __sleep(),
__wakeup(), __toString(), __set_state() and __clone(),
--
Edit this bug report at https://bugs.php.net/bug.php?id=62994edit=1
Bug #62991 [Asn]: Segfault with generator and closure.
Edit report at https://bugs.php.net/bug.php?id=62991edit=1
ID: 62991
Updated by: larue...@php.net
Reported by:softwareelves at gmail dot com
Summary:Segfault with generator and closure.
Status: Assigned
Type: Bug
Package:Reproducible crash
Operating System: Mac OSx 10.8.1
PHP Version:master-Git-2012-09-02 (Git)
Assigned To:nikic
Block user comment: N
Private report: N
New Comment:
seems the closure has been released after it was executed while destruct the
outter scope..
Previous Comments:
[2012-09-02 01:58:12] softwareelves at gmail dot com
Description:
If you create a generator-closure inside of a function and call that function
before returning it, it'll cause memory corruption causing a segfault.
Test script:
---
?php
function test( array $array )
{
$closure = function() use ( $array ) {
var_dump( $array );
yield hi;
};
return $closure(); // if you return the $closure and call it outside
this function it works.
}
$generator = test( array( 1, 2, 3 ) );
foreach( $generator as $something ) {
// Segmentation fault: 11
}
Expected result:
array(3) { [0]= int(1) [1]= int(2) [2]= int(3) }
Actual result:
--
Segmentation fault: 11
--
Edit this bug report at https://bugs.php.net/bug.php?id=62991edit=1
Bug #62954 [Com]: startup problems fpm / php-fpm
Edit report at https://bugs.php.net/bug.php?id=62954edit=1
ID: 62954
Comment by: jonas at brachium-system dot net
Reported by:jonas at brachium-system dot net
Summary:startup problems fpm / php-fpm
Status: Feedback
Type: Bug
Package:FPM related
Operating System: Linux
PHP Version:5.3Git-2012-08-27 (Git)
Assigned To:fat
Block user comment: N
Private report: N
New Comment:
PHP 5.3.16-dev (fpm-fcgi) (built: Sep 2 2012 04:56:07)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2012 Zend Technologies
I have tried it with the current branch PHP-5.3.
It started two times correctly (Starts and detaches) after the second start the
problem occurs again.
So problem is not fixed - I have not tried 5.4 since fpm sapi is the same.
Previous Comments:
[2012-09-01 19:41:16] tony2...@php.net
I can't reproduce it here:
# /tmp/fpm/sbin/php-fpm -v
PHP 5.4.8-dev (fpm-fcgi) (built: Sep 1 2012 23:36:17) (DEBUG)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2012 Zend Technologies
It starts, spawns its children and detaches from terminal with no problem at
all.
Can you try the latest snapshot and check if you still can reproduce the issue?
[2012-08-27 22:54:12] al-php at none dot at
same problem here.
./configure --prefix=/prefix/ --enable-fpm --enable-bcmath --with-bz2
--enable-calendar --with-curl --enable-dba --enable-exif --enable-ftp
--enable-gd-native-ttf --with-jpeg-dir --with-png-dir --with-t1lib
--with-freetype-dir --with-gettext --enable-mbstring --with-mcrypt --with-mhash
--with-mysql=mysqlnd --with-mysqli=mysqlnd --with-pdo-mysql=mysqlnd
--enable-mysqlnd --with-openssl --with-pcre-regex --with-pspell --enable-shmop
--enable-soap --enable-sockets --enable-sysvmsg --enable-wddx --with-xsl
--enable-zip --with-zlib --with-tcadb --with-openssl-dir --with-gd
###
bin/php -v
PHP 5.4.5 (cli) (built: Aug 8 2012 01:03:00)
Copyright (c) 1997-2012 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2012 Zend Technologies
###
root@Ubuntu-1204-precise-64-minimal ~ # strace -fveall -p 2590 -p 2589
Process 2590 attached - interrupt to quit
Process 2589 attached - interrupt to quit
[pid 2589] wait4(-1, unfinished ...
[pid 2590] futex(0x7fc2a4d73720, FUTEX_WAIT_PRIVATE, 2, NULL
###
[2012-08-27 19:50:31] jonas at brachium-system dot net
Description:
PHP 5.3.14 with FPM on Debian Squeze works without any problems.
The PHP Version 5.3.15 / 5.3.16 and current Git branch PHP 5.3 is affected.
/usr/sbin/php5-fpm --fpm-config /etc/php5/fpm/php-fpm.conf
All pools are started and working, but the php5-fpm does not detach:
/usr/sbin/php5-fpm --fpm-config /etc/php5/fpm/php-fpm.conf
and here it hangs. ctrl +c does not work.
strace tells me:
Process 15949 attached - interrupt to quit
futex(0x7fb923e8ce40, FUTEX_WAIT_PRIVATE, 2, NULL
If I switch the configuration option daemonize to no php-fpm starts up
normal and can be aborted with ctrl+c.
If I copy sapi/fpm from 5.3.14 to the current php-src from git and compile it
again my configuration and php-fpm works and starts normal.
If I remove the USR1/USR2 handling from sapi/fpm/fpm/fpm_unix.c ( see patch )
php-fpm starts normal and detach correctly.
I think (See:
http://groups.google.com/group/highload-php-en/browse_thread/thread/fa6b16d533411f42)
PHP 5.4 branch is also affected.
PHP-FPM Configration:
-
[global]
pid = /var/run/php5-fpm.pid
error_log = /var/log/php5-fpm.log
daemonize = yes
[cust-websrv]
listen = /tmp/cust-webserv.socket
user = www-data
group = www-data
pm = dynamic
pm.max_children = 130
pm.start_servers = 15
pm.min_spare_servers = 5
pm.max_spare_servers = 15
pm.max_requests = 500
chdir = /
env[APPLICATION_ENV] = prod
[is-tracking]
listen = /tmp/is-tracking.socket
user = www-data
group = www-data
pm = dynamic
pm.max_children = 130
pm.start_servers = 15
pm.min_spare_servers = 5
pm.max_spare_servers = 15
pm.max_requests = 5000
chdir = /
env[APPLICATION_ENV] = prod
[limesurvey]
listen = /tmp/limesurvey.socket
user = www-data
group = www-data
pm = dynamic
pm.max_children = 40
pm.start_servers = 5
pm.min_spare_servers = 4
pm.max_spare_servers = 5
pm.max_requests = 500
chdir = /
env[APPLICATION_ENV] = prod
Actual result:
--
strace, with the problem:
open(/var/log/php5-fpm.log, O_WRONLY|O_CREAT|O_APPEND, 0600) = 3
fcntl(3, F_GETFD) = 0
fcntl(3, F_SETFD, FD_CLOEXEC) = 0
stat(/, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
stat(/, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
stat(/, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
geteuid()
rt_sigaction(SIGUSR1,
Bug #62991 [PATCH]: Segfault with generator and closure.
Edit report at https://bugs.php.net/bug.php?id=62991edit=1
ID: 62991
Patch added by: larue...@php.net
Reported by:softwareelves at gmail dot com
Summary:Segfault with generator and closure.
Status: Assigned
Type: Bug
Package:Reproducible crash
Operating System: Mac OSx 10.8.1
PHP Version:master-Git-2012-09-02 (Git)
Assigned To:nikic
Block user comment: N
Private report: N
New Comment:
The following patch has been added/updated:
Patch Name: bug62991.patch
Revision: 1346579695
URL:
https://bugs.php.net/patch-display.php?bug=62991patch=bug62991.patchrevision=1346579695
Previous Comments:
[2012-09-02 08:25:57] larue...@php.net
seems the closure has been released after it was executed while destruct the
outter scope..
[2012-09-02 01:58:12] softwareelves at gmail dot com
Description:
If you create a generator-closure inside of a function and call that function
before returning it, it'll cause memory corruption causing a segfault.
Test script:
---
?php
function test( array $array )
{
$closure = function() use ( $array ) {
var_dump( $array );
yield hi;
};
return $closure(); // if you return the $closure and call it outside
this function it works.
}
$generator = test( array( 1, 2, 3 ) );
foreach( $generator as $something ) {
// Segmentation fault: 11
}
Expected result:
array(3) { [0]= int(1) [1]= int(2) [2]= int(3) }
Actual result:
--
Segmentation fault: 11
--
Edit this bug report at https://bugs.php.net/bug.php?id=62991edit=1
Bug #62991 [Com]: Segfault with generator and closure.
Edit report at https://bugs.php.net/bug.php?id=62991edit=1
ID: 62991
Comment by: larue...@php.net
Reported by:softwareelves at gmail dot com
Summary:Segfault with generator and closure.
Status: Assigned
Type: Bug
Package:Reproducible crash
Operating System: Mac OSx 10.8.1
PHP Version:master-Git-2012-09-02 (Git)
Assigned To:nikic
Block user comment: N
Private report: N
New Comment:
I got a fix for this. nikic, could you please review this? thanks
Previous Comments:
[2012-09-02 09:54:55] larue...@php.net
The following patch has been added/updated:
Patch Name: bug62991.patch
Revision: 1346579695
URL:
https://bugs.php.net/patch-display.php?bug=62991patch=bug62991.patchrevision=1346579695
[2012-09-02 08:25:57] larue...@php.net
seems the closure has been released after it was executed while destruct the
outter scope..
[2012-09-02 01:58:12] softwareelves at gmail dot com
Description:
If you create a generator-closure inside of a function and call that function
before returning it, it'll cause memory corruption causing a segfault.
Test script:
---
?php
function test( array $array )
{
$closure = function() use ( $array ) {
var_dump( $array );
yield hi;
};
return $closure(); // if you return the $closure and call it outside
this function it works.
}
$generator = test( array( 1, 2, 3 ) );
foreach( $generator as $something ) {
// Segmentation fault: 11
}
Expected result:
array(3) { [0]= int(1) [1]= int(2) [2]= int(3) }
Actual result:
--
Segmentation fault: 11
--
Edit this bug report at https://bugs.php.net/bug.php?id=62991edit=1
Bug #62991 [PATCH]: Segfault with generator and closure.
Edit report at https://bugs.php.net/bug.php?id=62991edit=1
ID: 62991
Patch added by: larue...@php.net
Reported by:softwareelves at gmail dot com
Summary:Segfault with generator and closure.
Status: Assigned
Type: Bug
Package:Reproducible crash
Operating System: Mac OSx 10.8.1
PHP Version:master-Git-2012-09-02 (Git)
Assigned To:nikic
Block user comment: N
Private report: N
New Comment:
The following patch has been added/updated:
Patch Name: bug62991.patch
Revision: 1346579896
URL:
https://bugs.php.net/patch-display.php?bug=62991patch=bug62991.patchrevision=1346579896
Previous Comments:
[2012-09-02 09:55:35] larue...@php.net
I got a fix for this. nikic, could you please review this? thanks
[2012-09-02 09:54:55] larue...@php.net
The following patch has been added/updated:
Patch Name: bug62991.patch
Revision: 1346579695
URL:
https://bugs.php.net/patch-display.php?bug=62991patch=bug62991.patchrevision=1346579695
[2012-09-02 08:25:57] larue...@php.net
seems the closure has been released after it was executed while destruct the
outter scope..
[2012-09-02 01:58:12] softwareelves at gmail dot com
Description:
If you create a generator-closure inside of a function and call that function
before returning it, it'll cause memory corruption causing a segfault.
Test script:
---
?php
function test( array $array )
{
$closure = function() use ( $array ) {
var_dump( $array );
yield hi;
};
return $closure(); // if you return the $closure and call it outside
this function it works.
}
$generator = test( array( 1, 2, 3 ) );
foreach( $generator as $something ) {
// Segmentation fault: 11
}
Expected result:
array(3) { [0]= int(1) [1]= int(2) [2]= int(3) }
Actual result:
--
Segmentation fault: 11
--
Edit this bug report at https://bugs.php.net/bug.php?id=62991edit=1
Bug #62991 [Com]: Segfault with generator and closure.
Edit report at https://bugs.php.net/bug.php?id=62991edit=1
ID: 62991
Comment by: larue...@php.net
Reported by:softwareelves at gmail dot com
Summary:Segfault with generator and closure.
Status: Assigned
Type: Bug
Package:Reproducible crash
Operating System: Mac OSx 10.8.1
PHP Version:master-Git-2012-09-02 (Git)
Assigned To:nikic
Block user comment: N
Private report: N
New Comment:
update patch, fix tabs
Previous Comments:
[2012-09-02 09:58:16] larue...@php.net
The following patch has been added/updated:
Patch Name: bug62991.patch
Revision: 1346579896
URL:
https://bugs.php.net/patch-display.php?bug=62991patch=bug62991.patchrevision=1346579896
[2012-09-02 09:55:35] larue...@php.net
I got a fix for this. nikic, could you please review this? thanks
[2012-09-02 09:54:55] larue...@php.net
The following patch has been added/updated:
Patch Name: bug62991.patch
Revision: 1346579695
URL:
https://bugs.php.net/patch-display.php?bug=62991patch=bug62991.patchrevision=1346579695
[2012-09-02 08:25:57] larue...@php.net
seems the closure has been released after it was executed while destruct the
outter scope..
[2012-09-02 01:58:12] softwareelves at gmail dot com
Description:
If you create a generator-closure inside of a function and call that function
before returning it, it'll cause memory corruption causing a segfault.
Test script:
---
?php
function test( array $array )
{
$closure = function() use ( $array ) {
var_dump( $array );
yield hi;
};
return $closure(); // if you return the $closure and call it outside
this function it works.
}
$generator = test( array( 1, 2, 3 ) );
foreach( $generator as $something ) {
// Segmentation fault: 11
}
Expected result:
array(3) { [0]= int(1) [1]= int(2) [2]= int(3) }
Actual result:
--
Segmentation fault: 11
--
Edit this bug report at https://bugs.php.net/bug.php?id=62991edit=1
Bug #62991 [Com]: Segfault with generator and closure.
Edit report at https://bugs.php.net/bug.php?id=62991edit=1
ID: 62991
Comment by: ni...@php.net
Reported by:softwareelves at gmail dot com
Summary:Segfault with generator and closure.
Status: Assigned
Type: Bug
Package:Reproducible crash
Operating System: Mac OSx 10.8.1
PHP Version:master-Git-2012-09-02 (Git)
Assigned To:nikic
Block user comment: N
Private report: N
New Comment:
@laruence: The patch looks fine for me.
The only thing that looks strange are these whitespace changes:
-ZEND_BEGIN_ARG_INFO_EX(arginfo_closure_bindto, 0, 0, 1)
+ ZEND_BEGIN_ARG_INFO_EX(arginfo_closure_bindto, 0, 0, 1)
ZEND_ARG_INFO(0, newthis)
ZEND_ARG_INFO(0, newscope)
ZEND_END_ARG_INFO()
-ZEND_BEGIN_ARG_INFO_EX(arginfo_closure_bind, 0, 0, 2)
+ ZEND_BEGIN_ARG_INFO_EX(arginfo_closure_bind, 0, 0, 2)
ZEND_ARG_INFO(0, closure)
ZEND_ARG_INFO(0, newthis)
ZEND_ARG_INFO(0, newscope)
ZEND_END_ARG_INFO()
-static const zend_function_entry closure_functions[] = {
- ZEND_ME(Closure, __construct, NULL, ZEND_ACC_PRIVATE)
- ZEND_ME(Closure, bind, arginfo_closure_bind,
ZEND_ACC_PUBLIC|ZEND_ACC_STATIC)
- ZEND_MALIAS(Closure, bindTo, bind, arginfo_closure_bindto,
ZEND_ACC_PUBLIC)
- {NULL, NULL, NULL}
-};
+ static const zend_function_entry closure_functions[] = {
+ ZEND_ME(Closure, __construct, NULL, ZEND_ACC_PRIVATE)
+ ZEND_ME(Closure, bind, arginfo_closure_bind,
ZEND_ACC_PUBLIC|ZEND_ACC_STATIC)
+ ZEND_MALIAS(Closure, bindTo, bind,
arginfo_closure_bindto, ZEND_ACC_PUBLIC)
+ {NULL, NULL, NULL}
+ };
Looks like the indentation is slightly off there :)
Previous Comments:
[2012-09-02 09:58:39] larue...@php.net
update patch, fix tabs
[2012-09-02 09:58:16] larue...@php.net
The following patch has been added/updated:
Patch Name: bug62991.patch
Revision: 1346579896
URL:
https://bugs.php.net/patch-display.php?bug=62991patch=bug62991.patchrevision=1346579896
[2012-09-02 09:55:35] larue...@php.net
I got a fix for this. nikic, could you please review this? thanks
[2012-09-02 09:54:55] larue...@php.net
The following patch has been added/updated:
Patch Name: bug62991.patch
Revision: 1346579695
URL:
https://bugs.php.net/patch-display.php?bug=62991patch=bug62991.patchrevision=1346579695
[2012-09-02 08:25:57] larue...@php.net
seems the closure has been released after it was executed while destruct the
outter scope..
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=62991
--
Edit this bug report at https://bugs.php.net/bug.php?id=62991edit=1
Bug #62991 [Com]: Segfault with generator and closure.
Edit report at https://bugs.php.net/bug.php?id=62991edit=1
ID: 62991
Comment by: ni...@php.net
Reported by:softwareelves at gmail dot com
Summary:Segfault with generator and closure.
Status: Assigned
Type: Bug
Package:Reproducible crash
Operating System: Mac OSx 10.8.1
PHP Version:master-Git-2012-09-02 (Git)
Assigned To:nikic
Block user comment: N
Private report: N
New Comment:
Oh, and also, I think it would be a little bit nicer if this:
+ if (execute_data-op_array-fn_flags ZEND_ACC_CLOSURE) {
+ destroy_op_array(execute_data-op_array);
+ efree(execute_data-op_array);
+ }
would be written as:
+ if (op_array-fn_flags ZEND_ACC_CLOSURE) {
+ destroy_op_array(op_array);
+ efree(op_array);
+ }
There already is a local op_array variable for execute_data-op_array, so it's
a bit shorter to use ;)
Previous Comments:
[2012-09-02 10:23:04] ni...@php.net
@laruence: The patch looks fine for me.
The only thing that looks strange are these whitespace changes:
-ZEND_BEGIN_ARG_INFO_EX(arginfo_closure_bindto, 0, 0, 1)
+ ZEND_BEGIN_ARG_INFO_EX(arginfo_closure_bindto, 0, 0, 1)
ZEND_ARG_INFO(0, newthis)
ZEND_ARG_INFO(0, newscope)
ZEND_END_ARG_INFO()
-ZEND_BEGIN_ARG_INFO_EX(arginfo_closure_bind, 0, 0, 2)
+ ZEND_BEGIN_ARG_INFO_EX(arginfo_closure_bind, 0, 0, 2)
ZEND_ARG_INFO(0, closure)
ZEND_ARG_INFO(0, newthis)
ZEND_ARG_INFO(0, newscope)
ZEND_END_ARG_INFO()
-static const zend_function_entry closure_functions[] = {
- ZEND_ME(Closure, __construct, NULL, ZEND_ACC_PRIVATE)
- ZEND_ME(Closure, bind, arginfo_closure_bind,
ZEND_ACC_PUBLIC|ZEND_ACC_STATIC)
- ZEND_MALIAS(Closure, bindTo, bind, arginfo_closure_bindto,
ZEND_ACC_PUBLIC)
- {NULL, NULL, NULL}
-};
+ static const zend_function_entry closure_functions[] = {
+ ZEND_ME(Closure, __construct, NULL, ZEND_ACC_PRIVATE)
+ ZEND_ME(Closure, bind, arginfo_closure_bind,
ZEND_ACC_PUBLIC|ZEND_ACC_STATIC)
+ ZEND_MALIAS(Closure, bindTo, bind,
arginfo_closure_bindto, ZEND_ACC_PUBLIC)
+ {NULL, NULL, NULL}
+ };
Looks like the indentation is slightly off there :)
[2012-09-02 09:58:39] larue...@php.net
update patch, fix tabs
[2012-09-02 09:58:16] larue...@php.net
The following patch has been added/updated:
Patch Name: bug62991.patch
Revision: 1346579896
URL:
https://bugs.php.net/patch-display.php?bug=62991patch=bug62991.patchrevision=1346579896
[2012-09-02 09:55:35] larue...@php.net
I got a fix for this. nikic, could you please review this? thanks
[2012-09-02 09:54:55] larue...@php.net
The following patch has been added/updated:
Patch Name: bug62991.patch
Revision: 1346579695
URL:
https://bugs.php.net/patch-display.php?bug=62991patch=bug62991.patchrevision=1346579695
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=62991
--
Edit this bug report at https://bugs.php.net/bug.php?id=62991edit=1
Bug #62991 [Asn]: Segfault with generator and closure.
Edit report at https://bugs.php.net/bug.php?id=62991edit=1
ID: 62991
Updated by: larue...@php.net
Reported by:softwareelves at gmail dot com
Summary:Segfault with generator and closure.
Status: Assigned
Type: Bug
Package:Reproducible crash
Operating System: Mac OSx 10.8.1
PHP Version:master-Git-2012-09-02 (Git)
Assigned To:nikic
Block user comment: N
Private report: N
New Comment:
okey, but is there a way to find out that whether a generator has been run once?
leaks reporting if the closure didn't run.
Previous Comments:
[2012-09-02 10:26:03] ni...@php.net
Oh, and also, I think it would be a little bit nicer if this:
+ if (execute_data-op_array-fn_flags ZEND_ACC_CLOSURE) {
+ destroy_op_array(execute_data-op_array);
+ efree(execute_data-op_array);
+ }
would be written as:
+ if (op_array-fn_flags ZEND_ACC_CLOSURE) {
+ destroy_op_array(op_array);
+ efree(op_array);
+ }
There already is a local op_array variable for execute_data-op_array, so it's
a bit shorter to use ;)
[2012-09-02 10:23:04] ni...@php.net
@laruence: The patch looks fine for me.
The only thing that looks strange are these whitespace changes:
-ZEND_BEGIN_ARG_INFO_EX(arginfo_closure_bindto, 0, 0, 1)
+ ZEND_BEGIN_ARG_INFO_EX(arginfo_closure_bindto, 0, 0, 1)
ZEND_ARG_INFO(0, newthis)
ZEND_ARG_INFO(0, newscope)
ZEND_END_ARG_INFO()
-ZEND_BEGIN_ARG_INFO_EX(arginfo_closure_bind, 0, 0, 2)
+ ZEND_BEGIN_ARG_INFO_EX(arginfo_closure_bind, 0, 0, 2)
ZEND_ARG_INFO(0, closure)
ZEND_ARG_INFO(0, newthis)
ZEND_ARG_INFO(0, newscope)
ZEND_END_ARG_INFO()
-static const zend_function_entry closure_functions[] = {
- ZEND_ME(Closure, __construct, NULL, ZEND_ACC_PRIVATE)
- ZEND_ME(Closure, bind, arginfo_closure_bind,
ZEND_ACC_PUBLIC|ZEND_ACC_STATIC)
- ZEND_MALIAS(Closure, bindTo, bind, arginfo_closure_bindto,
ZEND_ACC_PUBLIC)
- {NULL, NULL, NULL}
-};
+ static const zend_function_entry closure_functions[] = {
+ ZEND_ME(Closure, __construct, NULL, ZEND_ACC_PRIVATE)
+ ZEND_ME(Closure, bind, arginfo_closure_bind,
ZEND_ACC_PUBLIC|ZEND_ACC_STATIC)
+ ZEND_MALIAS(Closure, bindTo, bind,
arginfo_closure_bindto, ZEND_ACC_PUBLIC)
+ {NULL, NULL, NULL}
+ };
Looks like the indentation is slightly off there :)
[2012-09-02 09:58:39] larue...@php.net
update patch, fix tabs
[2012-09-02 09:58:16] larue...@php.net
The following patch has been added/updated:
Patch Name: bug62991.patch
Revision: 1346579896
URL:
https://bugs.php.net/patch-display.php?bug=62991patch=bug62991.patchrevision=1346579896
[2012-09-02 09:55:35] larue...@php.net
I got a fix for this. nikic, could you please review this? thanks
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=62991
--
Edit this bug report at https://bugs.php.net/bug.php?id=62991edit=1
Bug #62991 [PATCH]: Segfault with generator and closure.
Edit report at https://bugs.php.net/bug.php?id=62991edit=1
ID: 62991
Patch added by: larue...@php.net
Reported by:softwareelves at gmail dot com
Summary:Segfault with generator and closure.
Status: Assigned
Type: Bug
Package:Reproducible crash
Operating System: Mac OSx 10.8.1
PHP Version:master-Git-2012-09-02 (Git)
Assigned To:nikic
Block user comment: N
Private report: N
New Comment:
The following patch has been added/updated:
Patch Name: bug62991.patch
Revision: 1346586306
URL:
https://bugs.php.net/patch-display.php?bug=62991patch=bug62991.patchrevision=1346586306
Previous Comments:
[2012-09-02 11:24:00] larue...@php.net
okey, but is there a way to find out that whether a generator has been run once?
leaks reporting if the closure didn't run.
[2012-09-02 10:26:03] ni...@php.net
Oh, and also, I think it would be a little bit nicer if this:
+ if (execute_data-op_array-fn_flags ZEND_ACC_CLOSURE) {
+ destroy_op_array(execute_data-op_array);
+ efree(execute_data-op_array);
+ }
would be written as:
+ if (op_array-fn_flags ZEND_ACC_CLOSURE) {
+ destroy_op_array(op_array);
+ efree(op_array);
+ }
There already is a local op_array variable for execute_data-op_array, so it's
a bit shorter to use ;)
[2012-09-02 10:23:04] ni...@php.net
@laruence: The patch looks fine for me.
The only thing that looks strange are these whitespace changes:
-ZEND_BEGIN_ARG_INFO_EX(arginfo_closure_bindto, 0, 0, 1)
+ ZEND_BEGIN_ARG_INFO_EX(arginfo_closure_bindto, 0, 0, 1)
ZEND_ARG_INFO(0, newthis)
ZEND_ARG_INFO(0, newscope)
ZEND_END_ARG_INFO()
-ZEND_BEGIN_ARG_INFO_EX(arginfo_closure_bind, 0, 0, 2)
+ ZEND_BEGIN_ARG_INFO_EX(arginfo_closure_bind, 0, 0, 2)
ZEND_ARG_INFO(0, closure)
ZEND_ARG_INFO(0, newthis)
ZEND_ARG_INFO(0, newscope)
ZEND_END_ARG_INFO()
-static const zend_function_entry closure_functions[] = {
- ZEND_ME(Closure, __construct, NULL, ZEND_ACC_PRIVATE)
- ZEND_ME(Closure, bind, arginfo_closure_bind,
ZEND_ACC_PUBLIC|ZEND_ACC_STATIC)
- ZEND_MALIAS(Closure, bindTo, bind, arginfo_closure_bindto,
ZEND_ACC_PUBLIC)
- {NULL, NULL, NULL}
-};
+ static const zend_function_entry closure_functions[] = {
+ ZEND_ME(Closure, __construct, NULL, ZEND_ACC_PRIVATE)
+ ZEND_ME(Closure, bind, arginfo_closure_bind,
ZEND_ACC_PUBLIC|ZEND_ACC_STATIC)
+ ZEND_MALIAS(Closure, bindTo, bind,
arginfo_closure_bindto, ZEND_ACC_PUBLIC)
+ {NULL, NULL, NULL}
+ };
Looks like the indentation is slightly off there :)
[2012-09-02 09:58:39] larue...@php.net
update patch, fix tabs
[2012-09-02 09:58:16] larue...@php.net
The following patch has been added/updated:
Patch Name: bug62991.patch
Revision: 1346579896
URL:
https://bugs.php.net/patch-display.php?bug=62991patch=bug62991.patchrevision=1346579896
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=62991
--
Edit this bug report at https://bugs.php.net/bug.php?id=62991edit=1
Bug #62991 [Asn]: Segfault with generator and closure.
Edit report at https://bugs.php.net/bug.php?id=62991edit=1
ID: 62991
Updated by: larue...@php.net
Reported by:softwareelves at gmail dot com
Summary:Segfault with generator and closure.
Status: Assigned
Type: Bug
Package:Reproducible crash
Operating System: Mac OSx 10.8.1
PHP Version:master-Git-2012-09-02 (Git)
Assigned To:nikic
Block user comment: N
Private report: N
New Comment:
a new patch has been attached, fixed the memleak issue, but the way is a little
tricky, used the op_array-reserved fields.
so I attached it here instead of ci it, wait for if we can find a better way
Previous Comments:
[2012-09-02 11:45:06] larue...@php.net
The following patch has been added/updated:
Patch Name: bug62991.patch
Revision: 1346586306
URL:
https://bugs.php.net/patch-display.php?bug=62991patch=bug62991.patchrevision=1346586306
[2012-09-02 11:24:00] larue...@php.net
okey, but is there a way to find out that whether a generator has been run once?
leaks reporting if the closure didn't run.
[2012-09-02 10:26:03] ni...@php.net
Oh, and also, I think it would be a little bit nicer if this:
+ if (execute_data-op_array-fn_flags ZEND_ACC_CLOSURE) {
+ destroy_op_array(execute_data-op_array);
+ efree(execute_data-op_array);
+ }
would be written as:
+ if (op_array-fn_flags ZEND_ACC_CLOSURE) {
+ destroy_op_array(op_array);
+ efree(op_array);
+ }
There already is a local op_array variable for execute_data-op_array, so it's
a bit shorter to use ;)
[2012-09-02 10:23:04] ni...@php.net
@laruence: The patch looks fine for me.
The only thing that looks strange are these whitespace changes:
-ZEND_BEGIN_ARG_INFO_EX(arginfo_closure_bindto, 0, 0, 1)
+ ZEND_BEGIN_ARG_INFO_EX(arginfo_closure_bindto, 0, 0, 1)
ZEND_ARG_INFO(0, newthis)
ZEND_ARG_INFO(0, newscope)
ZEND_END_ARG_INFO()
-ZEND_BEGIN_ARG_INFO_EX(arginfo_closure_bind, 0, 0, 2)
+ ZEND_BEGIN_ARG_INFO_EX(arginfo_closure_bind, 0, 0, 2)
ZEND_ARG_INFO(0, closure)
ZEND_ARG_INFO(0, newthis)
ZEND_ARG_INFO(0, newscope)
ZEND_END_ARG_INFO()
-static const zend_function_entry closure_functions[] = {
- ZEND_ME(Closure, __construct, NULL, ZEND_ACC_PRIVATE)
- ZEND_ME(Closure, bind, arginfo_closure_bind,
ZEND_ACC_PUBLIC|ZEND_ACC_STATIC)
- ZEND_MALIAS(Closure, bindTo, bind, arginfo_closure_bindto,
ZEND_ACC_PUBLIC)
- {NULL, NULL, NULL}
-};
+ static const zend_function_entry closure_functions[] = {
+ ZEND_ME(Closure, __construct, NULL, ZEND_ACC_PRIVATE)
+ ZEND_ME(Closure, bind, arginfo_closure_bind,
ZEND_ACC_PUBLIC|ZEND_ACC_STATIC)
+ ZEND_MALIAS(Closure, bindTo, bind,
arginfo_closure_bindto, ZEND_ACC_PUBLIC)
+ {NULL, NULL, NULL}
+ };
Looks like the indentation is slightly off there :)
[2012-09-02 09:58:39] larue...@php.net
update patch, fix tabs
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=62991
--
Edit this bug report at https://bugs.php.net/bug.php?id=62991edit=1
Bug #62991 [PATCH]: Segfault with generator and closure.
Edit report at https://bugs.php.net/bug.php?id=62991edit=1
ID: 62991
Patch added by: larue...@php.net
Reported by:softwareelves at gmail dot com
Summary:Segfault with generator and closure.
Status: Assigned
Type: Bug
Package:Reproducible crash
Operating System: Mac OSx 10.8.1
PHP Version:master-Git-2012-09-02 (Git)
Assigned To:nikic
Block user comment: N
Private report: N
New Comment:
The following patch has been added/updated:
Patch Name: bug62991.phpt
Revision: 1346586639
URL:
https://bugs.php.net/patch-display.php?bug=62991patch=bug62991.phptrevision=1346586639
Previous Comments:
[2012-09-02 11:46:56] larue...@php.net
a new patch has been attached, fixed the memleak issue, but the way is a little
tricky, used the op_array-reserved fields.
so I attached it here instead of ci it, wait for if we can find a better way
[2012-09-02 11:45:06] larue...@php.net
The following patch has been added/updated:
Patch Name: bug62991.patch
Revision: 1346586306
URL:
https://bugs.php.net/patch-display.php?bug=62991patch=bug62991.patchrevision=1346586306
[2012-09-02 11:24:00] larue...@php.net
okey, but is there a way to find out that whether a generator has been run once?
leaks reporting if the closure didn't run.
[2012-09-02 10:26:03] ni...@php.net
Oh, and also, I think it would be a little bit nicer if this:
+ if (execute_data-op_array-fn_flags ZEND_ACC_CLOSURE) {
+ destroy_op_array(execute_data-op_array);
+ efree(execute_data-op_array);
+ }
would be written as:
+ if (op_array-fn_flags ZEND_ACC_CLOSURE) {
+ destroy_op_array(op_array);
+ efree(op_array);
+ }
There already is a local op_array variable for execute_data-op_array, so it's
a bit shorter to use ;)
[2012-09-02 10:23:04] ni...@php.net
@laruence: The patch looks fine for me.
The only thing that looks strange are these whitespace changes:
-ZEND_BEGIN_ARG_INFO_EX(arginfo_closure_bindto, 0, 0, 1)
+ ZEND_BEGIN_ARG_INFO_EX(arginfo_closure_bindto, 0, 0, 1)
ZEND_ARG_INFO(0, newthis)
ZEND_ARG_INFO(0, newscope)
ZEND_END_ARG_INFO()
-ZEND_BEGIN_ARG_INFO_EX(arginfo_closure_bind, 0, 0, 2)
+ ZEND_BEGIN_ARG_INFO_EX(arginfo_closure_bind, 0, 0, 2)
ZEND_ARG_INFO(0, closure)
ZEND_ARG_INFO(0, newthis)
ZEND_ARG_INFO(0, newscope)
ZEND_END_ARG_INFO()
-static const zend_function_entry closure_functions[] = {
- ZEND_ME(Closure, __construct, NULL, ZEND_ACC_PRIVATE)
- ZEND_ME(Closure, bind, arginfo_closure_bind,
ZEND_ACC_PUBLIC|ZEND_ACC_STATIC)
- ZEND_MALIAS(Closure, bindTo, bind, arginfo_closure_bindto,
ZEND_ACC_PUBLIC)
- {NULL, NULL, NULL}
-};
+ static const zend_function_entry closure_functions[] = {
+ ZEND_ME(Closure, __construct, NULL, ZEND_ACC_PRIVATE)
+ ZEND_ME(Closure, bind, arginfo_closure_bind,
ZEND_ACC_PUBLIC|ZEND_ACC_STATIC)
+ ZEND_MALIAS(Closure, bindTo, bind,
arginfo_closure_bindto, ZEND_ACC_PUBLIC)
+ {NULL, NULL, NULL}
+ };
Looks like the indentation is slightly off there :)
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=62991
--
Edit this bug report at https://bugs.php.net/bug.php?id=62991edit=1
[PHP-BUG] Bug #62998 [NEW]: pg_query_params() doesn't handle NULL
From: php at richardneill dot org Operating system: Linux PHP version: 5.3.16 Package: PostgreSQL related Bug Type: Bug Bug description:pg_query_params() doesn't handle NULL Description: pg_query_params($conn,$sql,$params) is supposed to correctly handle NULL-SQL_NULL. It doesn't do this (despite the documentation); instead it breaks the query. Documentation If parameters are used, they are referred to in the query string as $1, $2, etc. params specifies the actual values of the parameters. A NULL value in this array means the corresponding parameter is SQL NULL. Test script: --- Here's a simple example: $result = pg_query_params ($conn, select CASE WHEN NULL is $1 then 'it is null' ELSE 'it is not null' END, array(NULL) ); echo pg_last_error($conn); print_r (pg_fetch_assoc($result)); This query fails, because the parameter $1 is not actually passed as NULL, instead it seems to be the empty string. My SQL is definitely right: pg_query_params ($conn, select CASE WHEN NULL is NULL then 'it is null' ELSE 'it is not null' END, array() ); works fine, to return the string it is null. Expected result: It should be possible to pass SQL_NULL to the database in a parameter. -- Edit bug report at https://bugs.php.net/bug.php?id=62998edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=62998r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=62998r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=62998r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=62998r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=62998r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=62998r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=62998r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=62998r=needscript Try newer version: https://bugs.php.net/fix.php?id=62998r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=62998r=support Expected behavior: https://bugs.php.net/fix.php?id=62998r=notwrong Not enough info: https://bugs.php.net/fix.php?id=62998r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=62998r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=62998r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=62998r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=62998r=dst IIS Stability: https://bugs.php.net/fix.php?id=62998r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=62998r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=62998r=float No Zend Extensions: https://bugs.php.net/fix.php?id=62998r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=62998r=mysqlcfg
Bug #62954 [Com]: startup problems fpm / php-fpm
Edit report at https://bugs.php.net/bug.php?id=62954edit=1
ID: 62954
Comment by: per at techspot dot com
Reported by:jonas at brachium-system dot net
Summary:startup problems fpm / php-fpm
Status: Feedback
Type: Bug
Package:FPM related
Operating System: Linux
PHP Version:5.3Git-2012-08-27 (Git)
Assigned To:fat
Block user comment: N
Private report: N
New Comment:
This bug occurs more frequently on heavily loaded websites.
On my testserver it is difficult to reproduce with a low load.
But on my live server doing a service php-fpm restart makes it fail most
times.
For some reason the problem occurs less frequently in php-fpm 5.4.6 vs 5.3.16
opcode cachers also makes it occur more frequently, but it's possible to
reproduce with no opcode cacher loaded aswell, same rules as above for
frequency still apply (5.3 vs 5.4)
Output from testserver below running CentOS v6.3 with all patches applied and
php v5.4 via the remi repository:
http://rpms.famillecollet.com/enterprise/6/test/x86_64/
# php -v
PHP 5.4.6 (cli) (built: Aug 16 2012 14:26:39)
Copyright (c) 1997-2012 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2012 Zend Technologies
with XCache v2.0.1, Copyright (c) 2005-2012, by mOo
# DAEMON_COREFILE_LIMIT=unlimited strace -s1024 -f /etc/init.d/php-fpm restart
21 | grep -i SEGV
[pid 3017] rt_sigaction(SIGSEGV, {0x7fddd5050730, [SEGV],
SA_RESTORER|SA_RESTART, 0x7fdddb55a920}, {SIG_DFL, [], 0}, 8) = 0
[pid 3017] rt_sigaction(SIGSEGV, {SIG_DFL, [SEGV], SA_RESTORER|SA_RESTART,
0x7fdddb55a920}, unfinished ...
[pid 3017] ... rt_sigaction resumed {0x7fddd5050730, [SEGV],
SA_RESTORER|SA_RESTART, 0x7fdddb55a920}, 8) = 0
Previous Comments:
[2012-09-02 09:07:29] jonas at brachium-system dot net
PHP 5.3.16-dev (fpm-fcgi) (built: Sep 2 2012 04:56:07)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2012 Zend Technologies
I have tried it with the current branch PHP-5.3.
It started two times correctly (Starts and detaches) after the second start the
problem occurs again.
So problem is not fixed - I have not tried 5.4 since fpm sapi is the same.
[2012-09-01 19:41:16] tony2...@php.net
I can't reproduce it here:
# /tmp/fpm/sbin/php-fpm -v
PHP 5.4.8-dev (fpm-fcgi) (built: Sep 1 2012 23:36:17) (DEBUG)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2012 Zend Technologies
It starts, spawns its children and detaches from terminal with no problem at
all.
Can you try the latest snapshot and check if you still can reproduce the issue?
[2012-08-27 22:54:12] al-php at none dot at
same problem here.
./configure --prefix=/prefix/ --enable-fpm --enable-bcmath --with-bz2
--enable-calendar --with-curl --enable-dba --enable-exif --enable-ftp
--enable-gd-native-ttf --with-jpeg-dir --with-png-dir --with-t1lib
--with-freetype-dir --with-gettext --enable-mbstring --with-mcrypt --with-mhash
--with-mysql=mysqlnd --with-mysqli=mysqlnd --with-pdo-mysql=mysqlnd
--enable-mysqlnd --with-openssl --with-pcre-regex --with-pspell --enable-shmop
--enable-soap --enable-sockets --enable-sysvmsg --enable-wddx --with-xsl
--enable-zip --with-zlib --with-tcadb --with-openssl-dir --with-gd
###
bin/php -v
PHP 5.4.5 (cli) (built: Aug 8 2012 01:03:00)
Copyright (c) 1997-2012 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2012 Zend Technologies
###
root@Ubuntu-1204-precise-64-minimal ~ # strace -fveall -p 2590 -p 2589
Process 2590 attached - interrupt to quit
Process 2589 attached - interrupt to quit
[pid 2589] wait4(-1, unfinished ...
[pid 2590] futex(0x7fc2a4d73720, FUTEX_WAIT_PRIVATE, 2, NULL
###
[2012-08-27 19:50:31] jonas at brachium-system dot net
Description:
PHP 5.3.14 with FPM on Debian Squeze works without any problems.
The PHP Version 5.3.15 / 5.3.16 and current Git branch PHP 5.3 is affected.
/usr/sbin/php5-fpm --fpm-config /etc/php5/fpm/php-fpm.conf
All pools are started and working, but the php5-fpm does not detach:
/usr/sbin/php5-fpm --fpm-config /etc/php5/fpm/php-fpm.conf
and here it hangs. ctrl +c does not work.
strace tells me:
Process 15949 attached - interrupt to quit
futex(0x7fb923e8ce40, FUTEX_WAIT_PRIVATE, 2, NULL
If I switch the configuration option daemonize to no php-fpm starts up
normal and can be aborted with ctrl+c.
If I copy sapi/fpm from 5.3.14 to the current php-src from git and compile it
again my configuration and php-fpm works and starts normal.
If I remove the USR1/USR2 handling from sapi/fpm/fpm/fpm_unix.c ( see patch )
php-fpm starts normal and detach correctly.
I think (See:
Bug #62954 [Com]: startup problems fpm / php-fpm
Edit report at https://bugs.php.net/bug.php?id=62954edit=1
ID: 62954
Comment by: david at appliedautonomics dot com
Reported by:jonas at brachium-system dot net
Summary:startup problems fpm / php-fpm
Status: Feedback
Type: Bug
Package:FPM related
Operating System: Linux
PHP Version:5.3Git-2012-08-27 (Git)
Assigned To:fat
Block user comment: N
Private report: N
New Comment:
Fixed on Debian Squeez via adding to fastcgi params:
fastcgi_buffer_size 16k;
fastcgi_buffers 4 16k;
Previous Comments:
[2012-09-02 16:43:24] per at techspot dot com
This bug occurs more frequently on heavily loaded websites.
On my testserver it is difficult to reproduce with a low load.
But on my live server doing a service php-fpm restart makes it fail most
times.
For some reason the problem occurs less frequently in php-fpm 5.4.6 vs 5.3.16
opcode cachers also makes it occur more frequently, but it's possible to
reproduce with no opcode cacher loaded aswell, same rules as above for
frequency still apply (5.3 vs 5.4)
Output from testserver below running CentOS v6.3 with all patches applied and
php v5.4 via the remi repository:
http://rpms.famillecollet.com/enterprise/6/test/x86_64/
# php -v
PHP 5.4.6 (cli) (built: Aug 16 2012 14:26:39)
Copyright (c) 1997-2012 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2012 Zend Technologies
with XCache v2.0.1, Copyright (c) 2005-2012, by mOo
# DAEMON_COREFILE_LIMIT=unlimited strace -s1024 -f /etc/init.d/php-fpm restart
21 | grep -i SEGV
[pid 3017] rt_sigaction(SIGSEGV, {0x7fddd5050730, [SEGV],
SA_RESTORER|SA_RESTART, 0x7fdddb55a920}, {SIG_DFL, [], 0}, 8) = 0
[pid 3017] rt_sigaction(SIGSEGV, {SIG_DFL, [SEGV], SA_RESTORER|SA_RESTART,
0x7fdddb55a920}, unfinished ...
[pid 3017] ... rt_sigaction resumed {0x7fddd5050730, [SEGV],
SA_RESTORER|SA_RESTART, 0x7fdddb55a920}, 8) = 0
[2012-09-02 09:07:29] jonas at brachium-system dot net
PHP 5.3.16-dev (fpm-fcgi) (built: Sep 2 2012 04:56:07)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2012 Zend Technologies
I have tried it with the current branch PHP-5.3.
It started two times correctly (Starts and detaches) after the second start the
problem occurs again.
So problem is not fixed - I have not tried 5.4 since fpm sapi is the same.
[2012-09-01 19:41:16] tony2...@php.net
I can't reproduce it here:
# /tmp/fpm/sbin/php-fpm -v
PHP 5.4.8-dev (fpm-fcgi) (built: Sep 1 2012 23:36:17) (DEBUG)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2012 Zend Technologies
It starts, spawns its children and detaches from terminal with no problem at
all.
Can you try the latest snapshot and check if you still can reproduce the issue?
[2012-08-27 22:54:12] al-php at none dot at
same problem here.
./configure --prefix=/prefix/ --enable-fpm --enable-bcmath --with-bz2
--enable-calendar --with-curl --enable-dba --enable-exif --enable-ftp
--enable-gd-native-ttf --with-jpeg-dir --with-png-dir --with-t1lib
--with-freetype-dir --with-gettext --enable-mbstring --with-mcrypt --with-mhash
--with-mysql=mysqlnd --with-mysqli=mysqlnd --with-pdo-mysql=mysqlnd
--enable-mysqlnd --with-openssl --with-pcre-regex --with-pspell --enable-shmop
--enable-soap --enable-sockets --enable-sysvmsg --enable-wddx --with-xsl
--enable-zip --with-zlib --with-tcadb --with-openssl-dir --with-gd
###
bin/php -v
PHP 5.4.5 (cli) (built: Aug 8 2012 01:03:00)
Copyright (c) 1997-2012 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2012 Zend Technologies
###
root@Ubuntu-1204-precise-64-minimal ~ # strace -fveall -p 2590 -p 2589
Process 2590 attached - interrupt to quit
Process 2589 attached - interrupt to quit
[pid 2589] wait4(-1, unfinished ...
[pid 2590] futex(0x7fc2a4d73720, FUTEX_WAIT_PRIVATE, 2, NULL
###
[2012-08-27 19:50:31] jonas at brachium-system dot net
Description:
PHP 5.3.14 with FPM on Debian Squeze works without any problems.
The PHP Version 5.3.15 / 5.3.16 and current Git branch PHP 5.3 is affected.
/usr/sbin/php5-fpm --fpm-config /etc/php5/fpm/php-fpm.conf
All pools are started and working, but the php5-fpm does not detach:
/usr/sbin/php5-fpm --fpm-config /etc/php5/fpm/php-fpm.conf
and here it hangs. ctrl +c does not work.
strace tells me:
Process 15949 attached - interrupt to quit
futex(0x7fb923e8ce40, FUTEX_WAIT_PRIVATE, 2, NULL
If I switch the configuration option daemonize to no php-fpm starts up
normal and can be aborted with ctrl+c.
If I copy sapi/fpm from 5.3.14 to
[PHP-BUG] Bug #63000 [NEW]: MCAST_JOIN_GROUP on OSX is broken
From: igor at wiedler dot ch
Operating system: Mac OSX 10.7, 10.8
PHP version: 5.4.6
Package: Sockets related
Bug Type: Bug
Bug description:MCAST_JOIN_GROUP on OSX is broken
Description:
The multicast support in PHP 5.4 makes use of MCAST_JOIN_GROUP if it is
present.
The problem is that OSX 10.7 added the constant, but did not correctly
implement
the feature. This causes the setsockopt call to fail.
The solution to the problem is to not use MCAST_JOIN_GROUP on OSX.
Test script:
---
?php
if (!extension_loaded('sockets')) {
die('skip sockets extension not available.');
}
if (PHP_OS !== 'Darwin') {
die('is not OSX.');
}
$socket = socket_create(AF_INET, SOCK_DGRAM, SOL_UDP);
socket_bind($socket, '0.0.0.0', 31057);
$so = socket_set_option($socket, IPPROTO_IP, MCAST_JOIN_GROUP, array(
group = '224.0.0.251',
interface = 0,
));
var_dump($so);
Expected result:
bool(true)
Actual result:
--
PHP Warning: socket_set_option(): unable to set socket option [22]:
Invalid
argument in /Users/igor/code/react-mdns-userland/src/React/Mdns/Client.php
on
line 27
PHP Stack trace:
PHP 1. {main}()
/Users/igor/code/react-mdns-userland/examples/client.php:0
PHP 2. React\Mdns\Client-query() /Users/igor/code/react-mdns-
userland/examples/client.php:10
PHP 3. socket_set_option() /Users/igor/code/react-mdns-
userland/src/React/Mdns/Client.php:27
bool(false)
--
Edit bug report at https://bugs.php.net/bug.php?id=63000edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=63000r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=63000r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=63000r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=63000r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=63000r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=63000r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=63000r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=63000r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=63000r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=63000r=support
Expected behavior:
https://bugs.php.net/fix.php?id=63000r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=63000r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=63000r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=63000r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=63000r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=63000r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=63000r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=63000r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=63000r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=63000r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=63000r=mysqlcfg
Bug #63000 [Com]: MCAST_JOIN_GROUP on OSX is broken
Edit report at https://bugs.php.net/bug.php?id=63000edit=1
ID: 63000
Comment by: igor at wiedler dot ch
Reported by:igor at wiedler dot ch
Summary:MCAST_JOIN_GROUP on OSX is broken
Status: Open
Type: Bug
Package:Sockets related
Operating System: Mac OSX 10.7, 10.8
PHP Version:5.4.6
Block user comment: N
Private report: N
New Comment:
See also: http://trac.videolan.org/vlc/ticket/6104#comment:19
Previous Comments:
[2012-09-02 21:38:36] igor at wiedler dot ch
Description:
The multicast support in PHP 5.4 makes use of MCAST_JOIN_GROUP if it is
present.
The problem is that OSX 10.7 added the constant, but did not correctly
implement
the feature. This causes the setsockopt call to fail.
The solution to the problem is to not use MCAST_JOIN_GROUP on OSX.
Test script:
---
?php
if (!extension_loaded('sockets')) {
die('skip sockets extension not available.');
}
if (PHP_OS !== 'Darwin') {
die('is not OSX.');
}
$socket = socket_create(AF_INET, SOCK_DGRAM, SOL_UDP);
socket_bind($socket, '0.0.0.0', 31057);
$so = socket_set_option($socket, IPPROTO_IP, MCAST_JOIN_GROUP, array(
group = '224.0.0.251',
interface = 0,
));
var_dump($so);
Expected result:
bool(true)
Actual result:
--
PHP Warning: socket_set_option(): unable to set socket option [22]: Invalid
argument in /Users/igor/code/react-mdns-userland/src/React/Mdns/Client.php on
line 27
PHP Stack trace:
PHP 1. {main}() /Users/igor/code/react-mdns-userland/examples/client.php:0
PHP 2. React\Mdns\Client-query() /Users/igor/code/react-mdns-
userland/examples/client.php:10
PHP 3. socket_set_option() /Users/igor/code/react-mdns-
userland/src/React/Mdns/Client.php:27
bool(false)
--
Edit this bug report at https://bugs.php.net/bug.php?id=63000edit=1
Bug #62984 [Opn-Dup]: -1 month in date moves day 31 to day 1 in the same month.
Edit report at https://bugs.php.net/bug.php?id=62984edit=1
ID: 62984
Updated by: ahar...@php.net
Reported by:eyre dot jonathan at gmail dot com
Summary:-1 month in date moves day 31 to day 1 in the same
month.
-Status: Open
+Status: Duplicate
Type: Bug
Package:Date/time related
Operating System: Debian Linux
PHP Version:5.3.16
Block user comment: N
Private report: N
New Comment:
Expected behaviour. Duplicate of bug #22486, bug #44073, bug #62980, and
probably about fifty other bugs in the tracker.
Previous Comments:
[2012-08-31 16:32:28] eyre dot jonathan at gmail dot com
Description:
When looping backwards in time using the -1 Month feature of date(), July is
printed twice. This actually occurs whenever $finalEndDate is a month with 31
days.
The -1 Month syntax does not work when the date is the 31st of the month. It
apparently tries to set July 31 to June 31, which does not exist. The 31st of
June is calculated to be July 1st, hence the double printing of July 2012 in
the example below.
Test script:
---
$finalEndDate = 8/31/2012;
$finalStartDate = 12/31/2010;
$StartTime = strtotime($finalStartDate); //$StartDateDB);
$EndTime = strtotime($finalEndDate); //$EndDateDB);
$StartMark = getdate($StartTime);
$EndMark = getdate($EndTime);
$u = 0;
while ($StartTime = $EndTime) {
$MonthString = $EndMark[month] . . $EndMark[year];
echo comparing [ . $StartTime . ] to [ . $EndTime . ]... created[ .
$MonthString . ]BR\n;
$u++;
$EndTime = strtotime(-1 month, $EndTime); // THIS IS THE BUGGY LINE
$EndMark = getdate($EndTime);
}
Expected result:
comparing [1338440400] to [1346389200]... created[August 2012]
comparing [1338440400] to [1343710800]... created[July 2012]
comparing [1338440400] to [1338526800]... created[June 2012]
Actual result:
--
comparing [1338440400] to [1346389200]... created[August 2012]
comparing [1338440400] to [1343710800]... created[July 2012]
comparing [1338440400] to [1341118800]... created[July 2012]
comparing [1338440400] to [1338526800]... created[June 2012]
--
Edit this bug report at https://bugs.php.net/bug.php?id=62984edit=1
Bug #63000 [Com]: MCAST_JOIN_GROUP on OSX is broken
Edit report at https://bugs.php.net/bug.php?id=63000edit=1
ID: 63000
Comment by: reeze dot xia at gmail dot com
Reported by:igor at wiedler dot ch
Summary:MCAST_JOIN_GROUP on OSX is broken
Status: Open
Type: Bug
Package:Sockets related
Operating System: Mac OSX 10.7, 10.8
PHP Version:5.4.6
Block user comment: N
Private report: N
New Comment:
Ah, you mention which version the bug exist, both 10.710.8 right ?
Is there any way to detect whether is broken or not
disable it seems not a better choice.
Previous Comments:
[2012-09-02 21:41:13] igor at wiedler dot ch
See also: http://trac.videolan.org/vlc/ticket/6104#comment:19
[2012-09-02 21:38:36] igor at wiedler dot ch
Description:
The multicast support in PHP 5.4 makes use of MCAST_JOIN_GROUP if it is
present.
The problem is that OSX 10.7 added the constant, but did not correctly
implement
the feature. This causes the setsockopt call to fail.
The solution to the problem is to not use MCAST_JOIN_GROUP on OSX.
Test script:
---
?php
if (!extension_loaded('sockets')) {
die('skip sockets extension not available.');
}
if (PHP_OS !== 'Darwin') {
die('is not OSX.');
}
$socket = socket_create(AF_INET, SOCK_DGRAM, SOL_UDP);
socket_bind($socket, '0.0.0.0', 31057);
$so = socket_set_option($socket, IPPROTO_IP, MCAST_JOIN_GROUP, array(
group = '224.0.0.251',
interface = 0,
));
var_dump($so);
Expected result:
bool(true)
Actual result:
--
PHP Warning: socket_set_option(): unable to set socket option [22]: Invalid
argument in /Users/igor/code/react-mdns-userland/src/React/Mdns/Client.php on
line 27
PHP Stack trace:
PHP 1. {main}() /Users/igor/code/react-mdns-userland/examples/client.php:0
PHP 2. React\Mdns\Client-query() /Users/igor/code/react-mdns-
userland/examples/client.php:10
PHP 3. socket_set_option() /Users/igor/code/react-mdns-
userland/src/React/Mdns/Client.php:27
bool(false)
--
Edit this bug report at https://bugs.php.net/bug.php?id=63000edit=1
Bug #63000 [Com]: MCAST_JOIN_GROUP on OSX is broken
Edit report at https://bugs.php.net/bug.php?id=63000edit=1
ID: 63000
Comment by: reeze dot xia at gmail dot com
Reported by:igor at wiedler dot ch
Summary:MCAST_JOIN_GROUP on OSX is broken
Status: Open
Type: Bug
Package:Sockets related
Operating System: Mac OSX 10.7, 10.8
PHP Version:5.4.6
Block user comment: N
Private report: N
New Comment:
I haven't use this option before, if it's an important feature,
if your patch didn't apply the only impact is the warning issued ?
that maybe need to be fixed, but if not...
eg this bug https://bugs.php.net/bug.php?id=62881 I reported.
maybe the bug reported may set to won't fix :(
more conversation see: https://github.com/php/php-src/pull/176
anyway I prefer it get fixed :)
Previous Comments:
[2012-09-03 02:47:47] reeze dot xia at gmail dot com
Ah, you mention which version the bug exist, both 10.710.8 right ?
Is there any way to detect whether is broken or not
disable it seems not a better choice.
[2012-09-02 21:41:13] igor at wiedler dot ch
See also: http://trac.videolan.org/vlc/ticket/6104#comment:19
[2012-09-02 21:38:36] igor at wiedler dot ch
Description:
The multicast support in PHP 5.4 makes use of MCAST_JOIN_GROUP if it is
present.
The problem is that OSX 10.7 added the constant, but did not correctly
implement
the feature. This causes the setsockopt call to fail.
The solution to the problem is to not use MCAST_JOIN_GROUP on OSX.
Test script:
---
?php
if (!extension_loaded('sockets')) {
die('skip sockets extension not available.');
}
if (PHP_OS !== 'Darwin') {
die('is not OSX.');
}
$socket = socket_create(AF_INET, SOCK_DGRAM, SOL_UDP);
socket_bind($socket, '0.0.0.0', 31057);
$so = socket_set_option($socket, IPPROTO_IP, MCAST_JOIN_GROUP, array(
group = '224.0.0.251',
interface = 0,
));
var_dump($so);
Expected result:
bool(true)
Actual result:
--
PHP Warning: socket_set_option(): unable to set socket option [22]: Invalid
argument in /Users/igor/code/react-mdns-userland/src/React/Mdns/Client.php on
line 27
PHP Stack trace:
PHP 1. {main}() /Users/igor/code/react-mdns-userland/examples/client.php:0
PHP 2. React\Mdns\Client-query() /Users/igor/code/react-mdns-
userland/examples/client.php:10
PHP 3. socket_set_option() /Users/igor/code/react-mdns-
userland/src/React/Mdns/Client.php:27
bool(false)
--
Edit this bug report at https://bugs.php.net/bug.php?id=63000edit=1
Bug #61753 [Com]: Error while compiling
Edit report at https://bugs.php.net/bug.php?id=61753edit=1 ID: 61753 Comment by: hexes at mail dot ru Reported by:hexes at mail dot ru Summary:Error while compiling Status: Open Type: Bug Package:Sybase-ct (ctlib) related Operating System: Gentoo linux PHP Version:5.3.10 Block user comment: N Private report: N New Comment: ls -1 /opt/sybase/OCS-15_0/lib/ libsmapp.a libsybblk.a libsybblk_r.a libsybblk_r.so libsybblk.so libsybcomn.a libsybcomn_r.a libsybcomn_r.so libsybcomn.so libsybcs.a libsybcs_r.a libsybcs_r.so libsybcs.so libsybct.a libsybct_r.a libsybct_r.so libsybct.so libsybdb.a libsybdb.so libsybdldap.so.15.0.0 libsybdldap.so.15.0.3 libsybfssl.so.15.0.0 libsybfssl.so.15.0.3 libsybintl.a libsybintl_r.a libsybintl_r.so libsybintl.so libsybskrb.so.15.0.0 libsybskrb.so.15.0.3 libsybtcl.a libsybtcl_r.a libsybtcl_r.so libsybtcl.so libsybunic.a libsybunic.so Guys there is NO libcomn.a, libcs.a, libct.a, libintl.a Why php try to find it??!?!? Previous Comments: [2012-04-17 08:04:25] hexes at mail dot ru Description: In file included from /home/tmp/portage/dev-lang/php-5.3.10/work/sapis- build/cli/ext/sybase_ct/php_sybase_ct.h:62:0, from /home/tmp/portage/dev-lang/php-5.3.10/work/sapis- build/cli/ext/sybase_ct/php_sybase_ct.c:29: /opt/sybase/OCS-15_0/include/ctpublic.h:269:63: error: expected declaration specifiers or â...â before âSQLDAâ make: *** [ext/sybase_ct/php_sybase_ct.lo] Error 1 make: *** Waiting for unfinished jobs * ERROR: dev-lang/php-5.3.10 failed (compile phase): * emake failed -- Edit this bug report at https://bugs.php.net/bug.php?id=61753edit=1
Bug #63000 [Opn]: MCAST_JOIN_GROUP on OSX is broken
Edit report at https://bugs.php.net/bug.php?id=63000edit=1
ID: 63000
Updated by: larue...@php.net
Reported by:igor at wiedler dot ch
Summary:MCAST_JOIN_GROUP on OSX is broken
Status: Open
Type: Bug
Package:Sockets related
Operating System: Mac OSX 10.7, 10.8
PHP Version:5.4.6
Block user comment: N
Private report: N
New Comment:
reeze, this one is not like that one you reported.
that one is trivial, and in some situation it's not a bug ( empty user name is
allowed in theory).
but this is a bug. (I didn't test with this, just judge by the reporting)
Previous Comments:
[2012-09-03 02:53:16] reeze dot xia at gmail dot com
I haven't use this option before, if it's an important feature,
if your patch didn't apply the only impact is the warning issued ?
that maybe need to be fixed, but if not...
eg this bug https://bugs.php.net/bug.php?id=62881 I reported.
maybe the bug reported may set to won't fix :(
more conversation see: https://github.com/php/php-src/pull/176
anyway I prefer it get fixed :)
[2012-09-03 02:47:47] reeze dot xia at gmail dot com
Ah, you mention which version the bug exist, both 10.710.8 right ?
Is there any way to detect whether is broken or not
disable it seems not a better choice.
[2012-09-02 21:41:13] igor at wiedler dot ch
See also: http://trac.videolan.org/vlc/ticket/6104#comment:19
[2012-09-02 21:38:36] igor at wiedler dot ch
Description:
The multicast support in PHP 5.4 makes use of MCAST_JOIN_GROUP if it is
present.
The problem is that OSX 10.7 added the constant, but did not correctly
implement
the feature. This causes the setsockopt call to fail.
The solution to the problem is to not use MCAST_JOIN_GROUP on OSX.
Test script:
---
?php
if (!extension_loaded('sockets')) {
die('skip sockets extension not available.');
}
if (PHP_OS !== 'Darwin') {
die('is not OSX.');
}
$socket = socket_create(AF_INET, SOCK_DGRAM, SOL_UDP);
socket_bind($socket, '0.0.0.0', 31057);
$so = socket_set_option($socket, IPPROTO_IP, MCAST_JOIN_GROUP, array(
group = '224.0.0.251',
interface = 0,
));
var_dump($so);
Expected result:
bool(true)
Actual result:
--
PHP Warning: socket_set_option(): unable to set socket option [22]: Invalid
argument in /Users/igor/code/react-mdns-userland/src/React/Mdns/Client.php on
line 27
PHP Stack trace:
PHP 1. {main}() /Users/igor/code/react-mdns-userland/examples/client.php:0
PHP 2. React\Mdns\Client-query() /Users/igor/code/react-mdns-
userland/examples/client.php:10
PHP 3. socket_set_option() /Users/igor/code/react-mdns-
userland/src/React/Mdns/Client.php:27
bool(false)
--
Edit this bug report at https://bugs.php.net/bug.php?id=63000edit=1
