Bug #65687 [Fbk-Opn]: oci_connect() fails with segmentation fault signal
Edit report at https://bugs.php.net/bug.php?id=65687edit=1 ID: 65687 User updated by:grig-siren at rambler dot ru Reported by:grig-siren at rambler dot ru Summary:oci_connect() fails with segmentation fault signal -Status: Feedback +Status: Open Type: Bug Package:Oracle related Operating System: Linux PHP Version:Irrelevant Block user comment: N Private report: N New Comment: Sorry, but I can't do so. To do so I need DBA access rights to Oracle to restore user's password life time and make this password expired. But I don't have such rights. But I'm sure the problem is located inside oci_connect() call and execution. To locate it I have put debugging trigger_error() calls in my script in different places. And when I put trigger_error() call just before call to oci_connect() and another just after it - then I have got 'before' print in '/var/log/httpd/error_log' and fauilure message just after it. BTW, when I tried to connect to the same database with another tools (such as SQLDeveloper or SQL*Plus), I have got message ORA-2800x (sorry, I don't remember the last digit). I think, oci_connect() receives the same message, but don't expect it, and that's the reason of failure. Previous Comments: [2013-09-17 21:47:56] fel...@php.net Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php for *NIX and http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32 Once you have generated a backtrace, please submit it to this bug report and change the status back to Open. Thank you for helping us make PHP better. [2013-09-17 10:15:34] grig-siren at rambler dot ru Description: I have tried to connect to Oracle database after user's password has expired. And result was: failure of PHP with message child pid ... exit signal Segmentation fault(11) in '/var/log/httpd/error_log' file. Then I asked Oracle DBA to modify user's profile and set password life time to unlimited - and after that all my scripts again work correctly. As I understand, the reason of such situation is warning message about password expiration issued by database during connection process. I think, this message is a big surprise for function oci_connect(). -- Edit this bug report at https://bugs.php.net/bug.php?id=65687edit=1
Bug #65598 [Com]: Closure executed via static autoload incorrectly marked as static
Edit report at https://bugs.php.net/bug.php?id=65598edit=1 ID: 65598 Comment by: bixuehujin at gmail dot com Reported by:php at davidstockton dot com Summary:Closure executed via static autoload incorrectly marked as static Status: Open Type: Bug Package:Scripting Engine problem Operating System: Centos 6 PHP Version:5.5.3 Block user comment: N Private report: N New Comment: Indeedï¼it is odd and out of expect. AFAIK, there is no difference between create closure in static methods and require a file that will create a closure. Because of the created closure in both have the same scope. Consider the following two examples: 1: create closure in static method //main.php class Test { public static function createClosure() { $c = function () { //some code }; return $c; } } 2: create closure in a single file and require it //main.php class Test { public static function createClosure() { require 'closure.php'; return $c; } } //closure.php $c = function () { //some code }; The both examples have the same behavior, and both scope of $c are Test. But according to the invariants in Zend/zend_closures.c, say: If the closure is unscoped, it has no bound object. The the closure is scoped, it's either static or it's bound see detail: https://github.com/php/php-src/blob/47ee470992014c738891d05b5acc89c2de90f2ac/Zend/zend_closures.c#L483,L498 So the behavior of this issue is valid according to the invariants. *By the way, i am also want to know why we should have the invariants.* Previous Comments: [2013-09-17 21:30:38] php at davidstockton dot com The closure is not created in a static method, it's just loaded via an autoloader that happens to be static. Seems odd that we should expect different behavior of the code based on if the autoloader is static or non-static. [2013-09-17 20:52:18] bixuehujin at gmail dot com The reason is closures created in static methods are static, even without the keyword. see https://github.com/php/php-src/blob/a447acdcc6f12ea3a5dcd22416cb033e62995935/Zend/tests/closure_045.phpt [2013-08-30 23:55:29] php at davidstockton dot com Description: If I load a class via a static autoloader which has executable code (including a closure) and then try to bind the closure to an object of the class, I get a warning and error: Warning: Cannot bind an instance to a static closure and Fatal error: Using $this when not in object context If I run the script directly (not via autoloader) everything works as expected. If I make the autoloader non-static, everything works as expected. Test script: --- Sample contains two files, a static autoloader which will load the class file and the class file which also contains executable code. If the autoloader is a plain function or a non-static method then the code works as expected. If the executable code is removed from the class file and placed into the autoloader file, everything works as expected. php Autoloader.php (bad behavior) php ClosureBug.php (correct behavior) https://gist.github.com/dstockto/6395158 Expected result: 42 Actual result: -- Warning: Cannot bind an instance to a static closure in /vagrant/src/Bug/ClosureBug.php on line 9 Fatal error: Using $this when not in object context in /vagrant/src/Bug/ClosureBug.php on line 19 -- Edit this bug report at https://bugs.php.net/bug.php?id=65598edit=1
Bug #54054 [Opn-Nab]: Autoload not called in user-defined error handler function in case of E_STRICT
Edit report at https://bugs.php.net/bug.php?id=54054edit=1 ID: 54054 Updated by: tony2...@php.net Reported by:morpika at vipmail dot hu Summary:Autoload not called in user-defined error handler function in case of E_STRICT -Status: Open +Status: Not a bug Type: Bug Package:Scripting Engine problem Operating System: FreeBSD 8.0 PHP Version:5.3.5 Block user comment: N Private report: N New Comment: Here's how it looks: 1) PHP tries to compile a file 2) an error is found and the error handler is triggered (but we're still in compilation phase) 3) since we're already in compiler, we can't call the compiler again - the compiler is not reentrant, so autoload is skipped. 4) class not found. This behaviour is by design and isn't going to change without complete rewrite of the compiler (if ever). Previous Comments: [2013-08-22 09:07:24] ota dot mares at gmail dot com I have the same issue with a more complex setup using monolog, the custom monolog error handler and gelf as logger. Instead of logging the message Warning: The use statement with non-compound name 'UnexpectedValueException' has no effect in ...IndexController.php on line 11 the php error handling hickups, resulting in following error: Fatal error: Class 'Gelf\Message' not found in ...IndexController.php on line 11. Please note that the above warning is never shown or logged in this case. All you get is a confusing fatal message. In all other scenarios the logging works, which leads to the assumption that the autoloading never happens in the given case. [2012-12-27 09:41:18] nicolas dot grekas+php at gmail dot com This bug is a duplicate of bug #42098. [2011-09-14 12:41:59] web at darrengordon dot net The use of opcoding caching can cause this issue to not be reproducable. Test steps: 1. Enable opcode caching (APC), restart your httpd to ensure the opcode cache is clean. 2. Request testa.php to trigger the E_STRICT. Result: --- *error_handler(): Declaration of Bar::baz() should be compatible with that of Foo::baz() Fatal error: Class 'Error' not found in /path/trigger_e_strict.php on line 3 3. Uncomment line #25: include('doesntexist'); and re-request testa.php to trigger the E_WARNING. Result: --- *error_handler(): include(doesntexist): failed to open stream: No such file or directory *__autoload(): Error *Error::output() *error_handler(): include(): Failed opening 'doesntexist' for inclusion (include_path='.:/path:/usr/share/php') *Error::output() *error_handler(): Declaration of Bar::baz() should be compatible with that of Foo::baz() *Error::output() 4. Recomment line #25: include('doesntexist'); and re-request testa.php to trigger the E_STRICT. Result: --- *error_handler(): Declaration of Bar::baz() should be compatible with that of Foo::baz() *_autoload(): Error *Error::output() Expected result: Steps 2. and 4. should output the same result as the code is identical. Actual result: Steps 2. and 4. output different results. Step 2. behaves according to the Actual result of bug #54054. Step 4. behaves according to the Expected result of bug #54054. Notes: This behaviour should be noted when reproducing bug #54054 as it will cause the issue to not be reproducable. Environment: PHP 5.3.2 Apache/2.2.14 Ubuntu 10.04.3 LTS Code: testa.php - ?php error_reporting(-1); // Set error handler set_error_handler('error_handler'); // Error handler function error_handler($severity, $message) { echo *error_handler(): \$message\\n; return Error::output(); } // Autoloader function __autoload($class) { echo *__autoload(): \$class\\n; // Load class 'Error' eval(class $class { public static function output() { echo '*' . __CLASS__ . '::output()\n'; } }); } // Trigger E_WARNING - Uncomment to alter opcode cache //include('doesntexist'); // Trigger E_STRICT include('testb.php'); ? testb.php - ?php // Trigger E_STRICT class Foo { public function baz($var){} } class Bar extends Foo { public function baz() {} } ? [2011-09-14 11:43:03] phil at propcom dot co dot uk This is still an issue. The 2 test cases below should hopefully sum this up for you. Case 1... include() call fails and generates an E_WARNING E_WARNING is caught by the error handler Error handler attempts to use \Error class and calls the autoloader because it is not currently loaded ...Case 2 The included file (http://codepad.viper-7.com/xyCn8C) generates an E_STRICT E_STRICT is caught
Bug #60149 [Opn-Nab]: SPL autoloader not called in error handler triggered by private __call
Edit report at https://bugs.php.net/bug.php?id=60149edit=1 ID: 60149 Updated by: tony2...@php.net Reported by:gedrox at gmail dot com Summary:SPL autoloader not called in error handler triggered by private __call -Status: Open +Status: Not a bug Type: Bug Package:SPL related Operating System: Ubuntu 11.10 PHP Version:5.3.8 Block user comment: N Private report: N New Comment: This is by design, autoload cannot be triggered from compiler. See my explanation in bug 54054. Previous Comments: [2012-01-26 09:30:29] phil at propcom dot co dot uk This is similar to https://bugs.php.net/bug.php?id=54054. The two may be related. [2011-10-27 15:18:57] gedrox at gmail dot com Description: No SPL registered autoloader is called inside custom error handler if it has been triggered by private __call() magic function what should be public instead. Test script: --- http://gedrox.eu/php_spl_autoloader_error_handler_private_call.tar Run run.php file. Expected result: Tried to load class 'DoesNotExist_1' Caught error 'The magic method __call() must have public visibility and cannot be static' Tried to load class 'DoesNotExist_2' Done Actual result: -- Tried to load class 'DoesNotExist_1' Caught error 'The magic method __call() must have public visibility and cannot be static' Fatal error: Uncaught exception 'RuntimeException' with message 'Assertion failed on line '66' in LoaderTest.php on line 45 RuntimeException: Assertion failed on line '66' in LoaderTest.php on line 45 Call Stack: 0.0001 635080 1. {main}() run.php:0 0.0003 665536 2. LoaderTest-testFailure() run.php:6 0.0004 670584 3. assert() LoaderTest.php:66 0.0004 671144 4. LoaderTest-assertionFail() LoaderTest.php:0 -- Edit this bug report at https://bugs.php.net/bug.php?id=60149edit=1
Bug #42098 [Nab]: E_STRICT doesn't trigger __autoload()
Edit report at https://bugs.php.net/bug.php?id=42098edit=1 ID: 42098 Updated by: tony2...@php.net Reported by:nicolas dot grekas+php at gmail dot com Summary:E_STRICT doesn't trigger __autoload() Status: Not a bug Type: Bug Package:Scripting Engine problem Operating System: * PHP Version:5.2.3 Block user comment: N Private report: N New Comment: See detailed answer in bug #54054. Previous Comments: [2012-12-28 10:55:04] nicolas dot grekas+php at gmail dot com The error codes concerned by this bug are the ones used in Zend/zend_compile.c: E_STRICT, E_DEPRECATED, E_NOTICE, E_WARNING, E_ERROR, E_CORE_ERROR, E_COMPILE_ERROR and E_COMPILE_WARNING. So virtually no error code is safe. A workaround strategy at source code level would be to stack errors at compile time, then trigger them just when compile time is over. Is it possible? Anyone as a better idea? [2012-12-27 09:41:18] nicolas dot grekas+php at gmail dot com Related To: Bug #54054 [2011-09-14 11:51:47] phil at propcom dot co dot uk This is related to https://bugs.php.net/bug.php?id=54054edit=2 which I have just commented on proving some, hopefully, sane example code. [2010-05-25 11:12:20] i at walkinraven dot name I think autoload will not work in exception_handler or error_handler, that is the problem. [2007-08-17 23:08:16] tony2...@php.net Ah ah ! You play with words :) No, he just said the same thing in other words. The first time, you said : - Only execute time errors can be caught with user error handler., and now: - during compile - autoload wont be triggered There are two stages: 1) compile; 2) execute. Compile-time errors cannot be caught, only execute-time errors can be. But that's still a bug for me in this case. My workaround does exactily what PHP internals should do automagically, nothing more ! This is how the things work. 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=42098 -- Edit this bug report at https://bugs.php.net/bug.php?id=42098edit=1
Req #60760 [Asn]: Converting zend_parse_parameters() to zend_parse_parameters_none()
Edit report at https://bugs.php.net/bug.php?id=60760edit=1 ID: 60760 Updated by: ni...@php.net Reported by:dragoo...@php.net Summary:Converting zend_parse_parameters() to zend_parse_parameters_none() Status: Assigned Type: Feature/Change Request Package:SPL related Operating System: N/A PHP Version:5 Assigned To:levim Block user comment: N Private report: N New Comment: @levi You should use the == FAILURE variant. Nearly all PHP code does the failure/success comparison at the end :) Previous Comments: [2013-09-17 23:58:15] le...@php.net My latest patch changes a few of these. Also, there were two styles in use: if (zend_parse_parameters_none() == FAILURE) if (FAILURE == zend_parse_parameters_none()) I picked the latter as `if (FAILURE` indicates the purpose a bit better, in my opinion. If I should have picked the former: let me know and I'll attach a new patch. [2013-09-17 23:55:45] le...@php.net The following patch has been added/updated: Patch Name: spl_zpp_none.patch Revision: 1379462145 URL: https://bugs.php.net/patch-display.php?bug=60760patch=spl_zpp_none.patchrevision=1379462145 [2012-01-20 02:37:31] dragoo...@php.net This is just the way a lot of the phpsrc has been built. Look around various /ext/ places and you'll see it. I'm just cleaning things up and keeping consistency. Got a few more cleanup patches to submit on the SplHeap class for this same reason as i've been working on that class recently. - Paul. [2012-01-20 02:23:52] larue...@php.net if no parameters will be accpected, why call to zend_parse_parameters? just a arginfo will be enough. [2012-01-15 03:33:27] dragoo...@php.net The following patch has been added/updated: Patch Name: spl_dllist_zend_parse_parameters_none.diff Revision: 1326598407 URL: https://bugs.php.net/patch-display.php?bug=60760patch=spl_dllist_zend_parse_parameters_none.diffrevision=1326598407 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=60760 -- Edit this bug report at https://bugs.php.net/bug.php?id=60760edit=1
[PHP-BUG] Req #65694 [NEW]: error calendar in year 2016, with function mktime()
From: philippe dot alcaina at hotmail dot fr Operating system: windows linux PHP version: 5.5.3 Package: Date/time related Bug Type: Feature/Change Request Bug description:error calendar in year 2016, with function mktime() Description: I'm a french developer computer. For an internet tool I need to get a list of weeks after having selected one year and one month. By testing I found a BUG in the year 2016. PHP gives me: 1 January 2016 the number of week: 53 (instead of 1) January 31, 2016 the number of week: 4 (instead of 5) then the error shifts in other months. The system works correctly in 2013, 2014, 2015. Test script: --- I provide you sample of the code that allows me to build this list of weeks, I particularly use mktime () // timestamp of first day of month $time = mktime(0,0,0,$mois_select,1,$annee_select); // number of days of month $nbrJoursMois = intval(date('t',$time)); // the number of the first week $numSemaineDebutMois = intval(date('W', $time)); // timestamp of end month $timeFinMois = mktime(0,0,0,$mois_select,$nbrJoursMois,$annee_select); // the number of the last week $numSemaineFinMois = intval(date('W', $timeFinMois)); / Display results / $annee_select = 2016 $mois_select = 1 $time = 1451602800 $nbrJoursMois = 31 $numSemaineDebutMois = 53 (Error) $timeFinMois = 1454194800 $numSemaineFinMoisnum = 4 (Error) -- Edit bug report at https://bugs.php.net/bug.php?id=65694edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=65694r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=65694r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=65694r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=65694r=fixed Fixed in release: https://bugs.php.net/fix.php?id=65694r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=65694r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=65694r=needscript Try newer version: https://bugs.php.net/fix.php?id=65694r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=65694r=support Expected behavior: https://bugs.php.net/fix.php?id=65694r=notwrong Not enough info: https://bugs.php.net/fix.php?id=65694r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=65694r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=65694r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=65694r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=65694r=dst IIS Stability: https://bugs.php.net/fix.php?id=65694r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=65694r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=65694r=float No Zend Extensions: https://bugs.php.net/fix.php?id=65694r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=65694r=mysqlcfg
[PHP-BUG] Req #65695 [NEW]: mktime() with year 2016
From: philippe dot alcaina at hotmail dot fr Operating system: PHP version: 5.5.3 Package: *Calendar problems Bug Type: Feature/Change Request Bug description:mktime() with year 2016 Description: I'm a french developer computer. For an internet tool I need to get a list of weeks after having selected one year and one month. By testing I found a BUG in the year 2016. PHP gives me: 1 January 2016 the number of week: 53 (instead of 1) January 31, 2016 the number of week: 4 (instead of 5) then the error shifts in other months. The system works correctly in 2013, 2014, 2015. I provide you sample of the code that allows me to build this list of weeks, I particularly use mktime () // timestamp of first day of month $time = mktime(0,0,0,$mois_select,1,$annee_select); // number of days of month $nbrJoursMois = intval(date('t',$time)); // the number of the first week $numSemaineDebutMois = intval(date('W', $time)); // timestamp of end month $timeFinMois = mktime(0,0,0,$mois_select,$nbrJoursMois,$annee_select); // the number of the last week $numSemaineFinMois = intval(date('W', $timeFinMois)); / Display results / $annee_select = 2016 $mois_select = 1 $time = 1451602800 $nbrJoursMois = 31 $numSemaineDebutMois = 53 (Error) $timeFinMois = 1454194800 $numSemaineFinMoisnum = 4 (Error) -- Edit bug report at https://bugs.php.net/bug.php?id=65695edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=65695r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=65695r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=65695r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=65695r=fixed Fixed in release: https://bugs.php.net/fix.php?id=65695r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=65695r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=65695r=needscript Try newer version: https://bugs.php.net/fix.php?id=65695r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=65695r=support Expected behavior: https://bugs.php.net/fix.php?id=65695r=notwrong Not enough info: https://bugs.php.net/fix.php?id=65695r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=65695r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=65695r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=65695r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=65695r=dst IIS Stability: https://bugs.php.net/fix.php?id=65695r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=65695r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=65695r=float No Zend Extensions: https://bugs.php.net/fix.php?id=65695r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=65695r=mysqlcfg
[PHP-BUG] Req #65696 [NEW]: Bug Calendar year 2016 with mktime()
From: philippe dot alcaina at hotmail dot fr Operating system: PHP version: 5.5.3 Package: *Calendar problems Bug Type: Feature/Change Request Bug description:Bug Calendar year 2016 with mktime() Description: I'm a french developer computer. For an internet tool I need to get a list of weeks after having selected one year and one month. By testing I found a BUG in the year 2016. PHP gives me: 1 January 2016 the number of week: 53 (instead of 1) January 31, 2016 the number of week: 4 (instead of 5) then the error shifts in other months. The system works correctly in 2013, 2014, 2015. Test script: --- I provide you sample of the code that allows me to build this list of weeks, I particularly use mktime () // timestamp of first day of month $time = mktime(0,0,0,$mois_select,1,$annee_select); // number of days of month $nbrJoursMois = intval(date('t',$time)); // the number of the first week $numSemaineDebutMois = intval(date('W', $time)); // timestamp of end month $timeFinMois = mktime(0,0,0,$mois_select,$nbrJoursMois,$annee_select); // the number of the last week $numSemaineFinMois = intval(date('W', $timeFinMois)); / Display results / $annee_select = 2016 $mois_select = 1 $time = 1451602800 $nbrJoursMois = 31 $numSemaineDebutMois = 53 (Error) $timeFinMois = 1454194800 $numSemaineFinMoisnum = 4 (Error) -- Edit bug report at https://bugs.php.net/bug.php?id=65696edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=65696r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=65696r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=65696r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=65696r=fixed Fixed in release: https://bugs.php.net/fix.php?id=65696r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=65696r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=65696r=needscript Try newer version: https://bugs.php.net/fix.php?id=65696r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=65696r=support Expected behavior: https://bugs.php.net/fix.php?id=65696r=notwrong Not enough info: https://bugs.php.net/fix.php?id=65696r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=65696r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=65696r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=65696r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=65696r=dst IIS Stability: https://bugs.php.net/fix.php?id=65696r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=65696r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=65696r=float No Zend Extensions: https://bugs.php.net/fix.php?id=65696r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=65696r=mysqlcfg
Req #65696 [Opn-Dup]: Bug Calendar year 2016 with mktime()
Edit report at https://bugs.php.net/bug.php?id=65696edit=1 ID: 65696 Updated by: ni...@php.net Reported by:philippe dot alcaina at hotmail dot fr Summary:Bug Calendar year 2016 with mktime() -Status: Open +Status: Duplicate Type: Feature/Change Request Package:*Calendar problems PHP Version:5.5.3 Block user comment: N Private report: N New Comment: Duplicate of http://php.net/65694. Previous Comments: [2013-09-18 10:46:31] philippe dot alcaina at hotmail dot fr Description: I'm a french developer computer. For an internet tool I need to get a list of weeks after having selected one year and one month. By testing I found a BUG in the year 2016. PHP gives me: 1 January 2016 the number of week: 53 (instead of 1) January 31, 2016 the number of week: 4 (instead of 5) then the error shifts in other months. The system works correctly in 2013, 2014, 2015. Test script: --- I provide you sample of the code that allows me to build this list of weeks, I particularly use mktime () // timestamp of first day of month $time = mktime(0,0,0,$mois_select,1,$annee_select); // number of days of month $nbrJoursMois = intval(date('t',$time)); // the number of the first week $numSemaineDebutMois = intval(date('W', $time)); // timestamp of end month $timeFinMois = mktime(0,0,0,$mois_select,$nbrJoursMois,$annee_select); // the number of the last week $numSemaineFinMois = intval(date('W', $timeFinMois)); / Display results / $annee_select = 2016 $mois_select = 1 $time = 1451602800 $nbrJoursMois = 31 $numSemaineDebutMois = 53 (Error) $timeFinMois = 1454194800 $numSemaineFinMoisnum = 4 (Error) -- Edit this bug report at https://bugs.php.net/bug.php?id=65696edit=1
Req #65695 [Opn-Dup]: mktime() with year 2016
Edit report at https://bugs.php.net/bug.php?id=65695edit=1 ID: 65695 Updated by: ni...@php.net Reported by:philippe dot alcaina at hotmail dot fr Summary:mktime() with year 2016 -Status: Open +Status: Duplicate Type: Feature/Change Request Package:*Calendar problems PHP Version:5.5.3 Block user comment: N Private report: N New Comment: Duplicate of http://php.net/65694. Previous Comments: [2013-09-18 10:33:04] philippe dot alcaina at hotmail dot fr Description: I'm a french developer computer. For an internet tool I need to get a list of weeks after having selected one year and one month. By testing I found a BUG in the year 2016. PHP gives me: 1 January 2016 the number of week: 53 (instead of 1) January 31, 2016 the number of week: 4 (instead of 5) then the error shifts in other months. The system works correctly in 2013, 2014, 2015. I provide you sample of the code that allows me to build this list of weeks, I particularly use mktime () // timestamp of first day of month $time = mktime(0,0,0,$mois_select,1,$annee_select); // number of days of month $nbrJoursMois = intval(date('t',$time)); // the number of the first week $numSemaineDebutMois = intval(date('W', $time)); // timestamp of end month $timeFinMois = mktime(0,0,0,$mois_select,$nbrJoursMois,$annee_select); // the number of the last week $numSemaineFinMois = intval(date('W', $timeFinMois)); / Display results / $annee_select = 2016 $mois_select = 1 $time = 1451602800 $nbrJoursMois = 31 $numSemaineDebutMois = 53 (Error) $timeFinMois = 1454194800 $numSemaineFinMoisnum = 4 (Error) -- Edit this bug report at https://bugs.php.net/bug.php?id=65695edit=1
Req #65694 [Opn-Nab]: error calendar in year 2016, with function mktime()
Edit report at https://bugs.php.net/bug.php?id=65694edit=1 ID: 65694 Updated by: der...@php.net Reported by:philippe dot alcaina at hotmail dot fr Summary:error calendar in year 2016, with function mktime() -Status: Open +Status: Not a bug Type: Feature/Change Request Package:Date/time related Operating System: windows linux PHP Version:5.5.3 Block user comment: N Private report: N New Comment: Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php This seems to work just fine. PHP uses the ISO8601 calendar which indeed has a week 2015-53 for the period Mon Dec 28, 2015 to Sun Jan 3, 2016. Please see http://en.wikipedia.org/wiki/ISO_week_date for more information. Previous Comments: [2013-09-18 10:22:52] philippe dot alcaina at hotmail dot fr Description: I'm a french developer computer. For an internet tool I need to get a list of weeks after having selected one year and one month. By testing I found a BUG in the year 2016. PHP gives me: 1 January 2016 the number of week: 53 (instead of 1) January 31, 2016 the number of week: 4 (instead of 5) then the error shifts in other months. The system works correctly in 2013, 2014, 2015. Test script: --- I provide you sample of the code that allows me to build this list of weeks, I particularly use mktime () // timestamp of first day of month $time = mktime(0,0,0,$mois_select,1,$annee_select); // number of days of month $nbrJoursMois = intval(date('t',$time)); // the number of the first week $numSemaineDebutMois = intval(date('W', $time)); // timestamp of end month $timeFinMois = mktime(0,0,0,$mois_select,$nbrJoursMois,$annee_select); // the number of the last week $numSemaineFinMois = intval(date('W', $timeFinMois)); / Display results / $annee_select = 2016 $mois_select = 1 $time = 1451602800 $nbrJoursMois = 31 $numSemaineDebutMois = 53 (Error) $timeFinMois = 1454194800 $numSemaineFinMoisnum = 4 (Error) -- Edit this bug report at https://bugs.php.net/bug.php?id=65694edit=1
Bug #65451 [Com]: Segmentation fault on compiling the script
Edit report at https://bugs.php.net/bug.php?id=65451edit=1 ID: 65451 Comment by: tim at bortnik dot org Reported by:chupaka at gmail dot com Summary:Segmentation fault on compiling the script Status: Feedback Type: Bug Package:Reproducible crash Operating System: Fedora 19 PHP Version:5.5.1 Block user comment: N Private report: N New Comment: Similar problem was caused by apc for me. Increased apc.shm_size up to 512M (that may vary in different setups) and it is gone. Previous Comments: [2013-08-15 17:15:50] a...@php.net About the reproduce script - any chance to get rid of GET parameters and external file dependency? Whereby it might be not that important as it crashes just compiling. I've just tried on windows and (ubuntu with and without dtrace), no crash. Maybe that's dtrace version, dunno. Is it reproduceable if you compile without dtrace support, could you please try? [2013-08-14 17:09:21] chupaka at gmail dot com Description: I faced the problem after upgrading from php-5.3 to php-5.4, and now it continues in php-5.5 on Apache 2.4.6. The script (thumb.php) works correctly almost all the time (clients open webpage normally), but in Apache logs, there are messages: [Wed Aug 14 19:33:31.106671 2013] [core:notice] [pid 9968] AH00052: child pid 21804 exit signal Segmentation fault (11) [Wed Aug 14 19:33:31.106736 2013] [core:notice] [pid 9968] AH00052: child pid 23371 exit signal Segmentation fault (11) [Wed Aug 14 19:33:31.106762 2013] [core:notice] [pid 9968] AH00052: child pid 23373 exit signal Segmentation fault (11) Test script: --- thumb.php (it's the only file I saw so far that provokes segfaults): ? if (!isset($_GET['m'], $_GET['n'])) { echo No parameters in thumb.php, _GET is .var_export($_GET, true).!; die(); } $m = (integer)$_GET['m']; $n = (integer)$_GET['n']; $dn = (floor($m / 100))./; $fn = $dn.$m-$n.jpg; if (!file_exists($fn)) die(No frame found!); if (!file_exists(thumbs/.$fn) or (filemtime($fn) filemtime(thumbs/.$fn)) or (filesize(thumbs/.$fn) == 0)) { if (!file_exists(thumbs/.$dn)) mkdir(thumbs/.$dn); $img = imagecreatefromjpeg($fn); $size = getimagesize($fn); $nimg = imagecreatetruecolor(80, 40); imagecopyresampled($nimg, $img, 0, 0, 0, 0, 80, 40, $size[0], $size[1]); imagejpeg($nimg, thumbs/.$fn, 85); } readfile(thumbs/.$fn); ? Expected result: No Segmentation faults Actual result: -- gdb attached to a child shows this after failure: Program received signal SIGSEGV, Segmentation fault. 0xb6a40af2 in zend_stack_push (stack=stack@entry=0xb6c0d3d0 compiler_globals+368, element=element@entry=0xb6c0d3ac compiler_globals+332, size=size@entry=36) at /usr/src/debug/php-5.5.1/Zend/zend_stack.c:42 42 stack-elements[stack-top] = (void *) emalloc(size); (gdb) backtrace #0 0xb6a40af2 in zend_stack_push (stack=stack@entry=0xb6c0d3d0 compiler_globals+368, element=element@entry=0xb6c0d3ac compiler_globals+332, size=size@entry=36) at /usr/src/debug/php-5.5.1/Zend/zend_stack.c:42 #1 0xb6a09eca in compile_file (file_handle=file_handle@entry=0xbfa206f8, type=type@entry=2) at Zend/zend_language_scanner.l:586 #2 0xb6a30f56 in dtrace_compile_file (file_handle=0xbfa206f8, type=2) at /usr/src/debug/php-5.5.1/Zend/zend_dtrace.c:40 #3 0xb6a4390a in zend_execute_scripts (type=type@entry=2, retval=retval@entry=0x0, file_count=file_count@entry=1) at /usr/src/debug/php-5.5.1/Zend/zend.c:1308 #4 0xb6afeccf in php_handler (r=0xb9938c48) at /usr/src/debug/php-5.5.1/sapi/apache2handler/sapi_apache2.c:669 (gdb) backtrace full #0 0xb6a40af2 in zend_stack_push (stack=stack@entry=0xb6c0d3d0 compiler_globals+368, element=element@entry=0xb6c0d3ac compiler_globals+332, size=size@entry=36) at /usr/src/debug/php-5.5.1/Zend/zend_stack.c:42 No locals. #1 0xb6a09eca in compile_file (file_handle=file_handle@entry=0xbfa206f8, type=type@entry=2) at Zend/zend_language_scanner.l:586 original_lex_state = {yy_leng = 0, yy_start = 0x0, yy_text = 0x0, yy_cursor = 0x0, yy_marker = 0x0, yy_limit = 0x0, yy_state = 0, state_stack = {top = 0, max = 0, elements = 0x0}, heredoc_label_stack = {top = 0, max = 0, elements = 0x0, top_element = 0x0, persistent = 0 '\000'}, in = 0x0, lineno = 0, filename = 0x0, script_org = 0x0, script_org_size = 0, script_filtered = 0x0, script_filtered_size = 0, input_filter = 0x0, output_filter = 0x0, script_encoding = 0x0} op_array = 0xb662112c original_active_op_array = 0x0 retval = 0xb662112c compiler_result = optimized out compilation_successful = 0 '\000'
[PHP-BUG] Bug #65697 [NEW]: is_link not working with windows junctions
From: giunta dot gaetano at gmail dot com Operating system: win7 64bit PHP version: 5.4.19 Package: *Directory/Filesystem functions Bug Type: Bug Bug description:is_link not working with windows junctions Description: is_link seems to return false for junction points which show up as JUNCTION when using the DIR command. It seems to work for junctions which show up as SYMLINKD when using the DIR command. tested on php 5.3.27 and 5.4.14 (32 bit of course) Test script: --- ?php $paths = array( linksource, linktarget, linktarget2 ); foreach ( $paths as $path ) { echo \n $path\n; var_dump( is_link( $path ) ); var_dump( is_dir( $path ) ); var_dump( array_diff( stat($path), lstat($path) ) ); } Expected result: results of DIR command: 07/09/2013 15:59DIR linksource 07/09/2013 19:11JUNCTION linktarget [D:\htdocs\linksource] 18/09/2013 14:30SYMLINKD linktarget2 [linksource] Actual result: -- D:\htdocsphp linktest.php linksource bool(false) bool(true) array(0) { } linktarget bool(false) bool(true) array(8) { [2]= int(16895) [8]= int(1378562389) [9]= int(1378562389) [10]= int(1378562389) [mode]= int(16895) [atime]= int(1378562389) [mtime]= int(1378562389) [ctime]= int(1378562389) } linktarget2 bool(true) bool(true) array(8) { [2]= int(16895) [8]= int(1378562389) [9]= int(1378562389) [10]= int(1378562389) [mode]= int(16895) [atime]= int(1378562389) [mtime]= int(1378562389) [ctime]= int(1378562389) } -- Edit bug report at https://bugs.php.net/bug.php?id=65697edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=65697r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=65697r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=65697r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=65697r=fixed Fixed in release: https://bugs.php.net/fix.php?id=65697r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=65697r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=65697r=needscript Try newer version: https://bugs.php.net/fix.php?id=65697r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=65697r=support Expected behavior: https://bugs.php.net/fix.php?id=65697r=notwrong Not enough info: https://bugs.php.net/fix.php?id=65697r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=65697r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=65697r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=65697r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=65697r=dst IIS Stability: https://bugs.php.net/fix.php?id=65697r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=65697r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=65697r=float No Zend Extensions: https://bugs.php.net/fix.php?id=65697r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=65697r=mysqlcfg
[PHP-BUG] Bug #65698 [NEW]: certificates validity parsing does not work past 2050
From: tranzig at gmail dot com Operating system: PHP version: master-Git-2013-09-18 (Git) Package: OpenSSL related Bug Type: Bug Bug description:certificates validity parsing does not work past 2050 Description: In asn1_time_to_time_t [ext/openssl/openssl.c], the Y2K bug makes a cameo appearance: [...] *thestr = '\0'; thestr -= 2; thetime.tm_year = atoi(thestr); if (thetime.tm_year 68) { thetime.tm_year += 100; } This piece of code is the part of a backwards UTCTime parser. It moves 2 positions to the left, and converts those two characters to an int. However, certs with a validity past 2050 contain GeneralizedTime formatted timestamps allowing 4 characters in the year field instead of the UTCTime this function parses (badly). [rfc5280, 4.1.2.5] Test script: --- An example script that demonstrates the problem with a cert expiring 2101: http://pastebin.com/Yij0q1qn Expected result: Actual time string of validity: 21010828070405Z parsed with strtotime: 4154655845 [2101-08-28] parsed with asn1_time_to_time_t: 4154655845 [2101-08-28] Actual result: -- Actual time string of validity: 21010828070405Z parsed with strtotime: 4154655845 [2101-08-28] parsed with asn1_time_to_time_t: 998982245 [2001-08-28] -- Edit bug report at https://bugs.php.net/bug.php?id=65698edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=65698r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=65698r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=65698r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=65698r=fixed Fixed in release: https://bugs.php.net/fix.php?id=65698r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=65698r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=65698r=needscript Try newer version: https://bugs.php.net/fix.php?id=65698r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=65698r=support Expected behavior: https://bugs.php.net/fix.php?id=65698r=notwrong Not enough info: https://bugs.php.net/fix.php?id=65698r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=65698r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=65698r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=65698r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=65698r=dst IIS Stability: https://bugs.php.net/fix.php?id=65698r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=65698r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=65698r=float No Zend Extensions: https://bugs.php.net/fix.php?id=65698r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=65698r=mysqlcfg
Req #60760 [PATCH]: Converting zend_parse_parameters() to zend_parse_parameters_none()
Edit report at https://bugs.php.net/bug.php?id=60760edit=1 ID: 60760 Patch added by: le...@php.net Reported by:dragoo...@php.net Summary:Converting zend_parse_parameters() to zend_parse_parameters_none() Status: Assigned Type: Feature/Change Request Package:SPL related Operating System: N/A PHP Version:5 Assigned To:levim Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: spl_zpp_none.diff Revision: 1379516433 URL: https://bugs.php.net/patch-display.php?bug=60760patch=spl_zpp_none.diffrevision=1379516433 Previous Comments: [2013-09-18 09:39:20] ni...@php.net @levi You should use the == FAILURE variant. Nearly all PHP code does the failure/success comparison at the end :) [2013-09-17 23:58:15] le...@php.net My latest patch changes a few of these. Also, there were two styles in use: if (zend_parse_parameters_none() == FAILURE) if (FAILURE == zend_parse_parameters_none()) I picked the latter as `if (FAILURE` indicates the purpose a bit better, in my opinion. If I should have picked the former: let me know and I'll attach a new patch. [2013-09-17 23:55:45] le...@php.net The following patch has been added/updated: Patch Name: spl_zpp_none.patch Revision: 1379462145 URL: https://bugs.php.net/patch-display.php?bug=60760patch=spl_zpp_none.patchrevision=1379462145 [2012-01-20 02:37:31] dragoo...@php.net This is just the way a lot of the phpsrc has been built. Look around various /ext/ places and you'll see it. I'm just cleaning things up and keeping consistency. Got a few more cleanup patches to submit on the SplHeap class for this same reason as i've been working on that class recently. - Paul. [2012-01-20 02:23:52] larue...@php.net if no parameters will be accpected, why call to zend_parse_parameters? just a arginfo will be enough. 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=60760 -- Edit this bug report at https://bugs.php.net/bug.php?id=60760edit=1
Req #60760 [Com]: Converting zend_parse_parameters() to zend_parse_parameters_none()
Edit report at https://bugs.php.net/bug.php?id=60760edit=1 ID: 60760 Comment by: le...@php.net Reported by:dragoo...@php.net Summary:Converting zend_parse_parameters() to zend_parse_parameters_none() Status: Assigned Type: Feature/Change Request Package:SPL related Operating System: N/A PHP Version:5 Assigned To:levim Block user comment: N Private report: N New Comment: The latest patch follows the convention: zend_parse_parameters_none() == FAILURE It also converts a few zpp that are not 'none': FAILURE == zend_parse_parameters(...) zend_parse_parameters(...) == FAILURE Previous Comments: [2013-09-18 15:00:33] le...@php.net The following patch has been added/updated: Patch Name: spl_zpp_none.diff Revision: 1379516433 URL: https://bugs.php.net/patch-display.php?bug=60760patch=spl_zpp_none.diffrevision=1379516433 [2013-09-18 09:39:20] ni...@php.net @levi You should use the == FAILURE variant. Nearly all PHP code does the failure/success comparison at the end :) [2013-09-17 23:58:15] le...@php.net My latest patch changes a few of these. Also, there were two styles in use: if (zend_parse_parameters_none() == FAILURE) if (FAILURE == zend_parse_parameters_none()) I picked the latter as `if (FAILURE` indicates the purpose a bit better, in my opinion. If I should have picked the former: let me know and I'll attach a new patch. [2013-09-17 23:55:45] le...@php.net The following patch has been added/updated: Patch Name: spl_zpp_none.patch Revision: 1379462145 URL: https://bugs.php.net/patch-display.php?bug=60760patch=spl_zpp_none.patchrevision=1379462145 [2012-01-20 02:37:31] dragoo...@php.net This is just the way a lot of the phpsrc has been built. Look around various /ext/ places and you'll see it. I'm just cleaning things up and keeping consistency. Got a few more cleanup patches to submit on the SplHeap class for this same reason as i've been working on that class recently. - Paul. 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=60760 -- Edit this bug report at https://bugs.php.net/bug.php?id=60760edit=1
Bug #60961 [Com]: Graceful Restart (USR2) isn't very graceful
Edit report at https://bugs.php.net/bug.php?id=60961edit=1 ID: 60961 Comment by: baohx2000 at gmail dot com Reported by:phpbugs at oops dot mooo dot com Summary:Graceful Restart (USR2) isn't very graceful Status: Assigned Type: Bug Package:FPM related Operating System: Debian Squeeze PHP Version:5.3.9 Assigned To:fat Block user comment: N Private report: N New Comment: Having this issue on 5.5.3. Sending USR2 to master process kills the master and orphans the children. Have to then kill all children before I can restart the master process. Previous Comments: [2013-02-13 15:57:49] phpbugs at oops dot mooo dot com Try setting process_control_timeout to something higher than 0. [2013-02-13 09:47:32] php-bugs at puzzled dot xs4all dot nl CentOS 6.3 with php-5.3.3 and the FPM code from 5.3.20 still has the same issue. FWIW this makes it challenging to use nginx with php-fpm because it results in a 502 Bad Gateway. I'm more than happy to help testing a patch. [2012-07-17 06:40:44] megazubr at gmail dot com Centos 5.8, php 5.4.4 compiled from source with --enable-fpm When doing USR2 on master pid of php-fpm daemon 1. kill child(502 Bad gatway on long_loop.php in same time) 2. restart daemon with another master pid As i see, it's not a graceful reload. master pid - 12788 child(long_loop.php) - 12795 strace -f -s 8000 -p 12788 [pid 12795] munmap(0x2b017edd1000, 1168) = 0 [pid 12795] munmap(0x2b017edd2000, 1168) = 0 [pid 12795] munmap(0x2b017edd3000, 1168) = 0 [pid 12795] munmap(0x2b017edb5000, 112) = 0 [pid 12795] time(NULL) = 1342505962 [pid 12795] dup2(1, 2) = 2 [pid 12795] close(4)= 0 [pid 12795] dup2(13, 0) = 0 [pid 12795] geteuid() = 0 [pid 12795] setgid(500) = 0 [pid 12795] open(/proc/sys/kernel/ngroups_max, O_RDONLY) = 4 [pid 12795] read(4, 65536\n, 31) = 6 [pid 12795] close(4)= 0 [pid 12795] open(/etc/group, O_RDONLY) = 4 [pid 12795] fcntl(4, F_GETFD) = 0 [pid 12795] fcntl(4, F_SETFD, FD_CLOEXEC) = 0 [pid 12795] fstat(4, {st_mode=S_IFREG|0644, st_size=693, ...}) = 0 [pid 12795] mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2b017b3ce000 [pid 12795] lseek(4, 0, SEEK_CUR) = 0 [pid 12795] read(4, root:x:0:root\nbin:x:1:root,bin,daemon\ndaemon:x:2:root,bin,daemon\nsys:x:3:roo t,bin,adm\nadm:x:4:root,adm,daemon\ntty:x:5:\ndisk:x:6:root\nlp:x:7:daemon,lp\nm em:x:8:\nkmem:x:9:\nwheel:x:10:root\nmail:x:12:mail,exim\nnews:x:13:news\nuucp:x :14:uucp\nman:x:15:\ngames:x:20:\ngopher:x:30:\ndip:x:40:\nftp:x:50:\nlock:x:54: \nnobody:x:99:\nusers:x:100:\nnscd:x:28:\nfloppy:x:19:\nvcsa:x:69:\npcap:x:77:\n utmp:x:22:\nutempter:x:35:\nslocate:x:21:\naudio:x:63:\nrpc:x:32:\nmailnull:x:47 :\nsmmsp:x:51:\necryptfs:x:101:\nsshd:x:74:\ndbus:x:81:\navahi:x:70:\nrpcuser:x: 29:\nnfsnobody:x:65534:\nhaldaemon:x:68:\navahi- autoipd:x:102:\nmysql:x:27:\nftpgroup:x:107:\nexim:x:93:\nscreen:x:84:\nfwh:x:50 0:\nqwqwqw:x:501:\n1q2w3e:x:502:\n1q:x:503:\n2w:x:504:\n, 4096) = 693 [pid 12795] read(4, , 4096) = 0 [pid 12795] close(4)= 0 [pid 12795] munmap(0x2b017b3ce000, 4096) = 0 [pid 12795] setgroups(1, [500]) = 0 [pid 12795] setuid(500) = 0 [pid 12795] prctl(0x4, 0x1, 0, 0, 0)= 0 [pid 12795] clock_gettime(CLOCK_MONOTONIC, {1029872, 690313456}) = 0 [pid 12795] close(6)= 0 [pid 12795] close(8)= 0 [pid 12795] rt_sigaction(SIGTERM, {SIG_DFL, [], SA_RESTORER, 0x322c6302f0}, NULL, 8) = 0 [pid 12795] rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x322c6302f0}, NULL, 8) = 0 [pid 12795] rt_sigaction(SIGUSR1, {SIG_DFL, [], SA_RESTORER, 0x322c6302f0}, NULL, 8) = 0 [pid 12795] rt_sigaction(SIGUSR2, {SIG_DFL, [], SA_RESTORER, 0x322c6302f0}, NULL, 8) = 0 [pid 12795] rt_sigaction(SIGCHLD, {SIG_DFL, [], SA_RESTORER, 0x322c6302f0}, NULL, 8) = 0 [pid 12795] rt_sigaction(SIGQUIT, {0x7c33f0, [], SA_RESTORER|SA_RESTART, 0x322c6302f0}, NULL, 8) = 0 [pid 12795] close(9)= 0 [pid 12795] close(10) = 0 [pid 12795] close(11) = 0 [pid 12795] close(12) = 0 [pid 12795] close(13) = 0 [pid 12795] clock_gettime(CLOCK_MONOTONIC, {1029872, 692338456}) = 0 [pid 12795] accept(0, {sa_family=AF_INET, sin_port=htons(60781), sin_addr=inet_addr(127.0.0.1)}, [16]) = 4 [pid 12795] clock_gettime(CLOCK_MONOTONIC, {1029872, 692611456}) = 0 [pid 12795] time(NULL) = 1342505962 [pid 12795] times({tms_utime=0, tms_stime=0, tms_cutime=0, tms_cstime=0}) =
[PHP-BUG] Bug #65700 [NEW]: Sending USR2 (reload) to master process kills it
From: baohx2000 at gmail dot com Operating system: Ubuntu 12.04 PHP version: 5.5.3 Package: FPM related Bug Type: Bug Bug description:Sending USR2 (reload) to master process kills it Description: Start php-fpm process with a pool. Get pid of master process kill -USR2 [pid] Expected: master sends reload signal to all children (essentially a graceful restart). Actual: master process dies. No output. Nothing logged. Child processes orphaned. Test script: --- Modules loaded: [PHP Modules] bcmath bz2 calendar Core ctype curl date dba dom ereg exif fileinfo filter ftp gd gearman gettext hash iconv json libphonenumberphp libxml mbstring mcrypt memcache memcached mhash mongo mysql mysqli OAuth openssl pcntl pcre PDO pdo_mysql Phar posix redis Reflection session shmop SimpleXML soap sockets SPL standard sysvmsg sysvsem sysvshm tidy tokenizer wddx xml xmlreader xmlwriter Zend OPcache zip zlib [Zend Modules] Zend OPcache Expected result: master sends reload signal to all children (essentially a graceful restart). Actual result: -- master process dies. No output. Nothing logged. Child processes orphaned. -- Edit bug report at https://bugs.php.net/bug.php?id=65700edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=65700r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=65700r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=65700r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=65700r=fixed Fixed in release: https://bugs.php.net/fix.php?id=65700r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=65700r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=65700r=needscript Try newer version: https://bugs.php.net/fix.php?id=65700r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=65700r=support Expected behavior: https://bugs.php.net/fix.php?id=65700r=notwrong Not enough info: https://bugs.php.net/fix.php?id=65700r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=65700r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=65700r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=65700r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=65700r=dst IIS Stability: https://bugs.php.net/fix.php?id=65700r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=65700r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=65700r=float No Zend Extensions: https://bugs.php.net/fix.php?id=65700r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=65700r=mysqlcfg
Bug #65700 [Opn-Csd]: Sending USR2 (reload) to master process kills it
Edit report at https://bugs.php.net/bug.php?id=65700edit=1 ID: 65700 User updated by:baohx2000 at gmail dot com Reported by:baohx2000 at gmail dot com Summary:Sending USR2 (reload) to master process kills it -Status: Open +Status: Closed Type: Bug Package:FPM related Operating System: Ubuntu 12.04 PHP Version:5.5.3 Block user comment: N Private report: N New Comment: Disregard, should have been using SIGUSR2 instead of USR2. Previous Comments: [2013-09-18 16:36:33] baohx2000 at gmail dot com Description: Start php-fpm process with a pool. Get pid of master process kill -USR2 [pid] Expected: master sends reload signal to all children (essentially a graceful restart). Actual: master process dies. No output. Nothing logged. Child processes orphaned. Test script: --- Modules loaded: [PHP Modules] bcmath bz2 calendar Core ctype curl date dba dom ereg exif fileinfo filter ftp gd gearman gettext hash iconv json libphonenumberphp libxml mbstring mcrypt memcache memcached mhash mongo mysql mysqli OAuth openssl pcntl pcre PDO pdo_mysql Phar posix redis Reflection session shmop SimpleXML soap sockets SPL standard sysvmsg sysvsem sysvshm tidy tokenizer wddx xml xmlreader xmlwriter Zend OPcache zip zlib [Zend Modules] Zend OPcache Expected result: master sends reload signal to all children (essentially a graceful restart). Actual result: -- master process dies. No output. Nothing logged. Child processes orphaned. -- Edit this bug report at https://bugs.php.net/bug.php?id=65700edit=1
Bug #65367 [Com]: Segmentation fault when mixing = and =
Edit report at https://bugs.php.net/bug.php?id=65367edit=1 ID: 65367 Comment by: jbozza at mindsites dot com Reported by:mbecc...@php.net Summary:Segmentation fault when mixing = and = Status: Closed Type: Bug Package:Reproducible crash Operating System: Any PHP Version:5.5.1 Assigned To:laruence Block user comment: N Private report: N New Comment: This bug has been listed as closed and fixed in git, but the problem still remains in 5.4.19. Looking at the diff for both files fixed, the 5.4.19 source code is still missing the changed lines. According to the changelogs, 5.5.2 received the fixes on August 15, 2013, but 5.4.18 (released the same day) did not receive the fixes. Can this be applied to 5.4.x? Comment at 2013-08-05 14:50 UTC, by mbecc...@php.net even mentions 5.4. Previous Comments: [2013-08-06 07:45:27] larue...@php.net thanks for the ssh access, it is helpful. fixed in: http://git.php.net/?p=php- src.git;a=commit;h=a831499b4a1029118dc45375e62af42043110ade [2013-08-06 05:53:18] mbecc...@php.net Yes, I've used a fresh git clone. [2013-08-06 03:02:53] larue...@php.net did you built it frome a fresh work dir? [2013-08-05 14:50:51] mbecc...@php.net I have upgraded PHP 5.4 to latest-git on a new machine. With the patch applied I now see many test runs consistently fail with a segafult. Reverting to 5.4.17 fixes the segfault. Backtrace is: #0 0x009beb33 in zend_std_object_get_class (object=0x7fffef535cd0) at /root/compile/php-src/Zend/zend_object_handlers.c:1500 zobj = 0x7fff0021 #1 0x0098dd98 in zend_get_class_entry (zobject=0x7fffef535cd0) at /root/compile/php-src/Zend/zend_API.c:238 No locals. #2 0x00a17121 in ZEND_INIT_METHOD_CALL_SPEC_CV_CONST_HANDLER (execute_data=0x77fa1ea0) at /root/compile/php-src/Zend/zend_vm_execute.h:29282 opline = 0x70a34228 function_name = 0x70a35058 function_name_strval = 0x77f97d50 setFileNameProtection function_name_strlen = 21 #3 0x009c6513 in execute (op_array=0x1446f00) at /root/compile/php-src/Zend/zend_vm_execute.h:410 ret = 0 execute_data = 0x77fa1ea0 nested = 1 '\001' original_in_execution = 0 '\000' #4 0x0098ca9f in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /root/compile/php-src/Zend/zend.c:1315 files = {{gp_offset = 40, fp_offset = 48, overflow_arg_area = 0x7fffae40, reg_save_area = 0x7fffad80}} i = 1 file_handle = 0x7fffd1e0 orig_op_array = 0x0 orig_retval_ptr_ptr = 0x0 orig_interactive = 0 #5 0x00902ff4 in php_execute_script (primary_file=0x7fffd1e0) at /root/compile/php-src/main/main.c:2497 realfile = /home/atlassian/bamboo/xml-data/build-dir/AP-RET-P53P/tests/run.php\000\000\000\000\000\021, '\000' repeats 15 times, P\301\377\377\377\177\000\000\336U\225\000\000\000\000\000\234\066\336\367\377\177\000\000\000\020$\001\000\000\000\000\016\000\000\000\000\000\000\000\260\302\377\377\377\177\000\000-\000\000\000\000\000\000\000fII\\000\000\000\000\240\336\367\377\177\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000%%\211\000\000\000\000\000\030\255\231\365\377\177\000\000\214\236\231\365\377\177\000\000... __orig_bailout = 0x7fffd2f0 __bailout = {{__jmpbuf = {0, -26362260470167, 4380576, 140737488348720, 0, 0, -263622602725482883, 263621642691976829}, __mask_was_saved = 0, __saved_mask = {__val = {0, 0, 140737314399616, 140737488343184, 0, 140737488343200, 4380576, 140737488348720, 0, 0, 9431409, 140737488344000, 140737488349319, 19186208, 287762808856, 21253568 prepend_file_p = 0x0 append_file_p = 0x0 prepend_file = {type = ZEND_HANDLE_FILENAME, filename = 0x0, opened_path = 0x0, handle = {fd = 0, fp = 0x0, stream = {handle = 0x0, isatty = 0, mmap = {len = 0, pos = 0, map = 0x0, buf = 0x0, old_handle = 0x0, old_closer = 0x0}, reader = 0x0, fsizer = 0x0, closer = 0x0}}, free_filename = 0 '\000'} append_file = {type = ZEND_HANDLE_FILENAME, filename = 0x0, opened_path = 0x0, handle = {fd = 0, fp = 0x0, stream = {handle = 0x0, isatty = 0, mmap = {len = 0, pos = 0, map = 0x0, buf = 0x0, old_handle = 0x0, old_closer = 0x0}, reader = 0x0, fsizer = 0x0, closer = 0x0}}, free_filename = 0 '\000'} old_cwd = 0x7fffae60 use_heap = 0 '\000' retval = 0
[PHP-BUG] Bug #65701 [NEW]: copy() doesn't work when destination filename is created by tempnam()
From: flack at contentcontrol-berlin dot de Operating system: Ubuntu Linux PHP version: 5.5.3 Package: *General Issues Bug Type: Bug Bug description:copy() doesn't work when destination filename is created by tempnam() Description: See the script below. The expected output is int(4) instead, I get int(0) I tested on the Ubuntu packages for php 5.3.10, 5.4.4 and 5.5.3. When I use file_put_contents($src, $dst) instead of copy(), it works as expected. Also, when I use fopen() and stream_copy_to_stream(). Only the plain copy() function doesn't behave as expected. Everything is on the same hard disk and was tested on three different machines (Ubuntu 12.04, 13.04 and Debian 7). Test script: --- $src = '/tmp/file.txt'; touch ($src); file_put_contents($src, 'test'); $dst = tempnam('/tmp', 'dst'); copy($src, $dst); var_dump(filesize($dst)); Expected result: int(4) Actual result: -- int(0) -- Edit bug report at https://bugs.php.net/bug.php?id=65701edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=65701r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=65701r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=65701r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=65701r=fixed Fixed in release: https://bugs.php.net/fix.php?id=65701r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=65701r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=65701r=needscript Try newer version: https://bugs.php.net/fix.php?id=65701r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=65701r=support Expected behavior: https://bugs.php.net/fix.php?id=65701r=notwrong Not enough info: https://bugs.php.net/fix.php?id=65701r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=65701r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=65701r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=65701r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=65701r=dst IIS Stability: https://bugs.php.net/fix.php?id=65701r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=65701r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=65701r=float No Zend Extensions: https://bugs.php.net/fix.php?id=65701r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=65701r=mysqlcfg
Bug #65701 [Opn]: copy() doesn't work when destination filename is created by tempnam()
Edit report at https://bugs.php.net/bug.php?id=65701edit=1 ID: 65701 User updated by:flack at contentcontrol-berlin dot de Reported by:flack at contentcontrol-berlin dot de Summary:copy() doesn't work when destination filename is created by tempnam() Status: Open Type: Bug Package:*General Issues Operating System: Ubuntu Linux PHP Version:5.5.3 Block user comment: N Private report: N New Comment: Typo: Should read file_put_contents($src, file_get_contents($dst)) for the version that works Previous Comments: [2013-09-18 17:51:33] flack at contentcontrol-berlin dot de Description: See the script below. The expected output is int(4) instead, I get int(0) I tested on the Ubuntu packages for php 5.3.10, 5.4.4 and 5.5.3. When I use file_put_contents($src, $dst) instead of copy(), it works as expected. Also, when I use fopen() and stream_copy_to_stream(). Only the plain copy() function doesn't behave as expected. Everything is on the same hard disk and was tested on three different machines (Ubuntu 12.04, 13.04 and Debian 7). Test script: --- $src = '/tmp/file.txt'; touch ($src); file_put_contents($src, 'test'); $dst = tempnam('/tmp', 'dst'); copy($src, $dst); var_dump(filesize($dst)); Expected result: int(4) Actual result: -- int(0) -- Edit this bug report at https://bugs.php.net/bug.php?id=65701edit=1
Bug #65701 [Com]: copy() doesn't work when destination filename is created by tempnam()
Edit report at https://bugs.php.net/bug.php?id=65701edit=1 ID: 65701 Comment by: flack at contentcontrol-berlin dot de Reported by:flack at contentcontrol-berlin dot de Summary:copy() doesn't work when destination filename is created by tempnam() Status: Open Type: Bug Package:*General Issues Operating System: Ubuntu Linux PHP Version:5.5.3 Block user comment: N Private report: N New Comment: Argh, third time's the charm: file_put_contents($dst, file_get_contents($src)) is working Previous Comments: [2013-09-18 17:53:00] flack at contentcontrol-berlin dot de Typo: Should read file_put_contents($src, file_get_contents($dst)) for the version that works [2013-09-18 17:51:33] flack at contentcontrol-berlin dot de Description: See the script below. The expected output is int(4) instead, I get int(0) I tested on the Ubuntu packages for php 5.3.10, 5.4.4 and 5.5.3. When I use file_put_contents($src, $dst) instead of copy(), it works as expected. Also, when I use fopen() and stream_copy_to_stream(). Only the plain copy() function doesn't behave as expected. Everything is on the same hard disk and was tested on three different machines (Ubuntu 12.04, 13.04 and Debian 7). Test script: --- $src = '/tmp/file.txt'; touch ($src); file_put_contents($src, 'test'); $dst = tempnam('/tmp', 'dst'); copy($src, $dst); var_dump(filesize($dst)); Expected result: int(4) Actual result: -- int(0) -- Edit this bug report at https://bugs.php.net/bug.php?id=65701edit=1
Bug #65697 [Opn-Nab]: is_link not working with windows junctions
Edit report at https://bugs.php.net/bug.php?id=65697edit=1 ID: 65697 Updated by: paj...@php.net Reported by:giunta dot gaetano at gmail dot com Summary:is_link not working with windows junctions -Status: Open +Status: Not a bug Type: Bug Package:*Directory/Filesystem functions Operating System: win7 64bit PHP Version:5.4.19 Block user comment: N Private report: N New Comment: Junctions are not symlinks, the result is correct. Also the junctions pointing to a directory may work. I remember some windows version specific changes here, where it ended as symlink or junction (recent always do it as symlonk afair) Previous Comments: [2013-09-18 12:51:32] giunta dot gaetano at gmail dot com Description: is_link seems to return false for junction points which show up as JUNCTION when using the DIR command. It seems to work for junctions which show up as SYMLINKD when using the DIR command. tested on php 5.3.27 and 5.4.14 (32 bit of course) Test script: --- ?php $paths = array( linksource, linktarget, linktarget2 ); foreach ( $paths as $path ) { echo \n $path\n; var_dump( is_link( $path ) ); var_dump( is_dir( $path ) ); var_dump( array_diff( stat($path), lstat($path) ) ); } Expected result: results of DIR command: 07/09/2013 15:59DIR linksource 07/09/2013 19:11JUNCTION linktarget [D:\htdocs\linksource] 18/09/2013 14:30SYMLINKD linktarget2 [linksource] Actual result: -- D:\htdocsphp linktest.php linksource bool(false) bool(true) array(0) { } linktarget bool(false) bool(true) array(8) { [2]= int(16895) [8]= int(1378562389) [9]= int(1378562389) [10]= int(1378562389) [mode]= int(16895) [atime]= int(1378562389) [mtime]= int(1378562389) [ctime]= int(1378562389) } linktarget2 bool(true) bool(true) array(8) { [2]= int(16895) [8]= int(1378562389) [9]= int(1378562389) [10]= int(1378562389) [mode]= int(16895) [atime]= int(1378562389) [mtime]= int(1378562389) [ctime]= int(1378562389) } -- Edit this bug report at https://bugs.php.net/bug.php?id=65697edit=1
Bug #65700 [Csd-Nab]: Sending USR2 (reload) to master process kills it
Edit report at https://bugs.php.net/bug.php?id=65700edit=1 ID: 65700 Updated by: ras...@php.net Reported by:baohx2000 at gmail dot com Summary:Sending USR2 (reload) to master process kills it -Status: Closed +Status: Not a bug Type: Bug Package:FPM related Operating System: Ubuntu 12.04 PHP Version:5.5.3 Block user comment: N Private report: N Previous Comments: [2013-09-18 16:42:36] baohx2000 at gmail dot com Disregard, should have been using SIGUSR2 instead of USR2. [2013-09-18 16:36:33] baohx2000 at gmail dot com Description: Start php-fpm process with a pool. Get pid of master process kill -USR2 [pid] Expected: master sends reload signal to all children (essentially a graceful restart). Actual: master process dies. No output. Nothing logged. Child processes orphaned. Test script: --- Modules loaded: [PHP Modules] bcmath bz2 calendar Core ctype curl date dba dom ereg exif fileinfo filter ftp gd gearman gettext hash iconv json libphonenumberphp libxml mbstring mcrypt memcache memcached mhash mongo mysql mysqli OAuth openssl pcntl pcre PDO pdo_mysql Phar posix redis Reflection session shmop SimpleXML soap sockets SPL standard sysvmsg sysvsem sysvshm tidy tokenizer wddx xml xmlreader xmlwriter Zend OPcache zip zlib [Zend Modules] Zend OPcache Expected result: master sends reload signal to all children (essentially a graceful restart). Actual result: -- master process dies. No output. Nothing logged. Child processes orphaned. -- Edit this bug report at https://bugs.php.net/bug.php?id=65700edit=1
Bug #65697 [Nab]: is_link not working with windows junctions
Edit report at https://bugs.php.net/bug.php?id=65697edit=1 ID: 65697 Updated by: paj...@php.net Reported by:giunta dot gaetano at gmail dot com Summary:is_link not working with windows junctions Status: Not a bug Type: Bug Package:*Directory/Filesystem functions Operating System: win7 64bit PHP Version:5.4.19 Block user comment: N Private report: N New Comment: It is not about making sense or not. It is about backward compability and how they actually behave from a file system point of view. Think of junction like hard links. You can't see hard link with is_link, no matter the platform. Previous Comments: [2013-09-18 20:13:02] giunta dot gaetano at gmail dot com Mmm, if it walks like a duck and quacks like a duck... For all scenarios I can figure (backups, deploying code using symlinks), treating a junction as a symlink makes more sense than not doing it. Right now the only way to tell if a folder is actually a real one or not is to use the array_diff trick I put in the test script. It looks hackish, cumbersome, and why should lstat() treat a junction differently than is_link() anyway?) It is true that windows versions starting with Vista do create symlinks by default, but tools like Link Shell Extension or the venerable sysinternals junction.exe still allow one to create Junctions. [2013-09-18 19:00:39] paj...@php.net Junctions are not symlinks, the result is correct. Also the junctions pointing to a directory may work. I remember some windows version specific changes here, where it ended as symlink or junction (recent always do it as symlonk afair) [2013-09-18 12:51:32] giunta dot gaetano at gmail dot com Description: is_link seems to return false for junction points which show up as JUNCTION when using the DIR command. It seems to work for junctions which show up as SYMLINKD when using the DIR command. tested on php 5.3.27 and 5.4.14 (32 bit of course) Test script: --- ?php $paths = array( linksource, linktarget, linktarget2 ); foreach ( $paths as $path ) { echo \n $path\n; var_dump( is_link( $path ) ); var_dump( is_dir( $path ) ); var_dump( array_diff( stat($path), lstat($path) ) ); } Expected result: results of DIR command: 07/09/2013 15:59DIR linksource 07/09/2013 19:11JUNCTION linktarget [D:\htdocs\linksource] 18/09/2013 14:30SYMLINKD linktarget2 [linksource] Actual result: -- D:\htdocsphp linktest.php linksource bool(false) bool(true) array(0) { } linktarget bool(false) bool(true) array(8) { [2]= int(16895) [8]= int(1378562389) [9]= int(1378562389) [10]= int(1378562389) [mode]= int(16895) [atime]= int(1378562389) [mtime]= int(1378562389) [ctime]= int(1378562389) } linktarget2 bool(true) bool(true) array(8) { [2]= int(16895) [8]= int(1378562389) [9]= int(1378562389) [10]= int(1378562389) [mode]= int(16895) [atime]= int(1378562389) [mtime]= int(1378562389) [ctime]= int(1378562389) } -- Edit this bug report at https://bugs.php.net/bug.php?id=65697edit=1
Bug #65697 [Nab]: is_link not working with windows junctions
Edit report at https://bugs.php.net/bug.php?id=65697edit=1 ID: 65697 User updated by:giunta dot gaetano at gmail dot com Reported by:giunta dot gaetano at gmail dot com Summary:is_link not working with windows junctions Status: Not a bug Type: Bug Package:*Directory/Filesystem functions Operating System: win7 64bit PHP Version:5.4.19 Block user comment: N Private report: N New Comment: Ok, then be it Previous Comments: [2013-09-18 20:21:11] paj...@php.net It is not about making sense or not. It is about backward compability and how they actually behave from a file system point of view. Think of junction like hard links. You can't see hard link with is_link, no matter the platform. [2013-09-18 20:13:02] giunta dot gaetano at gmail dot com Mmm, if it walks like a duck and quacks like a duck... For all scenarios I can figure (backups, deploying code using symlinks), treating a junction as a symlink makes more sense than not doing it. Right now the only way to tell if a folder is actually a real one or not is to use the array_diff trick I put in the test script. It looks hackish, cumbersome, and why should lstat() treat a junction differently than is_link() anyway?) It is true that windows versions starting with Vista do create symlinks by default, but tools like Link Shell Extension or the venerable sysinternals junction.exe still allow one to create Junctions. [2013-09-18 19:00:39] paj...@php.net Junctions are not symlinks, the result is correct. Also the junctions pointing to a directory may work. I remember some windows version specific changes here, where it ended as symlink or junction (recent always do it as symlonk afair) [2013-09-18 12:51:32] giunta dot gaetano at gmail dot com Description: is_link seems to return false for junction points which show up as JUNCTION when using the DIR command. It seems to work for junctions which show up as SYMLINKD when using the DIR command. tested on php 5.3.27 and 5.4.14 (32 bit of course) Test script: --- ?php $paths = array( linksource, linktarget, linktarget2 ); foreach ( $paths as $path ) { echo \n $path\n; var_dump( is_link( $path ) ); var_dump( is_dir( $path ) ); var_dump( array_diff( stat($path), lstat($path) ) ); } Expected result: results of DIR command: 07/09/2013 15:59DIR linksource 07/09/2013 19:11JUNCTION linktarget [D:\htdocs\linksource] 18/09/2013 14:30SYMLINKD linktarget2 [linksource] Actual result: -- D:\htdocsphp linktest.php linksource bool(false) bool(true) array(0) { } linktarget bool(false) bool(true) array(8) { [2]= int(16895) [8]= int(1378562389) [9]= int(1378562389) [10]= int(1378562389) [mode]= int(16895) [atime]= int(1378562389) [mtime]= int(1378562389) [ctime]= int(1378562389) } linktarget2 bool(true) bool(true) array(8) { [2]= int(16895) [8]= int(1378562389) [9]= int(1378562389) [10]= int(1378562389) [mode]= int(16895) [atime]= int(1378562389) [mtime]= int(1378562389) [ctime]= int(1378562389) } -- Edit this bug report at https://bugs.php.net/bug.php?id=65697edit=1
Bug #65697 [Nab]: is_link not working with windows junctions
Edit report at https://bugs.php.net/bug.php?id=65697edit=1 ID: 65697 User updated by:giunta dot gaetano at gmail dot com Reported by:giunta dot gaetano at gmail dot com Summary:is_link not working with windows junctions Status: Not a bug Type: Bug Package:*Directory/Filesystem functions Operating System: win7 64bit PHP Version:5.4.19 Block user comment: N Private report: N New Comment: Mmm, if it walks like a duck and quacks like a duck... For all scenarios I can figure (backups, deploying code using symlinks), treating a junction as a symlink makes more sense than not doing it. Right now the only way to tell if a folder is actually a real one or not is to use the array_diff trick I put in the test script. It looks hackish, cumbersome, and why should lstat() treat a junction differently than is_link() anyway?) It is true that windows versions starting with Vista do create symlinks by default, but tools like Link Shell Extension or the venerable sysinternals junction.exe still allow one to create Junctions. Previous Comments: [2013-09-18 19:00:39] paj...@php.net Junctions are not symlinks, the result is correct. Also the junctions pointing to a directory may work. I remember some windows version specific changes here, where it ended as symlink or junction (recent always do it as symlonk afair) [2013-09-18 12:51:32] giunta dot gaetano at gmail dot com Description: is_link seems to return false for junction points which show up as JUNCTION when using the DIR command. It seems to work for junctions which show up as SYMLINKD when using the DIR command. tested on php 5.3.27 and 5.4.14 (32 bit of course) Test script: --- ?php $paths = array( linksource, linktarget, linktarget2 ); foreach ( $paths as $path ) { echo \n $path\n; var_dump( is_link( $path ) ); var_dump( is_dir( $path ) ); var_dump( array_diff( stat($path), lstat($path) ) ); } Expected result: results of DIR command: 07/09/2013 15:59DIR linksource 07/09/2013 19:11JUNCTION linktarget [D:\htdocs\linksource] 18/09/2013 14:30SYMLINKD linktarget2 [linksource] Actual result: -- D:\htdocsphp linktest.php linksource bool(false) bool(true) array(0) { } linktarget bool(false) bool(true) array(8) { [2]= int(16895) [8]= int(1378562389) [9]= int(1378562389) [10]= int(1378562389) [mode]= int(16895) [atime]= int(1378562389) [mtime]= int(1378562389) [ctime]= int(1378562389) } linktarget2 bool(true) bool(true) array(8) { [2]= int(16895) [8]= int(1378562389) [9]= int(1378562389) [10]= int(1378562389) [mode]= int(16895) [atime]= int(1378562389) [mtime]= int(1378562389) [ctime]= int(1378562389) } -- Edit this bug report at https://bugs.php.net/bug.php?id=65697edit=1
Bug #53397 [Com]: Modulo is not accurate with double
Edit report at https://bugs.php.net/bug.php?id=53397edit=1 ID: 53397 Comment by: cmbecker69 at gmx dot de Reported by:mryaggi at hotmail dot com Summary:Modulo is not accurate with double Status: Verified Type: Bug Package:Scripting Engine problem Operating System: All PHP Version:Irrelevant Block user comment: N Private report: N New Comment: The operation a - (floor(a/b)*b) gives not the modulo, but the remainder. Furthermore it seems the suggested patch does neither cater for large divisors nor large results. It *might* be reasonable to stick with the current implementation, and to state clearly in the documentation[1] that the modulus operator gives correct results only for integers in the range [-PHP_INT_MAX - 1, PHP_INT_MAX]. The current wording is somewhat misleading, IMHO. [1] http://www.php.net/manual/en/language.operators.arithmetic.php Previous Comments: [2013-08-06 08:28:02] yohg...@php.net Test with 5.5.1 32bit. This issue exists still. [2010-11-24 15:12:40] mryaggi at hotmail dot com Description: In C++ : 129059460 % 8640 = 3780 //correct But In PHP : 129059460 % 8640 = 30811200 //wrong However, in PHP : 129059460 - (floor(129059460/8640)*8640) = 3780 //correct! Can modulo opertor be implemented this way when left value PHP_INT_MAX ? See Patch in attachement Test script: --- echo 129059460 % 8640; echo \n; echo 129059460 - (floor(129059460/8640)*8640); Expected result: 3780 3780 Actual result: -- 30811200 3780 -- Edit this bug report at https://bugs.php.net/bug.php?id=53397edit=1
Bug #64332 [Com]: Problems with BR Save time (BRST)
Edit report at https://bugs.php.net/bug.php?id=64332edit=1 ID: 64332 Comment by: cmbecker69 at gmx dot de Reported by:bernardo at datamex dot com dot br Summary:Problems with BR Save time (BRST) Status: Open Type: Bug Package:Date/time related Operating System: Window,Linux,FreeBSD PHP Version:Irrelevant Block user comment: N Private report: N New Comment: If I'm not mistaken the actual results are correct, and the expected results are wrong. At least according to Wikipedia[1] America/Sao_Paulo and America/Bahia have the same offset to UTC and identical DST offset. If so, this is not a bug (but rather an older bug was fixed). [1] http://en.wikipedia.org/wiki/Bras%C3%ADlia_Summer_Time Previous Comments: [2013-03-01 17:59:17] bernardo at datamex dot com dot br Description: I changed my server application before Freebsd with php 5.3.3 now Ubuntu with php 5.3.10. I noticed that there are differences between treatment dates in different timezones. Note that when BRST America/Sao_Paulo advances one hour. Test script: --- ?php error_reporting(E_ALL); $timezone = date_default_timezone_get(); $time = mktime(12,0,0,1,15,2013); $agoraAqui = date(d/m/Y H:i:s); $antesAqui = date(d/m/Y H:i:s, $time); date_default_timezone_set('America/Bahia'); $agoraLa = date(d/m/Y H:i:s); $antesLa = date(d/m/Y H:i:s, $time); echo table border=1 tr td/tdtdNOW/tdtdIn BRST ({$time})/td /tr tr td{$timezone}/tdtd{$agoraAqui}/tdtd{$antesAqui}/td /tr tr tdAmerica/Bahia/tdtd{$agoraLa}/tdtd{$antesLa}/td /tr /table br / a href='http://wwp.greenwichmeantime.com/time-zone/south-america/brazil/time-brazil/'time-brazil/a ; ? Expected result: NOW | In BRST (1358258400) America/Sao_Paulo | 01/03/2013 14:46:27 | 15/01/2013 12:00:00 America/Bahia | 01/03/2013 14:46:27 | 15/01/2013 11:00:00 Actual result: -- Correct in: - freebsd + php 5.3.3 - freebsd + php 5.3.6 - windows + php 5.3.8 NOW | In BRST (1358258400) America/Sao_Paulo | 01/03/2013 14:46:27 | 15/01/2013 12:00:00 America/Bahia | 01/03/2013 14:46:27 | 15/01/2013 11:00:00 Error in: - freebsd + php 5.3.10 - ubuntu + php 5.3.10 - windows + php 5.4.3 NOW | In BRST (1358258400) America/Sao_Paulo | 01/03/2013 14:46:27 | 15/01/2013 12:00:00 America/Bahia | 01/03/2013 14:46:27 | 15/01/2013 12:00:00 -- Edit this bug report at https://bugs.php.net/bug.php?id=64332edit=1
Bug #65693 [Com]: mssql_fetch_batch does not fetch next batch
Edit report at https://bugs.php.net/bug.php?id=65693edit=1 ID: 65693 Comment by: ken-phpbugs at norganna dot com Reported by:ken-phpbugs at norganna dot com Summary:mssql_fetch_batch does not fetch next batch Status: Open Type: Bug Package:MSSQL related Operating System: Linux PHP Version:5.5.3 Block user comment: N Private report: N New Comment: Actually, the patch I provided does not help if you are running multiple queries. It seems that the dbcancel() for any query on the link cancels all queries on the link, so that if another query decides to free a result, your completely separate batch result is nuked at the same time. The only way I can work out to make it multi-query safe is to comment out the dbcancel() line altogether. Previous Comments: [2013-09-18 05:47:05] ken-phpbugs at norganna dot com I made a minor copy/paste fail with the test script: $remain = mssql_fetch_batch($res); $res should be $result. Bug is still valid. [2013-09-18 05:09:20] ken-phpbugs at norganna dot com Description: When sending batch requests to the mssql server, the mssql result is having dbcancel() called prematurely on the handle (via the _free_mssql_result function). Because we are processing batches of the result set we need the query to stay open until we are finished fetching all the rows (not just the first batch). In a non-batch scenario, it is fine to cancel the query after the first batch is called, because all rows have been fetched. I have attached a patch, which fixes the problem, but probably not in the right way. I have no clue what the right way actually would be or what the repercussions of applying the patch are. It is meant for illustrative purposes only. Test script: --- ?php // Connect to MSSQL and select the database $link = mssql_connect('hostpath', 'user', 'pass'); mssql_select_db('db', $link); // Send a query to a table that has 12 rows print Given a table with 12 rows:\n; $result = mssql_query('SELECT * FROM tablename', $link, 5); do { while ($row = mssql_fetch_assoc($result)) { print Row found\n; } $remain = mssql_fetch_batch($res); print Remainder $remain\n; } while ($remain 0); Expected result: Given a table with 12 rows: Row found Row found Row found Row found Row found Remainder 5 Row found Row found Row found Row found Row found Remainder 2 Row found Row found Remainder 0 Actual result: -- Given a table with 12 rows: Row found Row found Row found Row found Row found Remainder 1 Row found Remainder 0 -- Edit this bug report at https://bugs.php.net/bug.php?id=65693edit=1
Bug #64332 [Opn]: Problems with BR Save time (BRST)
Edit report at https://bugs.php.net/bug.php?id=64332edit=1 ID: 64332 User updated by:bernardo at datamex dot com dot br Reported by:bernardo at datamex dot com dot br Summary:Problems with BR Save time (BRST) Status: Open Type: Bug Package:Date/time related Operating System: Window,Linux,FreeBSD PHP Version:Irrelevant Block user comment: N Private report: N New Comment: Please read this part Does Brazil observe Daylight Saving Time? in link http://wwp.greenwichmeantime.com/time-zone/south-america/brazil/time-brazil/ Brazil Decree No. 7826 of 15 October.2012. Gives new wording of art. 2 of Decree No. 6558 of 08 September 2008 establishing daylight saving time in part of the national territory. Daylight saving time will be valid in the states of Rio Grande do Sul, Santa Catarina, Parana, Sao Paulo, Rio de Janeiro, Espirito Santo, Minas Gerais, Goiás, Mato Grosso, Mato Grosso do Sul, Tocatins and the Federal District. Previous Comments: [2013-09-18 22:37:13] cmbecker69 at gmx dot de If I'm not mistaken the actual results are correct, and the expected results are wrong. At least according to Wikipedia[1] America/Sao_Paulo and America/Bahia have the same offset to UTC and identical DST offset. If so, this is not a bug (but rather an older bug was fixed). [1] http://en.wikipedia.org/wiki/Bras%C3%ADlia_Summer_Time [2013-03-01 17:59:17] bernardo at datamex dot com dot br Description: I changed my server application before Freebsd with php 5.3.3 now Ubuntu with php 5.3.10. I noticed that there are differences between treatment dates in different timezones. Note that when BRST America/Sao_Paulo advances one hour. Test script: --- ?php error_reporting(E_ALL); $timezone = date_default_timezone_get(); $time = mktime(12,0,0,1,15,2013); $agoraAqui = date(d/m/Y H:i:s); $antesAqui = date(d/m/Y H:i:s, $time); date_default_timezone_set('America/Bahia'); $agoraLa = date(d/m/Y H:i:s); $antesLa = date(d/m/Y H:i:s, $time); echo table border=1 tr td/tdtdNOW/tdtdIn BRST ({$time})/td /tr tr td{$timezone}/tdtd{$agoraAqui}/tdtd{$antesAqui}/td /tr tr tdAmerica/Bahia/tdtd{$agoraLa}/tdtd{$antesLa}/td /tr /table br / a href='http://wwp.greenwichmeantime.com/time-zone/south-america/brazil/time-brazil/'time-brazil/a ; ? Expected result: NOW | In BRST (1358258400) America/Sao_Paulo | 01/03/2013 14:46:27 | 15/01/2013 12:00:00 America/Bahia | 01/03/2013 14:46:27 | 15/01/2013 11:00:00 Actual result: -- Correct in: - freebsd + php 5.3.3 - freebsd + php 5.3.6 - windows + php 5.3.8 NOW | In BRST (1358258400) America/Sao_Paulo | 01/03/2013 14:46:27 | 15/01/2013 12:00:00 America/Bahia | 01/03/2013 14:46:27 | 15/01/2013 11:00:00 Error in: - freebsd + php 5.3.10 - ubuntu + php 5.3.10 - windows + php 5.4.3 NOW | In BRST (1358258400) America/Sao_Paulo | 01/03/2013 14:46:27 | 15/01/2013 12:00:00 America/Bahia | 01/03/2013 14:46:27 | 15/01/2013 12:00:00 -- Edit this bug report at https://bugs.php.net/bug.php?id=64332edit=1
[PHP-BUG] Req #65703 [NEW]: Primitives, Strings and Arrays as Objects
From: worldoffame at hotmail dot com Operating system: Irrelevant PHP version: Irrelevant Package: Class/Object related Bug Type: Feature/Change Request Bug description:Primitives, Strings and Arrays as Objects Description: Well currently in PHP not everything is an object, if you use the object operator - on an integer variable(like 2-toFloat()) you will get an error. Strings and Arrays are not object either, and these are bigger problems than primitives like integers, floats and booleans. So I propose that in PHP 5.6 everything is an object. The PHP core will provide special classes such as Boolean, Integer, Float, String and Array, all of them have methods for client users to manipulate. For Booleans and Integers, the methods will be quite limited. But for Strings and Arrays, each currently available orphan string/array functions can be made into methods. Below is how you'd play with strings and arrays in PHP 5.5 and 5.6: PHP 5.5: echo strtoupper(this is a string); $array = sort([2, 5, 1, 4, 6, 3]); PHP 5.6: echo this is a string-toUpper(); $array = [2, 5, 1, 4, 6, 3]-sort(); Id say the proposed methods are much more elegant, and thats how Python and Ruby deal with strings and arrays. Also the keyword array will be removed as Array will be used as a class name. In PHP 5.7 and beyond it may be a good point to consider deprecating the traditiona/procedural way of creating primitive types, strings and arrays. -- Edit bug report at https://bugs.php.net/bug.php?id=65703edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=65703r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=65703r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=65703r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=65703r=fixed Fixed in release: https://bugs.php.net/fix.php?id=65703r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=65703r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=65703r=needscript Try newer version: https://bugs.php.net/fix.php?id=65703r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=65703r=support Expected behavior: https://bugs.php.net/fix.php?id=65703r=notwrong Not enough info: https://bugs.php.net/fix.php?id=65703r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=65703r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=65703r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=65703r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=65703r=dst IIS Stability: https://bugs.php.net/fix.php?id=65703r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=65703r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=65703r=float No Zend Extensions: https://bugs.php.net/fix.php?id=65703r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=65703r=mysqlcfg
Req #65703 [Opn-Wfx]: Primitives, Strings and Arrays as Objects
Edit report at https://bugs.php.net/bug.php?id=65703edit=1 ID: 65703 Updated by: requi...@php.net Reported by:worldoffame at hotmail dot com Summary:Primitives, Strings and Arrays as Objects -Status: Open +Status: Wont fix Type: Feature/Change Request Package:Class/Object related Operating System: Irrelevant PHP Version:Irrelevant Block user comment: N Private report: N New Comment: This has been brought up numerous times before with the answer of not going to happen anytime soon. You can bring this subject up on the internals mailing list but know that requesting such a huge (I don't know if I can stress that enough) change simply because other languages do it that way won't get much of a positive response. http://www.php.net/mailing-lists.php#internals You may also be interested in the autoboxing RFC. https://wiki.php.net/rfc/autoboxing Previous Comments: [2013-09-19 04:02:57] worldoffame at hotmail dot com Description: Well currently in PHP not everything is an object, if you use the object operator - on an integer variable(like 2-toFloat()) you will get an error. Strings and Arrays are not object either, and these are bigger problems than primitives like integers, floats and booleans. So I propose that in PHP 5.6 everything is an object. The PHP core will provide special classes such as Boolean, Integer, Float, String and Array, all of them have methods for client users to manipulate. For Booleans and Integers, the methods will be quite limited. But for Strings and Arrays, each currently available orphan string/array functions can be made into methods. Below is how you'd play with strings and arrays in PHP 5.5 and 5.6: PHP 5.5: echo strtoupper(this is a string); $array = sort([2, 5, 1, 4, 6, 3]); PHP 5.6: echo this is a string-toUpper(); $array = [2, 5, 1, 4, 6, 3]-sort(); Id say the proposed methods are much more elegant, and thats how Python and Ruby deal with strings and arrays. Also the keyword array will be removed as Array will be used as a class name. In PHP 5.7 and beyond it may be a good point to consider deprecating the traditiona/procedural way of creating primitive types, strings and arrays. -- Edit this bug report at https://bugs.php.net/bug.php?id=65703edit=1