[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