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
