Bug #60169 [PATCH]: Conjunction of ternary and list crashes PHP
Edit report at https://bugs.php.net/bug.php?id=60169edit=1
ID: 60169
Patch added by: larue...@php.net
Reported by:the...@php.net
Summary:Conjunction of ternary and list crashes PHP
Status: Assigned
Type: Bug
Package:Scripting Engine problem
Operating System: Windows Vista
PHP Version:5.4.0beta2
Assigned To:lbarnaud
Block user comment: N
Private report: N
New Comment:
The following patch has been added/updated:
Patch Name: bug60169.diff
Revision: 1320043736
URL:
https://bugs.php.net/patch-display.php?bug=60169patch=bug60169.diffrevision=1320043736
Previous Comments:
[2011-10-31 03:24:05] larue...@php.net
The following patch has been added/updated:
Patch Name: invalid.patch
Revision: 1320031445
URL:
https://bugs.php.net/patch-display.php?bug=60169patch=invalid.patchrevision=1320031445
[2011-10-31 03:21:58] larue...@php.net
there is also segfault in (***)?:value notation.
like:
?php
$str = array('test');
list($a, $b) = is_array($str)?:$str;
and this make *the patch doesn't work* (a memory leak)
[2011-10-30 02:08:29] larue...@php.net
The following patch has been added/updated:
Patch Name: bug60169.phpt
Revision: 1319940509
URL:
https://bugs.php.net/patch-display.php?bug=60169patch=bug60169.phptrevision=1319940509
[2011-10-30 02:03:53] larue...@php.net
The following patch has been added/updated:
Patch Name: bug60169.diff
Revision: 1319940233
URL:
https://bugs.php.net/patch-display.php?bug=60169patch=bug60169.diffrevision=1319940233
[2011-10-30 02:01:56] paj...@php.net
Arnaud, could you try to give a look please? Happens only in 5.4, the recent
optimization in this area could be the cause.
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=60169
--
Edit this bug report at https://bugs.php.net/bug.php?id=60169edit=1
Bug #60169 [Com]: Conjunction of ternary and list crashes PHP
Edit report at https://bugs.php.net/bug.php?id=60169edit=1
ID: 60169
Comment by: larue...@php.net
Reported by:the...@php.net
Summary:Conjunction of ternary and list crashes PHP
Status: Assigned
Type: Bug
Package:Scripting Engine problem
Operating System: Windows Vista
PHP Version:5.4.0beta2
Assigned To:lbarnaud
Block user comment: N
Private report: N
New Comment:
I have submitted a new patch. lbarnaud, plz review it , thanks
Previous Comments:
[2011-10-31 06:48:56] larue...@php.net
The following patch has been added/updated:
Patch Name: bug60169.diff
Revision: 1320043736
URL:
https://bugs.php.net/patch-display.php?bug=60169patch=bug60169.diffrevision=1320043736
[2011-10-31 03:24:05] larue...@php.net
The following patch has been added/updated:
Patch Name: invalid.patch
Revision: 1320031445
URL:
https://bugs.php.net/patch-display.php?bug=60169patch=invalid.patchrevision=1320031445
[2011-10-31 03:21:58] larue...@php.net
there is also segfault in (***)?:value notation.
like:
?php
$str = array('test');
list($a, $b) = is_array($str)?:$str;
and this make *the patch doesn't work* (a memory leak)
[2011-10-30 02:08:29] larue...@php.net
The following patch has been added/updated:
Patch Name: bug60169.phpt
Revision: 1319940509
URL:
https://bugs.php.net/patch-display.php?bug=60169patch=bug60169.phptrevision=1319940509
[2011-10-30 02:03:53] larue...@php.net
The following patch has been added/updated:
Patch Name: bug60169.diff
Revision: 1319940233
URL:
https://bugs.php.net/patch-display.php?bug=60169patch=bug60169.diffrevision=1319940233
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=60169
--
Edit this bug report at https://bugs.php.net/bug.php?id=60169edit=1
Bug #60157 [Fbk-Opn]: OPENSSL_CONF environment variable ignored
Edit report at https://bugs.php.net/bug.php?id=60157edit=1
ID: 60157
User updated by:zeusgerde at arcor dot de
Reported by:zeusgerde at arcor dot de
Summary:OPENSSL_CONF environment variable ignored
-Status: Feedback
+Status: Open
Type: Bug
Package:OpenSSL related
Operating System: Windows XP and Windows 7
PHP Version:5.3.8
Block user comment: N
Private report: N
New Comment:
Where do you set it? System wild? manually in your script?
In httpd.conf in a global scope:
| SetEnv OPENSSL_CONF D:\sandbox\openssl.cnf
You can see that it is set in the actual result:
| var_dump(getenv('OPENSSL_CONF'));
| // string(42) D:\sandbox\openssl.cnf
(hint: don't look at the string length, I scrambled the path in this bug report)
putenv(OPENSSL_CONF=whereyouwanit);
No change in the actual result. Even if I do this:
| putenv(OPENSSL_CONF=, getenv('OPENSSL_CONF'));
It only works if I use the $configargs parameter directly (see my first comment
at 2011-10-28 11:48 UTC)
Previous Comments:
[2011-10-28 12:45:52] paj...@php.net
Where do you set it? System wild? manually in your script?
try:
putenv(OPENSSL_CONF=whereyouwanit);
.. rest of your code..
Only to verify a possible cause.
[2011-10-28 11:50:18] zeusgerde at arcor dot de
BTW, this is the work-around
var_dump(openssl_pkey_new(array(
'config' = getenv('OPENSSL_CONF'),
)));
[2011-10-28 11:48:36] zeusgerde at arcor dot de
Description:
setting OPENSSL_CONF is ignored in openssl* functions despite the documentation
lists it as the first location where the configuration file is searched
http://de2.php.net/manual/en/openssl.installation.php
Test script:
---
?php
header('Content-Type: text/plain');
echo Current PHP version: , phpversion(), \n;
echo *** OPENSSL_CONF\n;
var_dump(getenv('OPENSSL_CONF'));
echo \n*** Errors before calling openssl_pkey_new\n;
while (($e = openssl_error_string()) !== false) {
var_dump($e);
}
echo \n*** Calling openssl_pkey_new\n;
var_dump(openssl_pkey_new());
echo \n*** Errors after calling openssl_pkey_new\n;
while (($e = openssl_error_string()) !== false) {
var_dump($e);
}
Expected result:
Current PHP version: 5.3.8
*** OPENSSL_CONF
string(42) D:\sandbox\openssl.cnf
*** Errors before calling openssl_pkey_new
*** Calling openssl_pkey_new
resource(2) of type (OpenSSL key)
*** Errors after calling openssl_pkey_new
Actual result:
--
Current PHP version: 5.3.8
*** OPENSSL_CONF
string(42) D:\sandbox\openssl.cnf
*** Errors before calling openssl_pkey_new
*** Calling openssl_pkey_new
bool(false)
*** Errors after calling openssl_pkey_new
string(51) error:02001003:system library:fopen:No such process
string(53) error:2006D080:BIO routines:BIO_new_file:no such file
string(63) error:0E064002:configuration file routines:CONF_load:system lib
string(51) error:02001003:system library:fopen:No such process
string(53) error:2006D080:BIO routines:BIO_new_file:no such file
string(63) error:0E064002:configuration file routines:CONF_load:system lib
--
Edit this bug report at https://bugs.php.net/bug.php?id=60157edit=1
[PHP-BUG] Bug #60179 [NEW]: wrong output with php_flag boolean
From:
Operating system: Gentoo Linux
PHP version: 5.3.8
Package: FPM related
Bug Type: Bug
Bug description:wrong output with php_flag boolean
Description:
Hello,
when setting php_flag to Off or false, then PHP FPM sets it to the string
Off rather than 0 or NULL.
In fpm.conf
php_flag[session.auto_start] = Off
or
php_flag[session.auto_start] = false
It seems that the failure is on all boolean flags.
Test script:
---
?
echo session.auto_start is : . ini_get('session.auto_start') . \n;
if (ini_get('session.auto_start')) {
echo Some code here .\n;
}
?
Expected result:
session.auto_start is : 0
Actual result:
--
session.auto_start is : Off
--
Edit bug report at https://bugs.php.net/bug.php?id=60179edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=60179r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=60179r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=60179r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=60179r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=60179r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=60179r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=60179r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=60179r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=60179r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=60179r=support
Expected behavior:
https://bugs.php.net/fix.php?id=60179r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=60179r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=60179r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=60179r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=60179r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=60179r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=60179r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=60179r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=60179r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=60179r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=60179r=mysqlcfg
Bug #60139 [PATCH]: Anonymous functions create cycles not detected by the GC
Edit report at https://bugs.php.net/bug.php?id=60139edit=1
ID: 60139
Patch added by: dmi...@php.net
Reported by:lbarn...@php.net
Summary:Anonymous functions create cycles not detected by
the GC
Status: Assigned
Type: Bug
Package:Performance problem
PHP Version:5.4.0beta2
Assigned To:dmitry
Block user comment: N
Private report: N
New Comment:
The following patch has been added/updated:
Patch Name: gc-closure.diff
Revision: 1320050649
URL:
https://bugs.php.net/patch-display.php?bug=60139patch=gc-closure.diffrevision=1320050649
Previous Comments:
[2011-10-26 10:36:24] lbarn...@php.net
Description:
In the following Script 1 and Script 2, the created objects are not destructed
until the engine shutdowns because of a reference cycle.
The objects hold a reference to an anonymous function that itself hold a
reference to the object.
It seems that the garbage collector is unable to break the cycle.
Script 3 doesn't leak memory because the anonymous function doesn't hold a
reference to the object.
Test script:
---
# Script 1 (leaks with php5.4)
?php
class Foo
{
public $x;
public function __construct() {
$this-x = function() {};
}
}
echo memory_get_usage(), \n;
for ($i = 0; $i 1000; ++$i) {
new Foo;
}
gc_collect_cycles();
echo memory_get_usage(), \n;
?
# Script 2 (leaks with php5.3)
?php
class Foo
{
public $x;
public function __construct() {
$self = $this;
$this-x = function() use ($self) {};
}
}
echo memory_get_usage(), \n;
for ($i = 0; $i 1000; ++$i) {
new Foo;
}
gc_collect_cycles();
echo memory_get_usage(), \n;
?
# Script 3 (no leak)
?php
class Foo
{
public $x;
public function __construct() {
$this-x = get_fun();
}
}
function get_fun() {
return function() {};
}
echo memory_get_usage(), \n;
for ($i = 0; $i 1000; ++$i) {
new Foo;
}
gc_collect_cycles();
echo memory_get_usage(), \n;
?
Expected result:
Memory usage before and after is approximatel the same:
121040
121152
Actual result:
--
Objects are never freed and memory usage increases:
120724
417640
--
Edit this bug report at https://bugs.php.net/bug.php?id=60139edit=1
Req #57668 [Com]: IE support for AJAX samples
Edit report at https://bugs.php.net/bug.php?id=57668edit=1 ID: 57668 Comment by: rcravichauhan2 at gmail dot com Reported by:sl...@php.net Summary:IE support for AJAX samples Status: Open Type: Feature/Change Request Package:SCA_SDO Operating System: Windows XP PHP Version:5.2.0 Block user comment: N Private report: N New Comment: then subtracted the any value then last remaining the find results Previous Comments: [2007-05-14 09:49:27] sl...@php.net Description: Those samples that use AJAX style interactions with PHP SCA services don't work in Internet Explorer. They do work in Firefox. Reproduce code: --- Try any of the examples/SCA/helloworld* examples in IE and you will see that the sample fails because it can't make the correct XMLHTTPRequest Expected result: Working sample Actual result: -- Failure in sample -- Edit this bug report at https://bugs.php.net/bug.php?id=57668edit=1
Bug #60172 [Opn-Ana]: make fails
Edit report at https://bugs.php.net/bug.php?id=60172edit=1 ID: 60172 Updated by: f...@php.net Reported by:martin at psinas dot com Summary:make fails -Status: Open +Status: Analyzed Type: Bug Package:Compile Failure Operating System: Ubuntu 10.04 / Apache2 PHP Version:5.4SVN-2011-10-29 (snap) Block user comment: N Private report: N New Comment: I could just reproduce that on Debian testing. It seems the configure script in snaps fails to mention that you don't have bison/re2c installed. So the configure says everything ok, but due to a missing (generated) zend_ini_parser.c you can't compile. The check works for 5.4-HEAD. Previous Comments: [2011-10-29 22:55:35] martin at psinas dot com Description: I already have PHP installed, trying to upgrade to latest development version. I'm using Ubuntu 10.04 w/ Apache2. Test script: --- worm@worm-desktop:~$ wget http://snaps.php.net/php5.4-201110292230.tar.gz worm@worm-desktop:~$ tar -xvzf php5.4-201110292230.tar.gz worm@worm-desktop:~$ cd php5.4-201110292230 worm@worm-desktop:~/php5.4-201110292230$ ./configure worm@worm-desktop:~/php5.4-201110292230$ sudo make Actual result: -- /php5.4-201110292230/ext/sqlite3/libsqlite -I/home/worm/php5.4-201110292230/TSRM -I/home/worm/php5.4-201110292230/Zend-I/usr/include -g -O2 - fvisibility=hidden -DZEND_SIGNALS -c /home/worm/php5.4- 201110292230/Zend/zend_ini_parser.c -o Zend/zend_ini_parser.lo cc: /home/worm/php5.4-201110292230/Zend/zend_ini_parser.c: No such file or directory cc: no input files make: *** [Zend/zend_ini_parser.lo] Error 1 -- Edit this bug report at https://bugs.php.net/bug.php?id=60172edit=1
Bug #55759 [Opn]: mem leak when use built-in server
Edit report at https://bugs.php.net/bug.php?id=55759edit=1 ID: 55759 Updated by: f...@php.net Reported by:larue...@php.net Summary:mem leak when use built-in server Status: Open Type: Bug Package:Built-in web server PHP Version:5.4.0beta1 Block user comment: N Private report: N New Comment: Cannot reproduce on Debian testing with neither beta1 nor beta2 Previous Comments: [2011-09-25 17:08:14] fel...@php.net I can't reproduce it. [2011-09-22 03:01:20] larue...@php.net Description: router.php ?php return FALSE; ? a.php ?php echo ll ? ./php -S -t . router.php then request http://*/a.php Expected result: 11 Actual result: -- [Thu Sep 22 10:55:32 2011] 172.21.232.67:50662 [200]: /a.php [Thu Sep 22 10:55:32 2011] Script: '-' php-src/trunk/main/output.c(803) : Freeing 0x2A95DDB200 (88 bytes), script=- php-src/trunk/Zend/zend_alloc.c(2529) : Actual location (location was relayed) [Thu Sep 22 10:55:32 2011] Script: '-' php-src/trunk/main/output.c(804) : Freeing 0x2A95DDB2B0 (23 bytes), script=- [Thu Sep 22 10:55:32 2011] Script: '-' php-src/trunk/main/output.c(809) : Freeing 0x2A95DDB320 (8192 bytes), script=- [Thu Sep 22 10:55:32 2011] Script: '-' php-src/trunk/Zend/zend_stack.c(37) : Freeing 0x2A95DDD378 (512 bytes), script=- [Thu Sep 22 10:55:32 2011] Script: '-' php-src/trunk/Zend/zend_stack.c(42) : Freeing 0x2A95DDD5D0 (8 bytes), script=- -- Edit this bug report at https://bugs.php.net/bug.php?id=55759edit=1
Bug #60156 [Opn-Fbk]: Segmentation fault at _zend_mm_alloc_int
Edit report at https://bugs.php.net/bug.php?id=60156edit=1
ID: 60156
Updated by: f...@php.net
Reported by:dbetz at df dot eu
Summary:Segmentation fault at _zend_mm_alloc_int
-Status: Open
+Status: Feedback
Type: Bug
Package:FPM related
Operating System: Gentoo
PHP Version:5.3.8
Block user comment: N
Private report: N
New Comment:
Not enough information was provided for us to be able
to handle this bug. Please re-read the instructions at
http://bugs.php.net/how-to-report.php
If you can provide more information, feel free to add it
to this bug and change the status back to Open.
Thank you for your interest in PHP.
It does not seem to be a problem related to FPM but to core.
Can you reproduce the bug with php-cgi, php-cli or mod_php ?
Previous Comments:
[2011-10-28 06:43:44] dbetz at df dot eu
Description:
Hello,
when posting in vBulletin Board the PHP-FPM receives an segfault.
Program received signal SIGSEGV, Segmentation fault.
_zend_mm_alloc_int (heap=0x8a3aa30, size=52) at
/root/compile/php-5.3/latest/php-5.3.8/Zend/zend_alloc.c:1835
1835/root/compile/php-5.3/latest/php-5.3.8/Zend/zend_alloc.c: No such file
or directory.
in /root/compile/php-5.3/latest/php-5.3.8/Zend/zend_alloc.c
(gdb) bt full
#0 _zend_mm_alloc_int (heap=0x8a3aa30, size=52) at
/root/compile/php-5.3/latest/php-5.3.8/Zend/zend_alloc.c:1835
bitmap = value optimized out
best_fit = value optimized out
true_size = 60
block_size = value optimized out
remaining_size = value optimized out
segment_size = value optimized out
segment = value optimized out
keep_rest = value optimized out
#1 0x0842ea0c in _zend_hash_quick_add_or_update (ht=0x90dc2f0, arKey=0x90d8b78
plaintext_parser, nKeyLength=17, h=3773187690, pData=0x90d8b64,
nDataSize=4, pDest=0xba7522a8, flag=1) at
/root/compile/php-5.3/latest/php-5.3.8/Zend/zend_hash.c:315
p = 0x0
#2 0x0842ef06 in zend_hash_copy (target=0x90dc2f0, source=0x8e88318,
pCopyConstructor=0x84216f0 zval_add_ref, tmp=0xba7522e8, size=4)
at /root/compile/php-5.3/latest/php-5.3.8/Zend/zend_hash.c:788
p = 0x90d8b58
new_entry = 0x90d8a40
#3 0x084217df in _zval_copy_ctor_func (zvalue=0x9003c60) at
/root/compile/php-5.3/latest/php-5.3.8/Zend/zend_variables.c:134
tmp = 0x5b
original_ht = 0x8e88318
#4 0x084226a0 in _zval_copy_ctor (type=8, format=0x898f84c Use of undefined
constant %s - assumed '%s')
at /root/compile/php-5.3/latest/php-5.3.8/Zend/zend_variables.h:45
No locals.
#5 zend_error (type=8, format=0x898f84c Use of undefined constant %s -
assumed '%s') at /root/compile/php-5.3/latest/php-5.3.8/Zend/zend.c:1103
retval = value optimized out
z_error_type = 0x90054d4
z_error_message = 0x90da358
z_error_filename = 0x90082a0
z_error_lineno = 0x90082f4
z_context = 0x9003c60
error_filename = 0x90d5b34
/home/user/testforen/domaingo/includes/functions_newpost.php(668) : eval()'d
code
error_lineno = 43
orig_user_error_handler = value optimized out
in_compilation = value optimized out
saved_class_entry = value optimized out
#6 0x08448926 in ZEND_FETCH_CONSTANT_SPEC_UNUSED_CONST_HANDLER
(execute_data=0x8b92abc)
at /root/compile/php-5.3/latest/php-5.3.8/Zend/zend_vm_execute.h:17844
actual = 0x90dafe4 postid
opline = 0x90de7e0
#7 0x0844d33e in execute (op_array=0x8e90548) at
/root/compile/php-5.3/latest/php-5.3.8/Zend/zend_vm_execute.h:107
ret = value optimized out
execute_data = 0x8b92abc
nested = 1 '\001'
original_in_execution = 0 '\000'
#8 0x08421b46 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at
/root/compile/php-5.3/latest/php-5.3.8/Zend/zend.c:1236
i = 1
file_handle = 0xba7568a0
orig_op_array = 0x0
orig_retval_ptr_ptr = 0x0
#9 0x083cf596 in php_execute_script (primary_file=0xba7568a0) at
/root/compile/php-5.3/latest/php-5.3.8/main/main.c:2284
realfile =
ø4uºóûJ\b\000ý©ÿÿÿÿ\000\000\000\000sd@\b@è¼\b\020@¿©8´¼\b|FuºO±Ã\001ù\213\t\000(5uº\t;J\b\003\000\000\000\030\065uº\b\000\000\000\000\000\000\000 \203=©ôo=©NÃ.©\000\000\000\000\001\000\000\000|Fuº¤ö¼\bô\206\000\000\060ª£\b¤ö¼\bX5uº\002\000\000\000
\000\000\000\002\000\000\000\001\000\000\000P\204=©\025A;©\000\000\000\000Ã\203=©ä?;©ïB;©\020\000\000\000\000\000\000\000\a\000\000\000 \203=©\000\000\002\000Ã\203=©ôo=© \203=©ôðä\b¨5uº,\005/©...
---Type return to continue, or q return to quit---
__orig_bailout = 0xba756750
__bailout = {{__jmpbuf = {-1166710624, 149219088, -1166719584,
-1166719512, 2100435798, -292405198}, __mask_was_saved = 0,
Bug #60139 [PATCH]: Anonymous functions create cycles not detected by the GC
Edit report at https://bugs.php.net/bug.php?id=60139edit=1
ID: 60139
Patch added by: dmi...@php.net
Reported by:lbarn...@php.net
Summary:Anonymous functions create cycles not detected by
the GC
Status: Assigned
Type: Bug
Package:Performance problem
PHP Version:5.4.0beta2
Assigned To:dmitry
Block user comment: N
Private report: N
New Comment:
The following patch has been added/updated:
Patch Name: gc-closure.diff
Revision: 1320059056
URL:
https://bugs.php.net/patch-display.php?bug=60139patch=gc-closure.diffrevision=1320059056
Previous Comments:
[2011-10-31 08:44:09] dmi...@php.net
The following patch has been added/updated:
Patch Name: gc-closure.diff
Revision: 1320050649
URL:
https://bugs.php.net/patch-display.php?bug=60139patch=gc-closure.diffrevision=1320050649
[2011-10-26 10:36:24] lbarn...@php.net
Description:
In the following Script 1 and Script 2, the created objects are not destructed
until the engine shutdowns because of a reference cycle.
The objects hold a reference to an anonymous function that itself hold a
reference to the object.
It seems that the garbage collector is unable to break the cycle.
Script 3 doesn't leak memory because the anonymous function doesn't hold a
reference to the object.
Test script:
---
# Script 1 (leaks with php5.4)
?php
class Foo
{
public $x;
public function __construct() {
$this-x = function() {};
}
}
echo memory_get_usage(), \n;
for ($i = 0; $i 1000; ++$i) {
new Foo;
}
gc_collect_cycles();
echo memory_get_usage(), \n;
?
# Script 2 (leaks with php5.3)
?php
class Foo
{
public $x;
public function __construct() {
$self = $this;
$this-x = function() use ($self) {};
}
}
echo memory_get_usage(), \n;
for ($i = 0; $i 1000; ++$i) {
new Foo;
}
gc_collect_cycles();
echo memory_get_usage(), \n;
?
# Script 3 (no leak)
?php
class Foo
{
public $x;
public function __construct() {
$this-x = get_fun();
}
}
function get_fun() {
return function() {};
}
echo memory_get_usage(), \n;
for ($i = 0; $i 1000; ++$i) {
new Foo;
}
gc_collect_cycles();
echo memory_get_usage(), \n;
?
Expected result:
Memory usage before and after is approximatel the same:
121040
121152
Actual result:
--
Objects are never freed and memory usage increases:
120724
417640
--
Edit this bug report at https://bugs.php.net/bug.php?id=60139edit=1
Bug #60139 [PATCH]: Anonymous functions create cycles not detected by the GC
Edit report at https://bugs.php.net/bug.php?id=60139edit=1
ID: 60139
Patch added by: dmi...@php.net
Reported by:lbarn...@php.net
Summary:Anonymous functions create cycles not detected by
the GC
Status: Assigned
Type: Bug
Package:Performance problem
PHP Version:5.4.0beta2
Assigned To:dmitry
Block user comment: N
Private report: N
New Comment:
The following patch has been added/updated:
Patch Name: gc-closure2.diff
Revision: 1320059088
URL:
https://bugs.php.net/patch-display.php?bug=60139patch=gc-closure2.diffrevision=1320059088
Previous Comments:
[2011-10-31 11:04:17] dmi...@php.net
The following patch has been added/updated:
Patch Name: gc-closure.diff
Revision: 1320059056
URL:
https://bugs.php.net/patch-display.php?bug=60139patch=gc-closure.diffrevision=1320059056
[2011-10-31 08:44:09] dmi...@php.net
The following patch has been added/updated:
Patch Name: gc-closure.diff
Revision: 1320050649
URL:
https://bugs.php.net/patch-display.php?bug=60139patch=gc-closure.diffrevision=1320050649
[2011-10-26 10:36:24] lbarn...@php.net
Description:
In the following Script 1 and Script 2, the created objects are not destructed
until the engine shutdowns because of a reference cycle.
The objects hold a reference to an anonymous function that itself hold a
reference to the object.
It seems that the garbage collector is unable to break the cycle.
Script 3 doesn't leak memory because the anonymous function doesn't hold a
reference to the object.
Test script:
---
# Script 1 (leaks with php5.4)
?php
class Foo
{
public $x;
public function __construct() {
$this-x = function() {};
}
}
echo memory_get_usage(), \n;
for ($i = 0; $i 1000; ++$i) {
new Foo;
}
gc_collect_cycles();
echo memory_get_usage(), \n;
?
# Script 2 (leaks with php5.3)
?php
class Foo
{
public $x;
public function __construct() {
$self = $this;
$this-x = function() use ($self) {};
}
}
echo memory_get_usage(), \n;
for ($i = 0; $i 1000; ++$i) {
new Foo;
}
gc_collect_cycles();
echo memory_get_usage(), \n;
?
# Script 3 (no leak)
?php
class Foo
{
public $x;
public function __construct() {
$this-x = get_fun();
}
}
function get_fun() {
return function() {};
}
echo memory_get_usage(), \n;
for ($i = 0; $i 1000; ++$i) {
new Foo;
}
gc_collect_cycles();
echo memory_get_usage(), \n;
?
Expected result:
Memory usage before and after is approximatel the same:
121040
121152
Actual result:
--
Objects are never freed and memory usage increases:
120724
417640
--
Edit this bug report at https://bugs.php.net/bug.php?id=60139edit=1
Req #30432 [Com]: Add alternate syntax
Edit report at https://bugs.php.net/bug.php?id=30432edit=1 ID: 30432 Comment by: christian dot reinecke at web dot de Reported by:vivers at one dot net Summary:Add alternate syntax Status: Wont fix Type: Feature/Change Request Package:Feature/Change Request Operating System: All PHP Version:5.0.2 Block user comment: N Private report: N New Comment: Can you explain why you declined that? Because I'm not the only one using the alternative syntax in views/templates, especially for if/elseif/else and some old-school pages that do not have anything like a controller require try/catch statements mixed in HTML, so that syntax would really help. Previous Comments: [2004-10-14 14:42:15] der...@php.net Nope, we won't add more old-style alternative syntax like this. [2004-10-14 14:33:16] vivers at one dot net Description: Can you add alternate syntax for try ... catch? Something like: try : ... catch () : ... endtry; I'm using exceptions on presentation pages and this syntax would make the source much more readable. -- Edit this bug report at https://bugs.php.net/bug.php?id=30432edit=1
Bug #60156 [Fbk-Opn]: Segmentation fault at _zend_mm_alloc_int
Edit report at https://bugs.php.net/bug.php?id=60156edit=1 ID: 60156 User updated by:dbetz at df dot eu Reported by:dbetz at df dot eu Summary:Segmentation fault at _zend_mm_alloc_int -Status: Feedback +Status: Open Type: Bug Package:FPM related Operating System: Gentoo PHP Version:5.3.8 Block user comment: N Private report: N New Comment: Hello, i cant reproduce this with php-cgi and php-fpm with --enable-debug When i compile php-fpm w/o --enable-debug i hit this segfault. With php = 5.3.7rc3-dev i always get an segfault in zend_assign_to_variable See https://bugs.php.net/bug.php?id=54488 It is always the same procedure to reproduce this segfaults. Previous Comments: [2011-10-31 10:56:23] f...@php.net Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to Open. Thank you for your interest in PHP. It does not seem to be a problem related to FPM but to core. Can you reproduce the bug with php-cgi, php-cli or mod_php ? [2011-10-28 06:43:44] dbetz at df dot eu Description: Hello, when posting in vBulletin Board the PHP-FPM receives an segfault. Program received signal SIGSEGV, Segmentation fault. _zend_mm_alloc_int (heap=0x8a3aa30, size=52) at /root/compile/php-5.3/latest/php-5.3.8/Zend/zend_alloc.c:1835 1835/root/compile/php-5.3/latest/php-5.3.8/Zend/zend_alloc.c: No such file or directory. in /root/compile/php-5.3/latest/php-5.3.8/Zend/zend_alloc.c (gdb) bt full #0 _zend_mm_alloc_int (heap=0x8a3aa30, size=52) at /root/compile/php-5.3/latest/php-5.3.8/Zend/zend_alloc.c:1835 bitmap = value optimized out best_fit = value optimized out true_size = 60 block_size = value optimized out remaining_size = value optimized out segment_size = value optimized out segment = value optimized out keep_rest = value optimized out #1 0x0842ea0c in _zend_hash_quick_add_or_update (ht=0x90dc2f0, arKey=0x90d8b78 plaintext_parser, nKeyLength=17, h=3773187690, pData=0x90d8b64, nDataSize=4, pDest=0xba7522a8, flag=1) at /root/compile/php-5.3/latest/php-5.3.8/Zend/zend_hash.c:315 p = 0x0 #2 0x0842ef06 in zend_hash_copy (target=0x90dc2f0, source=0x8e88318, pCopyConstructor=0x84216f0 zval_add_ref, tmp=0xba7522e8, size=4) at /root/compile/php-5.3/latest/php-5.3.8/Zend/zend_hash.c:788 p = 0x90d8b58 new_entry = 0x90d8a40 #3 0x084217df in _zval_copy_ctor_func (zvalue=0x9003c60) at /root/compile/php-5.3/latest/php-5.3.8/Zend/zend_variables.c:134 tmp = 0x5b original_ht = 0x8e88318 #4 0x084226a0 in _zval_copy_ctor (type=8, format=0x898f84c Use of undefined constant %s - assumed '%s') at /root/compile/php-5.3/latest/php-5.3.8/Zend/zend_variables.h:45 No locals. #5 zend_error (type=8, format=0x898f84c Use of undefined constant %s - assumed '%s') at /root/compile/php-5.3/latest/php-5.3.8/Zend/zend.c:1103 retval = value optimized out z_error_type = 0x90054d4 z_error_message = 0x90da358 z_error_filename = 0x90082a0 z_error_lineno = 0x90082f4 z_context = 0x9003c60 error_filename = 0x90d5b34 /home/user/testforen/domaingo/includes/functions_newpost.php(668) : eval()'d code error_lineno = 43 orig_user_error_handler = value optimized out in_compilation = value optimized out saved_class_entry = value optimized out #6 0x08448926 in ZEND_FETCH_CONSTANT_SPEC_UNUSED_CONST_HANDLER (execute_data=0x8b92abc) at /root/compile/php-5.3/latest/php-5.3.8/Zend/zend_vm_execute.h:17844 actual = 0x90dafe4 postid opline = 0x90de7e0 #7 0x0844d33e in execute (op_array=0x8e90548) at /root/compile/php-5.3/latest/php-5.3.8/Zend/zend_vm_execute.h:107 ret = value optimized out execute_data = 0x8b92abc nested = 1 '\001' original_in_execution = 0 '\000' #8 0x08421b46 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /root/compile/php-5.3/latest/php-5.3.8/Zend/zend.c:1236 i = 1 file_handle = 0xba7568a0 orig_op_array = 0x0 orig_retval_ptr_ptr = 0x0 #9 0x083cf596 in php_execute_script (primary_file=0xba7568a0) at /root/compile/php-5.3/latest/php-5.3.8/main/main.c:2284 realfile = ø4uºóûJ\b\000ý©ÿÿÿÿ\000\000\000\000sd@\b@è¼\b\020@¿©8´¼\b|FuºO±Ã\001ù\213\t\000(5uº\t;J\b\003\000\000\000\030\065uº\b\000\000\000\000\000\000\000 \203=©ôo=©NÃ.©\000\000\000\000\001\000\000\000|Fuº¤ö¼\bô\206\000\000\060ª£\b¤ö¼\bX5uº\002\000\000\000
Bug #46149 [Com]: openssl_sign() can't generate the signature where sign DSA Private key
Edit report at https://bugs.php.net/bug.php?id=46149edit=1
ID: 46149
Comment by: menkaur at gmail dot com
Reported by:hanbsd at 163 dot com
Summary:openssl_sign() can't generate the signature where
sign DSA Private key
Status: Bogus
Type: Bug
Package:OpenSSL related
Operating System: Centos 5.0
PHP Version:5.2.6
Block user comment: N
Private report: N
New Comment:
I'm getting this bug in version 5.2.17; openssl_sign silently fails, signature
is empty
Here's the code to reproduce it:
$priv_key = '-BEGIN DSA PRIVATE KEY-
MIIDVQIBAAKCAQEA/uhSKJA6k5sSnYo+uBgi+mzJ72hqZrWgc+dNLpiiKoHsqDZ6
7kGW0J3wnhU0FxpV2SVL57SfG6dC7GvwsJYBidSEJqe3bARP8WI4yL9wm1PVTqFD
4zNkj1+zUZDWQWpJxaA8I10sJR08/WbwgD63bD6jg4JiPaowFMOrufYAW92hjANQ
D7eZ+t0GXAoDB5L6q8btVRfJrGOvkdDN6eyzc7kpJEVC9g1J9Q6glnHQRIGdW4Ot
ys/bpv2mGMfEykyTWhcMSLaAZ0YLTyKRfjYm8g7dCFWo3i8Fu0Jr+N3IWZI9Jgw5
lGyUSX8x89gjMsqtcOzcrjOtC51oAh+pio8jaQIhAM2VbbgAoxSSVO3Nd5y2mPiO
k62rr9cCj4tNy0MtYG3rAoIBABnMeAAeJpNpe3UhmWrGSJN/nQe76FSIhV/0wsu4
Xu65tW610i+uf8t0ZDqHCrbF9LSvk6vPiBydKhOmmStCa/aJJZhCKYI9/8WgtXG8
kSvAzLTNnozSLeHkapZHJwqY1wT+qxElheXjHJBRzgXVqwB+0CeJokJYlWiaPfuN
n3H1GDekuYXSFAaK4bC4TEsctQH1/403ljSbv99aXVDTVSnW0hdbokyLSPsiJjvz
w6GkyEiK/j6V2dTrIRn2X2ftzbTsE+0vEenHosIzJwM8+zUrhLvVvPBARWnbmsQ/
YstGs7WERGQzkFSsuPsWCN53Os4NnBEPiYg8//Cy1EHat3ACggEAD3mqwlAaPixs
Up49/HYlGqrU4e862rWY7mb5XRJ7AY9t70C5hhZrVO/DTgpGkwO0Yi/cYo6W0g//
cP73Nb2KZwaiyTCet2VsXb0H/8gvi8OqlidEpormedYW1T0DoyVrw57gXF0hp0D8
scfZBg0hFM/hHlmqHPKYiZtDp5imk5TeSyIoLdyJjW8jII2ni8ryStjvZ61aAPyK
VH8in3DpVANpn3MSGv1Hv1RYxaago71fVUyOkm1/pFNqBNIwBAxBIUsIPdNpjoGB
bLKXDshCfdXkQJxnx80nVDslEkv10BapLqIr98uswU/bBYMduF6Xrg5pdugDG3Cw
X8n3glog8QIgayYvNGvBvrDp9piq8RDg9mQJsd4IFBlpF7MnqIc749M=
-END DSA PRIVATE KEY-
';
$pkeyid = openssl_get_privatekey($priv_key);
if(empty($pkeyid)){
die(Can't load key id);
}
$data = $_GET['i'];
// compute signature
if(!openssl_sign($data, $signature, $pkeyid,OPENSSL_ALGO_SHA1)){
echo Failed to sign data: $data;
}
// free the key from memory
openssl_free_key($pkeyid);
if(empty($signature)){
echo signature empty;
}
echo base64_encode($signature);
Previous Comments:
[2008-11-18 02:18:03] paj...@php.net
Duplicate of #41033 (which is fixed)
[2008-11-07 07:48:21] t dot dettrick at its dot uq dot edu dot au
This is related to Bug #41033 - PHP doesn't support signing or verification
with DSA, because it requires EVP_dss1() instead of EVP_sha1(), and the patch
to provide a constant for that hash algorithm hasn't been merged yet.
[2008-09-22 11:45:57] hanbsd at 163 dot com
Description:
I create private key with
$configargs = array(
digest_alg = sha1,
private_key_bits = 1024,
private_key_type = OPENSSL_KEYTYPE_DSA,
encrypt_key = false
);
But I can not get signature by openssl_sign($data, $signature, $key).
Then I use openssl in shell
#openssl dgst -dss1 -sign id_dsa foo.sha1 sigfile.bin
openssl create a signature file : sigfile.bin
#openssl dgst -dss1 -verify id_dsa.pub -signature sigfile.bin foo.sha1
openssl print: Verified OK
It looks something bug of PHP function openssl_sign()
Reproduce code:
---
$data = sfsdfsdfs;
$fp = fopen(/home/id_dsa, r);
$pkey = fread($fp, 8192);
fclose($fp);
$key = openssl_get_privatekey($pkey);
openssl_sign($data, $signature, $key);
openssl_free_key($key);
echo $signature;
Expected result:
openssl_sign() can create signature
Actual result:
--
openssl_sign() can not create signature , $signature is empty
--
Edit this bug report at https://bugs.php.net/bug.php?id=46149edit=1
Bug #60179 [PATCH]: wrong output with php_flag boolean
Edit report at https://bugs.php.net/bug.php?id=60179edit=1
ID: 60179
Patch added by: f...@php.net
Reported by:dbetz at df dot eu
Summary:wrong output with php_flag boolean
Status: Open
Type: Bug
Package:FPM related
Operating System: Gentoo Linux
PHP Version:5.3.8
Block user comment: N
Private report: N
New Comment:
The following patch has been added/updated:
Patch Name: fpm-bug60179.patch
Revision: 1320066041
URL:
https://bugs.php.net/patch-display.php?bug=60179patch=fpm-bug60179.patchrevision=1320066041
Previous Comments:
[2011-10-31 08:43:30] dbetz at df dot eu
Description:
Hello,
when setting php_flag to Off or false, then PHP FPM sets it to the string Off
rather than 0 or NULL.
In fpm.conf
php_flag[session.auto_start] = Off
or
php_flag[session.auto_start] = false
It seems that the failure is on all boolean flags.
Test script:
---
?
echo session.auto_start is : . ini_get('session.auto_start') . \n;
if (ini_get('session.auto_start')) {
echo Some code here .\n;
}
?
Expected result:
session.auto_start is : 0
Actual result:
--
session.auto_start is : Off
--
Edit this bug report at https://bugs.php.net/bug.php?id=60179edit=1
Bug #60179 [Opn-Fbk]: wrong output with php_flag boolean
Edit report at https://bugs.php.net/bug.php?id=60179edit=1
ID: 60179
Updated by: f...@php.net
Reported by:dbetz at df dot eu
Summary:wrong output with php_flag boolean
-Status: Open
+Status: Feedback
Type: Bug
Package:FPM related
Operating System: Gentoo Linux
PHP Version:5.3.8
-Assigned To:
+Assigned To:fat
Block user comment: N
Private report: N
New Comment:
Can you please test the patch attached ?
If you can test it quickly I can integrate it before 5.3.9 is going RC1.
thx
++ fat
Previous Comments:
[2011-10-31 13:00:41] f...@php.net
The following patch has been added/updated:
Patch Name: fpm-bug60179.patch
Revision: 1320066041
URL:
https://bugs.php.net/patch-display.php?bug=60179patch=fpm-bug60179.patchrevision=1320066041
[2011-10-31 08:43:30] dbetz at df dot eu
Description:
Hello,
when setting php_flag to Off or false, then PHP FPM sets it to the string Off
rather than 0 or NULL.
In fpm.conf
php_flag[session.auto_start] = Off
or
php_flag[session.auto_start] = false
It seems that the failure is on all boolean flags.
Test script:
---
?
echo session.auto_start is : . ini_get('session.auto_start') . \n;
if (ini_get('session.auto_start')) {
echo Some code here .\n;
}
?
Expected result:
session.auto_start is : 0
Actual result:
--
session.auto_start is : Off
--
Edit this bug report at https://bugs.php.net/bug.php?id=60179edit=1
Bug #54488 [Bgs]: SIGSEGV in zend_assign_to_variable
Edit report at https://bugs.php.net/bug.php?id=54488edit=1
ID: 54488
Updated by: paj...@php.net
Reported by:dbetz at df dot eu
Summary:SIGSEGV in zend_assign_to_variable
Status: Bogus
Type: Bug
Package:FPM related
Operating System: Gentoo
PHP Version:5.3.6
Assigned To:fat
Block user comment: N
Private report: N
New Comment:
@dbetz at df dot eu
Please provide a way to reproduce this problem (aka not randomly). That means
to
debug a little bit to see what happens in your app while it crashes. using
vBulletin as a base to fix such crashes is not an option for us.
Thanks for your understanding,
Previous Comments:
[2011-07-22 05:20:45] dbetz at df dot eu
Hello,
after some time without problems now i get many segfaults:
Program received signal SIGSEGV, Segmentation fault.
_zend_mm_alloc_int (heap=0x8a65570, size=52) at
/root/compile/php-5.3-fpm/snaps/php5.3-201107150430/Zend/zend_alloc.c:1835
1835/root/compile/php-5.3-fpm/snaps/php5.3-201107150430/Zend/zend_alloc.c:
No such file or directory.
in /root/compile/php-5.3-fpm/snaps/php5.3-201107150430/Zend/zend_alloc.c
(gdb) bt full
#0 _zend_mm_alloc_int (heap=0x8a65570, size=52) at
/root/compile/php-5.3-fpm/snaps/php5.3-201107150430/Zend/zend_alloc.c:1835
bitmap = value optimized out
best_fit = value optimized out
true_size = 60
block_size = value optimized out
remaining_size = value optimized out
segment_size = value optimized out
segment = value optimized out
keep_rest = value optimized out
#1 0x08450e8c in _zend_hash_quick_add_or_update (ht=0x94a6144, arKey=0x94a2ecc
plaintext_parser, nKeyLength=17, h=3773187690, pData=0x94a2eb8,
nDataSize=4, pDest=0xb4dfd1f8, flag=1) at
/root/compile/php-5.3-fpm/snaps/php5.3-201107150430/Zend/zend_hash.c:315
p = 0x0
#2 0x08451386 in zend_hash_copy (target=0x94a6144, source=0x92a7994,
pCopyConstructor=0x8443f90 zval_add_ref, tmp=0xb4dfd238, size=4)
at /root/compile/php-5.3-fpm/snaps/php5.3-201107150430/Zend/zend_hash.c:787
p = 0x94a2eac
new_entry = 0x94a2e08
#3 0x0844407f in _zval_copy_ctor_func (zvalue=0x935eb10) at
/root/compile/php-5.3-fpm/snaps/php5.3-201107150430/Zend/zend_variables.c:134
tmp = 0x5b
original_ht = 0x92a7994
#4 0x0844487d in _zval_copy_ctor (type=8, format=0x89b9f2c Use of undefined
constant %s - assumed '%s')
at
/root/compile/php-5.3-fpm/snaps/php5.3-201107150430/Zend/zend_variables.h:45
No locals.
#5 zend_error (type=8, format=0x89b9f2c Use of undefined constant %s -
assumed '%s')
at /root/compile/php-5.3-fpm/snaps/php5.3-201107150430/Zend/zend.c:1078
retval = value optimized out
z_error_type = 0x93ccd28
z_error_message = 0x94a49d8
z_error_filename = 0x935cd3c
z_error_lineno = 0x935cd88
z_context = 0x935eb10
error_filename = 0x949feec
/kunden/145279_85737/liveforen/domaingo/includes/functions_newpost.php(668) :
eval()'d code
error_lineno = 43
orig_user_error_handler = value optimized out
in_compilation = value optimized out
saved_class_entry = value optimized out
#6 0x0846a0d6 in ZEND_FETCH_CONSTANT_SPEC_UNUSED_CONST_HANDLER
(execute_data=0x8bca78c)
at
/root/compile/php-5.3-fpm/snaps/php5.3-201107150430/Zend/zend_vm_execute.h:17844
actual = 0x94a5574 postid
opline = 0x94a825c
#7 0x0846eaee in execute (op_array=0x8e24980) at
/root/compile/php-5.3-fpm/snaps/php5.3-201107150430/Zend/zend_vm_execute.h:107
ret = value optimized out
execute_data = 0x8bca78c
nested = 1 '\001'
original_in_execution = 0 '\000'
#8 0x084443e6 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at
/root/compile/php-5.3-fpm/snaps/php5.3-201107150430/Zend/zend.c:1195
i = 1
file_handle = 0xb4e01790
orig_op_array = 0x0
orig_retval_ptr_ptr = 0x0
#9 0x083f2bd6 in php_execute_script (primary_file=0xb4e01790) at
/root/compile/php-5.3-fpm/snaps/php5.3-201107150430/main/main.c:2284
realfile =
èãôC\021M\b\000\060X¢ÿÿÿÿ\000\000\000\000#\217B\bô\020+\tÃ\\ãÃÃ*\tlõôå\235X\001\065~\r\000\030äô©RL\b\003\000\000\000\bäô\b\000\000\000\000\000\000\000pU¦\bn|A£\001\005\000\001\000\000\000\000\001\000\000\000lõô¸.\027\t\220\002\000\000pU¦\b¸.\027\tHäô#\217B\b\210ÃN£\002\000\000\000\001\000\000\000däô\001ôô\000\000\000\000¸ÃN£»Ã?\bl/\027\t\020\000\000\000\002\000\000\000/ÃL£\200ÃN£Ã\032\002\000¸ÃN£ô¿N£\200ÃN£Ã\000+\t\230äô|¢A£..---Type
return to continue, or q return to quit---
.
__orig_bailout = 0xb4e01640
__bailout = {{__jmpbuf = {-1260382320, 153810792, -1260391280,
-1260391208, 2072411008, -1166720775}, __mask_was_saved
Bug #60179 [Asn-Fbk]: wrong output with php_flag boolean
Edit report at https://bugs.php.net/bug.php?id=60179edit=1
ID: 60179
Updated by: f...@php.net
Reported by:dbetz at df dot eu
Summary:wrong output with php_flag boolean
-Status: Assigned
+Status: Feedback
Type: Bug
Package:FPM related
Operating System: Gentoo Linux
PHP Version:5.3.8
Assigned To:fat
Block user comment: N
Private report: N
New Comment:
1- On wich version did you apply the patch ? Please test the patch on the
lastest 5.3.x snapshot.
2- you should not surrender the parameter with double quote:
php_flag[session.auto_start] = Off
should be
php_flag[session.auto_start] = Off
Can you get rid of the bug. On my side, I have the last 5.3.x snapshot and it
works great. I can't reproduce your problem.
Previous Comments:
[2011-10-31 13:11:01] dbetz at df dot eu
Hello,
sorry, the problem still exists.
session.auto_start is : Off
Some code here .
With cli:
session.auto_start is : 0
[2011-10-31 13:02:09] f...@php.net
Can you please test the patch attached ?
If you can test it quickly I can integrate it before 5.3.9 is going RC1.
thx
++ fat
[2011-10-31 13:00:41] f...@php.net
The following patch has been added/updated:
Patch Name: fpm-bug60179.patch
Revision: 1320066041
URL:
https://bugs.php.net/patch-display.php?bug=60179patch=fpm-bug60179.patchrevision=1320066041
[2011-10-31 08:43:30] dbetz at df dot eu
Description:
Hello,
when setting php_flag to Off or false, then PHP FPM sets it to the string Off
rather than 0 or NULL.
In fpm.conf
php_flag[session.auto_start] = Off
or
php_flag[session.auto_start] = false
It seems that the failure is on all boolean flags.
Test script:
---
?
echo session.auto_start is : . ini_get('session.auto_start') . \n;
if (ini_get('session.auto_start')) {
echo Some code here .\n;
}
?
Expected result:
session.auto_start is : 0
Actual result:
--
session.auto_start is : Off
--
Edit this bug report at https://bugs.php.net/bug.php?id=60179edit=1
Bug #60179 [Fbk-Asn]: wrong output with php_flag boolean
Edit report at https://bugs.php.net/bug.php?id=60179edit=1
ID: 60179
User updated by:dbetz at df dot eu
Reported by:dbetz at df dot eu
Summary:wrong output with php_flag boolean
-Status: Feedback
+Status: Assigned
Type: Bug
Package:FPM related
Operating System: Gentoo Linux
PHP Version:5.3.8
Assigned To:fat
Block user comment: N
Private report: N
New Comment:
Hi fat,
i have tested the latest snapshot with the patch and have changed the config to
php_flag[session.auto_start] = Off
But the problem is still here.
Looking into fpm_conf.c at: static char *fpm_conf_set_array(... :
if (convert_to_bool) {
char *err = fpm_conf_set_boolean(value, subconf, 0);
if (err) return err;
kv-value = strdup(b ? On : Off);
}
It looks like kv-value is either string On or Off or am i wrong ?
Previous Comments:
[2011-10-31 13:18:55] f...@php.net
1- On wich version did you apply the patch ? Please test the patch on the
lastest 5.3.x snapshot.
2- you should not surrender the parameter with double quote:
php_flag[session.auto_start] = Off
should be
php_flag[session.auto_start] = Off
Can you get rid of the bug. On my side, I have the last 5.3.x snapshot and it
works great. I can't reproduce your problem.
[2011-10-31 13:11:01] dbetz at df dot eu
Hello,
sorry, the problem still exists.
session.auto_start is : Off
Some code here .
With cli:
session.auto_start is : 0
[2011-10-31 13:02:09] f...@php.net
Can you please test the patch attached ?
If you can test it quickly I can integrate it before 5.3.9 is going RC1.
thx
++ fat
[2011-10-31 13:00:41] f...@php.net
The following patch has been added/updated:
Patch Name: fpm-bug60179.patch
Revision: 1320066041
URL:
https://bugs.php.net/patch-display.php?bug=60179patch=fpm-bug60179.patchrevision=1320066041
[2011-10-31 08:43:30] dbetz at df dot eu
Description:
Hello,
when setting php_flag to Off or false, then PHP FPM sets it to the string Off
rather than 0 or NULL.
In fpm.conf
php_flag[session.auto_start] = Off
or
php_flag[session.auto_start] = false
It seems that the failure is on all boolean flags.
Test script:
---
?
echo session.auto_start is : . ini_get('session.auto_start') . \n;
if (ini_get('session.auto_start')) {
echo Some code here .\n;
}
?
Expected result:
session.auto_start is : 0
Actual result:
--
session.auto_start is : Off
--
Edit this bug report at https://bugs.php.net/bug.php?id=60179edit=1
Bug #60179 [Fbk-Asn]: wrong output with php_flag boolean
Edit report at https://bugs.php.net/bug.php?id=60179edit=1
ID: 60179
User updated by:dbetz at df dot eu
Reported by:dbetz at df dot eu
Summary:wrong output with php_flag boolean
-Status: Feedback
+Status: Assigned
Type: Bug
Package:FPM related
Operating System: Gentoo Linux
PHP Version:5.3.8
Assigned To:fat
Block user comment: N
Private report: N
New Comment:
Hello,
sorry, the problem still exists.
session.auto_start is : Off
Some code here .
With cli:
session.auto_start is : 0
Previous Comments:
[2011-10-31 13:02:09] f...@php.net
Can you please test the patch attached ?
If you can test it quickly I can integrate it before 5.3.9 is going RC1.
thx
++ fat
[2011-10-31 13:00:41] f...@php.net
The following patch has been added/updated:
Patch Name: fpm-bug60179.patch
Revision: 1320066041
URL:
https://bugs.php.net/patch-display.php?bug=60179patch=fpm-bug60179.patchrevision=1320066041
[2011-10-31 08:43:30] dbetz at df dot eu
Description:
Hello,
when setting php_flag to Off or false, then PHP FPM sets it to the string Off
rather than 0 or NULL.
In fpm.conf
php_flag[session.auto_start] = Off
or
php_flag[session.auto_start] = false
It seems that the failure is on all boolean flags.
Test script:
---
?
echo session.auto_start is : . ini_get('session.auto_start') . \n;
if (ini_get('session.auto_start')) {
echo Some code here .\n;
}
?
Expected result:
session.auto_start is : 0
Actual result:
--
session.auto_start is : Off
--
Edit this bug report at https://bugs.php.net/bug.php?id=60179edit=1
Bug #60176 [Opn-Fbk]: date + strtotime fails to calculate date
Edit report at https://bugs.php.net/bug.php?id=60176edit=1
ID: 60176
Updated by: f...@php.net
Reported by:sombra2eternity at gmail dot com
Summary:date + strtotime fails to calculate date
-Status: Open
+Status: Feedback
Type: Bug
Package:Date/time related
Operating System: Ubuntu
PHP Version:5.3.8
Block user comment: N
Private report: N
New Comment:
I can't reproduce this with PHP_5_3 HEAD.
Could you please check that your date.timezone is set correctly in your
php.ini?
It could help to compare Y-m-d H:i:s output.
Previous Comments:
[2011-10-31 00:20:04] sombra2eternity at gmail dot com
Description:
Dont know if corrected in new versions but I cant actually upgrade so I write
it here anyway to be sure its reported.
Strtotime/date fails to get the date in a simple test.
I think I found a bug:
echo date(Y-m-d,strtotime('2011-10-30')+86400);
//returns 2011-10-30 and should return 2011-10-31
desktop7@desktop7-desktop:~$ php -v
PHP 5.3.5-1ubuntu7.3 with Suhosin-Patch (cli) (built: Oct 13 2011 21:56:07)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
Test script:
---
echo date(Y-m-d,strtotime('2011-10-30')+86400);
Expected result:
2011-10-31
Actual result:
--
2011-10-30
--
Edit this bug report at https://bugs.php.net/bug.php?id=60176edit=1
Bug #60179 [Asn]: wrong output with php_flag boolean
Edit report at https://bugs.php.net/bug.php?id=60179edit=1
ID: 60179
Updated by: f...@php.net
Reported by:dbetz at df dot eu
Summary:wrong output with php_flag boolean
Status: Assigned
Type: Bug
Package:FPM related
Operating System: Gentoo Linux
PHP Version:5.3.8
Assigned To:fat
Block user comment: N
Private report: N
New Comment:
hum ... not sure to understand your problem afterall :)
without the patch:
If I set php_flag[session.auto_start]=On
ini_get(session.auto_start) returns On
and session are created for each page (auto start is on as asked)
If I set php_flag[session.auto_start]=Off
ini_get(session.auto_start) returns Off
and session are NOT created for each page (auto start is off as asked)
For me this works as expected.
Do you have the same behavior ?
Previous Comments:
[2011-10-31 13:52:48] dbetz at df dot eu
Hi fat,
i have tested the latest snapshot with the patch and have changed the config to
php_flag[session.auto_start] = Off
But the problem is still here.
Looking into fpm_conf.c at: static char *fpm_conf_set_array(... :
if (convert_to_bool) {
char *err = fpm_conf_set_boolean(value, subconf, 0);
if (err) return err;
kv-value = strdup(b ? On : Off);
}
It looks like kv-value is either string On or Off or am i wrong ?
[2011-10-31 13:18:55] f...@php.net
1- On wich version did you apply the patch ? Please test the patch on the
lastest 5.3.x snapshot.
2- you should not surrender the parameter with double quote:
php_flag[session.auto_start] = Off
should be
php_flag[session.auto_start] = Off
Can you get rid of the bug. On my side, I have the last 5.3.x snapshot and it
works great. I can't reproduce your problem.
[2011-10-31 13:11:01] dbetz at df dot eu
Hello,
sorry, the problem still exists.
session.auto_start is : Off
Some code here .
With cli:
session.auto_start is : 0
[2011-10-31 13:02:09] f...@php.net
Can you please test the patch attached ?
If you can test it quickly I can integrate it before 5.3.9 is going RC1.
thx
++ fat
[2011-10-31 13:00:41] f...@php.net
The following patch has been added/updated:
Patch Name: fpm-bug60179.patch
Revision: 1320066041
URL:
https://bugs.php.net/patch-display.php?bug=60179patch=fpm-bug60179.patchrevision=1320066041
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=60179
--
Edit this bug report at https://bugs.php.net/bug.php?id=60179edit=1
Bug #60179 [Asn]: wrong output with php_flag boolean
Edit report at https://bugs.php.net/bug.php?id=60179edit=1
ID: 60179
User updated by:dbetz at df dot eu
Reported by:dbetz at df dot eu
Summary:wrong output with php_flag boolean
Status: Assigned
Type: Bug
Package:FPM related
Operating System: Gentoo Linux
PHP Version:5.3.8
Assigned To:fat
Block user comment: N
Private report: N
New Comment:
Hello,
yes, the option is set correct, but the return value of ini_get() is different
than whith php-cgi.
Most apps like typo3, joomla, wordpress, eg. are checking in the installer, if
php.ini settings are correct.
These setting are checked thru ini_get.
When ini_get(session.auto_start) is not 0 but Off, then the check fails.
Here is the sample code from typo3 installer:
if (ini_get('session.auto_start')) {
$sessionCreationError = 'Error: session.auto-start
is enabled.br /';
$sessionCreationError .= 'The PHP option
session.auto-start is enabled. Disable this option in php.ini or
.htaccess:br /';
I hope you understand now my problem.
Previous Comments:
[2011-10-31 14:22:10] f...@php.net
hum ... not sure to understand your problem afterall :)
without the patch:
If I set php_flag[session.auto_start]=On
ini_get(session.auto_start) returns On
and session are created for each page (auto start is on as asked)
If I set php_flag[session.auto_start]=Off
ini_get(session.auto_start) returns Off
and session are NOT created for each page (auto start is off as asked)
For me this works as expected.
Do you have the same behavior ?
[2011-10-31 13:52:48] dbetz at df dot eu
Hi fat,
i have tested the latest snapshot with the patch and have changed the config to
php_flag[session.auto_start] = Off
But the problem is still here.
Looking into fpm_conf.c at: static char *fpm_conf_set_array(... :
if (convert_to_bool) {
char *err = fpm_conf_set_boolean(value, subconf, 0);
if (err) return err;
kv-value = strdup(b ? On : Off);
}
It looks like kv-value is either string On or Off or am i wrong ?
[2011-10-31 13:18:55] f...@php.net
1- On wich version did you apply the patch ? Please test the patch on the
lastest 5.3.x snapshot.
2- you should not surrender the parameter with double quote:
php_flag[session.auto_start] = Off
should be
php_flag[session.auto_start] = Off
Can you get rid of the bug. On my side, I have the last 5.3.x snapshot and it
works great. I can't reproduce your problem.
[2011-10-31 13:11:01] dbetz at df dot eu
Hello,
sorry, the problem still exists.
session.auto_start is : Off
Some code here .
With cli:
session.auto_start is : 0
[2011-10-31 13:02:09] f...@php.net
Can you please test the patch attached ?
If you can test it quickly I can integrate it before 5.3.9 is going RC1.
thx
++ fat
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=60179
--
Edit this bug report at https://bugs.php.net/bug.php?id=60179edit=1
Bug #60176 [Fbk-Opn]: date + strtotime fails to calculate date
Edit report at https://bugs.php.net/bug.php?id=60176edit=1
ID: 60176
User updated by:sombra2eternity at gmail dot com
Reported by:sombra2eternity at gmail dot com
Summary:date + strtotime fails to calculate date
-Status: Feedback
+Status: Open
Type: Bug
Package:Date/time related
Operating System: Ubuntu
-PHP Version:5.3.8
+PHP Version:5.4
Block user comment: N
Private report: N
New Comment:
I just compiled: php5.4-201110311230
---
desktop7@desktop7-desktop:~/php5.4-201110311230/sapi/cli$ ./php -v
PHP 5.4.0RC1-dev (cli) (built: Oct 31 2011 15:21:08)
Copyright (c) 1997-2011 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2011 Zend Technologies
---
desktop7@desktop7-desktop:~/php5.4-201110311230/sapi/cli$ ./php
/var/www/strto.php
2011-10-30
CONTENT OF STRTO.PHP:
?php
date_default_timezone_set('Europe/Madrid');
echo date('Y-m-d',strtotime('2011-10-30')+86400);
?
Thanks for helping me
Previous Comments:
[2011-10-31 14:01:32] f...@php.net
I can't reproduce this with PHP_5_3 HEAD.
Could you please check that your date.timezone is set correctly in your
php.ini?
It could help to compare Y-m-d H:i:s output.
[2011-10-31 00:20:04] sombra2eternity at gmail dot com
Description:
Dont know if corrected in new versions but I cant actually upgrade so I write
it here anyway to be sure its reported.
Strtotime/date fails to get the date in a simple test.
I think I found a bug:
echo date(Y-m-d,strtotime('2011-10-30')+86400);
//returns 2011-10-30 and should return 2011-10-31
desktop7@desktop7-desktop:~$ php -v
PHP 5.3.5-1ubuntu7.3 with Suhosin-Patch (cli) (built: Oct 13 2011 21:56:07)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
Test script:
---
echo date(Y-m-d,strtotime('2011-10-30')+86400);
Expected result:
2011-10-31
Actual result:
--
2011-10-30
--
Edit this bug report at https://bugs.php.net/bug.php?id=60176edit=1
Bug #60179 [Asn]: wrong output with php_flag boolean
Edit report at https://bugs.php.net/bug.php?id=60179edit=1
ID: 60179
User updated by:dbetz at df dot eu
Reported by:dbetz at df dot eu
Summary:wrong output with php_flag boolean
Status: Assigned
Type: Bug
Package:FPM related
Operating System: Gentoo Linux
PHP Version:5.3.8
Assigned To:fat
Block user comment: N
Private report: N
New Comment:
In the php manual http://php.net/ini_get is an notice:
Hinweis: When querying boolean values
A boolean ini value of off will be returned as an empty string or 0 while a
boolean ini value of on will be returned as 1. The function can also return
the literal string of INI value.
--
It looks like, that the value is not boolen Off but string Off
Previous Comments:
[2011-10-31 14:34:49] dbetz at df dot eu
Hello,
yes, the option is set correct, but the return value of ini_get() is different
than whith php-cgi.
Most apps like typo3, joomla, wordpress, eg. are checking in the installer, if
php.ini settings are correct.
These setting are checked thru ini_get.
When ini_get(session.auto_start) is not 0 but Off, then the check fails.
Here is the sample code from typo3 installer:
if (ini_get('session.auto_start')) {
$sessionCreationError = 'Error: session.auto-start
is enabled.br /';
$sessionCreationError .= 'The PHP option
session.auto-start is enabled. Disable this option in php.ini or
.htaccess:br /';
I hope you understand now my problem.
[2011-10-31 14:22:10] f...@php.net
hum ... not sure to understand your problem afterall :)
without the patch:
If I set php_flag[session.auto_start]=On
ini_get(session.auto_start) returns On
and session are created for each page (auto start is on as asked)
If I set php_flag[session.auto_start]=Off
ini_get(session.auto_start) returns Off
and session are NOT created for each page (auto start is off as asked)
For me this works as expected.
Do you have the same behavior ?
[2011-10-31 13:52:48] dbetz at df dot eu
Hi fat,
i have tested the latest snapshot with the patch and have changed the config to
php_flag[session.auto_start] = Off
But the problem is still here.
Looking into fpm_conf.c at: static char *fpm_conf_set_array(... :
if (convert_to_bool) {
char *err = fpm_conf_set_boolean(value, subconf, 0);
if (err) return err;
kv-value = strdup(b ? On : Off);
}
It looks like kv-value is either string On or Off or am i wrong ?
[2011-10-31 13:18:55] f...@php.net
1- On wich version did you apply the patch ? Please test the patch on the
lastest 5.3.x snapshot.
2- you should not surrender the parameter with double quote:
php_flag[session.auto_start] = Off
should be
php_flag[session.auto_start] = Off
Can you get rid of the bug. On my side, I have the last 5.3.x snapshot and it
works great. I can't reproduce your problem.
[2011-10-31 13:11:01] dbetz at df dot eu
Hello,
sorry, the problem still exists.
session.auto_start is : Off
Some code here .
With cli:
session.auto_start is : 0
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=60179
--
Edit this bug report at https://bugs.php.net/bug.php?id=60179edit=1
Bug #60160 [PATCH]: imagefill() doesn't work correctly for small images
Edit report at https://bugs.php.net/bug.php?id=60160edit=1
ID: 60160
Patch added by: f...@php.net
Reported by:kieran at menor dot dk
Summary:imagefill() doesn't work correctly for small images
Status: Open
Type: Bug
Package:GD related
Operating System: Windows 7 x64, Debian 6 x64
PHP Version:5.3.8
Block user comment: N
Private report: N
New Comment:
The following patch has been added/updated:
Patch Name: fix-imagefill-for-images-smaller-than-4px-width
Revision: 1320072664
URL:
https://bugs.php.net/patch-display.php?bug=60160patch=fix-imagefill-for-images-smaller-than-4px-widthrevision=1320072664
Previous Comments:
[2011-10-28 17:39:06] kieran at menor dot dk
Workaround:
Use imagefilledrectangle() instead, alike so:
function imagefillfix($image, $x, $y, $color)
{
return imagefilledrectangle($image, $x, $y, imagesx($image) - 1,
imagesy($image) - 1, $color);
}
[2011-10-28 17:30:08] kieran at menor dot dk
Description:
imagefill() doesn't work correctly for images with a width lower than 4 pixels.
Image height makes no difference.
Test script:
---
?php
header('Content-Type: image/png');
$im = imagecreatetruecolor(3, 3);
imagefill($im, 0, 0, imagecolorallocate($im, 255, 255, 255));
imagepng($im);
imagedestroy($im);
Expected result:
Completely white 3x3 pixels image expected.
Actual result:
--
Upper and left edge white, 2x2 black square in lower right corner.
http://caffie.net/broken.php
--
Edit this bug report at https://bugs.php.net/bug.php?id=60160edit=1
Bug #60160 [Opn-Ana]: imagefill() doesn't work correctly for small images
Edit report at https://bugs.php.net/bug.php?id=60160edit=1
ID: 60160
Updated by: f...@php.net
Reported by:kieran at menor dot dk
Summary:imagefill() doesn't work correctly for small images
-Status: Open
+Status: Analyzed
Type: Bug
Package:GD related
Operating System: Windows 7 x64, Debian 6 x64
PHP Version:5.3.8
Block user comment: N
Private report: N
New Comment:
Related to https://bugs.php.net/51671 - that didn't get fixed completely, as
can be seen in the test for #51671.
Previous Comments:
[2011-10-31 14:51:05] f...@php.net
The following patch has been added/updated:
Patch Name: fix-imagefill-for-images-smaller-than-4px-width
Revision: 1320072664
URL:
https://bugs.php.net/patch-display.php?bug=60160patch=fix-imagefill-for-images-smaller-than-4px-widthrevision=1320072664
[2011-10-28 17:39:06] kieran at menor dot dk
Workaround:
Use imagefilledrectangle() instead, alike so:
function imagefillfix($image, $x, $y, $color)
{
return imagefilledrectangle($image, $x, $y, imagesx($image) - 1,
imagesy($image) - 1, $color);
}
[2011-10-28 17:30:08] kieran at menor dot dk
Description:
imagefill() doesn't work correctly for images with a width lower than 4 pixels.
Image height makes no difference.
Test script:
---
?php
header('Content-Type: image/png');
$im = imagecreatetruecolor(3, 3);
imagefill($im, 0, 0, imagecolorallocate($im, 255, 255, 255));
imagepng($im);
imagedestroy($im);
Expected result:
Completely white 3x3 pixels image expected.
Actual result:
--
Upper and left edge white, 2x2 black square in lower right corner.
http://caffie.net/broken.php
--
Edit this bug report at https://bugs.php.net/bug.php?id=60160edit=1
Bug #60160 [PATCH]: imagefill() doesn't work correctly for small images
Edit report at https://bugs.php.net/bug.php?id=60160edit=1
ID: 60160
Patch added by: f...@php.net
Reported by:kieran at menor dot dk
Summary:imagefill() doesn't work correctly for small images
Status: Analyzed
Type: Bug
Package:GD related
Operating System: Windows 7 x64, Debian 6 x64
PHP Version:5.3.8
Block user comment: N
Private report: N
New Comment:
The following patch has been added/updated:
Patch Name: bug60160.phpt
Revision: 1320074804
URL:
https://bugs.php.net/patch-display.php?bug=60160patch=bug60160.phptrevision=1320074804
Previous Comments:
[2011-10-31 15:19:15] f...@php.net
Related to https://bugs.php.net/51671 - that didn't get fixed completely, as
can be seen in the test for #51671.
[2011-10-31 14:51:05] f...@php.net
The following patch has been added/updated:
Patch Name: fix-imagefill-for-images-smaller-than-4px-width
Revision: 1320072664
URL:
https://bugs.php.net/patch-display.php?bug=60160patch=fix-imagefill-for-images-smaller-than-4px-widthrevision=1320072664
[2011-10-28 17:39:06] kieran at menor dot dk
Workaround:
Use imagefilledrectangle() instead, alike so:
function imagefillfix($image, $x, $y, $color)
{
return imagefilledrectangle($image, $x, $y, imagesx($image) - 1,
imagesy($image) - 1, $color);
}
[2011-10-28 17:30:08] kieran at menor dot dk
Description:
imagefill() doesn't work correctly for images with a width lower than 4 pixels.
Image height makes no difference.
Test script:
---
?php
header('Content-Type: image/png');
$im = imagecreatetruecolor(3, 3);
imagefill($im, 0, 0, imagecolorallocate($im, 255, 255, 255));
imagepng($im);
imagedestroy($im);
Expected result:
Completely white 3x3 pixels image expected.
Actual result:
--
Upper and left edge white, 2x2 black square in lower right corner.
http://caffie.net/broken.php
--
Edit this bug report at https://bugs.php.net/bug.php?id=60160edit=1
Bug #60176 [Opn-Bgs]: date + strtotime fails to calculate date
Edit report at https://bugs.php.net/bug.php?id=60176edit=1
ID: 60176
Updated by: f...@php.net
Reported by:sombra2eternity at gmail dot com
Summary:date + strtotime fails to calculate date
-Status: Open
+Status: Bogus
Type: Bug
Package:Date/time related
Operating System: Ubuntu
PHP Version:5.4
Block user comment: N
Private report: N
New Comment:
We are happy to tell you that you just discovered Daylight Savings
Time. For more information see:
http://webexhibits.org/daylightsaving/b.html
Instead of using mktime/date consider using gmmktime and gmdate which do
not suffer from DST.
You do realize that there are indeed 24h between 2011-10-30 00:00:00 and
2011-10-30 23:00:00, right?
This is when DST was adjusted.
Try your code with 2011-10-31 and you'll see 2011-11-01 as a result of adding
24h.
Previous Comments:
[2011-10-31 14:37:58] sombra2eternity at gmail dot com
I just compiled: php5.4-201110311230
---
desktop7@desktop7-desktop:~/php5.4-201110311230/sapi/cli$ ./php -v
PHP 5.4.0RC1-dev (cli) (built: Oct 31 2011 15:21:08)
Copyright (c) 1997-2011 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2011 Zend Technologies
---
desktop7@desktop7-desktop:~/php5.4-201110311230/sapi/cli$ ./php
/var/www/strto.php
2011-10-30
CONTENT OF STRTO.PHP:
?php
date_default_timezone_set('Europe/Madrid');
echo date('Y-m-d',strtotime('2011-10-30')+86400);
?
Thanks for helping me
[2011-10-31 14:01:32] f...@php.net
I can't reproduce this with PHP_5_3 HEAD.
Could you please check that your date.timezone is set correctly in your
php.ini?
It could help to compare Y-m-d H:i:s output.
[2011-10-31 00:20:04] sombra2eternity at gmail dot com
Description:
Dont know if corrected in new versions but I cant actually upgrade so I write
it here anyway to be sure its reported.
Strtotime/date fails to get the date in a simple test.
I think I found a bug:
echo date(Y-m-d,strtotime('2011-10-30')+86400);
//returns 2011-10-30 and should return 2011-10-31
desktop7@desktop7-desktop:~$ php -v
PHP 5.3.5-1ubuntu7.3 with Suhosin-Patch (cli) (built: Oct 13 2011 21:56:07)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
Test script:
---
echo date(Y-m-d,strtotime('2011-10-30')+86400);
Expected result:
2011-10-31
Actual result:
--
2011-10-30
--
Edit this bug report at https://bugs.php.net/bug.php?id=60176edit=1
Bug #60166 [Opn-Ana]: Locale::lookup() returns an empty string if the first arg is an empty array
Edit report at https://bugs.php.net/bug.php?id=60166edit=1
ID: 60166
Updated by: f...@php.net
Reported by:np dot viktorov at gmail dot com
Summary:Locale::lookup() returns an empty string if the
first arg is an empty array
-Status: Open
+Status: Analyzed
Type: Bug
Package:intl
Operating System: Debian GNU/Linux 6.0.2 (squeeze)
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
RFC4647 (http://www.ietf.org/rfc/rfc4647.txt) states:
3.4.1. Default Values
Each application, protocol, or specification that uses lookup MUST
define the defaulting behavior when no tag matches the language
priority list. What this action consists of strongly depends on how
lookup is being applied. Some examples of defaulting behavior
include:
o return an item with no language tag or an item of a non-linguistic
nature, such as an image or sound
o return a null string as the language tag value, in cases where the
protocol permits the empty value (see, for example, xml:lang in
[XML10])
o return a particular language tag designated for the operation
o return the language tag i-default (see [RFC2277])
o return an error condition or error message
o return a list of available languages for the user to select from
-
So this *might* be classified unexpected behavior instead of a bug.
The fix would probably be easy, PHP_5_3/ext/intl/locale_methods.c,1537 :
»···if( !hash_arr || zend_hash_num_elements( hash_arr ) == 0 ) {
»···»···RETURN_EMPTY_STRING();
»···}
But as I have no clue what this would break, I will not change this now.
Previous Comments:
[2011-10-29 11:29:11] np dot viktorov at gmail dot com
I forgot the INTL information.
According to phpinfo() the INTL version information is this:
- version 1.1.0
- ICU version 4.4.1
[2011-10-29 11:24:32] np dot viktorov at gmail dot com
Description:
Locale::lookup() will return an empty string if the first argument is an empty
array() no matter that we have already set the default argument (argument #4)
Test script:
---
?php
$available = array();
$default = en;
$requested = eu-us;
$result = Locale::lookup($available, $requested, null, $default);
var_dump($result);
/*
if we create atleast one element, for example de it will work fine
*/
Expected result:
According to the documentation we should expect to get en because this is the
default locale provided as the fourth argument. This doesn't happen.
Actual result:
--
The actual result is (an empty string), not null, not false, just an empty
string.
--
Edit this bug report at https://bugs.php.net/bug.php?id=60166edit=1
[PHP-BUG] Bug #60180 [NEW]: $_SERVER[PHP_SELF] incorrect
From: Operating system: Windows XP with SP3 PHP version: 5.4SVN-2011-10-31 (snap) Package: Built-in web server Bug Type: Bug Bug description:$_SERVER[PHP_SELF] incorrect Description: When going to, for example, /admin/phpinfo.php/foo/bar?foo=bar, you should get the following (using Apache and PHP on Windows XP): $_SERVER[REQUEST_URI] == /admin/phpinfo.php/foo/bar?foo=bar $_SERVER[PHP_SELF] == /admin/phpinfo.php/foo/bar $_SERVER[SCRIPT_NAME] == /admin/phpinfo.php $_SERVER[PATH_INFO]== /foo/bar $_SERVER[QUERY_STRING] == foo=bar In the snap for October 31, 2011, REQUEST_URI, PATH_INFO and QUERY_STRING are correct, but the following are wrong: $_SERVER[PHP_SELF] == \admin\phpinfo.php (slashes incorrectly replaced by backslashes, and PATH_INFO ending has been incorrectly removed) $_SERVER[SCRIPT_NAME] == (missing completely) Test script: --- phpinfo.php file contains: ?php phpinfo(); ? Expected result: Going to /admin/phpinfo.php/foo/bar?foo=bar should get: $_SERVER[REQUEST_URI] == /admin/phpinfo.php/foo/bar?foo=bar $_SERVER[PHP_SELF] == /admin/phpinfo.php/foo/bar $_SERVER[SCRIPT_NAME] == /admin/phpinfo.php $_SERVER[PATH_INFO]== /foo/bar $_SERVER[QUERY_STRING] == foo=bar Actual result: -- $_SERVER[REQUEST_URI] == /admin/phpinfo.php/foo/bar?foo=bar (correct) $_SERVER[PHP_SELF] == \admin\phpinfo.php (incorrect) $_SERVER[SCRIPT_NAME] == (not set) $_SERVER[PATH_INFO]== /foo/bar (correct) $_SERVER[QUERY_STRING] == foo=bar (correct) -- Edit bug report at https://bugs.php.net/bug.php?id=60180edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60180r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60180r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60180r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60180r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60180r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60180r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60180r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60180r=needscript Try newer version: https://bugs.php.net/fix.php?id=60180r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60180r=support Expected behavior: https://bugs.php.net/fix.php?id=60180r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60180r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60180r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60180r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60180r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60180r=dst IIS Stability: https://bugs.php.net/fix.php?id=60180r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60180r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60180r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60180r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60180r=mysqlcfg
Bug #60180 [Com]: $_SERVER[PHP_SELF] incorrect
Edit report at https://bugs.php.net/bug.php?id=60180edit=1 ID: 60180 Comment by: david dot gero at ec dot gc dot ca Reported by:david dot gero at ec dot gc dot ca Summary:$_SERVER[PHP_SELF] incorrect Status: Open Type: Bug Package:Built-in web server Operating System: Windows XP with SP3 PHP Version:5.4SVN-2011-10-31 (snap) Block user comment: N Private report: N New Comment: Should have said that the snap was tested with the built-in PHP web server, and I was comparing it against the standard Apache + PHP setup Previous Comments: [2011-10-31 17:25:21] david dot gero at ec dot gc dot ca Description: When going to, for example, /admin/phpinfo.php/foo/bar?foo=bar, you should get the following (using Apache and PHP on Windows XP): $_SERVER[REQUEST_URI] == /admin/phpinfo.php/foo/bar?foo=bar $_SERVER[PHP_SELF] == /admin/phpinfo.php/foo/bar $_SERVER[SCRIPT_NAME] == /admin/phpinfo.php $_SERVER[PATH_INFO]== /foo/bar $_SERVER[QUERY_STRING] == foo=bar In the snap for October 31, 2011, REQUEST_URI, PATH_INFO and QUERY_STRING are correct, but the following are wrong: $_SERVER[PHP_SELF] == \admin\phpinfo.php (slashes incorrectly replaced by backslashes, and PATH_INFO ending has been incorrectly removed) $_SERVER[SCRIPT_NAME] == (missing completely) Test script: --- phpinfo.php file contains: ?php phpinfo(); ? Expected result: Going to /admin/phpinfo.php/foo/bar?foo=bar should get: $_SERVER[REQUEST_URI] == /admin/phpinfo.php/foo/bar?foo=bar $_SERVER[PHP_SELF] == /admin/phpinfo.php/foo/bar $_SERVER[SCRIPT_NAME] == /admin/phpinfo.php $_SERVER[PATH_INFO]== /foo/bar $_SERVER[QUERY_STRING] == foo=bar Actual result: -- $_SERVER[REQUEST_URI] == /admin/phpinfo.php/foo/bar?foo=bar (correct) $_SERVER[PHP_SELF] == \admin\phpinfo.php (incorrect) $_SERVER[SCRIPT_NAME] == (not set) $_SERVER[PATH_INFO]== /foo/bar (correct) $_SERVER[QUERY_STRING] == foo=bar (correct) -- Edit this bug report at https://bugs.php.net/bug.php?id=60180edit=1
Bug #60158 [Bgs]: Segmentation fault in _zend_mm_free_canary_int
Edit report at https://bugs.php.net/bug.php?id=60158edit=1
ID: 60158
User updated by:michael dot irey at gmail dot com
Reported by:michael dot irey at gmail dot com
Summary:Segmentation fault in _zend_mm_free_canary_int
Status: Bogus
Type: Bug
Package:Apache2 related
Operating System: Ubuntu 10.04.3 LTS
-PHP Version:5.3.8
+PHP Version:5.3.x
Block user comment: N
Private report: N
New Comment:
Ok, I have reproduced the bug from a clean PHP build using 5.3.8
Here is the new gdb details:
Program terminated with signal 11, Segmentation fault.
#0 0x7fabd4b288b6 in _zval_dtor_func (zvalue=0x7fff0a50eb70,
__zend_filename=0x7fabd4ea8558 /root/downloads/php-
5.3.8/Zend/zend_object_handlers.c, __zend_lineno=441)
at /root/downloads/php-5.3.8/Zend/zend_variables.c:35
35 CHECK_ZVAL_STRING_REL(zvalue);
(gdb) dump_bt executor_globals.current_execute_data
[0xd8959e80] setElement() /web/lib/zend/ZendFramework-1.11.10-
minimal/library/Zend/Form/Decorator/Abstract.php:186
[0xd8959b18] setElement() /web/lib/zend/ZendFramework-1.11.10-
minimal/library/Zend/Form/Element.php:2030
[0xd8959940] render() /web/lib/zend/ZendFramework-1.11.10-
minimal/library/Zend/Form/Element.php:2046
[0x0a50eec0] __toString()
[0xd89580d0] ???
/web/vhosts/imac.michael.dev.bluehawk.evanta.com/website/application/views/scrip
ts/contacts/duplicate.phtml:62
[0xd8957ed0] ??? /web/lib/zend/ZendFramework-1.11.10-
minimal/library/Zend/View.php:108
[0xd8957c88] _run() /web/lib/zend/ZendFramework-1.11.10-
minimal/library/Zend/View/Abstract.php:888
[0xd89579b8] render() /web/lib/zend/ZendFramework-1.11.10-
minimal/library/Zend/Controller/Action/Helper/ViewRenderer.php:900
[0xd89577b0] renderScript() /web/lib/zend/ZendFramework-1.11.10-
minimal/library/Zend/Controller/Action/Helper/ViewRenderer.php:921
[0xd8957670] render() /web/lib/zend/ZendFramework-1.11.10-
minimal/library/Zend/Controller/Action/Helper/ViewRenderer.php:960
[0xd89574a8] postDispatch() /web/lib/zend/ZendFramework-1.11.10-
minimal/library/Zend/Controller/Action/HelperBroker.php:277
[0xd8956e20] notifyPostDispatch() /web/lib/zend/ZendFramework-1.11.10-
minimal/library/Zend/Controller/Action.php:527
[0xd8956008] dispatch() /web/lib/zend/ZendFramework-1.11.10-
minimal/library/Zend/Controller/Dispatcher/Standard.php:295
[0xd89545e0] dispatch() /web/lib/zend/ZendFramework-1.11.10-
minimal/library/Zend/Controller/Front.php:954
[0xd89541e0] dispatch() /web/lib/zend/ZendFramework-1.11.10-
minimal/library/Zend/Application/Bootstrap/Bootstrap.php:97
[0xd89540a0] run() /web/lib/zend/ZendFramework-1.11.10-
minimal/library/Zend/Application.php:366
[0xd8953090] run()
/web/vhosts/imac.michael.dev.bluehawk.evanta.com/website/public/index.php:69
Previous Comments:
[2011-10-28 16:14:44] fel...@php.net
zend_alloc_canary.c is from Suhosin project, not PHP.
So, try reproduce the crash in a clean PHP build.
[2011-10-28 16:10:58] michael dot irey at gmail dot com
Added more detail in the summary
[2011-10-28 16:05:50] michael dot irey at gmail dot com
Description:
Using ZendFramework-1.11.10. Seg fault occurs also in 5.3.2 as well as 5.3.8.
Does
not occur in 5.2.4. Difficult to reproduce, but I will include the gdb
backtrace.
Basically assigning the value of variable to another, causes the seg fault. I
can
not determine why. The line $this-_element = $element; causes the seg fault.
Test script:
---
public function setElement($element)
{
if ((!$element instanceof Zend_Form_Element)
(!$element instanceof Zend_Form)
(!$element instanceof Zend_Form_DisplayGroup))
{
require_once 'Zend/Form/Decorator/Exception.php';
throw new Zend_Form_Decorator_Exception('Invalid element type
passed to decorator');
}
$this-_element = $element;
return $this;
}
Expected result:
Not this: exit signal Segmentation fault (11)
Actual result:
--
Program terminated with signal 11, Segmentation fault.
#0 0x7ffd348abe53 in _zend_mm_free_canary_int (heap=0x7ffd39b11130,
p=0x21143c453bb97f0f) at /build/buildd/php5-5.3.2/Zend/zend_alloc_canary.c:2090
2090/build/buildd/php5-5.3.2/Zend/zend_alloc_canary.c: No such file or
directory.
in /build/buildd/php5-5.3.2/Zend/zend_alloc_canary.c
(gdb) dump_bt executor_globals.current_execute_data
[0x386f2e30] setElement() /web/lib/zend/ZendFramework-1.11.10-
minimal/library/Zend/Form/Decorator/Abstract.php:186
[0x386f2ac8] setElement() /web/lib/zend/ZendFramework-1.11.10-
minimal/library/Zend/Form/Element.php:2030
[0x386f28f0]
Bug #60158 [Bgs]: Segmentation fault in zend_variables.c
Edit report at https://bugs.php.net/bug.php?id=60158edit=1
ID: 60158
User updated by:michael dot irey at gmail dot com
Reported by:michael dot irey at gmail dot com
-Summary:Segmentation fault in _zend_mm_free_canary_int
+Summary:Segmentation fault in zend_variables.c
Status: Bogus
Type: Bug
Package:Apache2 related
Operating System: Ubuntu 10.04.3 LTS
PHP Version:5.3.x
Block user comment: N
Private report: N
New Comment:
Updated the summary line to contain zend_variables.c
Previous Comments:
[2011-10-31 18:47:39] michael dot irey at gmail dot com
Ok, I have reproduced the bug from a clean PHP build using 5.3.8
Here is the new gdb details:
Program terminated with signal 11, Segmentation fault.
#0 0x7fabd4b288b6 in _zval_dtor_func (zvalue=0x7fff0a50eb70,
__zend_filename=0x7fabd4ea8558 /root/downloads/php-
5.3.8/Zend/zend_object_handlers.c, __zend_lineno=441)
at /root/downloads/php-5.3.8/Zend/zend_variables.c:35
35 CHECK_ZVAL_STRING_REL(zvalue);
(gdb) dump_bt executor_globals.current_execute_data
[0xd8959e80] setElement() /web/lib/zend/ZendFramework-1.11.10-
minimal/library/Zend/Form/Decorator/Abstract.php:186
[0xd8959b18] setElement() /web/lib/zend/ZendFramework-1.11.10-
minimal/library/Zend/Form/Element.php:2030
[0xd8959940] render() /web/lib/zend/ZendFramework-1.11.10-
minimal/library/Zend/Form/Element.php:2046
[0x0a50eec0] __toString()
[0xd89580d0] ???
/web/vhosts/imac.michael.dev.bluehawk.evanta.com/website/application/views/scrip
ts/contacts/duplicate.phtml:62
[0xd8957ed0] ??? /web/lib/zend/ZendFramework-1.11.10-
minimal/library/Zend/View.php:108
[0xd8957c88] _run() /web/lib/zend/ZendFramework-1.11.10-
minimal/library/Zend/View/Abstract.php:888
[0xd89579b8] render() /web/lib/zend/ZendFramework-1.11.10-
minimal/library/Zend/Controller/Action/Helper/ViewRenderer.php:900
[0xd89577b0] renderScript() /web/lib/zend/ZendFramework-1.11.10-
minimal/library/Zend/Controller/Action/Helper/ViewRenderer.php:921
[0xd8957670] render() /web/lib/zend/ZendFramework-1.11.10-
minimal/library/Zend/Controller/Action/Helper/ViewRenderer.php:960
[0xd89574a8] postDispatch() /web/lib/zend/ZendFramework-1.11.10-
minimal/library/Zend/Controller/Action/HelperBroker.php:277
[0xd8956e20] notifyPostDispatch() /web/lib/zend/ZendFramework-1.11.10-
minimal/library/Zend/Controller/Action.php:527
[0xd8956008] dispatch() /web/lib/zend/ZendFramework-1.11.10-
minimal/library/Zend/Controller/Dispatcher/Standard.php:295
[0xd89545e0] dispatch() /web/lib/zend/ZendFramework-1.11.10-
minimal/library/Zend/Controller/Front.php:954
[0xd89541e0] dispatch() /web/lib/zend/ZendFramework-1.11.10-
minimal/library/Zend/Application/Bootstrap/Bootstrap.php:97
[0xd89540a0] run() /web/lib/zend/ZendFramework-1.11.10-
minimal/library/Zend/Application.php:366
[0xd8953090] run()
/web/vhosts/imac.michael.dev.bluehawk.evanta.com/website/public/index.php:69
[2011-10-28 16:14:44] fel...@php.net
zend_alloc_canary.c is from Suhosin project, not PHP.
So, try reproduce the crash in a clean PHP build.
[2011-10-28 16:10:58] michael dot irey at gmail dot com
Added more detail in the summary
[2011-10-28 16:05:50] michael dot irey at gmail dot com
Description:
Using ZendFramework-1.11.10. Seg fault occurs also in 5.3.2 as well as 5.3.8.
Does
not occur in 5.2.4. Difficult to reproduce, but I will include the gdb
backtrace.
Basically assigning the value of variable to another, causes the seg fault. I
can
not determine why. The line $this-_element = $element; causes the seg fault.
Test script:
---
public function setElement($element)
{
if ((!$element instanceof Zend_Form_Element)
(!$element instanceof Zend_Form)
(!$element instanceof Zend_Form_DisplayGroup))
{
require_once 'Zend/Form/Decorator/Exception.php';
throw new Zend_Form_Decorator_Exception('Invalid element type
passed to decorator');
}
$this-_element = $element;
return $this;
}
Expected result:
Not this: exit signal Segmentation fault (11)
Actual result:
--
Program terminated with signal 11, Segmentation fault.
#0 0x7ffd348abe53 in _zend_mm_free_canary_int (heap=0x7ffd39b11130,
p=0x21143c453bb97f0f) at /build/buildd/php5-5.3.2/Zend/zend_alloc_canary.c:2090
2090/build/buildd/php5-5.3.2/Zend/zend_alloc_canary.c: No such file or
directory.
in /build/buildd/php5-5.3.2/Zend/zend_alloc_canary.c
(gdb) dump_bt executor_globals.current_execute_data
[0x386f2e30] setElement()
Req #38334 [Com]: Proper data-type support for PDO_SQLITE
Edit report at https://bugs.php.net/bug.php?id=38334edit=1 ID: 38334 Comment by: mikemol at gmail dot com Reported by:mkhitrov at gmail dot com Summary:Proper data-type support for PDO_SQLITE Status: Open Type: Feature/Change Request Package:SQLite related Operating System: * PHP Version:5.2.3 Block user comment: N Private report: N New Comment: Similar surprises for me. Thoughts: (1) Mapping INTEGER to int isn't necessarily ideal, because there's no certainty (AFAIK) that sqlite3's integer value will fit within the range offered by int. PHP already has a type-promotion paradigm for handling this (by converting to float, which supports a larger range of precise integer values), but I don't know what it looks like in PHP's source code. (2) If PHP is converting sqlite3's numeric returns to strings, that means that users need to convert strings back to numeric types. That sounds error-prone and potentially lossy for both stages of that conversion, potentially resulting in data loss because of the unnecessary translation[1]. There might even be a vulnerability there, in the event large numbers are being stored, and those numbers are damaged during the translations. (3) If the semantics of the sqlite PDO driver were to change to reflect sqlite3's semantics instead of sqlite2's, that would likely break a lot of existing code. It stands to reason you wouldn't want the new semantics to be the default, but you'd definitely want the old semantics to be deprecated. Perhaps in release $next, there's an attribute to switch which versions' semantics are used, defaulting to current (sqlite2's) behavior, but allowing sqlite3's to be selected. In release $next+1, default to sqlite3's, and deprecate sqlite2's. In $next+2, remove sqlite3's, deprecate the attribute. In $next+4's, remove the attribute. As mkhitrov noted, at first glance, it looks faster to fix PHP's code-in-C[2] than fix one's own code-in-PHP. Realities of the situation, though, are that I'd likely end up waiting through a release or two before sqlite3 semantics are applied. [1] And certainly incorrect behavior, if the user is led to expect sqlite3 semantics; while I was researching to learn how sqlite behaved, I didn't even realize the sqlite2 semantics were in effect anywhere, leading me to write a fair amount of code assuming sqlite3 semantics. (I only discovered that the sqlite3 semantics weren't as expected while I was rechecking and building up my unit test suite for the app I'm on) [2] I don't hack on PHP source, but I frequently have to refer to it to clarify behaviors not clear in the documentation. I can mostly follow what goes on in some places, but I haven't tried modifying or adding anything. I don't trust myself to write the patch, certainly not yet, and probably not on billable time. Previous Comments: [2006-08-14 14:08:21] tony2...@php.net Since this is the intended behavior, there is no bug and your report should be classified as feature request. If not, I have to go back and spend a ton of time writing wrappers for PDO that will emulate what should have been proper behavior. You also can spend some time and cook a patch, that adds the functionality you want, we would gladly review it. [2006-08-14 13:55:56] maximkh at yahoo dot com Ok listen, until someone actually starts reading Feature/Change Requests, this is a PDO related issue. It's already been nearly 2 weeks, and I have yet to hear anything constructive from anyone. All I want is for someone to spend 5 minutes and tell me if there is even a chance it will be fixed in the next release. If so, great, I'll shut up and won't bother you. If not, I have to go back and spend a ton of time writing wrappers for PDO that will emulate what should have been proper behavior. [2006-08-13 15:58:43] maximkh at yahoo dot com Not exactly, it WAS typeless in version 2. As of version 3, it has well defined types as explained in the documentation: http://www.sqlite.org/datatype3.html If I was to store the number 18446744073709551615, SQLite v3 would store it as an 8-byte integer, but since PHP forces a conversion to string, it would take up 20 bytes. I'm sure you can see the problem, especially when dealing with certain scientific applications which is what I'm trying to write and use SQLite with. Considering that there is a perfect match between SQLite and PHP data-types, there is really no reason not to implement them... NULL- null INTEGER - integer REAL- float TEXT- string BLOB- binary string After taking a look through the actual PDO_SQLITE code, this kind of change would take half an hour to
Bug #60158 [Bgs]: Segmentation fault in zend_variables.c
Edit report at https://bugs.php.net/bug.php?id=60158edit=1
ID: 60158
User updated by:michael dot irey at gmail dot com
Reported by:michael dot irey at gmail dot com
Summary:Segmentation fault in zend_variables.c
Status: Bogus
Type: Bug
-Package:Apache2 related
+Package:Scripting Engine problem
Operating System: Ubuntu 10.04.3 LTS
PHP Version:5.3.x
Block user comment: N
Private report: N
New Comment:
Changed the package description
Previous Comments:
[2011-10-31 18:49:12] michael dot irey at gmail dot com
Updated the summary line to contain zend_variables.c
[2011-10-31 18:47:39] michael dot irey at gmail dot com
Ok, I have reproduced the bug from a clean PHP build using 5.3.8
Here is the new gdb details:
Program terminated with signal 11, Segmentation fault.
#0 0x7fabd4b288b6 in _zval_dtor_func (zvalue=0x7fff0a50eb70,
__zend_filename=0x7fabd4ea8558 /root/downloads/php-
5.3.8/Zend/zend_object_handlers.c, __zend_lineno=441)
at /root/downloads/php-5.3.8/Zend/zend_variables.c:35
35 CHECK_ZVAL_STRING_REL(zvalue);
(gdb) dump_bt executor_globals.current_execute_data
[0xd8959e80] setElement() /web/lib/zend/ZendFramework-1.11.10-
minimal/library/Zend/Form/Decorator/Abstract.php:186
[0xd8959b18] setElement() /web/lib/zend/ZendFramework-1.11.10-
minimal/library/Zend/Form/Element.php:2030
[0xd8959940] render() /web/lib/zend/ZendFramework-1.11.10-
minimal/library/Zend/Form/Element.php:2046
[0x0a50eec0] __toString()
[0xd89580d0] ???
/web/vhosts/imac.michael.dev.bluehawk.evanta.com/website/application/views/scrip
ts/contacts/duplicate.phtml:62
[0xd8957ed0] ??? /web/lib/zend/ZendFramework-1.11.10-
minimal/library/Zend/View.php:108
[0xd8957c88] _run() /web/lib/zend/ZendFramework-1.11.10-
minimal/library/Zend/View/Abstract.php:888
[0xd89579b8] render() /web/lib/zend/ZendFramework-1.11.10-
minimal/library/Zend/Controller/Action/Helper/ViewRenderer.php:900
[0xd89577b0] renderScript() /web/lib/zend/ZendFramework-1.11.10-
minimal/library/Zend/Controller/Action/Helper/ViewRenderer.php:921
[0xd8957670] render() /web/lib/zend/ZendFramework-1.11.10-
minimal/library/Zend/Controller/Action/Helper/ViewRenderer.php:960
[0xd89574a8] postDispatch() /web/lib/zend/ZendFramework-1.11.10-
minimal/library/Zend/Controller/Action/HelperBroker.php:277
[0xd8956e20] notifyPostDispatch() /web/lib/zend/ZendFramework-1.11.10-
minimal/library/Zend/Controller/Action.php:527
[0xd8956008] dispatch() /web/lib/zend/ZendFramework-1.11.10-
minimal/library/Zend/Controller/Dispatcher/Standard.php:295
[0xd89545e0] dispatch() /web/lib/zend/ZendFramework-1.11.10-
minimal/library/Zend/Controller/Front.php:954
[0xd89541e0] dispatch() /web/lib/zend/ZendFramework-1.11.10-
minimal/library/Zend/Application/Bootstrap/Bootstrap.php:97
[0xd89540a0] run() /web/lib/zend/ZendFramework-1.11.10-
minimal/library/Zend/Application.php:366
[0xd8953090] run()
/web/vhosts/imac.michael.dev.bluehawk.evanta.com/website/public/index.php:69
[2011-10-28 16:14:44] fel...@php.net
zend_alloc_canary.c is from Suhosin project, not PHP.
So, try reproduce the crash in a clean PHP build.
[2011-10-28 16:10:58] michael dot irey at gmail dot com
Added more detail in the summary
[2011-10-28 16:05:50] michael dot irey at gmail dot com
Description:
Using ZendFramework-1.11.10. Seg fault occurs also in 5.3.2 as well as 5.3.8.
Does
not occur in 5.2.4. Difficult to reproduce, but I will include the gdb
backtrace.
Basically assigning the value of variable to another, causes the seg fault. I
can
not determine why. The line $this-_element = $element; causes the seg fault.
Test script:
---
public function setElement($element)
{
if ((!$element instanceof Zend_Form_Element)
(!$element instanceof Zend_Form)
(!$element instanceof Zend_Form_DisplayGroup))
{
require_once 'Zend/Form/Decorator/Exception.php';
throw new Zend_Form_Decorator_Exception('Invalid element type
passed to decorator');
}
$this-_element = $element;
return $this;
}
Expected result:
Not this: exit signal Segmentation fault (11)
Actual result:
--
Program terminated with signal 11, Segmentation fault.
#0 0x7ffd348abe53 in _zend_mm_free_canary_int (heap=0x7ffd39b11130,
p=0x21143c453bb97f0f) at /build/buildd/php5-5.3.2/Zend/zend_alloc_canary.c:2090
2090/build/buildd/php5-5.3.2/Zend/zend_alloc_canary.c: No such file or
directory.
Bug #60154 [Bgs]: OCIEnvNlsCreate() failed. please check that LD_LIBRARY_PATH includes ...
Edit report at https://bugs.php.net/bug.php?id=60154edit=1 ID: 60154 Updated by: s...@php.net Reported by:jiten dot luhar at gmail dot com Summary:OCIEnvNlsCreate() failed. please check that LD_LIBRARY_PATH includes ... Status: Bogus Type: Bug Package:OCI8 related Operating System: AIX 6.1 PHP Version:5.3.8 Block user comment: N Private report: N New Comment: For future readers: AIX uses LIBPATH to set the path. Previous Comments: [2011-10-27 22:34:32] s...@php.net Since this works in command line PHP there's no indication of a bug in any PHP code. Please follow up on a support forum such at http://www.oracle.com/technetwork/forums/php/index.html There are few things that could be looked at. [2011-10-27 21:31:54] jiten dot luhar at gmail dot com Description: Hi, I recently build following after lots of strugle. Server: IBM OS: AIX 6.1 Apache: 2.2.19 PHP: 5.3.8 To make sure I have installed all the pre-requisite using AIX RPM packages without any errors. Configure command for Apache: ./configure --prefix=/opt/myenv/share --with-ssl=/usr/bin/openssl --enable-ssl --enable-setenvif --enable-rewrite --enable-so I have downloaded Oracle Instace Client 11.1.0.7(Basic + SDK) and unziped at /opt/myenv/share/oracle Configure Command for PHP: ./configure --prefix=/opt/myenv/share --with-config-file-scan-dir=/opt/myenv/share/etc/php.d --with-apxs2=/opt/myenv/share/bin/apxs --host=powerpc-ibm-aix6.1.0.0 --with-zlib --with-zlib-dir=/opt/freeware --enable-libxml --with-libxml-dir=/opt/freeware --with-pcre-dir=/opt/freeware --with-mysqli=mysqlnd --with-oci8=instantclient,/opt/myenv/share/oracle Now, While connecting Oracle database, its giving me following error. PHP Warning: ociplogon() [a href='function.ociplogon'function.ociplogon/a]: OCIEnvNlsCreate() failed. There is something wrong with your system - please check that LD_LIBRARY_PATH includes the directory with Oracle Instant Client libraries Surprisely, this error not Coming when i run PHP from SHELL script. It will comes when i run PHP using Apache on Browser. I tried every solution that i found on all other BUGS/Website. i.e. File: /opt/myenv/share/bin/envvars export LD_LIBRARY_PATH = /opt/myenv/share/oracle File: /opt/myenv/share/conf/httpd.conf SetEnv LD_LIBRARY_PATH /opt/myenv/share/oracle LoadModule php5_modulemodules/libphp5.so In phpinfo(), it shows LD_LIBRARY_PATH correctly in all sections where it should be. i.e. in ENVIRONMENT, in PHP Variables, In Apach Environment sections. But still, i am having same error with NO LUCK !!! [As i mentioned, i am not getting this error when executing same file from SHELL, and it connects to DB successfully] Expected result: OCI8 should able to find LD_LIBRARY_PATH. /opt/myenv/share/conf/httpd.conf: SetEnv LD_LIBRARY_PATH /opt/myenv/share/oracle LoadModule php5_modulemodules/libphp5.so /opt/myenv/share/bin/envvars: LD_LIBRARY_PATH=/opt/myenv/share/oracle export LD_LIBRARY_PATH /opt/myenv/share/oracle: -rw-rw-rw-1 rootroot 192 Sep 26 2008 SQLPLUS_README -r--r--r--1 rootroot 342 Sep 26 2008 glogin.sql -r-xr-xr-x1 rootroot 36838851 Sep 26 2008 libsqlplus.so -r-xr-xr-x1 rootroot 1508116 Sep 26 2008 libsqlplusic.so -r-xr-xr-x1 rootroot 36768154 Sep 26 2008 sqlplus -r--r--r--1 rootroot 40210154 Sep 26 2008 libclntsh.a -r--r--r--1 rootroot 6057596 Sep 26 2008 libocci.a -r-xr-xr-x1 rootroot 4606923 Sep 26 2008 libocci.so -r-xr-xr-x1 rootroot714625 Sep 26 2008 libocijdbc11.so -r--r--r--1 rootroot 1890499 Sep 26 2008 ojdbc5.jar -r--r--r--1 rootroot 1988051 Sep 26 2008 ojdbc6.jar -rw-rw-rw-1 rootroot 188 Sep 26 2008 BASIC_README -rwxrwxrwx1 rootroot 52556 Sep 26 2008 adrci -rwxrwxrwx1 rootroot 35546 Sep 26 2008 genezi -r-xr-xr-x1 rootroot 39129029 Sep 26 2008 libclntsh.so -r-xr-xr-x1 rootroot 4269968 Sep 26 2008 libnnz11.so -rwxrwxrwx1 rootroot 82898597 Sep 26 2008 libociei.so Actual result: -- PHP Warning: ociplogon() [a href='function.ociplogon'function.ociplogon/a]: OCIEnvNlsCreate() failed. There is something wrong with your system - please check that LD_LIBRARY_PATH includes the directory with Oracle Instant Client libraries -- Edit this bug report at https://bugs.php.net/bug.php?id=60154edit=1
Bug #60158 [Bgs-Fbk]: Segmentation fault in zend_variables.c
Edit report at https://bugs.php.net/bug.php?id=60158edit=1 ID: 60158 Updated by: paj...@php.net Reported by:michael dot irey at gmail dot com Summary:Segmentation fault in zend_variables.c -Status: Bogus +Status: Feedback Type: Bug Package:Scripting Engine problem Operating System: Ubuntu 10.04.3 LTS PHP Version:5.3.x Block user comment: N Private report: N New Comment: Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with ?php and ends with ?, is max. 10-20 lines long and does not require any external resources such as databases, etc. If the script requires a database to demonstrate the issue, please make sure it creates all necessary tables, stored procedures etc. Please avoid embedding huge scripts into the report. Previous Comments: [2011-10-31 19:51:35] michael dot irey at gmail dot com Changed the package description [2011-10-31 18:49:12] michael dot irey at gmail dot com Updated the summary line to contain zend_variables.c [2011-10-31 18:47:39] michael dot irey at gmail dot com Ok, I have reproduced the bug from a clean PHP build using 5.3.8 Here is the new gdb details: Program terminated with signal 11, Segmentation fault. #0 0x7fabd4b288b6 in _zval_dtor_func (zvalue=0x7fff0a50eb70, __zend_filename=0x7fabd4ea8558 /root/downloads/php- 5.3.8/Zend/zend_object_handlers.c, __zend_lineno=441) at /root/downloads/php-5.3.8/Zend/zend_variables.c:35 35 CHECK_ZVAL_STRING_REL(zvalue); (gdb) dump_bt executor_globals.current_execute_data [0xd8959e80] setElement() /web/lib/zend/ZendFramework-1.11.10- minimal/library/Zend/Form/Decorator/Abstract.php:186 [0xd8959b18] setElement() /web/lib/zend/ZendFramework-1.11.10- minimal/library/Zend/Form/Element.php:2030 [0xd8959940] render() /web/lib/zend/ZendFramework-1.11.10- minimal/library/Zend/Form/Element.php:2046 [0x0a50eec0] __toString() [0xd89580d0] ??? /web/vhosts/imac.michael.dev.bluehawk.evanta.com/website/application/views/scrip ts/contacts/duplicate.phtml:62 [0xd8957ed0] ??? /web/lib/zend/ZendFramework-1.11.10- minimal/library/Zend/View.php:108 [0xd8957c88] _run() /web/lib/zend/ZendFramework-1.11.10- minimal/library/Zend/View/Abstract.php:888 [0xd89579b8] render() /web/lib/zend/ZendFramework-1.11.10- minimal/library/Zend/Controller/Action/Helper/ViewRenderer.php:900 [0xd89577b0] renderScript() /web/lib/zend/ZendFramework-1.11.10- minimal/library/Zend/Controller/Action/Helper/ViewRenderer.php:921 [0xd8957670] render() /web/lib/zend/ZendFramework-1.11.10- minimal/library/Zend/Controller/Action/Helper/ViewRenderer.php:960 [0xd89574a8] postDispatch() /web/lib/zend/ZendFramework-1.11.10- minimal/library/Zend/Controller/Action/HelperBroker.php:277 [0xd8956e20] notifyPostDispatch() /web/lib/zend/ZendFramework-1.11.10- minimal/library/Zend/Controller/Action.php:527 [0xd8956008] dispatch() /web/lib/zend/ZendFramework-1.11.10- minimal/library/Zend/Controller/Dispatcher/Standard.php:295 [0xd89545e0] dispatch() /web/lib/zend/ZendFramework-1.11.10- minimal/library/Zend/Controller/Front.php:954 [0xd89541e0] dispatch() /web/lib/zend/ZendFramework-1.11.10- minimal/library/Zend/Application/Bootstrap/Bootstrap.php:97 [0xd89540a0] run() /web/lib/zend/ZendFramework-1.11.10- minimal/library/Zend/Application.php:366 [0xd8953090] run() /web/vhosts/imac.michael.dev.bluehawk.evanta.com/website/public/index.php:69 [2011-10-28 16:14:44] fel...@php.net zend_alloc_canary.c is from Suhosin project, not PHP. So, try reproduce the crash in a clean PHP build. [2011-10-28 16:10:58] michael dot irey at gmail dot com Added more detail in the summary 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=60158 -- Edit this bug report at https://bugs.php.net/bug.php?id=60158edit=1
Bug #48781 [Csd-Asn]: Cyclical garbage collector memory leak
Edit report at https://bugs.php.net/bug.php?id=48781edit=1 ID: 48781 User updated by:nate at frickenate dot com Reported by:nate at frickenate dot com Summary:Cyclical garbage collector memory leak -Status: Closed +Status: Assigned Type: Bug Package:Scripting Engine problem Operating System: Debian 5.0 kernel 2.6.24-23-xen PHP Version:5.3.0 Assigned To:dmitry Block user comment: N Private report: N New Comment: Confirmed, this bug has regressed. Since it was originally fixed, there are few commits to zend_execute.c where that fix was effectuated. http://svn.php.net/viewvc/php/php-src/branches/PHP_5_3/Zend/zend_execute.c? r1=293985r2=309342 This shows all changes to that file since the fix (inclusive). The added line at 273 was the fix for this bug. But then we see the other changes made around this fix, one of which must have caused the cyclical fix to be no longer useful. Previous Comments: [2011-09-13 11:28:12] nex2hex at ya dot ru On php 5.38 (win32) this bug still exists [2011-04-03 02:24:23] jas at rephunter dot net I believe this bug has regressed. We only recently upgraded from 5.3.2 to 5.3.5. And now several scripts are broken that have been working for years. By adding the unset of the variable at the end of the loop as shown in the first snippet below, the problem is fixed. So I believe that the symptom has regressed, although not necessarily the cause. [2010-04-20 14:55:01] dmi...@php.net Note that your test and expectation are not completely correct because the actual garbage collection occurs at undefined moments of time. As result the memory usage on different iteration will be different. To avoid this ambiguity add explicit call to gc_collect_cycles() before printing memory usage. [2010-04-20 14:50:54] dmi...@php.net This bug has been fixed in SVN. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. [2010-04-20 14:30:38] dmi...@php.net Automatic comment from SVN on behalf of dmitry Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=298213 Log: Fixed bug #48781 (Cyclical garbage collector memory leak) 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=48781 -- Edit this bug report at https://bugs.php.net/bug.php?id=48781edit=1
Bug #60158 [Fbk-Opn]: Segmentation fault in zend_variables.c
Edit report at https://bugs.php.net/bug.php?id=60158edit=1 ID: 60158 User updated by:michael dot irey at gmail dot com Reported by:michael dot irey at gmail dot com Summary:Segmentation fault in zend_variables.c -Status: Feedback +Status: Open Type: Bug Package:Scripting Engine problem Operating System: Ubuntu 10.04.3 LTS PHP Version:5.3.x Block user comment: N Private report: N New Comment: I would really like to provide a short example script to reproduce the problem. However, the problem only seems to pop up on when a large amount of objects are used, but that is only a guess. We use ZendFramework 1.11.x. I have re-compiled PHP with --enable-debug and when I execute the script that caused the seg fault I get this: Unknown(0) : Warning - String is not zero-terminated (APPLICATION_PATH?? bZZZ?b) (source: /root/downloads/php-5.3.8/Zend/zend_opcode.c:261) [Mon Oct 31 12:17:52 2011] Script: '/web/vhosts/imac.michael.dev.bluehawk.evanta.com/website/public/index.php' --- /root/downloads/php-5.3.8/Zend/zend_opcode.c(261) : Block 0x7f88250c2ab0 status: /root/downloads/php-5.3.8/Zend/zend_variables.c(36) : Actual location (location was relayed) Beginning: OK (allocated on Zend/zend_language_scanner.l:1695, 17 bytes) Start: OK End: Overflown (magic=0x002B instead of 0x62D3082C) 1 byte(s) overflown --- [Mon Oct 31 12:17:52 2011] Script: '/web/vhosts/imac.michael.dev.bluehawk.evanta.com/website/public/index.php' Zend/zend_language_scanner.l(1695) : Freeing 0x7F88250C2AB0 (17 bytes), script=/web/vhosts/imac.michael.dev.bluehawk.evanta.com/website/public/index.php === Total 1 memory leaks detected === Unknown(0) : Warning - String is not zero-terminated (APPLICATION_PATH?? bZZZ?b) (source: /root/downloads/php-5.3.8/Zend/zend_opcode.c:261) [Mon Oct 31 12:18:09 2011] Script: '/web/vhosts/imac.michael.dev.bluehawk.evanta.com/website/public/index.php' --- /root/downloads/php-5.3.8/Zend/zend_opcode.c(261) : Block 0x7f88250c2ab0 status: /root/downloads/php-5.3.8/Zend/zend_variables.c(36) : Actual location (location was relayed) Beginning: OK (allocated on Zend/zend_language_scanner.l:1695, 17 bytes) Start: OK End: Overflown (magic=0x002B instead of 0x62D3082C) 1 byte(s) overflown --- [Mon Oct 31 12:18:09 2011] Script: '/web/vhosts/imac.michael.dev.bluehawk.evanta.com/website/public/index.php' Zend/zend_language_scanner.l(1695) : Freeing 0x7F88250C2AB0 (17 bytes), script=/web/vhosts/imac.michael.dev.bluehawk.evanta.com/website/public/index.php === Total 1 memory leaks detected === Is there anything else I can do to help diagnose and resolve this issue? Previous Comments: [2011-10-31 20:13:05] paj...@php.net Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with ?php and ends with ?, is max. 10-20 lines long and does not require any external resources such as databases, etc. If the script requires a database to demonstrate the issue, please make sure it creates all necessary tables, stored procedures etc. Please avoid embedding huge scripts into the report. [2011-10-31 19:51:35] michael dot irey at gmail dot com Changed the package description [2011-10-31 18:49:12] michael dot irey at gmail dot com Updated the summary line to contain zend_variables.c [2011-10-31 18:47:39] michael dot irey at gmail dot com Ok, I have reproduced the bug from a clean PHP build using 5.3.8 Here is the new gdb details: Program terminated with signal 11, Segmentation fault. #0 0x7fabd4b288b6 in _zval_dtor_func (zvalue=0x7fff0a50eb70, __zend_filename=0x7fabd4ea8558 /root/downloads/php- 5.3.8/Zend/zend_object_handlers.c, __zend_lineno=441) at /root/downloads/php-5.3.8/Zend/zend_variables.c:35 35 CHECK_ZVAL_STRING_REL(zvalue); (gdb) dump_bt executor_globals.current_execute_data [0xd8959e80] setElement() /web/lib/zend/ZendFramework-1.11.10- minimal/library/Zend/Form/Decorator/Abstract.php:186 [0xd8959b18] setElement() /web/lib/zend/ZendFramework-1.11.10- minimal/library/Zend/Form/Element.php:2030 [0xd8959940] render() /web/lib/zend/ZendFramework-1.11.10- minimal/library/Zend/Form/Element.php:2046 [0x0a50eec0] __toString() [0xd89580d0] ???
Bug #60158 [Opn-Sus]: Segmentation fault in zend_variables.c
Edit report at https://bugs.php.net/bug.php?id=60158edit=1 ID: 60158 Updated by: paj...@php.net Reported by:michael dot irey at gmail dot com Summary:Segmentation fault in zend_variables.c -Status: Open +Status: Suspended Type: Bug Package:Scripting Engine problem Operating System: Ubuntu 10.04.3 LTS PHP Version:5.3.x Block user comment: N Private report: N New Comment: I would suggest to report this issue at zend framework or zend directly then. They can help you to figure out the issue. Previous Comments: [2011-10-31 21:02:56] michael dot irey at gmail dot com I would really like to provide a short example script to reproduce the problem. However, the problem only seems to pop up on when a large amount of objects are used, but that is only a guess. We use ZendFramework 1.11.x. I have re-compiled PHP with --enable-debug and when I execute the script that caused the seg fault I get this: Unknown(0) : Warning - String is not zero-terminated (APPLICATION_PATH?? bZZZ?b) (source: /root/downloads/php-5.3.8/Zend/zend_opcode.c:261) [Mon Oct 31 12:17:52 2011] Script: '/web/vhosts/imac.michael.dev.bluehawk.evanta.com/website/public/index.php' --- /root/downloads/php-5.3.8/Zend/zend_opcode.c(261) : Block 0x7f88250c2ab0 status: /root/downloads/php-5.3.8/Zend/zend_variables.c(36) : Actual location (location was relayed) Beginning: OK (allocated on Zend/zend_language_scanner.l:1695, 17 bytes) Start: OK End: Overflown (magic=0x002B instead of 0x62D3082C) 1 byte(s) overflown --- [Mon Oct 31 12:17:52 2011] Script: '/web/vhosts/imac.michael.dev.bluehawk.evanta.com/website/public/index.php' Zend/zend_language_scanner.l(1695) : Freeing 0x7F88250C2AB0 (17 bytes), script=/web/vhosts/imac.michael.dev.bluehawk.evanta.com/website/public/index.php === Total 1 memory leaks detected === Unknown(0) : Warning - String is not zero-terminated (APPLICATION_PATH?? bZZZ?b) (source: /root/downloads/php-5.3.8/Zend/zend_opcode.c:261) [Mon Oct 31 12:18:09 2011] Script: '/web/vhosts/imac.michael.dev.bluehawk.evanta.com/website/public/index.php' --- /root/downloads/php-5.3.8/Zend/zend_opcode.c(261) : Block 0x7f88250c2ab0 status: /root/downloads/php-5.3.8/Zend/zend_variables.c(36) : Actual location (location was relayed) Beginning: OK (allocated on Zend/zend_language_scanner.l:1695, 17 bytes) Start: OK End: Overflown (magic=0x002B instead of 0x62D3082C) 1 byte(s) overflown --- [Mon Oct 31 12:18:09 2011] Script: '/web/vhosts/imac.michael.dev.bluehawk.evanta.com/website/public/index.php' Zend/zend_language_scanner.l(1695) : Freeing 0x7F88250C2AB0 (17 bytes), script=/web/vhosts/imac.michael.dev.bluehawk.evanta.com/website/public/index.php === Total 1 memory leaks detected === Is there anything else I can do to help diagnose and resolve this issue? [2011-10-31 20:13:05] paj...@php.net Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with ?php and ends with ?, is max. 10-20 lines long and does not require any external resources such as databases, etc. If the script requires a database to demonstrate the issue, please make sure it creates all necessary tables, stored procedures etc. Please avoid embedding huge scripts into the report. [2011-10-31 19:51:35] michael dot irey at gmail dot com Changed the package description [2011-10-31 18:49:12] michael dot irey at gmail dot com Updated the summary line to contain zend_variables.c [2011-10-31 18:47:39] michael dot irey at gmail dot com Ok, I have reproduced the bug from a clean PHP build using 5.3.8 Here is the new gdb details: Program terminated with signal 11, Segmentation fault. #0 0x7fabd4b288b6 in _zval_dtor_func (zvalue=0x7fff0a50eb70, __zend_filename=0x7fabd4ea8558 /root/downloads/php- 5.3.8/Zend/zend_object_handlers.c, __zend_lineno=441) at /root/downloads/php-5.3.8/Zend/zend_variables.c:35 35 CHECK_ZVAL_STRING_REL(zvalue); (gdb) dump_bt executor_globals.current_execute_data [0xd8959e80] setElement() /web/lib/zend/ZendFramework-1.11.10- minimal/library/Zend/Form/Decorator/Abstract.php:186 [0xd8959b18] setElement()
Bug #52752 [Com]: Program terminated with signal 7, Bus error.
Edit report at https://bugs.php.net/bug.php?id=52752edit=1
ID: 52752
Comment by: juraj at lutter dot sk
Reported by:paulgao at yeah dot net
Summary:Program terminated with signal 7, Bus error.
Status: Feedback
Type: Bug
Package:Scripting Engine problem
Operating System: Centos 5 32bit
PHP Version:5.3SVN-2010-08-31 (SVN)
Block user comment: N
Private report: N
New Comment:
This same happens on Solaris 10/x86 with PHP 5.3.8 compiled using GCC4 and
using Apache 2.2.21.
root@[nwebs3 /var/crash/nwebs3]# pstack httpd-29691-cust_zend_apache3
core 'httpd-29691-cust_zend_apache3' of 29691: /opt/csw/apache2/sbin/httpd -f
/opt/csw/apache2/etc/httpd.conf -k star
fe0485d4 lex_scan (8046c74, 6c632f61, 746e6569, fe062825, 69762f63, 72656c6c)
+ 60
fe062863 zendlex (8046c70, 8045ae0, 8045690, fe04344b) + 4f
fe043ac2 zendparse (85af794, 2, 40, 2, 81c3ecc, 9) + 69a
fe047cd1 compile_file (8046e00, 8, 2, fe3630c8, 81f399c, 85b1265) + bd
fdd7706c sg_compile_file (8046e00, 8, 55, 0, fe3ae224, 31) + 20
fe0abaac (8047800, 81c3e12, 8046e98, fe3ae0c0, 88b39c8, 1007800)
fe0945d9 execute (81e10b4, 0, 2, 81c3ba8, 8046ecc, 8046ed4) + 195
fe074111 zend_execute_scripts (8, 0, 3, 0, 8047800, 0) + 129
fe0255af php_execute_script (8047800, 8380c78, 9c, fe0f72a9, fdc2, 8000) +
1df
fe0f7508 (8386cd0, 25, 8386fb0, 8387f60)
0807cdce ap_run_handler (8386cd0, 3b, 8047ae8, 807d135, 11e1a300, 0) + 32
0807d19f ap_invoke_handler (8386cd0, 0, 8047b18, 80712de) + af
08087fdd ap_process_request (8386cd0, 4, 8386cd0, 8386cd0) + 18d
0808599d ap_process_http_connection (837cf40, 0, 8047b78, 8082aed) + f1
08082802 ap_run_process_connection (837cf40, 837cca8, 837cc68, 80bcdd8,
fec42c40, 0) + 32
0808c34a child_main (10, 808beb8, 1, 0) + 406
0808c52e make_child (fddc1a5e, feb7667a, fec43c80, 6, 0, fec43c80) + de
0808d0ae ap_mpm_run (80be830, 80ec8e8, 80c0728, 80c0728) + aea
0806c9e4 main (6, 8047e08, 8047e24) + 6f8
0806be7c _start (6, 8047ea8, 8047ec4, 8047ec7, 8047ee7, 8047eea) + 80
Previous Comments:
[2011-02-09 12:40:08] paulgao at yeah dot net
core dump:
(gdb) bt
#0 0x082a1ac8 in lex_scan (zendlval=0xbf85525c) at
/root/php-5.3.5/Zend/zend_language_scanner.c:2063
#1 0x082b2df8 in zendlex (zendlval=0xbf855258) at
/root/php-5.3.5/Zend/zend_compile.c:4949
#2 0x0829c0f9 in zendparse () at
/root/php-5.3.5/Zend/zend_language_parser.c:3280
#3 0x082a0f3c in compile_file (file_handle=0xbf855330, type=8) at
/root/php-5.3.5/Zend/zend_language_scanner.c:359
#4 0x082fa1ca in ZEND_INCLUDE_OR_EVAL_SPEC_TMP_HANDLER
(execute_data=0x9fbd1b8) at /root/php-5.3.5/Zend/zend_vm_execute.h:5200
#5 0x082ed7e8 in execute (op_array=0x9f88d68) at
/root/php-5.3.5/Zend/zend_vm_execute.h:107
#6 0x082cb847 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at
/root/php-5.3.5/Zend/zend.c:1194
#7 0x0827ae7e in php_execute_script (primary_file=0xbf859858) at
/root/php-5.3.5/main/main.c:2265
#8 0x08352122 in main (argc=131072, argv=0x640004) at
/root/php-5.3.5/sapi/fpm/fpm/fpm_main.c:1882
[2011-02-09 12:38:42] paulgao at yeah dot net
?php
file_put_contents(__DIR__ . '/test.tpl', 'AAA?php $string = '.
str_repeat('A', mt_rand(1, 256 * 1024)) .'; ?BBB' . \r\n, LOCK_EX);
require_once __DIR__ . '/test.tpl';
?
please use âab -n 200 -n 20 http://localhost/test.phpâ to test it.
[2010-11-24 00:20:11] fel...@php.net
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ?php and ends with ?,
is max. 10-20 lines long and does not require any external
resources such as databases, etc. If the script requires a
database to demonstrate the issue, please make sure it creates
all necessary tables, stored procedures etc.
Please avoid embedding huge scripts into the report.
[2010-09-09 07:39:16] paulgao at yeah dot net
and, centos 64bit server, same result.
[2010-09-04 18:24:58] paulgao at yeah dot net
Anybody There?
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=52752
--
Edit this bug report at https://bugs.php.net/bug.php?id=52752edit=1
[PHP-BUG] Bug #60181 [NEW]: proc_open fails to read quoted whitespaced directories in Windows
From: Operating system: Windows 7 PHP version: 5.3.8 Package: Program Execution Bug Type: Bug Bug description:proc_open fails to read quoted whitespaced directories in Windows Description: Trying to execute via proc_open: C:/Program Files (x86)/Git/bin/git.exe status --porcelain --untracked-files=all -- D:/home/aldo/git/test whitespace is like not using them, since the result of STDERR is: 'C:/Program' is not recognized as an internal or external command, operable program or batch file. Test script: --- ?php $command = sprintf( '%s status --porcelain --untracked-files=all -- %s', // Git command 'C:/Program Files (x86)/Git/bin/git.exe', // Git executable 'D:/home/aldo/git/test with whitespace' // Directory ); // $command = 'C:/Program Files (x86)/Git/bin/git.exe status --porcelain --untracked-files=all -- D:/home/aldo/git/test with whitespace'; $proc = proc_open( $command, array ( array ( pipe, r ), array ( pipe, w ), array ( pipe, w ) ), $pipes ); echo stream_get_contents( $pipes[2] ); // Outputs: 'C:/Program' is not recognized as an internal or external command, // operable program or batch file. ? Expected result: proc_open read the quotes correctly and manages to run git-status smoothly Actual result: -- 'C:/Program' is not recognized as an internal or external command, operable program or batch file. -- Edit bug report at https://bugs.php.net/bug.php?id=60181edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60181r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60181r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60181r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60181r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60181r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60181r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60181r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60181r=needscript Try newer version: https://bugs.php.net/fix.php?id=60181r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60181r=support Expected behavior: https://bugs.php.net/fix.php?id=60181r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60181r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60181r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60181r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60181r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60181r=dst IIS Stability: https://bugs.php.net/fix.php?id=60181r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60181r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60181r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60181r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60181r=mysqlcfg
Bug #60173 [Opn-Asn]: Wrong message on trait instantiation
Edit report at https://bugs.php.net/bug.php?id=60173edit=1
ID: 60173
Updated by: g...@php.net
Reported by:php-bugs at majkl578 dot cz
Summary:Wrong message on trait instantiation
-Status: Open
+Status: Assigned
Type: Bug
Package:Scripting Engine problem
PHP Version:5.4SVN-2011-10-29 (snap)
-Assigned To:
+Assigned To:gron
Block user comment: N
Private report: N
Previous Comments:
[2011-10-30 00:06:22] php-bugs at majkl578 dot cz
Description:
Wrong error message when trait is being instanciated using reflection or being
unserialized by unserialize().
Test script:
---
trait Test
{}
$rc = new ReflectionClass('Test');
$rc-newInstance();
Expected result:
Fatal error: Cannot instantiate trait Test in %s on line %d
Actual result:
--
Fatal error: Cannot instantiate abstract class Test in %s on line %d
--
Edit this bug report at https://bugs.php.net/bug.php?id=60173edit=1
[PHP-BUG] Bug #60182 [NEW]: Implicit call to spl_autoload_call() does not throw exceptions
From:
Operating system: Debian GNU/Linux
PHP version: 5.3.8
Package: SPL related
Bug Type: Bug
Bug description:Implicit call to spl_autoload_call() does not throw exceptions
Description:
Exceptions thrown from custom autoload function are not thrown outside the
spl_autoload_call() function when it is implicitly called on expressions
like
'A::someMethod();' and '$b = A::CONSTANT;', i.e. when accessing static
methods
and constants of the class.
Test script:
---
?php
function autoload($class)
{
debug_print_backtrace();
throw new Exception('Test message');
}
spl_autoload_register('autoload');
try {
A::$someVariable;
} catch (Exception $e) {
echo $e-getMessage() . \n;
}
try {
A::someMethod();
} catch (Exception $e) {
echo $e-getMessage() . \n;
}
Expected result:
#0 autoload(A)
#1 spl_autoload_call(A) called at [/tmp/1.php:12]
Test message
#0 autoload(A)
#1 spl_autoload_call(A) called at [/tmp/1.php:18]
Test message
Actual result:
--
#0 autoload(A)
#1 spl_autoload_call(A) called at [/tmp/1.php:12]
Test message
#0 autoload(A)
#1 spl_autoload_call(A) called at [/tmp/1.php:18]
PHP Fatal error: Class 'A' not found in /tmp/1.php on line 18
PHP Stack trace:
PHP 1. {main}() /tmp/1.php:0
--
Edit bug report at https://bugs.php.net/bug.php?id=60182edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=60182r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=60182r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=60182r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=60182r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=60182r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=60182r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=60182r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=60182r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=60182r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=60182r=support
Expected behavior:
https://bugs.php.net/fix.php?id=60182r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=60182r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=60182r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=60182r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=60182r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=60182r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=60182r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=60182r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=60182r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=60182r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=60182r=mysqlcfg
Bug #60181 [Opn]: proc_open fails to read quoted whitespaced directories in Windows
Edit report at https://bugs.php.net/bug.php?id=60181edit=1 ID: 60181 Updated by: paj...@php.net Reported by:php at aldomx dot com Summary:proc_open fails to read quoted whitespaced directories in Windows Status: Open Type: Bug Package:Program Execution Operating System: Windows 7 PHP Version:5.3.8 Block user comment: N Private report: N New Comment: Works just fine: ?php $descriptorspec = array( 1 = array(pipe, w), 2 = array(pipe, w) ); $cmd = 'c:\\test\\bin with space\\t.bat'; $process = proc_open($cmd, $descriptorspec, $pipes); echo stream_get_contents($pipes[1]); echo stream_get_contents($pipes[2]); $return_value = proc_close($process); echo command returned $return_value\n; where t.bat contains only dir for testing Previous Comments: [2011-10-31 22:05:01] php at aldomx dot com Description: Trying to execute via proc_open: C:/Program Files (x86)/Git/bin/git.exe status --porcelain --untracked-files=all -- D:/home/aldo/git/test whitespace is like not using them, since the result of STDERR is: 'C:/Program' is not recognized as an internal or external command, operable program or batch file. Test script: --- ?php $command = sprintf( '%s status --porcelain --untracked-files=all -- %s', // Git command 'C:/Program Files (x86)/Git/bin/git.exe', // Git executable 'D:/home/aldo/git/test with whitespace' // Directory ); // $command = 'C:/Program Files (x86)/Git/bin/git.exe status --porcelain --untracked-files=all -- D:/home/aldo/git/test with whitespace'; $proc = proc_open( $command, array ( array ( pipe, r ), array ( pipe, w ), array ( pipe, w ) ), $pipes ); echo stream_get_contents( $pipes[2] ); // Outputs: 'C:/Program' is not recognized as an internal or external command, // operable program or batch file. ? Expected result: proc_open read the quotes correctly and manages to run git-status smoothly Actual result: -- 'C:/Program' is not recognized as an internal or external command, operable program or batch file. -- Edit this bug report at https://bugs.php.net/bug.php?id=60181edit=1
Bug #60181 [Opn]: proc_open fails to read quoted whitespaced directories in Windows
Edit report at https://bugs.php.net/bug.php?id=60181edit=1 ID: 60181 User updated by:php at aldomx dot com Reported by:php at aldomx dot com Summary:proc_open fails to read quoted whitespaced directories in Windows Status: Open Type: Bug Package:Program Execution Operating System: Windows 7 PHP Version:5.3.8 Block user comment: N Private report: N New Comment: Sorry, I forgot to specify when you use 2 or more quoted arguments (in my example git directory in program files and working directory) Previous Comments: [2011-10-31 22:43:35] paj...@php.net Works just fine: ?php $descriptorspec = array( 1 = array(pipe, w), 2 = array(pipe, w) ); $cmd = 'c:\\test\\bin with space\\t.bat'; $process = proc_open($cmd, $descriptorspec, $pipes); echo stream_get_contents($pipes[1]); echo stream_get_contents($pipes[2]); $return_value = proc_close($process); echo command returned $return_value\n; where t.bat contains only dir for testing [2011-10-31 22:05:01] php at aldomx dot com Description: Trying to execute via proc_open: C:/Program Files (x86)/Git/bin/git.exe status --porcelain --untracked-files=all -- D:/home/aldo/git/test whitespace is like not using them, since the result of STDERR is: 'C:/Program' is not recognized as an internal or external command, operable program or batch file. Test script: --- ?php $command = sprintf( '%s status --porcelain --untracked-files=all -- %s', // Git command 'C:/Program Files (x86)/Git/bin/git.exe', // Git executable 'D:/home/aldo/git/test with whitespace' // Directory ); // $command = 'C:/Program Files (x86)/Git/bin/git.exe status --porcelain --untracked-files=all -- D:/home/aldo/git/test with whitespace'; $proc = proc_open( $command, array ( array ( pipe, r ), array ( pipe, w ), array ( pipe, w ) ), $pipes ); echo stream_get_contents( $pipes[2] ); // Outputs: 'C:/Program' is not recognized as an internal or external command, // operable program or batch file. ? Expected result: proc_open read the quotes correctly and manages to run git-status smoothly Actual result: -- 'C:/Program' is not recognized as an internal or external command, operable program or batch file. -- Edit this bug report at https://bugs.php.net/bug.php?id=60181edit=1
Bug #60173 [Asn-Csd]: Wrong message on trait instantiation
Edit report at https://bugs.php.net/bug.php?id=60173edit=1
ID: 60173
Updated by: g...@php.net
Reported by:php-bugs at majkl578 dot cz
Summary:Wrong message on trait instantiation
-Status: Assigned
+Status: Closed
Type: Bug
Package:Scripting Engine problem
PHP Version:5.4SVN-2011-10-29 (snap)
Assigned To:gron
Block user comment: N
Private report: N
New Comment:
This bug has been fixed in SVN.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
For Windows:
http://windows.php.net/snapshots/
Thank you for the report, and for helping us make PHP better.
Fixed with SVN rev. 318621.
Previous Comments:
[2011-10-31 22:58:56] g...@php.net
Automatic comment from SVN on behalf of gron
Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=318621
Log: Fixed Bug #60173 (Wrong error message on reflective trait instantiation)
[2011-10-30 00:06:22] php-bugs at majkl578 dot cz
Description:
Wrong error message when trait is being instanciated using reflection or being
unserialized by unserialize().
Test script:
---
trait Test
{}
$rc = new ReflectionClass('Test');
$rc-newInstance();
Expected result:
Fatal error: Cannot instantiate trait Test in %s on line %d
Actual result:
--
Fatal error: Cannot instantiate abstract class Test in %s on line %d
--
Edit this bug report at https://bugs.php.net/bug.php?id=60173edit=1
Bug #60145 [Opn-Asn]: interface + use trait yields error for the abstract class?
Edit report at https://bugs.php.net/bug.php?id=60145edit=1
ID: 60145
Updated by: g...@php.net
Reported by:ninzya at inbox dot lv
Summary:interface + use trait yields error for the abstract
class?
-Status: Open
+Status: Assigned
Type: Bug
Package:Scripting Engine problem
Operating System: Any
PHP Version:5.4.0beta2
-Assigned To:
+Assigned To:gron
Block user comment: N
Private report: N
Previous Comments:
[2011-10-26 20:28:38] ninzya at inbox dot lv
Description:
The code in the test script contains one trait and an interface, that uses this
trait (use TestTrait). What I was trying to do here is to see how PHP behaves
if
i include use statement inside interface definition.
Suprisingly, test script produces very interesting result - I get a fatal error
with the following text: Class TestInterface contains 1 abstract method and
must
therefore be declared abstract or implement the remaining methods
(TestInterface::b). It looks like PHP's compiler messes up when I mix
interfaces
together with use statement and somehow treats TestInterface as an abstract
class.
I didn't go deeper to look into the problem as it's pretty clear that something
is
wrong here. In my opinion, PHP should not allow usage of use statment inside
interface defitions.
Test script:
---
trait TestTrait {
}
interface TestInterface {
use TestTrait;
public function b();
}
Expected result:
PHP Fatal error: use of use statement in interfaces is not allowed.
Actual result:
--
PHP Fatal error: Class TestInterface contains 1 abstract method and must
therefore
be declared abstract or implement the remaining methods (TestInterface::b).
--
Edit this bug report at https://bugs.php.net/bug.php?id=60145edit=1
Bug #60181 [Opn-Fbk]: proc_open fails to read quoted whitespaced directories in Windows
Edit report at https://bugs.php.net/bug.php?id=60181edit=1 ID: 60181 Updated by: paj...@php.net Reported by:php at aldomx dot com Summary:proc_open fails to read quoted whitespaced directories in Windows -Status: Open +Status: Feedback Type: Bug Package:Program Execution Operating System: Windows 7 PHP Version:5.3.8 Block user comment: N Private report: N New Comment: Have you tries to use escape shell args? Previous Comments: [2011-10-31 22:51:41] php at aldomx dot com Sorry, I forgot to specify when you use 2 or more quoted arguments (in my example git directory in program files and working directory) [2011-10-31 22:43:35] paj...@php.net Works just fine: ?php $descriptorspec = array( 1 = array(pipe, w), 2 = array(pipe, w) ); $cmd = 'c:\\test\\bin with space\\t.bat'; $process = proc_open($cmd, $descriptorspec, $pipes); echo stream_get_contents($pipes[1]); echo stream_get_contents($pipes[2]); $return_value = proc_close($process); echo command returned $return_value\n; where t.bat contains only dir for testing [2011-10-31 22:05:01] php at aldomx dot com Description: Trying to execute via proc_open: C:/Program Files (x86)/Git/bin/git.exe status --porcelain --untracked-files=all -- D:/home/aldo/git/test whitespace is like not using them, since the result of STDERR is: 'C:/Program' is not recognized as an internal or external command, operable program or batch file. Test script: --- ?php $command = sprintf( '%s status --porcelain --untracked-files=all -- %s', // Git command 'C:/Program Files (x86)/Git/bin/git.exe', // Git executable 'D:/home/aldo/git/test with whitespace' // Directory ); // $command = 'C:/Program Files (x86)/Git/bin/git.exe status --porcelain --untracked-files=all -- D:/home/aldo/git/test with whitespace'; $proc = proc_open( $command, array ( array ( pipe, r ), array ( pipe, w ), array ( pipe, w ) ), $pipes ); echo stream_get_contents( $pipes[2] ); // Outputs: 'C:/Program' is not recognized as an internal or external command, // operable program or batch file. ? Expected result: proc_open read the quotes correctly and manages to run git-status smoothly Actual result: -- 'C:/Program' is not recognized as an internal or external command, operable program or batch file. -- Edit this bug report at https://bugs.php.net/bug.php?id=60181edit=1
Bug #60181 [Fbk-Opn]: proc_open fails to read quoted whitespaced directories in Windows
Edit report at https://bugs.php.net/bug.php?id=60181edit=1 ID: 60181 User updated by:php at aldomx dot com Reported by:php at aldomx dot com Summary:proc_open fails to read quoted whitespaced directories in Windows -Status: Feedback +Status: Open Type: Bug Package:Program Execution Operating System: Windows 7 PHP Version:5.3.8 Block user comment: N Private report: N New Comment: Yes, same result Previous Comments: [2011-10-31 23:08:37] paj...@php.net Have you tries to use escape shell args? [2011-10-31 22:51:41] php at aldomx dot com Sorry, I forgot to specify when you use 2 or more quoted arguments (in my example git directory in program files and working directory) [2011-10-31 22:43:35] paj...@php.net Works just fine: ?php $descriptorspec = array( 1 = array(pipe, w), 2 = array(pipe, w) ); $cmd = 'c:\\test\\bin with space\\t.bat'; $process = proc_open($cmd, $descriptorspec, $pipes); echo stream_get_contents($pipes[1]); echo stream_get_contents($pipes[2]); $return_value = proc_close($process); echo command returned $return_value\n; where t.bat contains only dir for testing [2011-10-31 22:05:01] php at aldomx dot com Description: Trying to execute via proc_open: C:/Program Files (x86)/Git/bin/git.exe status --porcelain --untracked-files=all -- D:/home/aldo/git/test whitespace is like not using them, since the result of STDERR is: 'C:/Program' is not recognized as an internal or external command, operable program or batch file. Test script: --- ?php $command = sprintf( '%s status --porcelain --untracked-files=all -- %s', // Git command 'C:/Program Files (x86)/Git/bin/git.exe', // Git executable 'D:/home/aldo/git/test with whitespace' // Directory ); // $command = 'C:/Program Files (x86)/Git/bin/git.exe status --porcelain --untracked-files=all -- D:/home/aldo/git/test with whitespace'; $proc = proc_open( $command, array ( array ( pipe, r ), array ( pipe, w ), array ( pipe, w ) ), $pipes ); echo stream_get_contents( $pipes[2] ); // Outputs: 'C:/Program' is not recognized as an internal or external command, // operable program or batch file. ? Expected result: proc_open read the quotes correctly and manages to run git-status smoothly Actual result: -- 'C:/Program' is not recognized as an internal or external command, operable program or batch file. -- Edit this bug report at https://bugs.php.net/bug.php?id=60181edit=1
Bug #60181 [Opn]: proc_open fails to read quoted whitespaced directories in Windows
Edit report at https://bugs.php.net/bug.php?id=60181edit=1 ID: 60181 User updated by:php at aldomx dot com Reported by:php at aldomx dot com Summary:proc_open fails to read quoted whitespaced directories in Windows Status: Open Type: Bug Package:Program Execution Operating System: Windows 7 PHP Version:5.3.8 Block user comment: N Private report: N New Comment: As additional information, using the same string with exec(), system() or passthru() works fine, proc_open() is the only one with this issue. Previous Comments: [2011-10-31 23:13:03] php at aldomx dot com Yes, same result [2011-10-31 23:08:37] paj...@php.net Have you tries to use escape shell args? [2011-10-31 22:51:41] php at aldomx dot com Sorry, I forgot to specify when you use 2 or more quoted arguments (in my example git directory in program files and working directory) [2011-10-31 22:43:35] paj...@php.net Works just fine: ?php $descriptorspec = array( 1 = array(pipe, w), 2 = array(pipe, w) ); $cmd = 'c:\\test\\bin with space\\t.bat'; $process = proc_open($cmd, $descriptorspec, $pipes); echo stream_get_contents($pipes[1]); echo stream_get_contents($pipes[2]); $return_value = proc_close($process); echo command returned $return_value\n; where t.bat contains only dir for testing [2011-10-31 22:05:01] php at aldomx dot com Description: Trying to execute via proc_open: C:/Program Files (x86)/Git/bin/git.exe status --porcelain --untracked-files=all -- D:/home/aldo/git/test whitespace is like not using them, since the result of STDERR is: 'C:/Program' is not recognized as an internal or external command, operable program or batch file. Test script: --- ?php $command = sprintf( '%s status --porcelain --untracked-files=all -- %s', // Git command 'C:/Program Files (x86)/Git/bin/git.exe', // Git executable 'D:/home/aldo/git/test with whitespace' // Directory ); // $command = 'C:/Program Files (x86)/Git/bin/git.exe status --porcelain --untracked-files=all -- D:/home/aldo/git/test with whitespace'; $proc = proc_open( $command, array ( array ( pipe, r ), array ( pipe, w ), array ( pipe, w ) ), $pipes ); echo stream_get_contents( $pipes[2] ); // Outputs: 'C:/Program' is not recognized as an internal or external command, // operable program or batch file. ? Expected result: proc_open read the quotes correctly and manages to run git-status smoothly Actual result: -- 'C:/Program' is not recognized as an internal or external command, operable program or batch file. -- Edit this bug report at https://bugs.php.net/bug.php?id=60181edit=1
[PHP-BUG] Bug #60183 [NEW]: Bug resulting in out of sync ftp responses
From:
Operating system: All
PHP version: 5.3.8
Package: FTP related
Bug Type: Bug
Bug description:Bug resulting in out of sync ftp responses
Description:
Our servers make several hundred FTP-connections via PHP every day. About
one
out of every thousand connections PHP throws a warning with a
server-response
that is not even related to the executed command.
I've looked into the sourcecode and found a bug in the core of the ftp
extension. This bug appears whenever the ftp-server sends an extra response
that
PHP was not expecting, resulting in the response-buffer permanently running
out
of sync. Because of this, PHP will keep reading the wrong response lines
(and
thus often receiving the wrong ftp status codes) and will report most ftp
commands as failed after this.
Looking at different complaints scatterred across the internet about
receiving
unexpected responses from the PHP FTP extension after receiving 1 warning,
this
bug has been bugging people for quite some time now. Some of the current
ftp-
bugreports are a direct result of this bug.
Bugfix:
Clearing the 'extra' buffer object from the last response, before sending a
new
command.
# diff -urN ftp_old.c ftp.c
--- ftp_old.c 2011-11-01 00:28:05.0 +0100
+++ ftp.c 2011-11-01 00:29:29.0 +0100
@@ -1122,6 +1122,9 @@
data = ftp-outbuf;
+ /* Clear the extra-lines buffer */
+ ftp-extra = NULL;
+
if (my_send(ftp, ftp-fd, data, size) != size) {
return 0;
}
Test script:
---
How to reproduce:
Let the ftp-server send an extra (unexpected) server response, or simulate
one:
diff -urN ftp_old.c ftp.c
--- ftp_old.c 2011-11-01 00:28:05.0 +0100
+++ ftp.c 2011-11-01 01:07:34.0 +0100
@@ -1294,6 +1294,19 @@
#if HAVE_OPENSSL_EXT
}
#endif
+
+ /* Simulate an extra unexpected server command
+ in this case right after entering passive mode (code 227) */
+ char cmd[] = 200 OK.\n;
+ if (nr_bytes 0)
+ {
+ if (!strncmp(buf, 227 , 4))
+ {
+ strcat(ftp-inbuf, cmd);
+ nr_bytes += sizeof(cmd)-1;
+ }
+ }
+
return (nr_bytes);
}
/* }}} */
Expected result:
Expected result:
A warning.
Actual result:
--
Actual result:
A warning, but all commands followed by the last one are running out of
sync/failing. Also the warning thrown shows the wrong server response since
the
buffer is running out of sync.
--
Edit bug report at https://bugs.php.net/bug.php?id=60183edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=60183r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=60183r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=60183r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=60183r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=60183r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=60183r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=60183r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=60183r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=60183r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=60183r=support
Expected behavior:
https://bugs.php.net/fix.php?id=60183r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=60183r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=60183r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=60183r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=60183r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=60183r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=60183r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=60183r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=60183r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=60183r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=60183r=mysqlcfg
Bug #60145 [Asn-Csd]: interface + use trait yields error for the abstract class?
Edit report at https://bugs.php.net/bug.php?id=60145edit=1
ID: 60145
Updated by: g...@php.net
Reported by:ninzya at inbox dot lv
Summary:interface + use trait yields error for the abstract
class?
-Status: Assigned
+Status: Closed
Type: Bug
Package:Scripting Engine problem
Operating System: Any
PHP Version:5.4.0beta2
Assigned To:gron
Block user comment: N
Private report: N
New Comment:
This bug has been fixed in SVN.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
For Windows:
http://windows.php.net/snapshots/
Thank you for the report, and for helping us make PHP better.
Fixed with SVN rev 318625.
Previous Comments:
[2011-11-01 00:39:05] g...@php.net
Automatic comment from SVN on behalf of gron
Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=318625
Log: Fixed Bug #60145 (Usage of trait's use statement inside interfaces not
properly checked.)
[2011-10-26 20:28:38] ninzya at inbox dot lv
Description:
The code in the test script contains one trait and an interface, that uses this
trait (use TestTrait). What I was trying to do here is to see how PHP behaves
if
i include use statement inside interface definition.
Suprisingly, test script produces very interesting result - I get a fatal error
with the following text: Class TestInterface contains 1 abstract method and
must
therefore be declared abstract or implement the remaining methods
(TestInterface::b). It looks like PHP's compiler messes up when I mix
interfaces
together with use statement and somehow treats TestInterface as an abstract
class.
I didn't go deeper to look into the problem as it's pretty clear that something
is
wrong here. In my opinion, PHP should not allow usage of use statment inside
interface defitions.
Test script:
---
trait TestTrait {
}
interface TestInterface {
use TestTrait;
public function b();
}
Expected result:
PHP Fatal error: use of use statement in interfaces is not allowed.
Actual result:
--
PHP Fatal error: Class TestInterface contains 1 abstract method and must
therefore
be declared abstract or implement the remaining methods (TestInterface::b).
--
Edit this bug report at https://bugs.php.net/bug.php?id=60145edit=1
[PHP-BUG] Bug #60184 [NEW]: Exception stack frame text is misleading/incorrect
From:
Operating system:
PHP version: Irrelevant
Package: *General Issues
Bug Type: Bug
Bug description:Exception stack frame text is misleading/incorrect
Description:
The exception stack frame is created on line 2, however, it's thrown on
line 3.
Perhaps this text should be changed to instantiated ... on line 2
instead.
As a related issue, if you had an exception factory, this would cause
issues to no
end in that you cannot see the line number when the exception really was
thrown,
you would only see the stack from inside the factory.
Test script:
---
?php
$e = new Exception();
throw $e;
?
Expected result:
Fatal error: Uncaught exception 'Exception' in /code/PRdMIg:2 Stack trace:
#0
{main} thrown in /code/PRdMIg on line 3
OR
Fatal error: Uncaught exception 'Exception' in /code/PRdMIg:2 Stack trace:
#0
{main} instantiated in /code/PRdMIg on line 2
Actual result:
--
Fatal error: Uncaught exception 'Exception' in /code/PRdMIg:2 Stack trace:
#0
{main} thrown in /code/PRdMIg on line 2
--
Edit bug report at https://bugs.php.net/bug.php?id=60184edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=60184r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=60184r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=60184r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=60184r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=60184r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=60184r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=60184r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=60184r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=60184r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=60184r=support
Expected behavior:
https://bugs.php.net/fix.php?id=60184r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=60184r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=60184r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=60184r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=60184r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=60184r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=60184r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=60184r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=60184r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=60184r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=60184r=mysqlcfg
