Bug #63059 [Com]: Failed to build PHP-FPM
Edit report at https://bugs.php.net/bug.php?id=63059&edit=1 ID: 63059 Comment by: rainer dot jung at kippdata dot de Reported by:nam dot nh at nd24 dot net Summary:Failed to build PHP-FPM Status: Closed Type: Bug Package:Compile Failure Operating System: OpenIndiana 151a6 PHP Version:5.4.6 Block user comment: N Private report: N New Comment: Problem still unfixed in PHP 5.4.9 on Solaris 10. Same error as seen by the OP. The patch proposed here wasn't applied, so the problem still exists. Please apply the patch. It is a followup to Bug #62654. There the sapi/fpm/fpm/fpm_sockets.c file was fixed, but the sapi/fpm/fpm/fpm_sockets.h was forgotten. Previous Comments: [2012-10-14 01:43:21] nam dot nh at nd24 dot net Compile successful, then the case is closed [2012-10-14 01:41:58] nam dot nh at nd24 dot net The problem fixed. Thanks. [2012-10-13 17:47:35] mike at maytech dot net See patch attached; should fix the compilation problem. [2012-10-13 15:57:49] nam dot nh at nd24 dot net Found similar to bug #62654, but still get error when "make" [2012-09-11 06:00:16] nam dot nh at nd24 dot net Description: I'm building PHP 5.4.6 on a fresh machine that run OpenIndiana 151a6 OS, gcc version 4.6.3, error happens when do "make" Test script: --- ./configure --prefix=/usr/php --with-gd --with-mcrypt --with-zlib --enable-mbstring --with-mysql=mysqlnd --with-mysqli=mysqlnd --enable-inline-optimization --with-bz2 --enable-sockets --enable-mbregex --with-mhash --enable-zip --with-png-dir=/usr/include --with-jpeg-dir=/usr/include --with-freetype-dir=/usr/include --with-xpm-dir=/usr/include --enable-gd-native-ttf --with-pear=/usr/php/lib/php --disable-ipv6 --enable-fpm Expected result: Successfully Actual result: -- /bin/sh /usr/src/php-5.4.6/libtool --silent --preserve-dup-deps --mode=compile gcc -I/usr/src/php-5.4.6/sapi/fpm -Isapi/fpm/ -I/usr/src/php-5.4.6/sapi/fpm/ - DPHP_ATOM_INC -I/usr/src/php-5.4.6/include -I/usr/src/php-5.4.6/main - I/usr/src/php-5.4.6 -I/usr/src/php-5.4.6/ext/date/lib -I/usr/src/php- 5.4.6/ext/ereg/regex -I/usr/include/libxml2 -I/usr/X11R6/include - I/usr/include/freetype2 -I/usr/src/php-5.4.6/ext/mbstring/oniguruma - I/usr/src/php-5.4.6/ext/mbstring/libmbfl -I/usr/src/php- 5.4.6/ext/mbstring/libmbfl/mbfl -I/usr/src/php-5.4.6/ext/sqlite3/libsqlite - I/usr/src/php-5.4.6/TSRM -I/usr/src/php-5.4.6/Zend -D_POSIX_PTHREAD_SEMANTICS -I/usr/include -g -O2 -fvisibility=hidden -c /usr/src/php- 5.4.6/sapi/fpm/fpm/fastcgi.c -o sapi/fpm/fpm/fastcgi.lo /bin/sh /usr/src/php-5.4.6/libtool --silent --preserve-dup-deps --mode=compile gcc -I/usr/src/php-5.4.6/sapi/fpm -Isapi/fpm/ -I/usr/src/php-5.4.6/sapi/fpm/ - DPHP_ATOM_INC -I/usr/src/php-5.4.6/include -I/usr/src/php-5.4.6/main - I/usr/src/php-5.4.6 -I/usr/src/php-5.4.6/ext/date/lib -I/usr/src/php- 5.4.6/ext/ereg/regex -I/usr/include/libxml2 -I/usr/X11R6/include - I/usr/include/freetype2 -I/usr/src/php-5.4.6/ext/mbstring/oniguruma - I/usr/src/php-5.4.6/ext/mbstring/libmbfl -I/usr/src/php- 5.4.6/ext/mbstring/libmbfl/mbfl -I/usr/src/php-5.4.6/ext/sqlite3/libsqlite - I/usr/src/php-5.4.6/TSRM -I/usr/src/php-5.4.6/Zend -D_POSIX_PTHREAD_SEMANTICS -I/usr/include -g -O2 -fvisibility=hidden -c /usr/src/php- 5.4.6/sapi/fpm/fpm/fpm.c -o sapi/fpm/fpm/fpm.lo In file included from /usr/src/php-5.4.6/sapi/fpm/fpm/fpm.c:16:0: /usr/src/php-5.4.6/sapi/fpm/fpm/fpm_sockets.h:28:54: error: expected ';', ',' or ')' before numeric constant make: *** [sapi/fpm/fpm/fpm.lo] Error 1 -- Edit this bug report at https://bugs.php.net/bug.php?id=63059&edit=1
Bug #63714 [Nab]: incorrect global statement
Edit report at https://bugs.php.net/bug.php?id=63714&edit=1
ID: 63714
Updated by: larue...@php.net
Reported by:axdr at bk dot ru
Summary:incorrect global statement
Status: Not a bug
Type: Bug
Package:Scripting Engine problem
Operating System: Windows
PHP Version:5.4.9
Block user comment: N
Private report: N
New Comment:
try this:
$gvar = 'aaa';
$var = 'bbb';
func1();
unset($gvar); //reset the environment
unset($var);
$gvar = 'aaa';
$var = 'bbb';
func2();
Previous Comments:
[2012-12-08 00:17:26] axdr at bk dot ru
Please, ignore previous comment
function func1() {
global $gvar;
$var = &$GLOBALS['var'];
$GLOBALS['var'] = &$gvar;
var_dump($var, $GLOBALS['var'], $gvar);
}
function func2() {
global $gvar;
global $var;
$GLOBALS['var'] = &$gvar;
var_dump($var, $GLOBALS['var'], $gvar);
}
$gvar = 'aaa';
$var = 'bbb';
func1();
echo '';
$gvar = 'aaa';
$var = 'bbb';
func2();
output:
string 'bbb'
string 'aaa'
string 'aaa'
string 'bbb'
string 'bbb'
string 'bbb'
[2012-12-08 00:00:31] axdr at bk dot ru
global $var is reference to $GLOBALS['var']
but is not equivalent to $var = &$GLOBALS['var']
$gvar = 'aaa';
$var = 'bbb';
function func2() {
global $gvar;
global $var;
$GLOBALS['var'] = &$gvar;
var_dump($var, $GLOBALS['var']);
}
function func1() {
global $gvar;
$var = &$GLOBALS['var'];
$GLOBALS['var'] = &$gvar;
var_dump($var, $GLOBALS['var']);
}
function func3() {
$gvar = 'aaa';
$var1 = 'bbb'; // вмеÑÑо global $var
$var = &$var1;
$var1 = &$gvar;
var_dump($var, $var1);
}
func1();
echo '';
func2();
echo '';
func3();
output:
'bbb'
'aaa'
-
'aaa'
'aaa'
-
'bbb'
'aaa'
[2012-12-07 04:08:02] axdr at bk dot ru
Sorry. You are right.
But I think this is irrational.
It's impossible to read all documentation and to remember word for word.
This is a kind of underwater mine.
[2012-12-07 02:54:35] larue...@php.net
also see:
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
global $a;
make a local variable 'a' reference to $GLOBALS['a'];
also thinking of:
$b = &$a; // b reference to a
$b = &$c; // change reference to c
then:
global $a, $b; //b reference to $GLOBALS['b']
$a = 'aaa';
$b = &$a;//b now reference to local $a with GLOBALS['b'] unchanged
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=63714
--
Edit this bug report at https://bugs.php.net/bug.php?id=63714&edit=1
Bug #63708 [Opn->Nab]: imagefttext or imagettftext both function are return a blank image
Edit report at https://bugs.php.net/bug.php?id=63708&edit=1
ID: 63708
Updated by: s...@php.net
Reported by:rameezsoomro dot pk at live dot com
-Summary:5.16.1
+Summary:imagefttext or imagettftext both function are return
a blank image
-Status: Open
+Status: Not a bug
Type: Bug
Package:GD related
Operating System: Win 7
PHP Version:5.4.9
Block user comment: N
Private report: N
New Comment:
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. Due to the volume
of reports we can not explain in detail here why your report is not
a bug. The support channels will be able to provide an explanation
for you.
Thank you for your interest in PHP.
Previous Comments:
[2012-12-06 11:42:48] rameezsoomro dot pk at live dot com
Description:
Note: I i've choose wrong version on PHP Version list because my php version
not
available on list option...
I am using xampp on localhost/computer with Apache/2.4.3 (Win32) OpenSSL/1.0.1c
PHP/5.4.7
imagefttext or imagettftext both function are return a blank image (null) and
my
gd library was also enable ...tell me what should i do...
Test script:
---
// Set the content-type
header('Content-Type: image/png');
// Create the image
$im = imagecreatetruecolor(400, 30);
// Create some colors
$white = imagecolorallocate($im, 255, 255, 255);
$grey = imagecolorallocate($im, 128, 128, 128);
$black = imagecolorallocate($im, 0, 0, 0);
imagefilledrectangle($im, 0, 0, 399, 29, $white);
// The text to draw
$text = 'Testing...';
// Replace path by your own font path
$font = 'arial.ttf';
// Add some shadow to the text
imagefttext($im, 20, 0, 11, 21, $grey, $font, $text);
// Add the text
imagefttext($im, 20, 0, 10, 20, $black, $font, $text);
// Using imagepng() results in clearer text compared with imagejpeg()
imagepng($im);
imagedestroy($im);
--
Edit this bug report at https://bugs.php.net/bug.php?id=63708&edit=1
Bug #63714 [Nab]: incorrect global statement
Edit report at https://bugs.php.net/bug.php?id=63714&edit=1
ID: 63714
User updated by:axdr at bk dot ru
Reported by:axdr at bk dot ru
Summary:incorrect global statement
Status: Not a bug
Type: Bug
Package:Scripting Engine problem
Operating System: Windows
PHP Version:5.4.9
Block user comment: N
Private report: N
New Comment:
Please, ignore previous comment
function func1() {
global $gvar;
$var = &$GLOBALS['var'];
$GLOBALS['var'] = &$gvar;
var_dump($var, $GLOBALS['var'], $gvar);
}
function func2() {
global $gvar;
global $var;
$GLOBALS['var'] = &$gvar;
var_dump($var, $GLOBALS['var'], $gvar);
}
$gvar = 'aaa';
$var = 'bbb';
func1();
echo '';
$gvar = 'aaa';
$var = 'bbb';
func2();
output:
string 'bbb'
string 'aaa'
string 'aaa'
string 'bbb'
string 'bbb'
string 'bbb'
Previous Comments:
[2012-12-08 00:00:31] axdr at bk dot ru
global $var is reference to $GLOBALS['var']
but is not equivalent to $var = &$GLOBALS['var']
$gvar = 'aaa';
$var = 'bbb';
function func2() {
global $gvar;
global $var;
$GLOBALS['var'] = &$gvar;
var_dump($var, $GLOBALS['var']);
}
function func1() {
global $gvar;
$var = &$GLOBALS['var'];
$GLOBALS['var'] = &$gvar;
var_dump($var, $GLOBALS['var']);
}
function func3() {
$gvar = 'aaa';
$var1 = 'bbb'; // вмеÑÑо global $var
$var = &$var1;
$var1 = &$gvar;
var_dump($var, $var1);
}
func1();
echo '';
func2();
echo '';
func3();
output:
'bbb'
'aaa'
-
'aaa'
'aaa'
-
'bbb'
'aaa'
[2012-12-07 04:08:02] axdr at bk dot ru
Sorry. You are right.
But I think this is irrational.
It's impossible to read all documentation and to remember word for word.
This is a kind of underwater mine.
[2012-12-07 02:54:35] larue...@php.net
also see:
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
global $a;
make a local variable 'a' reference to $GLOBALS['a'];
also thinking of:
$b = &$a; // b reference to a
$b = &$c; // change reference to c
then:
global $a, $b; //b reference to $GLOBALS['b']
$a = 'aaa';
$b = &$a;//b now reference to local $a with GLOBALS['b'] unchanged
[2012-12-07 02:44:58] axdr at bk dot ru
'global'-declaration kills referencies
function func() {
global $a, $b;
$a = 'aaa';
$b = &$a;
echo "$a, $b", '';
global $a, $b;
echo "$a, $b";
}
func();
output:
aaa, aaa
aaa,
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=63714
--
Edit this bug report at https://bugs.php.net/bug.php?id=63714&edit=1
Bug #63714 [Nab]: incorrect global statement
Edit report at https://bugs.php.net/bug.php?id=63714&edit=1
ID: 63714
User updated by:axdr at bk dot ru
Reported by:axdr at bk dot ru
Summary:incorrect global statement
Status: Not a bug
Type: Bug
Package:Scripting Engine problem
Operating System: Windows
PHP Version:5.4.9
Block user comment: N
Private report: N
New Comment:
global $var is reference to $GLOBALS['var']
but is not equivalent to $var = &$GLOBALS['var']
$gvar = 'aaa';
$var = 'bbb';
function func2() {
global $gvar;
global $var;
$GLOBALS['var'] = &$gvar;
var_dump($var, $GLOBALS['var']);
}
function func1() {
global $gvar;
$var = &$GLOBALS['var'];
$GLOBALS['var'] = &$gvar;
var_dump($var, $GLOBALS['var']);
}
function func3() {
$gvar = 'aaa';
$var1 = 'bbb'; // вмеÑÑо global $var
$var = &$var1;
$var1 = &$gvar;
var_dump($var, $var1);
}
func1();
echo '';
func2();
echo '';
func3();
output:
'bbb'
'aaa'
-
'aaa'
'aaa'
-
'bbb'
'aaa'
Previous Comments:
[2012-12-07 04:08:02] axdr at bk dot ru
Sorry. You are right.
But I think this is irrational.
It's impossible to read all documentation and to remember word for word.
This is a kind of underwater mine.
[2012-12-07 02:54:35] larue...@php.net
also see:
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
global $a;
make a local variable 'a' reference to $GLOBALS['a'];
also thinking of:
$b = &$a; // b reference to a
$b = &$c; // change reference to c
then:
global $a, $b; //b reference to $GLOBALS['b']
$a = 'aaa';
$b = &$a;//b now reference to local $a with GLOBALS['b'] unchanged
[2012-12-07 02:44:58] axdr at bk dot ru
'global'-declaration kills referencies
function func() {
global $a, $b;
$a = 'aaa';
$b = &$a;
echo "$a, $b", '';
global $a, $b;
echo "$a, $b";
}
func();
output:
aaa, aaa
aaa,
[2012-12-07 02:37:38] axdr at bk dot ru
Description:
'global'-declaration inside a function dosn't affect referencies.
Test script:
---
function func() {
global $a, $b;
$a = 'aaa';
$b = &$a;
$GLOBALS['c'] = &$a;
}
func();
echo "$a, $b, $c";
Expected result:
aaa, aaa, aaa
Actual result:
--
aaa, , aaa
--
Edit this bug report at https://bugs.php.net/bug.php?id=63714&edit=1
[PHP-BUG] Bug #63724 [NEW]: MessageFormatter buggy when using select formats with nested parameters
From: eskwayrd at gmail dot com
Operating system: Linux
PHP version: 5.4.9
Package: I18N and L10N related
Bug Type: Bug
Bug description:MessageFormatter buggy when using select formats with nested
parameters
Description:
When a message formatter formats selects with nested variables, its
behaviour is
buggy.
Test script:
---
// attempting to translate file size
$locale = 'en_US';
$args = array(1.23435, 'M');
$format = "{1, select, k {{0} kB} M {{0} MB} other {{0} B}}";
echo "#1: ". msgfmt_format_message($locale, $format, $args) ."\n";
$format = "{1, select, k {{0} kB} M {{0, number, #.##} MB} other {{0}
B}}";
echo "#2: ". msgfmt_format_message($locale, $format, $args) ."\n";
echo "Error? ". intl_get_error_message() ."\n";
Expected result:
#1: 1.23435 MB
#2: 1.23 MB
Error? U_ZERO_ERROR
Actual result:
--
#1: 1.23435 MB
#2:
Error? Creating message formatter failed: U_ARGUMENT_TYPE_MISMATCH
--
Edit bug report at https://bugs.php.net/bug.php?id=63724&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=63724&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=63724&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=63724&r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=63724&r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=63724&r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=63724&r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=63724&r=needscript
Try newer version: https://bugs.php.net/fix.php?id=63724&r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=63724&r=support
Expected behavior: https://bugs.php.net/fix.php?id=63724&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=63724&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=63724&r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=63724&r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63724&r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=63724&r=dst
IIS Stability: https://bugs.php.net/fix.php?id=63724&r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=63724&r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=63724&r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=63724&r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=63724&r=mysqlcfg
Bug #45282 [Com]: SoapClient has namespace issues when WSDL is distributed
Edit report at https://bugs.php.net/bug.php?id=45282&edit=1
ID: 45282
Comment by: thorgal_fr at yahoo dot fr
Reported by:Martin dot Bosslet at googlemail dot com
Summary:SoapClient has namespace issues when WSDL is
distributed
Status: Verified
Type: Bug
Package:SOAP related
Operating System: *
PHP Version:5.*, 6CVS (2009-04-28)
Block user comment: N
Private report: N
New Comment:
Same "already defined" problem, different cause : methods are defined for two
distinct versions of SOAP.
http://wssie.eau-loire-bretagne.fr/AELB-IWS-MONITORING/services/MonitoringService?wsdl
Previous Comments:
[2012-01-03 22:57:40] pumuckel at metropolis dot de
Any progress on this issue?
[2008-12-12 18:13:38] clwells at nocworx dot com
This WSDL exhibits this behavior:
http://www.swsoft.com/webservices/vza/4.0.0/VZA.wsdl
[2008-06-16 15:54:52] Martin dot Bosslet at googlemail dot com
Description:
I have tried to access a web service whose WSDL is distributed among several
files each of which contains references to several further XSDs. Now the WSDL
itself is valid, as .NET or Java clients have accessed the services without any
problems. But when creating a new instance of SoapClient it fails because I'm
told that a certain element has already been defined. The problem is, that
there are elements with the same name, but they DO differ in
namespaces.
Reproduce code:
---
$client = new SoapClient('someURI');
/* Please email me to get a copy of the WSDLs producing the error. They're too
large to be posted here (although I tried to keep them small already) and I
have no facility to make them available online. */
Expected result:
No error when parsing the WSDL.
Actual result:
--
SoapFault exception: [WSDL] SOAP-ERROR: Parsing WSDL: '' already
defined in
--
Edit this bug report at https://bugs.php.net/bug.php?id=45282&edit=1
[PHP-BUG] Req #63723 [NEW]: make use of UID EXPUNGE
From: slim at inbox dot lv
Operating system: l
PHP version: 5.3.19
Package: IMAP related
Bug Type: Feature/Change Request
Bug description:make use of UID EXPUNGE
Description:
c-client supports UID EXPUNGE feature from RFC 4315
Following patch adds the functionality to imap_expunge() when UID is set as
second argument:
diff -ur php-5.3.17.orig/ext/imap/php_imap.c
php-5.3.17/ext/imap/php_imap.c
--- php-5.3.17.orig/ext/imap/php_imap.c 2012-10-29 17:49:28.0
+0200
+++ php-5.3.17/ext/imap/php_imap.c 2012-12-06 11:11:41.0
+0200
@@ -166,7 +166,8 @@
#endif
ZEND_BEGIN_ARG_INFO_EX(arginfo_imap_expunge, 0, 0, 1)
- ZEND_ARG_INFO(0, stream_id)
+ZEND_ARG_INFO(0, stream_id)
+ZEND_ARG_INFO(0, sequence)
ZEND_END_ARG_INFO()
ZEND_BEGIN_ARG_INFO_EX(arginfo_imap_gc, 0, 0, 1)
@@ -1137,6 +1138,7 @@
#if HAVE_IMAP_KRB && HAVE_IMAP_AUTH_GSS
php_info_print_table_row(2, "Kerberos Support", "enabled");
#endif
+ php_info_print_table_row(2, "IMAP UIDEXPUNGE Support", "enabled");
php_info_print_table_end();
}
/* }}} */
@@ -1553,18 +1555,23 @@
Permanently delete all messages marked for deletion */
PHP_FUNCTION(imap_expunge)
{
- zval *streamind;
- pils *imap_le_struct;
+ zval *streamind;
+ char *sequence;
+ long flags = 0x1;
+ int sequence_len;
+ int argc = ZEND_NUM_ARGS();
- if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "r",
&streamind) ==
FAILURE) {
- return;
- }
+pils *imap_le_struct;
- ZEND_FETCH_RESOURCE(imap_le_struct, pils *, &streamind, -1, "imap",
le_imap);
+if (zend_parse_parameters(argc TSRMLS_CC, "r|s", &streamind,
&sequence,
&sequence_len) == FAILURE) {
+return;
+}
- mail_expunge (imap_le_struct->imap_stream);
+ZEND_FETCH_RESOURCE(imap_le_struct, pils *, &streamind, -1,
"imap",
le_imap);
- RETURN_TRUE;
+mail_expunge_full (imap_le_struct->imap_stream, (argc == 2 ?
sequence :
NIL), (argc == 2 ? flags : NIL));
+
+RETURN_TRUE;
}
/* }}} */
Test script:
---
imap_expunge(resource $imap_stream, int $uid)
--
Edit bug report at https://bugs.php.net/bug.php?id=63723&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=63723&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=63723&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=63723&r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=63723&r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=63723&r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=63723&r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=63723&r=needscript
Try newer version: https://bugs.php.net/fix.php?id=63723&r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=63723&r=support
Expected behavior: https://bugs.php.net/fix.php?id=63723&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=63723&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=63723&r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=63723&r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63723&r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=63723&r=dst
IIS Stability: https://bugs.php.net/fix.php?id=63723&r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=63723&r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=63723&r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=63723&r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=63723&r=mysqlcfg
Bug #61467 [Com]: New "callable" typehint does not work (autoloading)
Edit report at https://bugs.php.net/bug.php?id=61467&edit=1
ID: 61467
Comment by: ni...@php.net
Reported by:david at grudl dot com
Summary:New "callable" typehint does not work (autoloading)
Status: Not a bug
Type: Bug
Package:Class/Object related
PHP Version:5.4.0
Block user comment: N
Private report: N
New Comment:
@paladin / @honza: We certainly won't introduce another type hint just to cover
some minority use case. Type hints are there to simplify the most common type
checks and callability-without-actual-callability is certainly not one of the
common cases. If you have special needs you can always just do the manual
is_callable call.
Previous Comments:
[2012-12-07 11:19:16] honza at mujserver dot net
I agree with paladin, but I don't think that *callable* is useful.
[2012-07-16 22:33:06] paladin at jstation dot cz
Hmm... I agree with David Grudl that current behavior is not ideal... so what
about two typehints? callback and callable?
function testA(callback $a)
{
//callback checks only syntax
}
function testB(callable $a)
{
//callable checks if it is really callable
}
[2012-03-27 16:58:41] david at grudl dot com
1) "Yes, something other than a string was expected." Really? What exactly is
expected? When a string points to something that _is_ callable, then it is not
a string?
call_user_func('xxx') triggers error 'expects parameter 1 to be a valid
callback, function 'xxx' not found or invalid function name' which is perfectly
understandable. Why the same function with typehint callable will not trigger
the same error message? It will trigger 'Argument 1 passed to call_user_funct()
must be callable, string given', which says that I shouldn't use the string.
And that's not simply true.
2) I would totally agree with you, if PHP was static language. But PHP is
dynamic language and it makes sense to have stored in the variable name of
class/function that has not yet been loaded. And most importantly: the life
cycle of PHP is a single HTTP request, lazy loading is very important for good
performance.
[2012-03-24 23:41:57] jan at skrasek dot com
There is no logic to check is_callable by typehint - these typehint is useless,
brings no new functionality. The only one possibile benefit is just check
validity of the callback structure, not the callabality self.
> A callable isn't a basic type like a string.
So, this typehint behaves differently than others. Yeah, so you prefer to mix
things together and make php much more chaotic.
> This is what most users expect when they check if something is callable.
Some research available? Or just empty words?
>From my point of view php is heading to hell by making these type of
>shortcuts. Yes, we are lazy programmers, but there is no need to rewrite if
>(is_callable(..)) as a typehint.
[2012-03-23 23:47:03] ras...@php.net
1) Yes, something other than a string was expected. When a string points to
something that isn't a callable function, then it is just a string, so I
consider the message correct.
2) Yes, I consider it correct. A callable isn't a basic type like a string. It
has to have a couple of characteristics, one of which is being actually
callable
which you can't know unless you check. This is what most users expect when they
check if something is callable. If something just looks like a callable
function
and it isn't, then you end up with an uncatchable fatal when you try to call
it,
so knowing that something looks like it might be a callable function isn't very
useful to most. They want to write robust code and catch any errors and that
can
only be done if we check for the existence of the callable function which is
why
it is the default.
And your example with array just reinforces this. An array typehint fully
checks
if an array is an array because it is a simple type that has no other
characteristics. An array can't pass the array typehint and then fatal out when
you try to use it as an array.
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=61467
--
Edit this bug report at https://bugs.php.net/bug.php?id=61467&edit=1
Bug #63638 [Com]: Cannot connect to SQL Server 2008 with PDO dblib
Edit report at https://bugs.php.net/bug.php?id=63638&edit=1
ID: 63638
Comment by: wdmeldon at gmail dot com
Reported by:pmeunier at cybergeneration dot com
Summary:Cannot connect to SQL Server 2008 with PDO dblib
Status: Open
Type: Bug
Package:PDO related
Operating System: Linux Slackware 13
PHP Version:5.4.9
Block user comment: N
Private report: N
New Comment:
I've tested this in SQL Server 2012, 2008 and 2005 with similar results. The
warnings do not always manifest however. I've noticed returning output will
prevent the warning as will calling other functions, but it's a crap shoot.
The connection seems to be fine and the data returned is as well, so more
annoying
than anything else.
Running Ubuntu Server 12.04 with PHP 5.4.9.
Previous Comments:
[2012-12-05 16:49:09] f dot marquis at of2m dot fr
same problem here, but only from time to time (not all connections are failing
like with pmeunier)
seems related to #63258
[2012-11-28 21:43:00] pmeunier at cybergeneration dot com
We made a compare between the /ext/pdo_dblib/ php 5.4.7 and php 5.4.9 and found
only one file was changed. Line 318 in dblib_driver.c went from :
// In PHP 5.4.7
DBSETOPT(H->link, DBQUOTEDIDENT, 1);
To :
// In PHP 5.4.9
DBSETOPT(H->link, DBQUOTEDIDENT, NULL);
For fun, we tried to revert to passing 1 for the last parameter... and guess
what ? It worked. Since we don't actually understand what this function makes,
and why the parameter was changed, we don't find this solution very clean,
unless it is eventually confirmed by a PHP developper.
[2012-11-28 21:09:02] pmeunier at cybergeneration dot com
Description:
We are relying on PDO_DBLIB to connect to our SQL Server 2008 Server in PHP,
hosted on a Linux platform. We were running PHP 5.4.7 and everything was fine.
When we upgraded to 5.4.9, all connections to SQL Server were failing with the
following error : Warning: PDO::__construct(): Called dbsetopt with parameter 3
NULL (severity 11). We tried with different logins to be sure that it was not a
permission issue, but the bug also occurs when trying to log with 'sa'.
Test script:
---
$connection = new PDO('dblib:host=myServerHost;dbname=MyDatabase', 'username',
'pass');
Expected result:
We expect no warnings to be thrown and connection to SQL Server to work
Actual result:
--
A warning is thrown : Warning: PDO::__construct(): Called dbsetopt with
parameter
3 NULL (severity 11)
--
Edit this bug report at https://bugs.php.net/bug.php?id=63638&edit=1
Bug #63719 [Opn]: mail function becomes slow until apache restart
Edit report at https://bugs.php.net/bug.php?id=63719&edit=1 ID: 63719 User updated by:skunk at ipfrom dot com Reported by:skunk at ipfrom dot com Summary:mail function becomes slow until apache restart Status: Open Type: Bug Package:Mail related Operating System: gentoo linux PHP Version:5.3.19 Block user comment: N Private report: N New Comment: i forgot to say the sendmail command works fine and even executing from the command line a script containing the mail() function is practically instantaneous, it happens only if apache (2.2.23) executes the script. Previous Comments: [2012-12-07 13:12:58] skunk at ipfrom dot com Description: i'm seeing this on more than one production servers: after some days of uptime the mail() function starts to take about a minute to execute and only a restart of apache (prefork) makes it fast again. one of the web servers is running roundcube which has the possibility to either use the mail() function or to connect directly to a smtp server, with the former after few days sending a mail becomes very slow while with the latest it's always fast, on a side note, when the slowness starts happening apache takes a long time to kill all processes on restart. thank you. Test script: --- sorry, i'm unable to replicate this issue because it happens on production servers with real traffic. Expected result: mail() function should exec fast Actual result: -- when mail() slows down a restart of apache is required -- Edit this bug report at https://bugs.php.net/bug.php?id=63719&edit=1
[PHP-BUG] Bug #63719 [NEW]: mail function becomes slow until apache restart
From: skunk at ipfrom dot com Operating system: gentoo linux PHP version: 5.3.19 Package: Mail related Bug Type: Bug Bug description:mail function becomes slow until apache restart Description: i'm seeing this on more than one production servers: after some days of uptime the mail() function starts to take about a minute to execute and only a restart of apache (prefork) makes it fast again. one of the web servers is running roundcube which has the possibility to either use the mail() function or to connect directly to a smtp server, with the former after few days sending a mail becomes very slow while with the latest it's always fast, on a side note, when the slowness starts happening apache takes a long time to kill all processes on restart. thank you. Test script: --- sorry, i'm unable to replicate this issue because it happens on production servers with real traffic. Expected result: mail() function should exec fast Actual result: -- when mail() slows down a restart of apache is required -- Edit bug report at https://bugs.php.net/bug.php?id=63719&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=63719&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=63719&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=63719&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=63719&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=63719&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=63719&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=63719&r=needscript Try newer version: https://bugs.php.net/fix.php?id=63719&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=63719&r=support Expected behavior: https://bugs.php.net/fix.php?id=63719&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=63719&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=63719&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=63719&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63719&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=63719&r=dst IIS Stability: https://bugs.php.net/fix.php?id=63719&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=63719&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=63719&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=63719&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=63719&r=mysqlcfg
Bug #43327 [Opn->Asn]: wrong return value from mail(), if sendmail_path is wrong
Edit report at https://bugs.php.net/bug.php?id=43327&edit=1
ID: 43327
Updated by: paj...@php.net
Reported by:carsten_sttgt at gmx dot de
Summary:wrong return value from mail(), if sendmail_path is
wrong
-Status: Open
+Status: Assigned
Type: Bug
Package:Mail related
Operating System: win32 only (?)
PHP Version:5.*, 6 (2009-08-07)
-Assigned To:
+Assigned To:pajoye
Block user comment: N
Private report: N
Previous Comments:
[2009-08-20 10:39:59] j...@php.net
Reopened, fix was reverted.
[2009-08-20 09:03:20] s...@php.net
Automatic comment from SVN on behalf of pajoye
Revision: http://svn.php.net/viewvc/?view=revision&revision=287495
Log: - revert fix for #43327, it breaks system&co functions
[2009-08-20 01:56:05] carsten_sttgt at gmx dot de
Hi Garrett,
> Can you retest with the latest 5.3 snapshot, and post feedback?
I can do this. Just some remarks first:
> This occurs because popen_ex executes the command using the comspec
> ('cmd.exe'), which will always create a valid process--but intended
> actual child process fails.
That's correct. No error during creation of the process ("cmd.exe" /
"GetLastError == 0"). But in this case, "cmd.exe" returns an exit code != 0,
which is available with "GetExitCodeProcess()". So you know there's a problem.
Regarding mail():
- mail() does not detect that "cmd.exe" can't start "sendmail.exe"
- it also does not detect, if "cmd.exe" can start "sendmail.exe",
but "sendmail.exe" is returning an exit code != 0
--> if "cmd.exe" can start a program, it's returning the exit
code from that program, and so this is available with
GetExitCodeProcess().
So there is the question, why does mail() does not test the return value of
pclose() in a correct way on windows? At the moment it looks like:
| #ifdef PHP_WIN32
| if (ret == -1)
| {
| MAIL_RET(0);
| } else {
|MAIL_RET(1);
| }
But I think it should be also something like?:
| if (ret != 0)
> I'm patching this so that it skips using cmd.exe--there is really
> no reason this should be here,
Some hints:
- If you want start an executable with just the name and without the
extension (like ".com, *.pl"), you must do this through "cmd.exe"
(only for "*.exe" files you can use just the name).
- In the MSDN you can read, that you have to use "cmd.exe" to start
a batchfile with CreateProcess. Ok, for me that's working without
"cmd.exe". But maybe this depends on the Windows version or
compiler.
Regards,
Carsten
[2009-08-19 18:56:08] garre...@php.net
Carsten,
Can you retest with the latest 5.3 snapshot, and post feedback?
Thanks
[2009-08-19 18:43:46] s...@php.net
Automatic comment from SVN on behalf of pajoye
Revision: http://svn.php.net/viewvc/?view=revision&revision=287480
Log: - fixed #43327, wrong return value from mail(), if sendmail_path is wrong
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=43327
--
Edit this bug report at https://bugs.php.net/bug.php?id=43327&edit=1
Bug #61467 [Com]: New "callable" typehint does not work (autoloading)
Edit report at https://bugs.php.net/bug.php?id=61467&edit=1
ID: 61467
Comment by: honza at mujserver dot net
Reported by:david at grudl dot com
Summary:New "callable" typehint does not work (autoloading)
Status: Not a bug
Type: Bug
Package:Class/Object related
PHP Version:5.4.0
Block user comment: N
Private report: N
New Comment:
I agree with paladin, but I don't think that *callable* is useful.
Previous Comments:
[2012-07-16 22:33:06] paladin at jstation dot cz
Hmm... I agree with David Grudl that current behavior is not ideal... so what
about two typehints? callback and callable?
function testA(callback $a)
{
//callback checks only syntax
}
function testB(callable $a)
{
//callable checks if it is really callable
}
[2012-03-27 16:58:41] david at grudl dot com
1) "Yes, something other than a string was expected." Really? What exactly is
expected? When a string points to something that _is_ callable, then it is not
a string?
call_user_func('xxx') triggers error 'expects parameter 1 to be a valid
callback, function 'xxx' not found or invalid function name' which is perfectly
understandable. Why the same function with typehint callable will not trigger
the same error message? It will trigger 'Argument 1 passed to call_user_funct()
must be callable, string given', which says that I shouldn't use the string.
And that's not simply true.
2) I would totally agree with you, if PHP was static language. But PHP is
dynamic language and it makes sense to have stored in the variable name of
class/function that has not yet been loaded. And most importantly: the life
cycle of PHP is a single HTTP request, lazy loading is very important for good
performance.
[2012-03-24 23:41:57] jan at skrasek dot com
There is no logic to check is_callable by typehint - these typehint is useless,
brings no new functionality. The only one possibile benefit is just check
validity of the callback structure, not the callabality self.
> A callable isn't a basic type like a string.
So, this typehint behaves differently than others. Yeah, so you prefer to mix
things together and make php much more chaotic.
> This is what most users expect when they check if something is callable.
Some research available? Or just empty words?
>From my point of view php is heading to hell by making these type of
>shortcuts. Yes, we are lazy programmers, but there is no need to rewrite if
>(is_callable(..)) as a typehint.
[2012-03-23 23:47:03] ras...@php.net
1) Yes, something other than a string was expected. When a string points to
something that isn't a callable function, then it is just a string, so I
consider the message correct.
2) Yes, I consider it correct. A callable isn't a basic type like a string. It
has to have a couple of characteristics, one of which is being actually
callable
which you can't know unless you check. This is what most users expect when they
check if something is callable. If something just looks like a callable
function
and it isn't, then you end up with an uncatchable fatal when you try to call
it,
so knowing that something looks like it might be a callable function isn't very
useful to most. They want to write robust code and catch any errors and that
can
only be done if we check for the existence of the callable function which is
why
it is the default.
And your example with array just reinforces this. An array typehint fully
checks
if an array is an array because it is a simple type that has no other
characteristics. An array can't pass the array typehint and then fatal out when
you try to use it as an array.
[2012-03-23 19:34:44] david at grudl dot com
Rasmus we're talking about two different things:
1) Error message "Must be callable, string given" means, that something other
than string was expected. Do you agree? I think current message is confusing.
2) The behavior of typehint is subjective, of course. But it would be nice if
you could consider, if it is really correct. We are talking about "type hint" -
and checking of validity of a *type*.
Type hint "array" means that the argument must be array. It's just about the
type. Validity of array must be checked by function itself. The type hint
"callable" I expect checks if argument is valid callable type (valid syntax),
nothing more.
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
Req #43845 [Com]: Function can no longer be called both statically and as instance method
Edit report at https://bugs.php.net/bug.php?id=43845&edit=1
ID: 43845
Comment by: php dot net at site dot lanzz dot org
Reported by:ms419 at freezone dot co dot uk
Summary:Function can no longer be called both statically and
as instance method
Status: Open
Type: Feature/Change Request
Package:Feature/Change Request
PHP Version:5.2.5
Block user comment: N
Private report: N
New Comment:
Since PHP does actually distinguish between static and non-static methods, it
makes no sense (as external interface) to disallow _both_ calling the same
method
as static and non-static _and_ having same-named static and non-static methods.
At run time PHP knows if you're calling a static or a non-static method, so it
can pick the correct one.
Here is an example where same-named static and non-static methods might make
sense:
class Foo {
static public function defaultInstance() {
static $instance = null;
if (is_null($instance)) {
$instance = new self();
}
}
static public function bar() {
$instance = self::defaultInstance();
return $instance->bar();
}
public function bar() {
// do something
}
}
Foo::bar() // no need to explicitly request the default instance
$f = new Foo();
$f->bar() // but now it is clear that we're doing the same thing with a
specific
instance
Previous Comments:
[2011-08-09 03:20:10] klaussantana at gmail dot com
Actually, you must declare your method static. It will not produce any warning,
but you will cannot be able to use $this.
Instead, you must always use the first parameter.
So this will be like this:
Remember.. You will always need to pass the instance for your method to work
correctly.
Farewell.
[2008-01-14 20:15:20] ms419 at freezone dot co dot uk
Description:
I understand that, unlike some other languages, PHP does not support
overloading: I can't implement two functions with the same name but different
signatures. However I can simulate overloading using func_get_args() and
testing with which arguments the function was called.
Now what I want is a function which can be called either as an instance method
with no arguments, or statically with one argument: an instance of the class. I
test whether the function was called statically or not using isset($this)
However in PHP5, this produces an error:
Non-static method BaseTaxonomy::getTerms() should not be called statically in...
Like it is possible to simulate overloading in PHP without generating errors, I
wish it were possible to define a function which can be called either
statically or as an instance method, without generating errors.
Much thanks, Jack
Reproduce code:
---
Toy example:
class BaseTaxonomy
{
protected $terms = null;
public function getTerms()
{
if (!isset($this))
{
$args = func_get_args();
return $args[0]->terms;
}
return $this->terms;
}
}
Actual result:
--
Non-static method BaseTaxonomy::getTerms() should not be called statically in...
--
Edit this bug report at https://bugs.php.net/bug.php?id=43845&edit=1
Bug #63709 [Ana]: flock() doesn't trigger mandatory locks on linux
Edit report at https://bugs.php.net/bug.php?id=63709&edit=1 ID: 63709 User updated by:eric dot saintetienne at gmail dot com Reported by:eric dot saintetienne at gmail dot com Summary:flock() doesn't trigger mandatory locks on linux Status: Analyzed Type: Bug Package:Filesystem function related Operating System: Linux PHP Version:5.3.19 Block user comment: N Private report: N New Comment: You're right, Python is smart and the trick is simple: fnctl module functions are coded such that they detect the type of the object they're given as argument. If it's an integer they assume it is a file descriptor otherwise they call its fileno() method to retrieve the file descriptor integer. So it's a matter of adding your own fileno() method to the PHP standard file object and making the dio_* routines calling it, when not provided with an integer. Does that makes sense to you? It's a suggestion, at the end of the day it's your decision of how to handle this issue, even though it seems to, I'm actually not pushing to get direct io integrated at any cost (I don't have any stake) but I just feel it's the way to go. Previous Comments: [2012-12-07 09:08:01] ahar...@php.net That's true, but they're still somewhat interchangeable in Python â higher level file objects returned by open() work with fcntl methods. That wouldn't be the case if we bundled dio without further work. [2012-12-07 08:55:27] eric dot saintetienne at gmail dot com You're right, dio is a plain inteface to the underlying C function hence exposing real file descriptors (integers). That's also what Python does: it exposes two different types of file objects: standard file objects via the builtin open() and file descriptors via os.open() Is that is feasible with php? [2012-12-07 08:48:41] ahar...@php.net My worry there is that dio resources are (as I recall, anyway) completely distinct from normal file resources, so you couldn't fopen() a file and then dio_fcntl() it: it's all or nothing. [2012-12-07 08:42:12] eric dot saintetienne at gmail dot com A fifth option is to pull the "Direct IO" extension into the mainline. http://pecl.php.net/package/dio This extension already expose fcntl() as well as a few other low-level POSIX routines, and have some amount of testing as it's in its fourth version already (though it's said to be in beta state) [2012-12-07 03:24:16] larue...@php.net I like 3 :) change the behavior of flock will intruduce a visible bc break The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=63709 -- Edit this bug report at https://bugs.php.net/bug.php?id=63709&edit=1
Bug #63709 [Ana]: flock() doesn't trigger mandatory locks on linux
Edit report at https://bugs.php.net/bug.php?id=63709&edit=1 ID: 63709 Updated by: ahar...@php.net Reported by:eric dot saintetienne at gmail dot com Summary:flock() doesn't trigger mandatory locks on linux Status: Analyzed Type: Bug Package:Filesystem function related Operating System: Linux PHP Version:5.3.19 Block user comment: N Private report: N New Comment: That's true, but they're still somewhat interchangeable in Python â higher level file objects returned by open() work with fcntl methods. That wouldn't be the case if we bundled dio without further work. Previous Comments: [2012-12-07 08:55:27] eric dot saintetienne at gmail dot com You're right, dio is a plain inteface to the underlying C function hence exposing real file descriptors (integers). That's also what Python does: it exposes two different types of file objects: standard file objects via the builtin open() and file descriptors via os.open() Is that is feasible with php? [2012-12-07 08:48:41] ahar...@php.net My worry there is that dio resources are (as I recall, anyway) completely distinct from normal file resources, so you couldn't fopen() a file and then dio_fcntl() it: it's all or nothing. [2012-12-07 08:42:12] eric dot saintetienne at gmail dot com A fifth option is to pull the "Direct IO" extension into the mainline. http://pecl.php.net/package/dio This extension already expose fcntl() as well as a few other low-level POSIX routines, and have some amount of testing as it's in its fourth version already (though it's said to be in beta state) [2012-12-07 03:24:16] larue...@php.net I like 3 :) change the behavior of flock will intruduce a visible bc break [2012-12-07 01:48:08] ahar...@php.net The key difference between Python and PHP here is that Python always uses fcntl() internally, whereas PHP will use flock() if it's available (which it obviously is on Linux) and will only fall back to fcntl() if it's not. flock() will never create a mandatory lock, so the manual page is wrong, which I'm pretty sure is my fault. Mea culpa. We can probably fix this by switching to preferring fcntl() within our flock() function as Python does, since that's actually the more useful behaviour, but that would be a (mild) BC break in how flock() behaves in practice â although it would actually bring it into line with what's documented. The options I see are: 1. Change the behaviour of flock() as described above to prefer fcntl(). 2. Add a new lockf() function, as suggested. 3. Just bite the bullet and expose fcntl() as a PHP function on POSIX platforms. 4. Do nothing and update the manual. :) Does anyone have any thoughts? I'm happy to do the donkey work, but am not really sure on the best way to proceed. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=63709 -- Edit this bug report at https://bugs.php.net/bug.php?id=63709&edit=1
Bug #63709 [Ana]: flock() doesn't trigger mandatory locks on linux
Edit report at https://bugs.php.net/bug.php?id=63709&edit=1 ID: 63709 User updated by:eric dot saintetienne at gmail dot com Reported by:eric dot saintetienne at gmail dot com Summary:flock() doesn't trigger mandatory locks on linux Status: Analyzed Type: Bug Package:Filesystem function related Operating System: Linux PHP Version:5.3.19 Block user comment: N Private report: N New Comment: You're right, dio is a plain inteface to the underlying C function hence exposing real file descriptors (integers). That's also what Python does: it exposes two different types of file objects: standard file objects via the builtin open() and file descriptors via os.open() Is that is feasible with php? Previous Comments: [2012-12-07 08:48:41] ahar...@php.net My worry there is that dio resources are (as I recall, anyway) completely distinct from normal file resources, so you couldn't fopen() a file and then dio_fcntl() it: it's all or nothing. [2012-12-07 08:42:12] eric dot saintetienne at gmail dot com A fifth option is to pull the "Direct IO" extension into the mainline. http://pecl.php.net/package/dio This extension already expose fcntl() as well as a few other low-level POSIX routines, and have some amount of testing as it's in its fourth version already (though it's said to be in beta state) [2012-12-07 03:24:16] larue...@php.net I like 3 :) change the behavior of flock will intruduce a visible bc break [2012-12-07 01:48:08] ahar...@php.net The key difference between Python and PHP here is that Python always uses fcntl() internally, whereas PHP will use flock() if it's available (which it obviously is on Linux) and will only fall back to fcntl() if it's not. flock() will never create a mandatory lock, so the manual page is wrong, which I'm pretty sure is my fault. Mea culpa. We can probably fix this by switching to preferring fcntl() within our flock() function as Python does, since that's actually the more useful behaviour, but that would be a (mild) BC break in how flock() behaves in practice â although it would actually bring it into line with what's documented. The options I see are: 1. Change the behaviour of flock() as described above to prefer fcntl(). 2. Add a new lockf() function, as suggested. 3. Just bite the bullet and expose fcntl() as a PHP function on POSIX platforms. 4. Do nothing and update the manual. :) Does anyone have any thoughts? I'm happy to do the donkey work, but am not really sure on the best way to proceed. [2012-12-06 14:19:38] eric dot saintetienne at gmail dot com Note that dio_fcntl() of the "Direct IO" extension can successfully exclusively lock the file, but this shouldn't be considered as a workaround as it's not always possible to install extensions. If flock() couldn't be modified for backward compatibility reasons, options could be added to alter its behaviour, or a new call lockf() would be welcome too. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=63709 -- Edit this bug report at https://bugs.php.net/bug.php?id=63709&edit=1
Bug #63709 [Ana]: flock() doesn't trigger mandatory locks on linux
Edit report at https://bugs.php.net/bug.php?id=63709&edit=1
ID: 63709
Updated by: ahar...@php.net
Reported by:eric dot saintetienne at gmail dot com
Summary:flock() doesn't trigger mandatory locks on linux
Status: Analyzed
Type: Bug
Package:Filesystem function related
Operating System: Linux
PHP Version:5.3.19
Block user comment: N
Private report: N
New Comment:
My worry there is that dio resources are (as I recall, anyway) completely
distinct from normal file resources, so you couldn't fopen() a file and then
dio_fcntl() it: it's all or nothing.
Previous Comments:
[2012-12-07 08:42:12] eric dot saintetienne at gmail dot com
A fifth option is to pull the "Direct IO" extension into the mainline.
http://pecl.php.net/package/dio
This extension already expose fcntl() as well as a few other low-level
POSIX routines, and have some amount of testing as it's in its fourth
version already (though it's said to be in beta state)
[2012-12-07 03:24:16] larue...@php.net
I like 3 :)
change the behavior of flock will intruduce a visible bc break
[2012-12-07 01:48:08] ahar...@php.net
The key difference between Python and PHP here is that Python always uses
fcntl() internally, whereas PHP will use flock() if it's available (which it
obviously is on Linux) and will only fall back to fcntl() if it's not. flock()
will never create a mandatory lock, so the manual page is wrong, which I'm
pretty sure is my fault. Mea culpa.
We can probably fix this by switching to preferring fcntl() within our flock()
function as Python does, since that's actually the more useful behaviour, but
that would be a (mild) BC break in how flock() behaves in practice â although
it would actually bring it into line with what's documented.
The options I see are:
1. Change the behaviour of flock() as described above to prefer fcntl().
2. Add a new lockf() function, as suggested.
3. Just bite the bullet and expose fcntl() as a PHP function on POSIX platforms.
4. Do nothing and update the manual. :)
Does anyone have any thoughts? I'm happy to do the donkey work, but am not
really sure on the best way to proceed.
[2012-12-06 14:19:38] eric dot saintetienne at gmail dot com
Note that dio_fcntl() of the "Direct IO" extension can successfully exclusively
lock the file, but this shouldn't be considered as a workaround as it's not
always
possible to install extensions.
If flock() couldn't be modified for backward compatibility reasons, options
could
be added to alter its behaviour, or a new call lockf() would be welcome too.
[2012-12-06 13:12:43] eric dot saintetienne at gmail dot com
Description:
Locking exclusively via flock a file opened for writing doesn't trigger a
mandatory lock.
The python script below could trigger the mandatory lock.
Maybe it's because PHP flock() is built on the C function call flock():
"When a program attempts to lock a file with lockf or fcntl that has mandatory
locking set, the kernel will prevent all other programs from accessing the
file.
Processes which use flock will not trigger a mandatory lock."
source: http://www.hackinglinuxexposed.com/articles/20030623.html
Python script:
#!/usr/bin/python
import os, fcntl
fd = os.open('mandlock-file', os.O_RDWR, 0755)
print 'fd=', fd
fcntl.lockf(fd, fcntl.LOCK_EX)
a = raw_input() # during that time, any attempt to open the file will hang
os.write(fd, a+'\n')
fcntl.lockf(fd, fcntl.LOCK_UN)
# now any attempt to open the file will succeed
os.close(fd)
# eof
Test script:
---
Expected result:
once the file is created and the mandatory lock setup for it:
during the 10 sec timer, opening the file (with or without explicit locking)
should hand until the php script terminates.
Actual result:
--
it's possible to opening the locked file during the 10s timer for reading and
writing.
--
Edit this bug report at https://bugs.php.net/bug.php?id=63709&edit=1
Bug #63709 [Ana]: flock() doesn't trigger mandatory locks on linux
Edit report at https://bugs.php.net/bug.php?id=63709&edit=1
ID: 63709
User updated by:eric dot saintetienne at gmail dot com
Reported by:eric dot saintetienne at gmail dot com
Summary:flock() doesn't trigger mandatory locks on linux
Status: Analyzed
Type: Bug
Package:Filesystem function related
Operating System: Linux
PHP Version:5.3.19
Block user comment: N
Private report: N
New Comment:
A fifth option is to pull the "Direct IO" extension into the mainline.
http://pecl.php.net/package/dio
This extension already expose fcntl() as well as a few other low-level
POSIX routines, and have some amount of testing as it's in its fourth
version already (though it's said to be in beta state)
Previous Comments:
[2012-12-07 03:24:16] larue...@php.net
I like 3 :)
change the behavior of flock will intruduce a visible bc break
[2012-12-07 01:48:08] ahar...@php.net
The key difference between Python and PHP here is that Python always uses
fcntl() internally, whereas PHP will use flock() if it's available (which it
obviously is on Linux) and will only fall back to fcntl() if it's not. flock()
will never create a mandatory lock, so the manual page is wrong, which I'm
pretty sure is my fault. Mea culpa.
We can probably fix this by switching to preferring fcntl() within our flock()
function as Python does, since that's actually the more useful behaviour, but
that would be a (mild) BC break in how flock() behaves in practice â although
it would actually bring it into line with what's documented.
The options I see are:
1. Change the behaviour of flock() as described above to prefer fcntl().
2. Add a new lockf() function, as suggested.
3. Just bite the bullet and expose fcntl() as a PHP function on POSIX platforms.
4. Do nothing and update the manual. :)
Does anyone have any thoughts? I'm happy to do the donkey work, but am not
really sure on the best way to proceed.
[2012-12-06 14:19:38] eric dot saintetienne at gmail dot com
Note that dio_fcntl() of the "Direct IO" extension can successfully exclusively
lock the file, but this shouldn't be considered as a workaround as it's not
always
possible to install extensions.
If flock() couldn't be modified for backward compatibility reasons, options
could
be added to alter its behaviour, or a new call lockf() would be welcome too.
[2012-12-06 13:12:43] eric dot saintetienne at gmail dot com
Description:
Locking exclusively via flock a file opened for writing doesn't trigger a
mandatory lock.
The python script below could trigger the mandatory lock.
Maybe it's because PHP flock() is built on the C function call flock():
"When a program attempts to lock a file with lockf or fcntl that has mandatory
locking set, the kernel will prevent all other programs from accessing the
file.
Processes which use flock will not trigger a mandatory lock."
source: http://www.hackinglinuxexposed.com/articles/20030623.html
Python script:
#!/usr/bin/python
import os, fcntl
fd = os.open('mandlock-file', os.O_RDWR, 0755)
print 'fd=', fd
fcntl.lockf(fd, fcntl.LOCK_EX)
a = raw_input() # during that time, any attempt to open the file will hang
os.write(fd, a+'\n')
fcntl.lockf(fd, fcntl.LOCK_UN)
# now any attempt to open the file will succeed
os.close(fd)
# eof
Test script:
---
Expected result:
once the file is created and the mandatory lock setup for it:
during the 10 sec timer, opening the file (with or without explicit locking)
should hand until the php script terminates.
Actual result:
--
it's possible to opening the locked file during the 10s timer for reading and
writing.
--
Edit this bug report at https://bugs.php.net/bug.php?id=63709&edit=1
