Bug #55222 [Com]: Fatal Error disappears when using paranthesis
Edit report at https://bugs.php.net/bug.php?id=55222edit=1 ID: 55222 Comment by: tom at kera dot name Reported by:hanskrentel at yahoo dot de Summary:Fatal Error disappears when using paranthesis Status: Verified Type: Bug Package:Scripting Engine problem Operating System: Linux PHP Version:5.3.6 Block user comment: N Private report: N New Comment: cataphract, this bug report came out of that Stack Overflow post. I don't think that the Stack Overflow post resolves it in any useful way. Previous Comments: [2011-08-24 08:56:18] hanskrentel at yahoo dot de I assume you want to say that the linked answer explicitly explains the problem. Should we make use of this feature when programming PHP or not? [2011-07-29 09:56:38] cataphr...@php.net See http://stackoverflow.com/questions/6726589/parentheses-altering-semantics-of-function-call-result/6732876#6732876 [2011-07-27 16:34:24] hanskrentel at yahoo dot de I can only remind again that the first comment from php.net obviously misread this report. I am _missing_ the fatal error. [2011-07-19 08:10:56] hanskrentel at yahoo dot de Actually I'm concerned that reset( (get_array()) ); does _not_ give a fatal error. This contradicts the last comment There's really no way to get around that [getting a fatal error]. Why does it not give a fatal error? There is no variable. [2011-07-18 22:21:36] ahar...@php.net reset() requires a variable that can be passed by reference. There's really no way to get around that, hence the fatal error. 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=55222 -- Edit this bug report at https://bugs.php.net/bug.php?id=55222edit=1
Bug #55655 [Opn]: Use ctlib 15.5 64bits failed
Edit report at https://bugs.php.net/bug.php?id=55655edit=1
ID: 55655
User updated by:michel dot payan at gmail dot com
Reported by:michel dot payan at gmail dot com
Summary:Use ctlib 15.5 64bits failed
Status: Open
Type: Bug
Package:Sybase-ct (ctlib) related
Operating System: Linux ReadHat 5.3 x86_64
-PHP Version:5.3.8
+PHP Version:5.2.17
Block user comment: N
Private report: N
New Comment:
Connexion work but queries not ...
Previous Comments:
[2011-09-09 14:59:01] michel dot payan at gmail dot com
I see that we can modify the file ext/sybase_ct/config.m4, but i can't know the
procedure to take this modification into account.
Is anyone can help me ? (phpize ...).
[2011-09-09 14:13:26] michel dot payan at gmail dot com
Description:
Y want to use PHP 5.2.17 with lib DB 1.7.14 for Oracle (11.2) and Sybase (15.5)
in a 64 bits environnement.
All work for Oracle.
Red Hat Enterprise Linux Server release 5.3 (Tikanga)
Linux linnt27.tlt 2.6.18-128.el5 #1 SMP Wed Dec 17 11:41:38 EST 2008 x86_64
x86_64 x86_64 GNU/Linux
Sybase CTISQL Utility/15.5/P-EBF17747 ESD #4/DRV.15.5.1/Linux Intel/Linux
2.6.9-55.ELsmp x86_64/BUILD1550-006/OPT/Sun Apr 18 01:03:56 2010
For Sybase i haved the knowed problem to take 64bits libraries ...
So i have manually modified the Makefile to put the good libraries, compilation
and installation work (make and make install), but have errors when i want to
execute sybase query !
Used config command:
cd $HOME/php-5.2.17
./configure --prefix=/home/oracle/php5.2.17
--with-apxs2=/home/oracle/apache/bin/apxs \
--disable-short-tags --with-zlib --enable-calendar --enable-ftp --with-gd
--with-freetype-dir \
--with-iconv --with-gettext --with-jpeg-dir=/usr/lib --with-png-dir
--enable-mbstring --enable-pcntl \
--enable-soap --enable-zip --with-pear --enable-bcmath --without-sqlite
--without-pdo-sqlite \
--enable-sigchild --with-libdir=lib64 --enable-gd-native-ttf --enable-xmlwriter
--without-readline --with-gd --with-xpm-dir --enable-exif \
--with-oci8=$ORACLE_HOME --with-pdo-oci=$ORACLE_HOME \
--with-sybase-ct=$SYBASE/$SYBASE_OCS
Manually modify Makefile to put:
CFLAGS = $(CFLAGS_CLEAN) -DSYB_LP64
EXTRA_LIBS = -lcrypt -lz -lsybcs64 -lsybct64 -lsybcomn64 -lsybintl64 -lsybtcl64
...
So, when i test connexion with the test.php script i have this error:
Fail to connect:
Erreur: DB Error: no database selected
DB Error: no database selected
So, if i change my dsn to sybase://indsyb_maj:psswd@DBSYBIND, the connection
work but i have this error:
Fatal error: Call to undefined method DB_Error::numRows() in
/home/oracle/SQWareWeb/v2.0/test.php on line 41
So, if i comment the line that call $res-numRows(), i have:
DB Error: unknown error
What the good solution to compile PHP with Sybase 64bits ? I have to stand in
PHP 5.2 ...
Test script:
---
?php
include('DB.php');
echo pre;
$dsn = sybase://indsyb_maj:psswd@DBSYBIND/syb_inddba;
$options = array('debug' = 2, 'portability' = DB_PORTABILITY_ALL);
$db = DB::connect($dsn,$options);
if (DB::isError($db))
{
echo dsn=$dsn\n;
echo Fail to connect:\n;
echo Erreur: .$db-getMessage().\n;
die ($db-getMessage());
}
$query = select distinct DataServer from tedt_Repository where Status!='OFF'
order by 1;
$res = $db-query($query);
echo Numrows: .$res-numRows().\n;
if (DB::isError($res))
{
die ($res-getMessage());
}
while ($record = $res-fetchRow(DB_FETCHMODE_ASSOC))
{
echo nl2br(print_r($record,true)).\n;
}
$res-free();
$db-disconnect();
?
--
Edit this bug report at https://bugs.php.net/bug.php?id=55655edit=1
Bug #54798 [Asn-Csd]: Segfault when CURLOPT_STDERR file pointer is closed before calling curl_exec
Edit report at https://bugs.php.net/bug.php?id=54798edit=1 ID: 54798 Updated by: bj...@php.net Reported by:sh...@php.net Summary:Segfault when CURLOPT_STDERR file pointer is closed before calling curl_exec -Status: Assigned +Status: Closed Type: Bug Package:cURL related Operating System: Ubuntu Linux 11.04 x86 PHP Version:trunk-SVN-2011-05-17 (SVN) Assigned To:bjori Block user comment: N Private report: N New Comment: http://svn.php.net/viewvc?view=revisionrevision=316511 Previous Comments: [2011-09-09 11:36:50] sh...@php.net The fix was wrong, reopening bug, see discussion over here: http://news.php.net/php.cvs/66389 and here http://news.php.net/php.cvs/66399 [2011-09-08 14:37:37] bj...@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/. For Windows: http://windows.php.net/snapshots/ Thank you for the report, and for helping us make PHP better. [2011-09-08 14:37:05] bj...@php.net Automatic comment from SVN on behalf of bjori Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=316417 Log: Fixed bug#54798Segfault when CURLOPT_STDERR file pointer is closed before calling curl_exec [2011-05-17 16:25:32] sh...@php.net Description: Related to http://bugs.php.net/bug.php?id=48203 Curl crashes when CURLOPT_STDERR file pointer is closed before calling curl_exec(), i.e. $fp = fopen(dirname(__FILE__) . '/bug48203.tmp', 'w'); $ch = curl_init(); curl_setopt($ch, CURLOPT_VERBOSE, 1); curl_setopt($ch, CURLOPT_STDERR, $fp); curl_setopt($ch, CURLOPT_URL, getenv(PHP_CURL_HTTP_REMOTE_SERVER)); fclose($fp); // -- premature close of $fp caused a crash! curl_exec($ch); // segfault Error is reproduced on latest svn php5.3, php5.4 and trunk Fix is also attached here. Test script: --- Full test script is available here: http://svn.php.net/viewvc/php/php-src/trunk/ext/curl/tests/bug48203.phpt?view=markup Expected result: No segfault, see test script Actual result: -- Segfault -- Edit this bug report at https://bugs.php.net/bug.php?id=54798edit=1
Req #55659 [Com]: Correcting phpt test files for current configurations
Edit report at https://bugs.php.net/bug.php?id=55659edit=1 ID: 55659 Comment by: mar...@php.net Reported by:lester at lsces dot co dot uk Summary:Correcting phpt test files for current configurations Status: Open Type: Feature/Change Request Package:InterBase related Operating System: Linux ( should be OS agnostic ) PHP Version:5.3.8 Block user comment: N Private report: N New Comment: fixed in 5.4 and trunk Previous Comments: [2011-09-12 09:36:22] mar...@php.net Automatic comment from SVN on behalf of mariuz Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=316515 Log: fixes #55659 also the 006 firebird test [2011-09-09 20:32:24] lester at lsces dot co dot uk Description: Test 003 result default field names have changed over time. Not sure how far bake the change goes database version wise. Test 006 is demonstrating how rounding of integers works rather than flagging an real error. 7.5 should always round up to 8, so that should be expected in the result set. Test script: --- Patch is for the test script ... -- Edit this bug report at https://bugs.php.net/bug.php?id=55659edit=1
Req #55659 [Opn-Csd]: Correcting phpt test files for current configurations
Edit report at https://bugs.php.net/bug.php?id=55659edit=1 ID: 55659 Updated by: mar...@php.net Reported by:lester at lsces dot co dot uk Summary:Correcting phpt test files for current configurations -Status: Open +Status: Closed Type: Feature/Change Request Package:InterBase related Operating System: Linux ( should be OS agnostic ) PHP Version:5.3.8 -Assigned To: +Assigned To:mariuz Block user comment: N Private report: N Previous Comments: [2011-09-12 09:40:47] mar...@php.net Automatic comment from SVN on behalf of mariuz Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=316516 Log: fixes bug #55659 adn 006 test for firebird driver [2011-09-12 09:40:01] mar...@php.net fixed in 5.4 and trunk [2011-09-12 09:36:22] mar...@php.net Automatic comment from SVN on behalf of mariuz Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=316515 Log: fixes #55659 also the 006 firebird test [2011-09-09 20:32:24] lester at lsces dot co dot uk Description: Test 003 result default field names have changed over time. Not sure how far bake the change goes database version wise. Test 006 is demonstrating how rounding of integers works rather than flagging an real error. 7.5 should always round up to 8, so that should be expected in the result set. Test script: --- Patch is for the test script ... -- Edit this bug report at https://bugs.php.net/bug.php?id=55659edit=1
Bug #42266 [Asn-Fbk]: BLOB functions do not work on 64bit systems
Edit report at https://bugs.php.net/bug.php?id=42266edit=1 ID: 42266 Updated by: mar...@php.net Reported by:karasek at ceskyserver dot cz Summary:BLOB functions do not work on 64bit systems -Status: Assigned +Status: Feedback Type: Bug Package:InterBase related Operating System: Linux 64-bit PHP Version:5.2.4 Assigned To:abies Block user comment: N Private report: N New Comment: Please try using this snapshot: http://snaps.php.net/php5.4-latest.tar.gz For Windows: http://windows.php.net/snapshots/ Previous Comments: [2009-09-07 10:11:20] lester at lsces dot co dot uk Currently I have PHP5.2.9 and 10 running without any blob id problem on a number of 64 bit distributions. And 5.3 running on Vista64 as well again without displaying this bug. So I think we need a lot more information from people who DO have this problem still [2009-07-23 09:30:41] andre at spiceware dot co dot za I can confirm that php 5.2.1 was the last working version for BLOBS on 64 bit operating system as I have downloaded all the versions since then to check each one. I have recently compiled 5.3.0 with no joy too! [2009-06-08 10:10:57] lester at lsces dot co dot uk I think we needs some proper feedback on this problem. There WAS a problem with some builds of PHP from 5.2.0 to 5.2.5 relating to how the blob ID was handled after some re-engineering of the core PHP code. This resulted in a problem which was clearly visible when running ADOdb, since it could not access the BLOB_ID. Since 5.2.6 that problem has been fixed, and I'm currently running both windows and linux x64 machineswithout the back to get around the problem. So as far as I am concerned this bug has been cleared. So where are people still seeing it and how can we recreate that view of the problem? [2009-05-21 20:35:59] mkoeditz at gmx dot de Well, i've just installed openSUSE 10.3 with php 25.2.9 and Firebird 2.1. 32 bit system. Same error. So I think there is no focus on the platform but the php version. Regards Martin [2008-09-08 14:24:17] andre at spiceware dot co dot za I compiled PHP 5.2.6 from source tar ball for Linux this last weekend and also ended up with the BLOB error. This is still a problem. 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=42266 -- Edit this bug report at https://bugs.php.net/bug.php?id=42266edit=1
Req #26379 [Asn-Fbk]: ext/interbase: must be linked with -lcrypt under FreeBSD
Edit report at https://bugs.php.net/bug.php?id=26379edit=1 ID: 26379 Updated by: mar...@php.net Reported by:nicol at aokp dot ru Summary:ext/interbase: must be linked with -lcrypt under FreeBSD -Status: Assigned +Status: Feedback Type: Feature/Change Request Package:InterBase related Operating System: FreeBSD 4.9 PHP Version:4.3.4 Assigned To:mariuz Block user comment: N Private report: N New Comment: Please try using this snapshot: http://snaps.php.net/php5.4-latest.tar.gz For Windows: http://windows.php.net/snapshots/ Previous Comments: [2011-07-19 16:29:58] mar...@php.net To do test ./configure on newest freebsd stable 8.x but i don't think this bug can be reproduced anymore (firebird doesn't use lcrypt or the extension for it) [2003-11-24 03:11:13] nicol at aokp dot ru Description: php 4.3.4/5.0.0.Beta2 same bug configure fails when detecting Interbase(Firebird) under FreeBSD (undefined reference to 'crypt'), because configure checks crypt() in -lcrypt after checking isc_detach_database() in -lgds and test program was linke without -lcrypt. -- Edit this bug report at https://bugs.php.net/bug.php?id=26379edit=1
Bug #49955 [Opn-Bgs]: Warning: Unknown: Unable to complete network request
Edit report at https://bugs.php.net/bug.php?id=49955edit=1
ID: 49955
Updated by: mar...@php.net
Reported by:atendimento at n2g dot com dot br
Summary:Warning: Unknown: Unable to complete network request
-Status: Open
+Status: Bogus
Type: Bug
Package:InterBase related
Operating System: Windows
PHP Version:5.2.11
Block user comment: N
Private report: N
New Comment:
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
seems to be a network issue with that host
Previous Comments:
[2010-01-11 17:01:24] mapopa at gmail dot com
I have started windows xp in virtualbox and found why it doesn't work
on windows
dowloaded the php 5.2.12 http://www.php.net/get/php-5.2.12-
Win32.zip/from/a/mirror
unzip it in c:\php
enable interbase dll extension in php.ini and allow persistent
connection
installed firebird 2.1.3 stable from
http://www.firebirdsql.org/index.php?op=filesid=engine_213
allow the installer to create the lagacy gds32 and firebird client dll
in system folder
Delete the old gds32 (interbase 6.0.x dll) from php folder
it's very old and unsupported, this is why it doesn't work on windows
(persistent connection)
http://picasaweb.google.com/lh/photo/C_I1CJYsyZXrGLtNjDxVTg?
authkey=Gv1sRgCIeMif_wgf2N3wEfeat=directlink
[2010-01-11 14:26:22] mapopa at gmail dot com
also tested with
PHP 5.2.12 (cli)
[2010-01-11 13:57:13] mapopa at gmail dot com
Bug #49955 http://bugs.php.net/bug.php?id=49955 can be closed , i
have tested with php 5.3 latest snapshot
and firebird is on a remote host
in fact i have tested with two remote hosts one with firebird 2.1 and
one with firebird 2.5
I guess 1000 connections are enough to see if it's all ok
I got no error , it never reaches to die zone
cat 49955.php
?
$user='SYSDBA';
$password='masterkey';
$database=192.168.0.1:/var/lib/firebird/2.5/data/employee.fdb;
for ($i = 1; $i = 1000; $i++) {
echo $i;
$conFb = @ibase_pconnect($database, $user, $password)
or die(Error when trying to connect!);
}
?
also tested from apache the scripts dies only when it reaches max
execution time , as expected for default php is 30 seconds
lynx http://localhost/49955.php
php versions tested: 5.3.3 snapshot (cli) (built: Jan 11 2010
13:19:54)
and 5.3.1 rc2 (cli) (built: Nov 2 2009 17:22:21) + apache module
[2009-10-23 16:21:05] atendimento at n2g dot com dot br
Ok. I've updated my PHP to this version and the error keeps the same. I don't
know what else to do!
[2009-10-23 10:16:56] j...@php.net
Please try using this snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
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=49955
--
Edit this bug report at https://bugs.php.net/bug.php?id=49955edit=1
Bug #55642 [-Opn]: DateTime doesn't use default timezone
Edit report at https://bugs.php.net/bug.php?id=55642edit=1
ID: 55642
Updated by: bj...@php.net
Reported by:alex dot whitman at durham dot ac dot uk
Summary:DateTime doesn't use default timezone
-Status: To be documented
+Status: Open
Type: Bug
Package:Date/time related
Operating System: CentOS 5
PHP Version:5.3.8
Block user comment: N
Private report: N
Previous Comments:
[2011-09-08 17:03:14] der...@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.
@ sets the timezone to UTC, this should be documented at
http://uk3.php.net/manual/en/datetime.formats.compound.php
[2011-09-08 14:35:30] alex dot whitman at durham dot ac dot uk
Description:
DateTime doesn't appear to use the default timezone (set either in php.ini or
with date_default_timezone_set()).
It's currently BST in the UK and without calling setTimeZone() on a DateTime
object, format() will produce a date/time that is one hour behind.
If setTimeZone() is called on a DateTime object then the date/time produced by
format() is correct.
date() by itself uses the default timezone that has been set. For consistency,
DateTime should do also.
Test script:
---
pre
?php
date_default_timezone_set('Europe/London');
$now = time();
// Initialising with a timestamp, second DateTimeZone parameter would
be ignored.
$dt1 = new DateTime('@' . $now);
echo 'DateTime-format()', \t, $dt1-format('Y-m-d H:i:s T Z e');
echo \n;
$dt2 = new DateTime('@' . $now);
$dt2-setTimeZone(new DateTimeZone('Europe/London'));
echo 'DateTime-format()', \t, $dt2-format('Y-m-d H:i:s T Z e');
echo \n;
echo 'date()', \t\t\t, date('Y-m-d H:i:s T Z e', $now);
?
pre
Expected result:
$dt1-format() should use Europe/London as the timezone and show the correct
time for that timezone.
Actual result:
--
$dt1-format() shows +00:00 as the timezone and is an hour behind.
--
Edit this bug report at https://bugs.php.net/bug.php?id=55642edit=1
Bug #55554 [Com]: Trait methods overriding legacy constructors
Edit report at https://bugs.php.net/bug.php?id=4edit=1
ID: 4
Comment by: g...@php.net
Reported by:ryan at zuttonet dot com
Summary:Trait methods overriding legacy constructors
Status: Open
Type: Bug
Package:*Programming Data Structures
Operating System: Ubuntu
PHP Version:5.4.0alpha3
Block user comment: N
Private report: N
New Comment:
Hi Ryan:
I am sorry, I don't think I understand what inconsistency you are pointing out.
Could you elaborate on the problem?
(And please include the code you are referring to directly here. Just to make
it
easier for me
to know that we are talking about exactly the same code.)
What I understand is you want to provide the constructor with a trait, right?
Like this:
?php
trait MyTrait {
public function constructor() {
echo Foo\n;
}
}
class MyClass {
use MyTrait {
constructor as __construct;
}
}
class MyClass2 {
use MyTrait {
constructor as MyClass2;
}
}
echo MyClass constructor: ;
$o = new MyClass; // echos Foo
echo \nMyClass2 constructor: ;
$o = new MyClass2; // doesn't echo Foo
echo \n;
?
The problem I see here is that for MyClass2 the constructor does not actually
get registered
as a constructor but just as a normal method.
That seems to be an inconsistency that needs to be fixed.
Ok, now to the new vs. legacy constructors:
class Bar {
function Bar() {
echo BarBar new ctor\n;
}
function __construct() {
echo Bar new ctor\n;
}
}
$o = new Bar;
?
Switching the order of the definition of the constructors doesn't influence the
result,
__construct always wins.
Both your examples behaves identical to the situation if the __construct would
have been
defined directly in the class. So, where is the problem here?
It is not an inconsistency with how PHP behaves without traits, from what I can
see.
Ah, and please try the latest code in the SVN, I am not exactly sure whether I
changed
anything that could be related to that between alpha3 and now. But I doubt it.
Thanks
Stefan
Previous Comments:
[2011-08-31 15:52:43] ryan at zuttonet dot com
Apologies; the literal expected output for the provided test scripts should be:
this is a constructor
As this is the output when using __construct() in the class definition instead
of
a legacy-style constructor.
[2011-08-31 15:49:30] ryan at zuttonet dot com
Description:
For the sake of consistency, exactly one of the following should be implemented:
1. Trait methods should be able to override __construct definitions
2. Trait methods should not be able to override legacy constructor definitions
Currently, trait methods are not able to override __construct
definitions. Trait methods are able to override legacy constructor definitions.
Test script:
---
Here are two test cases that will reproduce the defect:
https://gist.github.com/1183844
Expected result:
A trait-level __construct method (or a trait-level method aliased as
__construct)
should not be able to override any type of constructor in a class
Actual result:
--
Fatal error: Call to private SomeClass::__construct() from invalid context
--
Edit this bug report at https://bugs.php.net/bug.php?id=4edit=1
Bug #55554 [Opn-Asn]: Trait methods overriding legacy constructors
Edit report at https://bugs.php.net/bug.php?id=4edit=1
ID: 4
Updated by: g...@php.net
Reported by:ryan at zuttonet dot com
Summary:Trait methods overriding legacy constructors
-Status: Open
+Status: Assigned
Type: Bug
-Package:*Programming Data Structures
+Package:Scripting Engine problem
Operating System: Ubuntu
PHP Version:5.4.0alpha3
-Assigned To:
+Assigned To:gron
Block user comment: N
Private report: N
Previous Comments:
[2011-09-12 10:47:22] g...@php.net
Hi Ryan:
I am sorry, I don't think I understand what inconsistency you are pointing out.
Could you elaborate on the problem?
(And please include the code you are referring to directly here. Just to make
it
easier for me
to know that we are talking about exactly the same code.)
What I understand is you want to provide the constructor with a trait, right?
Like this:
?php
trait MyTrait {
public function constructor() {
echo Foo\n;
}
}
class MyClass {
use MyTrait {
constructor as __construct;
}
}
class MyClass2 {
use MyTrait {
constructor as MyClass2;
}
}
echo MyClass constructor: ;
$o = new MyClass; // echos Foo
echo \nMyClass2 constructor: ;
$o = new MyClass2; // doesn't echo Foo
echo \n;
?
The problem I see here is that for MyClass2 the constructor does not actually
get registered
as a constructor but just as a normal method.
That seems to be an inconsistency that needs to be fixed.
Ok, now to the new vs. legacy constructors:
class Bar {
function Bar() {
echo BarBar new ctor\n;
}
function __construct() {
echo Bar new ctor\n;
}
}
$o = new Bar;
?
Switching the order of the definition of the constructors doesn't influence the
result,
__construct always wins.
Both your examples behaves identical to the situation if the __construct would
have been
defined directly in the class. So, where is the problem here?
It is not an inconsistency with how PHP behaves without traits, from what I can
see.
Ah, and please try the latest code in the SVN, I am not exactly sure whether I
changed
anything that could be related to that between alpha3 and now. But I doubt it.
Thanks
Stefan
[2011-08-31 15:52:43] ryan at zuttonet dot com
Apologies; the literal expected output for the provided test scripts should be:
this is a constructor
As this is the output when using __construct() in the class definition instead
of
a legacy-style constructor.
[2011-08-31 15:49:30] ryan at zuttonet dot com
Description:
For the sake of consistency, exactly one of the following should be implemented:
1. Trait methods should be able to override __construct definitions
2. Trait methods should not be able to override legacy constructor definitions
Currently, trait methods are not able to override __construct
definitions. Trait methods are able to override legacy constructor definitions.
Test script:
---
Here are two test cases that will reproduce the defect:
https://gist.github.com/1183844
Expected result:
A trait-level __construct method (or a trait-level method aliased as
__construct)
should not be able to override any type of constructor in a class
Actual result:
--
Fatal error: Call to private SomeClass::__construct() from invalid context
--
Edit this bug report at https://bugs.php.net/bug.php?id=4edit=1
Req #55613 [Com]: Feature: Trait checks type of consuming class
Edit report at https://bugs.php.net/bug.php?id=55613edit=1 ID: 55613 Comment by: g...@php.net Reported by:wil dot moore at wimoore dot com Summary:Feature: Trait checks type of consuming class Status: Open Type: Feature/Change Request Package:Class/Object related Operating System: Mac (Darwin 10.8.0 i386) PHP Version:5.4.0alpha3 Block user comment: N Private report: N New Comment: So far the community was opposed to 'requiring' interfaces from using classes. However, you can always express 'require' relationships to individual methods by adding them as abstract methods to the trait. From my point of view that is also the way to go, since traits do not preserve your invariants, and are meant for code reuse only. Thus, if you imply a certain invariants with an interface, that is not enforced by a trait. A trait can require a certain method to be available since it will be using it, and you might want that to be check at compile time, but a trait does not promise to obey a certain set of requirements on invariants. Please consider using composition and classes if you have strong requirements on how to interact with an object. Previous Comments: [2011-09-06 01:10:51] wil dot moore at wimoore dot com Description: For instance, one may require that the use of a trait requires that the consuming class must be of a certain type or implement a specific interface. An example is Doctrine2's ArrayCollection. One may want to write a utility trait that mixes in functionality that is useful to this type of Collection. This trait would work with ArrayCollections or its decedents but would throw an Exception (i.e. TraitConsumerIllegalTypeException) if attempting to use with other types of classes. -- Edit this bug report at https://bugs.php.net/bug.php?id=55613edit=1
[PHP-BUG] Bug #55671 [NEW]: clean up the php 6 references in run-tests.php
From: tyrael Operating system: PHP version: Irrelevant Package: *General Issues Bug Type: Bug Bug description:clean up the php 6 references in run-tests.php Description: there are mentions and special cases for working with php6, which isn't valid anymore. we should remove those(unicode string/binary string types), and there are some, which should be enabled for = 504000: magic_quotes, safe_mode check, as those are removed with 5.4 -- Edit bug report at https://bugs.php.net/bug.php?id=55671edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=55671r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=55671r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=55671r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=55671r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=55671r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=55671r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=55671r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=55671r=needscript Try newer version: https://bugs.php.net/fix.php?id=55671r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=55671r=support Expected behavior: https://bugs.php.net/fix.php?id=55671r=notwrong Not enough info: https://bugs.php.net/fix.php?id=55671r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=55671r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=55671r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=55671r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=55671r=dst IIS Stability: https://bugs.php.net/fix.php?id=55671r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=55671r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=55671r=float No Zend Extensions: https://bugs.php.net/fix.php?id=55671r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=55671r=mysqlcfg
Bug #55662 [Asn-Fbk]: test script cause seg fault
Edit report at https://bugs.php.net/bug.php?id=55662edit=1
ID: 55662
Updated by: and...@php.net
Reported by:larue...@php.net
Summary:test script cause seg fault
-Status: Assigned
+Status: Feedback
Type: Bug
Package:MySQLi related
Operating System: Linux 64bit
PHP Version:5.4SVN-2011-09-10 (SVN)
Assigned To:mysql
Block user comment: N
Private report: N
New Comment:
Hi,
can you provide me with info about the version of your MySQL Server and the
client library.
Thanks!
Previous Comments:
[2011-09-10 04:39:15] larue...@php.net
Description:
ext/mysqli/tests/mysqli_explain_metadata.phpt cause a segment fault(linked
against libmysql)
backtrace:
#0 0x00302af6ff20 in strlen () from /lib64/tls/libc.so.6
#1 0x007dbeb5 in add_property_string_ex (arg=0x2a99479160,
key=0xb68dec
catalog, key_len=8,
str=0x20200a3e6e6f6974 Address 0x20200a3e6e6f6974 out of bounds,
duplicate=1)
at /home/huixc/opensource/php-src/trunk/Zend/zend_API.c:1561
#2 0x005f9a35 in php_add_field_properties (value=0x2a99479160,
field=0x1000410)
at /home/huixc/opensource/php-src/trunk/ext/mysqli/mysqli_api.c:1060
#3 0x005f9d80 in zif_mysqli_fetch_fields (ht=1,
return_value=0x2a994bcf68, return_value_ptr=0x0, this_ptr=0x0,
return_value_used=1)
at /home/huixc/opensource/php-src/trunk/ext/mysqli/mysqli_api.c:1118
#4 0x0080e1b6 in zend_do_fcall_common_helper_SPEC
(execute_data=0x2a95fbc0e8)
at /home/huixc/opensource/php-src/trunk/Zend/zend_vm_execute.h:642
#5 0x0081491a in ZEND_DO_FCALL_SPEC_CONST_HANDLER
(execute_data=0x2a95fbc0e8)
at /home/huixc/opensource/php-src/trunk/Zend/zend_vm_execute.h:2215
#6 0x0080ceba in execute (op_array=0xff40d0) at
/home/huixc/opensource/php-src/trunk/Zend/zend_vm_execute.h:410
#7 0x007d559c in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /home/huixc/opensource/php-src/trunk/Zend/zend.c:1262
#8 0x0075698b in php_execute_script (primary_file=0x7fb230) at
/home/huixc/opensource/php-src/trunk/main/main.c:2388
#9 0x008f53f9 in do_cli (argc=2, argv=0x7fb518) at
/home/huixc/opensource/php-src/trunk/sapi/cli/php_cli.c:983
#10 0x008f629a in main (argc=2, argv=0x7fb518) at
/home/huixc/opensource/php-src/trunk/sapi/cli/php_cli.c:1356
f2,
(gdb) p *field
$2 = {name = 0x10007d0 possible_keys, org_name = 0x10007e0 , table =
0x10007c0 , org_table = 0x10007c8 , db = 0x10007b8 ,
catalog = 0x20200a3e6e6f6974 Address 0x20200a3e6e6f6974 out of bounds, def
=
0x0, length = 4096, max_length = 0,
name_length = 537542259, org_name_length = 1818311712, table_length =
1047748969, org_table_length = 762278761, db_length = 959789112,
catalog_length = 792474157, def_length = 1634298977, flags = 0, decimals =
31,
charsetnr = 8, type = MYSQL_TYPE_VAR_STRING,
extension = 0x61696c612f3c3130}
Test script:
---
ext/mysqli/tests/mysqli_explain_metadata.phpt
Expected result:
passed
Actual result:
--
seg fault
--
Edit this bug report at https://bugs.php.net/bug.php?id=55662edit=1
Bug #55661 [Asn-Bgs]: mysqli/tests/bug54674.phpt failed when link against libmysql
Edit report at https://bugs.php.net/bug.php?id=55661edit=1 ID: 55661 Updated by: and...@php.net Reported by:larue...@php.net Summary:mysqli/tests/bug54674.phpt failed when link against libmysql -Status: Assigned +Status: Bogus Type: Bug Package:MySQLi related Operating System: Linux PHP Version:trunk-SVN-2011-09-10 (SVN) Assigned To:mysql Block user comment: N Private report: N New Comment: This is a bug in libmysql, which does things which contradict with the documentation. Previous Comments: [2011-09-10 04:41:23] larue...@php.net ext/mysqli/tests/mysqli_last_insert_id.phpt also failed, with diff: 002+ [007] API id should have been reset to 0 because previous query was SELECT, got API 1, SQL 1 003+ [010] API id should have been reset to 0 because previous query was SELECT, got API 1, SQL 1 008+ [027] API id should have been reset to 0 because previous query failed, got API 4, SQL 4 [2011-09-10 04:07:23] larue...@php.net Description: mysqli/tests/bug54674.phpt failed when linked against libmysql Test script: --- none Expected result: PASS Actual result: -- FAIELD diff: 001+ bool(false) 001- bool(true) -- Edit this bug report at https://bugs.php.net/bug.php?id=55661edit=1
Bug #55662 [Fbk-Opn]: test script cause seg fault
Edit report at https://bugs.php.net/bug.php?id=55662edit=1
ID: 55662
Updated by: larue...@php.net
Reported by:larue...@php.net
Summary:test script cause seg fault
-Status: Feedback
+Status: Open
Type: Bug
Package:MySQLi related
Operating System: Linux 64bit
PHP Version:5.4SVN-2011-09-10 (SVN)
Assigned To:mysql
Block user comment: N
Private report: N
New Comment:
Server version: 5.1.30 Source distribution, libmysql is also built from 5.1.30
Previous Comments:
[2011-09-12 11:33:10] and...@php.net
Hi,
can you provide me with info about the version of your MySQL Server and the
client library.
Thanks!
[2011-09-10 04:39:15] larue...@php.net
Description:
ext/mysqli/tests/mysqli_explain_metadata.phpt cause a segment fault(linked
against libmysql)
backtrace:
#0 0x00302af6ff20 in strlen () from /lib64/tls/libc.so.6
#1 0x007dbeb5 in add_property_string_ex (arg=0x2a99479160,
key=0xb68dec
catalog, key_len=8,
str=0x20200a3e6e6f6974 Address 0x20200a3e6e6f6974 out of bounds,
duplicate=1)
at /home/huixc/opensource/php-src/trunk/Zend/zend_API.c:1561
#2 0x005f9a35 in php_add_field_properties (value=0x2a99479160,
field=0x1000410)
at /home/huixc/opensource/php-src/trunk/ext/mysqli/mysqli_api.c:1060
#3 0x005f9d80 in zif_mysqli_fetch_fields (ht=1,
return_value=0x2a994bcf68, return_value_ptr=0x0, this_ptr=0x0,
return_value_used=1)
at /home/huixc/opensource/php-src/trunk/ext/mysqli/mysqli_api.c:1118
#4 0x0080e1b6 in zend_do_fcall_common_helper_SPEC
(execute_data=0x2a95fbc0e8)
at /home/huixc/opensource/php-src/trunk/Zend/zend_vm_execute.h:642
#5 0x0081491a in ZEND_DO_FCALL_SPEC_CONST_HANDLER
(execute_data=0x2a95fbc0e8)
at /home/huixc/opensource/php-src/trunk/Zend/zend_vm_execute.h:2215
#6 0x0080ceba in execute (op_array=0xff40d0) at
/home/huixc/opensource/php-src/trunk/Zend/zend_vm_execute.h:410
#7 0x007d559c in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /home/huixc/opensource/php-src/trunk/Zend/zend.c:1262
#8 0x0075698b in php_execute_script (primary_file=0x7fb230) at
/home/huixc/opensource/php-src/trunk/main/main.c:2388
#9 0x008f53f9 in do_cli (argc=2, argv=0x7fb518) at
/home/huixc/opensource/php-src/trunk/sapi/cli/php_cli.c:983
#10 0x008f629a in main (argc=2, argv=0x7fb518) at
/home/huixc/opensource/php-src/trunk/sapi/cli/php_cli.c:1356
f2,
(gdb) p *field
$2 = {name = 0x10007d0 possible_keys, org_name = 0x10007e0 , table =
0x10007c0 , org_table = 0x10007c8 , db = 0x10007b8 ,
catalog = 0x20200a3e6e6f6974 Address 0x20200a3e6e6f6974 out of bounds, def
=
0x0, length = 4096, max_length = 0,
name_length = 537542259, org_name_length = 1818311712, table_length =
1047748969, org_table_length = 762278761, db_length = 959789112,
catalog_length = 792474157, def_length = 1634298977, flags = 0, decimals =
31,
charsetnr = 8, type = MYSQL_TYPE_VAR_STRING,
extension = 0x61696c612f3c3130}
Test script:
---
ext/mysqli/tests/mysqli_explain_metadata.phpt
Expected result:
passed
Actual result:
--
seg fault
--
Edit this bug report at https://bugs.php.net/bug.php?id=55662edit=1
[PHP-BUG] Req #55672 [NEW]: Autoguessing TEST_PHP_EXECUTABLE if none is provided in run-tests.php
From: Operating system: PHP version: trunk-SVN-2011-09-12 (SVN) Package: *Configuration Issues Bug Type: Feature/Change Request Bug description:Autoguessing TEST_PHP_EXECUTABLE if none is provided in run-tests.php Description: Hello! I've made some improvements to run-tests.php: 1) Autoguessing TEST_PHP_EXECUTABLE and TEST_PHP_CGI_EXECUTABLE if they're not provided, i.e. assume they have value 'auto'. You can still pass your own value as usual. Autoguessing is done this way: Looking for ./sapi/cli/php from the current directory, and, if not found from directory where run-tests.php script is resides (Christofer Jones suggestion). php-cgi is looked for the same way. 2) Added option -n (use no php.ini) to the shebang line (#!/usr/bin/php -n) so it would run more reliably on some hosts. My Ubuntu setup did not have E letter in variables_order (i.e. variables_order=GPCS) so $_ENV array was empty and some tests were skipped when they could be run. 3) Some better error handling of wrong paths So now you can run run-tests.php with just $ ./run-tests.php ext instead of $ TEST_PHP_EXECUTABLE=auto php -n run-tests.php ext You can also run run-tests.php from sub-dir, it will correctly guess 'auto' as well: $ cd ext/ $ ../run-tests.php zlib -- Edit bug report at https://bugs.php.net/bug.php?id=55672edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=55672r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=55672r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=55672r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=55672r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=55672r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=55672r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=55672r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=55672r=needscript Try newer version: https://bugs.php.net/fix.php?id=55672r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=55672r=support Expected behavior: https://bugs.php.net/fix.php?id=55672r=notwrong Not enough info: https://bugs.php.net/fix.php?id=55672r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=55672r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=55672r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=55672r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=55672r=dst IIS Stability: https://bugs.php.net/fix.php?id=55672r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=55672r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=55672r=float No Zend Extensions: https://bugs.php.net/fix.php?id=55672r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=55672r=mysqlcfg
Bug #55662 [Asn-Opn]: test script cause seg fault
Edit report at https://bugs.php.net/bug.php?id=55662edit=1
ID: 55662
Updated by: u...@php.net
Reported by:larue...@php.net
Summary:test script cause seg fault
-Status: Assigned
+Status: Open
Type: Bug
Package:MySQLi related
Operating System: Linux 64bit
PHP Version:5.4SVN-2011-09-10 (SVN)
Assigned To:mysql
Block user comment: N
Private report: N
New Comment:
MySQL not PHP issue, http://bugs.mysql.com/?id=62350 .
Previous Comments:
[2011-09-12 11:38:04] larue...@php.net
Server version: 5.1.30 Source distribution, libmysql is also built from 5.1.30
[2011-09-12 11:33:10] and...@php.net
Hi,
can you provide me with info about the version of your MySQL Server and the
client library.
Thanks!
[2011-09-10 04:39:15] larue...@php.net
Description:
ext/mysqli/tests/mysqli_explain_metadata.phpt cause a segment fault(linked
against libmysql)
backtrace:
#0 0x00302af6ff20 in strlen () from /lib64/tls/libc.so.6
#1 0x007dbeb5 in add_property_string_ex (arg=0x2a99479160,
key=0xb68dec
catalog, key_len=8,
str=0x20200a3e6e6f6974 Address 0x20200a3e6e6f6974 out of bounds,
duplicate=1)
at /home/huixc/opensource/php-src/trunk/Zend/zend_API.c:1561
#2 0x005f9a35 in php_add_field_properties (value=0x2a99479160,
field=0x1000410)
at /home/huixc/opensource/php-src/trunk/ext/mysqli/mysqli_api.c:1060
#3 0x005f9d80 in zif_mysqli_fetch_fields (ht=1,
return_value=0x2a994bcf68, return_value_ptr=0x0, this_ptr=0x0,
return_value_used=1)
at /home/huixc/opensource/php-src/trunk/ext/mysqli/mysqli_api.c:1118
#4 0x0080e1b6 in zend_do_fcall_common_helper_SPEC
(execute_data=0x2a95fbc0e8)
at /home/huixc/opensource/php-src/trunk/Zend/zend_vm_execute.h:642
#5 0x0081491a in ZEND_DO_FCALL_SPEC_CONST_HANDLER
(execute_data=0x2a95fbc0e8)
at /home/huixc/opensource/php-src/trunk/Zend/zend_vm_execute.h:2215
#6 0x0080ceba in execute (op_array=0xff40d0) at
/home/huixc/opensource/php-src/trunk/Zend/zend_vm_execute.h:410
#7 0x007d559c in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /home/huixc/opensource/php-src/trunk/Zend/zend.c:1262
#8 0x0075698b in php_execute_script (primary_file=0x7fb230) at
/home/huixc/opensource/php-src/trunk/main/main.c:2388
#9 0x008f53f9 in do_cli (argc=2, argv=0x7fb518) at
/home/huixc/opensource/php-src/trunk/sapi/cli/php_cli.c:983
#10 0x008f629a in main (argc=2, argv=0x7fb518) at
/home/huixc/opensource/php-src/trunk/sapi/cli/php_cli.c:1356
f2,
(gdb) p *field
$2 = {name = 0x10007d0 possible_keys, org_name = 0x10007e0 , table =
0x10007c0 , org_table = 0x10007c8 , db = 0x10007b8 ,
catalog = 0x20200a3e6e6f6974 Address 0x20200a3e6e6f6974 out of bounds, def
=
0x0, length = 4096, max_length = 0,
name_length = 537542259, org_name_length = 1818311712, table_length =
1047748969, org_table_length = 762278761, db_length = 959789112,
catalog_length = 792474157, def_length = 1634298977, flags = 0, decimals =
31,
charsetnr = 8, type = MYSQL_TYPE_VAR_STRING,
extension = 0x61696c612f3c3130}
Test script:
---
ext/mysqli/tests/mysqli_explain_metadata.phpt
Expected result:
passed
Actual result:
--
seg fault
--
Edit this bug report at https://bugs.php.net/bug.php?id=55662edit=1
Bug #55662 [Asn-Bgs]: test script cause seg fault
Edit report at https://bugs.php.net/bug.php?id=55662edit=1
ID: 55662
Updated by: u...@php.net
Reported by:larue...@php.net
Summary:test script cause seg fault
-Status: Assigned
+Status: Bogus
Type: Bug
Package:MySQLi related
Operating System: Linux 64bit
PHP Version:5.4SVN-2011-09-10 (SVN)
Assigned To:mysql
Block user comment: N
Private report: N
New Comment:
Server/libmysql issue.
Previous Comments:
[2011-09-12 13:02:32] u...@php.net
MySQL not PHP issue, http://bugs.mysql.com/?id=62350 .
[2011-09-12 11:38:04] larue...@php.net
Server version: 5.1.30 Source distribution, libmysql is also built from 5.1.30
[2011-09-12 11:33:10] and...@php.net
Hi,
can you provide me with info about the version of your MySQL Server and the
client library.
Thanks!
[2011-09-10 04:39:15] larue...@php.net
Description:
ext/mysqli/tests/mysqli_explain_metadata.phpt cause a segment fault(linked
against libmysql)
backtrace:
#0 0x00302af6ff20 in strlen () from /lib64/tls/libc.so.6
#1 0x007dbeb5 in add_property_string_ex (arg=0x2a99479160,
key=0xb68dec
catalog, key_len=8,
str=0x20200a3e6e6f6974 Address 0x20200a3e6e6f6974 out of bounds,
duplicate=1)
at /home/huixc/opensource/php-src/trunk/Zend/zend_API.c:1561
#2 0x005f9a35 in php_add_field_properties (value=0x2a99479160,
field=0x1000410)
at /home/huixc/opensource/php-src/trunk/ext/mysqli/mysqli_api.c:1060
#3 0x005f9d80 in zif_mysqli_fetch_fields (ht=1,
return_value=0x2a994bcf68, return_value_ptr=0x0, this_ptr=0x0,
return_value_used=1)
at /home/huixc/opensource/php-src/trunk/ext/mysqli/mysqli_api.c:1118
#4 0x0080e1b6 in zend_do_fcall_common_helper_SPEC
(execute_data=0x2a95fbc0e8)
at /home/huixc/opensource/php-src/trunk/Zend/zend_vm_execute.h:642
#5 0x0081491a in ZEND_DO_FCALL_SPEC_CONST_HANDLER
(execute_data=0x2a95fbc0e8)
at /home/huixc/opensource/php-src/trunk/Zend/zend_vm_execute.h:2215
#6 0x0080ceba in execute (op_array=0xff40d0) at
/home/huixc/opensource/php-src/trunk/Zend/zend_vm_execute.h:410
#7 0x007d559c in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /home/huixc/opensource/php-src/trunk/Zend/zend.c:1262
#8 0x0075698b in php_execute_script (primary_file=0x7fb230) at
/home/huixc/opensource/php-src/trunk/main/main.c:2388
#9 0x008f53f9 in do_cli (argc=2, argv=0x7fb518) at
/home/huixc/opensource/php-src/trunk/sapi/cli/php_cli.c:983
#10 0x008f629a in main (argc=2, argv=0x7fb518) at
/home/huixc/opensource/php-src/trunk/sapi/cli/php_cli.c:1356
f2,
(gdb) p *field
$2 = {name = 0x10007d0 possible_keys, org_name = 0x10007e0 , table =
0x10007c0 , org_table = 0x10007c8 , db = 0x10007b8 ,
catalog = 0x20200a3e6e6f6974 Address 0x20200a3e6e6f6974 out of bounds, def
=
0x0, length = 4096, max_length = 0,
name_length = 537542259, org_name_length = 1818311712, table_length =
1047748969, org_table_length = 762278761, db_length = 959789112,
catalog_length = 792474157, def_length = 1634298977, flags = 0, decimals =
31,
charsetnr = 8, type = MYSQL_TYPE_VAR_STRING,
extension = 0x61696c612f3c3130}
Test script:
---
ext/mysqli/tests/mysqli_explain_metadata.phpt
Expected result:
passed
Actual result:
--
seg fault
--
Edit this bug report at https://bugs.php.net/bug.php?id=55662edit=1
Bug #55662 [Com]: mysql_stmt_result_metadata() returns invalid metadata on EXPLAIN then crash PHP
Edit report at https://bugs.php.net/bug.php?id=55662edit=1
ID: 55662
Comment by: larue...@php.net
Reported by:larue...@php.net
Summary:mysql_stmt_result_metadata() returns invalid
metadata on EXPLAIN then crash PHP
Status: Bogus
Type: Bug
Package:MySQLi related
Operating System: Linux 64bit
PHP Version:5.4SVN-2011-09-10 (SVN)
Assigned To:mysql
Block user comment: N
Private report: N
New Comment:
change title for more significant
Previous Comments:
[2011-09-12 13:04:56] u...@php.net
Server/libmysql issue.
[2011-09-12 13:02:32] u...@php.net
MySQL not PHP issue, http://bugs.mysql.com/?id=62350 .
[2011-09-12 11:38:04] larue...@php.net
Server version: 5.1.30 Source distribution, libmysql is also built from 5.1.30
[2011-09-12 11:33:10] and...@php.net
Hi,
can you provide me with info about the version of your MySQL Server and the
client library.
Thanks!
[2011-09-10 04:39:15] larue...@php.net
Description:
ext/mysqli/tests/mysqli_explain_metadata.phpt cause a segment fault(linked
against libmysql)
backtrace:
#0 0x00302af6ff20 in strlen () from /lib64/tls/libc.so.6
#1 0x007dbeb5 in add_property_string_ex (arg=0x2a99479160,
key=0xb68dec
catalog, key_len=8,
str=0x20200a3e6e6f6974 Address 0x20200a3e6e6f6974 out of bounds,
duplicate=1)
at /home/huixc/opensource/php-src/trunk/Zend/zend_API.c:1561
#2 0x005f9a35 in php_add_field_properties (value=0x2a99479160,
field=0x1000410)
at /home/huixc/opensource/php-src/trunk/ext/mysqli/mysqli_api.c:1060
#3 0x005f9d80 in zif_mysqli_fetch_fields (ht=1,
return_value=0x2a994bcf68, return_value_ptr=0x0, this_ptr=0x0,
return_value_used=1)
at /home/huixc/opensource/php-src/trunk/ext/mysqli/mysqli_api.c:1118
#4 0x0080e1b6 in zend_do_fcall_common_helper_SPEC
(execute_data=0x2a95fbc0e8)
at /home/huixc/opensource/php-src/trunk/Zend/zend_vm_execute.h:642
#5 0x0081491a in ZEND_DO_FCALL_SPEC_CONST_HANDLER
(execute_data=0x2a95fbc0e8)
at /home/huixc/opensource/php-src/trunk/Zend/zend_vm_execute.h:2215
#6 0x0080ceba in execute (op_array=0xff40d0) at
/home/huixc/opensource/php-src/trunk/Zend/zend_vm_execute.h:410
#7 0x007d559c in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /home/huixc/opensource/php-src/trunk/Zend/zend.c:1262
#8 0x0075698b in php_execute_script (primary_file=0x7fb230) at
/home/huixc/opensource/php-src/trunk/main/main.c:2388
#9 0x008f53f9 in do_cli (argc=2, argv=0x7fb518) at
/home/huixc/opensource/php-src/trunk/sapi/cli/php_cli.c:983
#10 0x008f629a in main (argc=2, argv=0x7fb518) at
/home/huixc/opensource/php-src/trunk/sapi/cli/php_cli.c:1356
f2,
(gdb) p *field
$2 = {name = 0x10007d0 possible_keys, org_name = 0x10007e0 , table =
0x10007c0 , org_table = 0x10007c8 , db = 0x10007b8 ,
catalog = 0x20200a3e6e6f6974 Address 0x20200a3e6e6f6974 out of bounds, def
=
0x0, length = 4096, max_length = 0,
name_length = 537542259, org_name_length = 1818311712, table_length =
1047748969, org_table_length = 762278761, db_length = 959789112,
catalog_length = 792474157, def_length = 1634298977, flags = 0, decimals =
31,
charsetnr = 8, type = MYSQL_TYPE_VAR_STRING,
extension = 0x61696c612f3c3130}
Test script:
---
ext/mysqli/tests/mysqli_explain_metadata.phpt
Expected result:
passed
Actual result:
--
seg fault
--
Edit this bug report at https://bugs.php.net/bug.php?id=55662edit=1
Bug #47304 [Com]: typecast of numeric string to float produces strange result
Edit report at https://bugs.php.net/bug.php?id=47304edit=1 ID: 47304 Comment by: michael dot fellinger at multitec-sono dot at Reported by:lennart dot vandendool at fonq dot nl Summary:typecast of numeric string to float produces strange result Status: Assigned Type: Bug Package:Scripting Engine problem Operating System: win32 only PHP Version:5.2.9 Assigned To:pajoye Block user comment: N Private report: N New Comment: Similar Bug in PHP Version 5.3.5 My Code: -- $ADODB = new COM( 'ADODB.Connection' ); $ADODB-open($strConn); $RS = $ADODB-execute(SELECT Lagerwert FROM tblStammdaten WHERE tblStammdaten.Seriennummer='74925KR9';); echo $RS-Fields(0)-Value . br; $x = sprintf(%f,$RS-Fields(0)-Value); echo $x; -- gives following result: --- 1900 18:0.00 --- It only happends with the number or string 1900 and only if the execute command from the adodb connection was performed. I gues i also happens with other numbers. Previous Comments: [2010-11-08 19:04:49] lennart dot vandendool at fonq dot nl The same goes for php-5.3.3-nts-Win32-VC9-x86 on SBS 2003 (x86) and 2008 R2 (x64) [2010-11-08 18:54:24] lennart dot vandendool at fonq dot nl I just tested php-5.3.3-Win32-VC9-x86 on Windows Server 2003 x86 and 2008 R2 x64. The problem doesn't occur anymore. [2010-07-13 12:45:53] ola dot andersson at liko dot se Thank you for your suggestion pajoye. Neither php-5.3.2-nts-Win32-VC6-x86 or php-5.3.2-nts-Win32-VC9-x86 include the extension php_mssql.dll. Without this extension I am not able to properly upgrade and test our systems with this version of PHP. Howcome php_mssql is no longer included with the distributions? [2010-07-12 13:48:17] paj...@php.net Please try with 5.3.2 or 5.3.3RC2 VC9 version. [2010-07-12 12:53:18] ola dot andersson at liko dot se Error occur also when fetching data from a MS SQL server having the column value 290.00 (database Money format). $query =select pris from sa_jobb_3_1 WHERE id='.$id.'; $result = mssql_query($query) or die($query); $row = mssql_fetch_array($result,MSSQL_ASSOC); printf(%f,$row['pris']); The code above outputs incorrectly 28:.00 and not as expected 290.00 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=47304 -- Edit this bug report at https://bugs.php.net/bug.php?id=47304edit=1
[PHP-BUG] Bug #55673 [NEW]: Compiler creates (unused) compiled variables for self::$foo
From: derick
Operating system: *
PHP version: 5.3SVN-2011-09-12 (SVN)
Package: Scripting Engine problem
Bug Type: Bug
Bug description:Compiler creates (unused) compiled variables for self::$foo
Description:
When having the following code:
?php
class foo {
function bar() {
self::$bar = 42;
}
}
?
The compiler generates compiled variable !0 for $bar, even though it's a
class variable:
derick@whisky:/tmp$ php -dvld.active=1 -r 'class foo { function bar() {
self::$bar = 42; } }'
Finding entry points
Branch analysis from position: 0
Return found
filename: Command line code
function name: (null)
number of ops: 2
compiled vars: none
line # * op fetch ext return
operands
-
1 0 NOP
1 RETURN
null
branch: # 0; line: 1-1; sop: 0; eop: 1
path #1: 0,
Class foo:
Function bar:
Finding entry points
Branch analysis from position: 0
Return found
filename: Command line code
function name: bar
number of ops: 4
compiled vars: !0 = $bar
line # * op fetch ext return
operands
-
0 ZEND_FETCH_CLASS 1
1 FETCH_W static member $1
'bar'
2 ASSIGN
$1, 42
3 RETURN
null
branch: # 0; line: 1-1; sop: 0; eop: 3
path #1: 0,
End of function bar.
End of class foo.
14:41 @Derick dmitry: I am wondering why self::$foo creates a compiled
variable. Any idea?
14:42 @Derick dmitry: it creates it, but it's never used
14:44 @dmitry I see. It's probably because od simple one-pass compiler
that first interpret $foo as local variable and only then as a class
variable :)
14:44 @Derick dmitry: any way we can fix that perhaps?
14:44 @dmitry Derick: could you please create a bug and assign it to me
14:44 @Derick yes, sure
--
Edit bug report at https://bugs.php.net/bug.php?id=55673edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=55673r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=55673r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=55673r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=55673r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=55673r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=55673r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=55673r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=55673r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=55673r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=55673r=support
Expected behavior:
https://bugs.php.net/fix.php?id=55673r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=55673r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=55673r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=55673r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=55673r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=55673r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=55673r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=55673r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=55673r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=55673r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=55673r=mysqlcfg
Req #55672 [Opn]: Autoguessing TEST_PHP_EXECUTABLE if none is provided in run-tests.php
Edit report at https://bugs.php.net/bug.php?id=55672edit=1 ID: 55672 Updated by: larue...@php.net Reported by:sh...@php.net Summary:Autoguessing TEST_PHP_EXECUTABLE if none is provided in run-tests.php Status: Open Type: Feature/Change Request Package:*Configuration Issues PHP Version:trunk-SVN-2011-09-12 (SVN) Block user comment: N Private report: N New Comment: how about use $0 ? Previous Comments: [2011-09-12 12:29:48] sh...@php.net Description: Hello! I've made some improvements to run-tests.php: 1) Autoguessing TEST_PHP_EXECUTABLE and TEST_PHP_CGI_EXECUTABLE if they're not provided, i.e. assume they have value 'auto'. You can still pass your own value as usual. Autoguessing is done this way: Looking for ./sapi/cli/php from the current directory, and, if not found from directory where run-tests.php script is resides (Christofer Jones suggestion). php-cgi is looked for the same way. 2) Added option -n (use no php.ini) to the shebang line (#!/usr/bin/php -n) so it would run more reliably on some hosts. My Ubuntu setup did not have E letter in variables_order (i.e. variables_order=GPCS) so $_ENV array was empty and some tests were skipped when they could be run. 3) Some better error handling of wrong paths So now you can run run-tests.php with just $ ./run-tests.php ext instead of $ TEST_PHP_EXECUTABLE=auto php -n run-tests.php ext You can also run run-tests.php from sub-dir, it will correctly guess 'auto' as well: $ cd ext/ $ ../run-tests.php zlib -- Edit this bug report at https://bugs.php.net/bug.php?id=55672edit=1
Req #55664 [Opn-Csd]: pdo-firebird specific tests using generic driver as well
Edit report at https://bugs.php.net/bug.php?id=55664edit=1 ID: 55664 Updated by: mar...@php.net Reported by:lester at lsces dot co dot uk Summary:pdo-firebird specific tests using generic driver as well -Status: Open +Status: Closed Type: Feature/Change Request Package:PDO related Operating System: OS agnostic? PHP Version:5.3.8 -Assigned To: +Assigned To:mariuz 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. i have solved by releasing the statement handle Previous Comments: [2011-09-10 08:35:11] lester at lsces dot co dot uk Description: pdo_firebird specific tests have been designed using the generic interbase driver to create and destroy test database. Intermittent timing problem causing an error on the generic driver where the pdo_firebird driver has not finished with the connection. The race condition needs investigating, but the pdo driver tests should not be reliant on the generic driver? All the other tests use a generic database rather than continually creating and destroying it which takes unnecessary time. Test script: --- Patch fixes test script -- Edit this bug report at https://bugs.php.net/bug.php?id=55664edit=1
Bug #50977 [Com]: imap_headerinfo Address buffer overflow
Edit report at https://bugs.php.net/bug.php?id=50977edit=1 ID: 50977 Comment by: jeremy at thomersonfamily dot com Reported by:lokitek at gmail dot com Summary:imap_headerinfo Address buffer overflow Status: Feedback Type: Bug Package:IMAP related Operating System: CentOS 5.4 PHP Version:5.2.12 Block user comment: N Private report: N New Comment: Although the OP never responded with a backtrace, it seems fairly easy to reproduce. I'm seeing it when I receive a message that has around 560 recipients in the TO field. If you are not able to easily reproduce it with that info, please reply to this thread and I'll provide additional debugging information. Previous Comments: [2010-11-07 21:25:44] fel...@php.net Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php for *NIX and http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32 Once you have generated a backtrace, please submit it to this bug report and change the status back to Open. Thank you for helping us make PHP better. [2010-11-01 11:54:45] paul at fubra dot com I'm also experiencing this error with CentOS release 5.3 (Final). yum list libc-client libc-client.i386 2004g-2.2.1 [2010-04-25 20:06:28] fel...@php.net Any news? [2010-02-20 01:00:00] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to Open. [2010-02-10 20:26:50] lokitek at gmail dot com drop centOS isn't all that easy - What would you recommend instead? ;) I'll update c-client and will let you know. Thanks! The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=50977 -- Edit this bug report at https://bugs.php.net/bug.php?id=50977edit=1
[PHP-BUG] Bug #55674 [NEW]: fgetcsv str_getcsv skip empty fields in some tab-separated records
From: Operating system: Linux (Centos 5.5) PHP version: 5.3.8 Package: Strings related Bug Type: Bug Bug description:fgetcsv str_getcsv skip empty fields in some tab-separated records Description: If the record contains an (unquoted) empty field followed by a quoted field, the empty field is skipped, so all following column positions are off. This happens when the delimiter is \t but not when it's ,, so it probably has something to do with changes related to trimming whitespace. This problem seems to have been introduced between 5.3.6 and 5.3.8. Test script: --- $s = 0\t\t\2\\n; $a = str_getcsv($s, \t); var_export($a); Expected result: array ( 0 = '0', 1 = '', 2 = '2', ) Actual result: -- array ( 0 = '0', 1 = '2', ) -- Edit bug report at https://bugs.php.net/bug.php?id=55674edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=55674r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=55674r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=55674r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=55674r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=55674r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=55674r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=55674r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=55674r=needscript Try newer version: https://bugs.php.net/fix.php?id=55674r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=55674r=support Expected behavior: https://bugs.php.net/fix.php?id=55674r=notwrong Not enough info: https://bugs.php.net/fix.php?id=55674r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=55674r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=55674r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=55674r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=55674r=dst IIS Stability: https://bugs.php.net/fix.php?id=55674r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=55674r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=55674r=float No Zend Extensions: https://bugs.php.net/fix.php?id=55674r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=55674r=mysqlcfg
Bug #55335 [Opn-Bgs]: PDO query processing with postgres standard_conforming_strings and escape chars
Edit report at https://bugs.php.net/bug.php?id=55335edit=1
ID: 55335
Updated by: il...@php.net
Reported by:jakob at revealit dot dk
Summary:PDO query processing with postgres
standard_conforming_strings and escape chars
-Status: Open
+Status: Bogus
Type: Bug
Package:PDO related
Operating System: *
PHP Version:5.3.6
Block user comment: N
Private report: N
New Comment:
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. Due to the volume
of reports we can not explain in detail here why your report is not
a bug. The support channels will be able to provide an explanation
for you.
Thank you for your interest in PHP.
The issue is not with PHP but rather PostgreSQL's PQescapeStringConn function
which is what PHP uses to escape to implement quote(). This function does not
appear to be aware of the standard_conforming_strings setting and continues to
use
\ where '' should be used.
Previous Comments:
[2011-08-01 11:29:13] jakob at revealit dot dk
Description:
The test script below shows the point best.
One thing to notice, is that this bug only happens when you have
standard_conforming_strings set to on in your postgres.conf file.
It seems like the fact that PHP uses '\' as escape char might be messing things
up, sd $pdo-quote(\\) return '\' when standard_conforming_strings is set to
on vs, '\\' when it's off.
Test script:
---
$pdo = new PDO($dns, $username, $password);
$statement = $pdo-prepare(SELECT table.* FROM table table WHERE (column ILIKE
:db_condition_placeholder_0 ESCAPE . $pdo-quote(\\) . ) AND (column ILIKE
:db_condition_placeholder_1 ESCAPE . $pdo-quote(\\) . ););
$statement-execute(array(':db_condition_placeholder_0' = 'test',
':db_condition_placeholder_1' = 'test'));
Expected result:
No errors and query executed:
Actual result:
--
Error produced: Warning: PDOStatement::execute(): SQLSTATE[HY093]: Invalid
parameter number: :db_condition_placeholder_1 in
--
Edit this bug report at https://bugs.php.net/bug.php?id=55335edit=1
Bug #55273 [Opn-Csd]: base64_decode with strict rejects whitespace after pad
Edit report at https://bugs.php.net/bug.php?id=55273edit=1
ID: 55273
Updated by: il...@php.net
Reported by:ljb9832 at pobox dot com
Summary:base64_decode with strict rejects whitespace after
pad
-Status: Open
+Status: Closed
Type: Bug
Package:URL related
Operating System: N/A
PHP Version:5.3.6
-Assigned To:
+Assigned To:iliaa
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.
Previous Comments:
[2011-09-12 17:20:09] il...@php.net
Automatic comment from SVN on behalf of iliaa
Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=316560
Log: Fixed bug #55273 (base64_decode() with strict rejects whitespace after pad)
[2011-07-23 21:22:22] ljb9832 at pobox dot com
Description:
Per RFC2045, section 6.8, base64 decoding should not count line breaks and
other whitespace as errors. When using $strict=True, base64_decode() does
ignore whitespace, except at the end of any base64 encoded data that ends with
padding characters (=). If there is whitespace after the padding character(s),
the string is rejected under strict testing. This is incorrect.
One particular problem with this is that you cannot reliably round-trip base64
encode/decode with strict checking when using chunk_split() on the encoded
data, because chunk_split puts a newline at the end of the data. If the length
of the original data is a multiple of 3, it works, otherwise it does not.
Test script:
---
?php
function test($s)
{
$v = chunk_split(base64_encode($s));
$r = base64_decode($v, True);
echo $s=;
var_dump($r);
}
test('PHP');
test('PH');
test('P');
Expected result:
PHP=string(3) PHP
PH=string(2) PH
P=string(1) P
Actual result:
--
PHP=string(3) PHP
PH=bool(false)
P=bool(false)
--
Edit this bug report at https://bugs.php.net/bug.php?id=55273edit=1
Bug #55646 [Opn-Csd]: decoding csr corrupts UTF8 characters
Edit report at https://bugs.php.net/bug.php?id=55646edit=1
ID: 55646
Updated by: cataphr...@php.net
Reported by:zedwoodnoreply at gmail dot com
Summary:decoding csr corrupts UTF8 characters
-Status: Open
+Status: Closed
Type: Bug
Package:OpenSSL related
Operating System: Ubuntu 10.04
PHP Version:5.3.8
-Assigned To:
+Assigned To:cataphract
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, but for 5.4 only due to backward compatibility concerns.
Thank you.
Previous Comments:
[2011-09-12 17:22:55] cataphr...@php.net
Automatic comment from SVN on behalf of cataphract
Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=316562
Log: - Fixed bug #55646: textual data is returned in UTF-8, but is input in
another encoding. 5.4 only as this implies a BC break.
[2011-09-08 18:01:20] zedwoodnoreply at gmail dot com
I saved the csr that php generated... and the parsed it with:
openssl asn1parse -in a.csr
0:d=0 hl=4 l= 687 cons: SEQUENCE
4:d=1 hl=4 l= 407 cons: SEQUENCE
8:d=2 hl=2 l= 1 prim: INTEGER :00
11:d=2 hl=2 l= 106 cons: SEQUENCE
13:d=3 hl=2 l= 11 cons: SET
15:d=4 hl=2 l= 9 cons: SEQUENCE
17:d=5 hl=2 l= 3 prim: OBJECT:countryName
22:d=5 hl=2 l= 2 prim: PRINTABLESTRING :US
26:d=3 hl=2 l= 13 cons: SET
28:d=4 hl=2 l= 11 cons: SEQUENCE
30:d=5 hl=2 l= 3 prim: OBJECT:stateOrProvinceName
35:d=5 hl=2 l= 4 prim: PRINTABLESTRING :Utah
41:d=3 hl=2 l= 15 cons: SET
43:d=4 hl=2 l= 13 cons: SEQUENCE
45:d=5 hl=2 l= 3 prim: OBJECT:localityName
50:d=5 hl=2 l= 6 prim: PRINTABLESTRING :Lindon
58:d=3 hl=2 l= 16 cons: SET
60:d=4 hl=2 l= 14 cons: SEQUENCE
62:d=5 hl=2 l= 3 prim: OBJECT:organizationName
67:d=5 hl=2 l= 7 prim: PRINTABLESTRING :Chinese
76:d=3 hl=2 l= 15 cons: SET
78:d=4 hl=2 l= 13 cons: SEQUENCE
80:d=5 hl=2 l= 3 prim: OBJECT:organizationalUnitName
85:d=5 hl=2 l= 6 prim: T61STRING :IT äº
93:d=3 hl=2 l= 24 cons: SET
95:d=4 hl=2 l= 22 cons: SEQUENCE
97:d=5 hl=2 l= 3 prim: OBJECT:commonName
102:d=5 hl=2 l= 15 prim: PRINTABLESTRING :www.example.com
119:d=2 hl=4 l= 290 cons: SEQUENCE
123:d=3 hl=2 l= 13 cons: SEQUENCE
125:d=4 hl=2 l= 9 prim: OBJECT:rsaEncryption
136:d=4 hl=2 l= 0 prim: NULL
138:d=3 hl=4 l= 271 prim: BIT STRING
413:d=2 hl=2 l= 0 cons: cont [ 0 ]
415:d=1 hl=2 l= 13 cons: SEQUENCE
417:d=2 hl=2 l= 9 prim: OBJECT:md5WithRSAEncryption
428:d=2 hl=2 l= 0 prim: NULL
430:d=1 hl=4 l= 257 prim: BIT STRING
[2011-09-08 17:57:51] zedwoodnoreply at gmail dot com
Description:
I did this in command line php,
OpenSSL 0.9.8k 25 Mar 2009
If I create a csr with a UTF8 character, then I ought to get the UTF8 character
out, untampered with when I parse it.
Test script:
---
?php
function stringAsHex($string){$unpacked = unpack(H*, $string);return
implode( , str_split($unpacked[1],2));}
$config = array(digest_alg = sha1,x509_extensions =
v3_ca,req_extensions = v3_req,private_key_bits =
2048,private_key_type = OPENSSL_KEYTYPE_RSA,encrypt_key = false,);
$csr_info = array(
countryName = US,
stateOrProvinceName = Utah,
localityName = Lindon,
organizationName = Chinese,
organizationalUnitName = IT \xe4\xba\x92,
commonName = www.example.com,);
$private = openssl_pkey_new($config);
$csr_res = openssl_csr_new($csr_info, $private);
openssl_csr_export($csr_res, $csr); //echo $csr;
$output = openssl_csr_get_subject($csr);
echo A: .$csr_info[organizationalUnitName].\n;
echo B: .stringAsHex($csr_info[organizationalUnitName]).\n;
echo C: .$output['OU'].\n;
echo D: .stringAsHex($output['OU']).\n;
Expected result:
A: IT äº
B: 49 54 20 e4 ba 92
C: IT äº
D: 49 54 20 e4 ba 92
Actual result:
--
A: IT äº
B: 49 54 20 e4 ba 92
C: IT äºÂ
D: 49 54 20 c3 a4 c2 ba c2 92
Bug #55554 [Asn]: Trait methods overriding legacy constructors
Edit report at https://bugs.php.net/bug.php?id=4edit=1
ID: 4
User updated by:ryan at zuttonet dot com
Reported by:ryan at zuttonet dot com
Summary:Trait methods overriding legacy constructors
Status: Assigned
Type: Bug
Package:Scripting Engine problem
Operating System: Ubuntu
PHP Version:5.4.0alpha3
Assigned To:gron
Block user comment: N
Private report: N
New Comment:
Thanks, Stefan (the defect directions explicitly say not to include examples
over 20 lines; that's why I provided the github link)
The real issue is this: should we be allowed to define, in a trait, a method
that will override the constructor of the class into which we're importing the
trait?
I think not, but currently it can be done, although not consistently.
Example 1:
?php
/**
*
* Defect: can alias-override class constructor, but only when using legacy
constructor naming convention
*
*/
trait SomeTrait {
private function constructor() {
echo this is abuse\n;
}
}
class SomeClass {
use SomeTrait {
constructor as __construct;
}
public function SomeClass() {
echo this is a constructor;
}
}
$c = new SomeClass(); // Fatal error: Call to private SomeClass::__construct()
In this example, I can override SomeClass::SomeClass() as the constructor by
importing SomeTrait::constructor() as SomeClass::__construct(). However, this
works only because I'm using the legacy constructor SomeClass::SomeClass(). If
I
had defined SomeClass::__construct() in SomeClass' definition, PHP would not
allow this trait abuse.
Example 2:
?php
/**
*
* Defect: can override class constructor, but only when using legacy
constructor naming convention
*
*/
trait SomeTrait {
private function __construct() {
echo this is abuse\n;
}
}
class SomeClass {
use SomeTrait;
public function SomeClass() {
echo this is a constructor;
}
}
$c = new SomeClass(); // Fatal error: Call to private SomeClass::__construct()
In this case, I can override the legacy constructor SomeClass::SomeClass() with
a method name SomeTrait::__construct(). However, if I had a method named
SomeClass::__construct(), it would not be overridden by the trait method.
Do my concerns make more sense now? It's not about what _should_ be allowed,
it's about the inconsistency in what currently is allowed.
In order to be consistent, either both types of constructors should be
overridable, or neither should (probably the latter).
Again, it's about the overriding of an existing constructor, not about the
mixing in of one into a class with no constructor.
Previous Comments:
[2011-09-12 10:47:22] g...@php.net
Hi Ryan:
I am sorry, I don't think I understand what inconsistency you are pointing out.
Could you elaborate on the problem?
(And please include the code you are referring to directly here. Just to make
it
easier for me
to know that we are talking about exactly the same code.)
What I understand is you want to provide the constructor with a trait, right?
Like this:
?php
trait MyTrait {
public function constructor() {
echo Foo\n;
}
}
class MyClass {
use MyTrait {
constructor as __construct;
}
}
class MyClass2 {
use MyTrait {
constructor as MyClass2;
}
}
echo MyClass constructor: ;
$o = new MyClass; // echos Foo
echo \nMyClass2 constructor: ;
$o = new MyClass2; // doesn't echo Foo
echo \n;
?
The problem I see here is that for MyClass2 the constructor does not actually
get registered
as a constructor but just as a normal method.
That seems to be an inconsistency that needs to be fixed.
Ok, now to the new vs. legacy constructors:
class Bar {
function Bar() {
echo BarBar new ctor\n;
}
function __construct() {
echo Bar new ctor\n;
}
}
$o = new Bar;
?
Switching the order of the definition of the constructors doesn't influence the
result,
__construct always wins.
Both your examples behaves identical to the situation if the __construct would
have been
defined directly in the class. So, where is the problem here?
It is not an inconsistency with how PHP behaves without traits, from what I can
see.
Ah, and please try the latest code in the SVN, I am not exactly sure whether I
changed
anything that could be related to that between alpha3 and now. But I doubt it.
Thanks
Stefan
[2011-08-31 15:52:43] ryan at zuttonet dot com
Apologies; the literal expected output for the provided test scripts should be:
this is a constructor
As this is the output when using __construct() in
Bug #55660 [Com]: SplFixedArray::fromArray causing segmentation fault 11
Edit report at https://bugs.php.net/bug.php?id=55660edit=1
ID: 55660
Comment by: rewilliams at crystaltech dot com
Reported by:rewilliams at crystaltech dot com
Summary:SplFixedArray::fromArray causing segmentation fault
11
Status: Feedback
Type: Bug
Package:Reproducible crash
Operating System: Mac OS X 10.7.1
PHP Version:5.3.8
Block user comment: N
Private report: N
New Comment:
FWIW, I just reproduced it on a Linux server running 5.3.4. I'm working on
getting
a backtrace, but I need to build a debug version of PHP first.
Previous Comments:
[2011-09-10 03:59:47] larue...@php.net
Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php for *NIX and
http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32
Once you have generated a backtrace, please submit it to this bug
report and change the status back to Open. Thank you for helping
us make PHP better.
I can not reproduce it with a test csv file(1005 line, 13 cloumns) with 5.3
trunk
[2011-09-09 21:32:23] rewilliams at crystaltech dot com
Hmm, I don't see how to upload reproduction scripts. The script is below; I'll
leave the data
file to the tester. I created a simple CSV file that had 10,005 lines of 13
columns each, where
the value of every column is the alphabet. It included one trailing blank line
and used CRLF line
endings.
Here's the script:
?php
ini_set('display_errors', 1);
ini_set('error_reporting', E_ALL | E_STRICT);
class NmsObj {
static public function ImportData($whichOption) {
$fileObj = new SplFileObject('TestData.csv');
$fileObj-setFlags(SplFileObject::SKIP_EMPTY |
SplFileObject::DROP_NEW_LINE |
SplFileObject::READ_CSV);
$return = array();
foreach ($fileObj as $oneLine) {
$return[] = new stdClass();
} //foreach
switch ($whichOption) {
case 1:
$return = array_slice($return, 0, );
$result = SplFixedArray::fromArray($return);
//we get here
return $result;
break;
case 2:
$return = array_slice($return, 0, 1);
$result = SplFixedArray::fromArray($return);
//we won't get here - get Segmentation fault:
11
return $result;
break;
} //switch
} //ImportData
} //NmsObj
//$dataSet1 = NmsObj::ImportData(1);
$dataSet1 = NmsObj::ImportData(2);
echo Done!\n;
?
[2011-09-09 21:26:12] rewilliams at crystaltech dot com
Description:
I created a script that uses SplFileObject to iterate over a CSV file. As it
goes, it creates a new object with each line's data and adds the object to an
array. Running it with 10k or more lines crashes with a Segmentation fault:
11
error message, while anything up to 9,999 lines works well. Adjusting PHP's
memory limit had no effect.
I've attached a partial reduction to this bug. It seems like I really need the
elements of the SplFileObject and the class for each line, as skipping either
one of those (even when the resulting array is much larger than 10k items)
causes the failure to disappear. I'm not sure exactly what the trigger is,
however. My reduction includes a sample CSV file of just over 10k lines, and
though it still uses SplFileObject and a per-line object, the class for the
latter is just an stdClass, and the data from the file is essentially ignored.
The script has two lines near the bottom that are method calls to ImportData().
Comment out one or the other to see the script run successfully or to see it
fail. Option 1 works; option 2 fails.
Note that I tested this under 5.3.6, not the 5.3.8 that's indicated on the bug.
I do not have access to the latter.
Expected result:
I'd expect the script to run to completion in all cases, assuming there is
sufficient memory.
Actual result:
--
The script fails in the case of = 1 items in the array being converted.
--
Edit this bug report at https://bugs.php.net/bug.php?id=55660edit=1
Bug #55660 [Com]: SplFixedArray::fromArray causing segmentation fault 11
Edit report at https://bugs.php.net/bug.php?id=55660edit=1
ID: 55660
Comment by: rewilliams at crystaltech dot com
Reported by:rewilliams at crystaltech dot com
Summary:SplFixedArray::fromArray causing segmentation fault
11
Status: Feedback
Type: Bug
Package:Reproducible crash
Operating System: Mac OS X 10.7.1
PHP Version:5.3.8
Block user comment: N
Private report: N
New Comment:
laruence@: I just caught that you stated your test file had 1005 lines. I'm not
sure if you misread what I wrote or if you mistyped what you tested, but the
test file I used was 10005 lines - you're off by an order of magnitude.
I uploaded my file to Dropbox. You can grab it here:
http://dl.dropbox.com/u/9434155/data.csv
If you're able to grab it and attach it to the bug or make it available
someplace more permanent, that would be great.
Previous Comments:
[2011-09-12 18:00:42] rewilliams at crystaltech dot com
FWIW, I just reproduced it on a Linux server running 5.3.4. I'm working on
getting
a backtrace, but I need to build a debug version of PHP first.
[2011-09-10 03:59:47] larue...@php.net
Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php for *NIX and
http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32
Once you have generated a backtrace, please submit it to this bug
report and change the status back to Open. Thank you for helping
us make PHP better.
I can not reproduce it with a test csv file(1005 line, 13 cloumns) with 5.3
trunk
[2011-09-09 21:32:23] rewilliams at crystaltech dot com
Hmm, I don't see how to upload reproduction scripts. The script is below; I'll
leave the data
file to the tester. I created a simple CSV file that had 10,005 lines of 13
columns each, where
the value of every column is the alphabet. It included one trailing blank line
and used CRLF line
endings.
Here's the script:
?php
ini_set('display_errors', 1);
ini_set('error_reporting', E_ALL | E_STRICT);
class NmsObj {
static public function ImportData($whichOption) {
$fileObj = new SplFileObject('TestData.csv');
$fileObj-setFlags(SplFileObject::SKIP_EMPTY |
SplFileObject::DROP_NEW_LINE |
SplFileObject::READ_CSV);
$return = array();
foreach ($fileObj as $oneLine) {
$return[] = new stdClass();
} //foreach
switch ($whichOption) {
case 1:
$return = array_slice($return, 0, );
$result = SplFixedArray::fromArray($return);
//we get here
return $result;
break;
case 2:
$return = array_slice($return, 0, 1);
$result = SplFixedArray::fromArray($return);
//we won't get here - get Segmentation fault:
11
return $result;
break;
} //switch
} //ImportData
} //NmsObj
//$dataSet1 = NmsObj::ImportData(1);
$dataSet1 = NmsObj::ImportData(2);
echo Done!\n;
?
[2011-09-09 21:26:12] rewilliams at crystaltech dot com
Description:
I created a script that uses SplFileObject to iterate over a CSV file. As it
goes, it creates a new object with each line's data and adds the object to an
array. Running it with 10k or more lines crashes with a Segmentation fault:
11
error message, while anything up to 9,999 lines works well. Adjusting PHP's
memory limit had no effect.
I've attached a partial reduction to this bug. It seems like I really need the
elements of the SplFileObject and the class for each line, as skipping either
one of those (even when the resulting array is much larger than 10k items)
causes the failure to disappear. I'm not sure exactly what the trigger is,
however. My reduction includes a sample CSV file of just over 10k lines, and
though it still uses SplFileObject and a per-line object, the class for the
latter is just an stdClass, and the data from the file is essentially ignored.
The script has two lines near the bottom that are method calls to ImportData().
Comment out one or the other to see the script run successfully or to see it
fail. Option 1 works; option 2 fails.
Note that I tested this
Bug #55554 [Asn]: Trait methods overriding legacy constructors
Edit report at https://bugs.php.net/bug.php?id=4edit=1
ID: 4
Updated by: g...@php.net
Reported by:ryan at zuttonet dot com
Summary:Trait methods overriding legacy constructors
Status: Assigned
Type: Bug
Package:Scripting Engine problem
Operating System: Ubuntu
PHP Version:5.4.0alpha3
Assigned To:gron
Block user comment: N
Private report: N
New Comment:
Hi Ryan:
(I wonder whether I could answer directly to those emails sent be the tracker,
this here manually is rather messy ...)
My main point is, that PHP does handle classes that define both kinds of
constructors in a very specific way. And that is consistent with how it is
handled
when traits are used.
The answer to your question, whether a trait should be able to override the
constructor of a class in which it is used, is no. The class definition should
always take precedence. However, the problem here is deeper. Since legacy
constructor and __construct are not considered equal, we got a problem.
The inequality allows you to define both in a class, as my previous example
showed. And well, for the same reason it also works with traits, of course with
unintended side effects.
I will see what pops up when I fix the issue that you can not define legacy
constructors with a trait. I will probably add a test that constructors are
handled more carefully in traits then. The WTF factor is much higher and not
worth
keeping the consistency, I think.
Best regards
Stefan
Previous Comments:
[2011-09-12 17:38:08] ryan at zuttonet dot com
Thanks, Stefan (the defect directions explicitly say not to include examples
over 20 lines; that's why I provided the github link)
The real issue is this: should we be allowed to define, in a trait, a method
that will override the constructor of the class into which we're importing the
trait?
I think not, but currently it can be done, although not consistently.
Example 1:
?php
/**
*
* Defect: can alias-override class constructor, but only when using legacy
constructor naming convention
*
*/
trait SomeTrait {
private function constructor() {
echo this is abuse\n;
}
}
class SomeClass {
use SomeTrait {
constructor as __construct;
}
public function SomeClass() {
echo this is a constructor;
}
}
$c = new SomeClass(); // Fatal error: Call to private SomeClass::__construct()
In this example, I can override SomeClass::SomeClass() as the constructor by
importing SomeTrait::constructor() as SomeClass::__construct(). However, this
works only because I'm using the legacy constructor SomeClass::SomeClass(). If
I
had defined SomeClass::__construct() in SomeClass' definition, PHP would not
allow this trait abuse.
Example 2:
?php
/**
*
* Defect: can override class constructor, but only when using legacy
constructor naming convention
*
*/
trait SomeTrait {
private function __construct() {
echo this is abuse\n;
}
}
class SomeClass {
use SomeTrait;
public function SomeClass() {
echo this is a constructor;
}
}
$c = new SomeClass(); // Fatal error: Call to private SomeClass::__construct()
In this case, I can override the legacy constructor SomeClass::SomeClass() with
a method name SomeTrait::__construct(). However, if I had a method named
SomeClass::__construct(), it would not be overridden by the trait method.
Do my concerns make more sense now? It's not about what _should_ be allowed,
it's about the inconsistency in what currently is allowed.
In order to be consistent, either both types of constructors should be
overridable, or neither should (probably the latter).
Again, it's about the overriding of an existing constructor, not about the
mixing in of one into a class with no constructor.
[2011-09-12 10:47:22] g...@php.net
Hi Ryan:
I am sorry, I don't think I understand what inconsistency you are pointing out.
Could you elaborate on the problem?
(And please include the code you are referring to directly here. Just to make
it
easier for me
to know that we are talking about exactly the same code.)
What I understand is you want to provide the constructor with a trait, right?
Like this:
?php
trait MyTrait {
public function constructor() {
echo Foo\n;
}
}
class MyClass {
use MyTrait {
constructor as __construct;
}
}
class MyClass2 {
use MyTrait {
constructor as MyClass2;
}
}
echo MyClass constructor: ;
$o = new MyClass; // echos Foo
echo \nMyClass2 constructor: ;
$o = new MyClass2; // doesn't echo Foo
echo \n;
?
The problem I
[PHP-BUG] Bug #55675 [NEW]: Buffer overflow error in imap_headerinfo can not be suppressed
From:
Operating system: CentOS 5.5
PHP version: Irrelevant
Package: IMAP related
Bug Type: Bug
Bug description:Buffer overflow error in imap_headerinfo can not be suppressed
Description:
This is related to https://bugs.php.net/bug.php?id=50977
There are really two bugs here:
1 - the bug linked above - the buffer overflow when a message has too many
addresses in the To: field (my test case had 580+)
2 - The fact that I can not suppress the error and continue script
execution
Here is the error that is generated due to #1:
[Mon Sep 12 17:14:42 2011] [error] [client 10.1.XXX.XXX] PHP Fatal error:
imap_headerinfo() [a
href='function.imap-headerinfo'function.imap-headerinfo/a]: Address
buffer overflow in /home/jrthomer/X/trunk/www/lib/imap.php on line 805,
referer: https://example.com/jrthomer_qa/index.php
The imap_headerinfo call never returns. The script is aborted.
The bigger problem is that no attempt at suppressing the error and
continuing processing is working. Typically we can catch an error like
this with a try/catch if the function returns an exception. If it does not
(worst case scenario), we can suppress all errors with the @ prefix
before the function call. In this case, neither worked. Additionally, I
tried set_error_handler with a custom error handler. The error handler
catches errors that I manually trigger using trigger_error (and the script
continues processing), but it does *not* get called for the error that is
pasted above.
The script below is an example that shows all the error handling methods I
have tried that are not working.
Test script:
---
function suppress_all_errors($errno, $errstr, $errfile, $errline) {
print(there was an error calling imap_headerinfo {$errno}, {$errstr},
{$errfile}, {$errline});
};
function getMessageHeaderInfo($objConn, $intUID, $blFullAttachmentDetails =
false) {
$intMessageNumber = imap_msgno($objConn, $intUID); // this works (in
other words, connection and message UID are okay)
$objHdr = false;
try {
set_error_handler(suppress_all_errors, E_ALL);
// this error ends up in my error suppress_all_errors error
handler
trigger_error(test, E_ERROR);
// the following line results in an error in the logs and aborts the
script
// note that the try/catch does not work (no exception is thrown),
// the @ error suppressor does not work (the error is still logged
and the script is aborted)
// and the custom error handler set above does not get triggered
$objHdr = @imap_headerinfo($objConn, $intMessageNumber); // ---
ERROR IS HERE
restore_error_handler();
} catch (Exception $e) {
print(error getting imap_headerinfo: {$e});
}
}
Expected result:
Two expected results:
1 - there should not be a buffer overflow
2 - in the event of the buffer overflow, I should be able to continue
script execution
--
Edit bug report at https://bugs.php.net/bug.php?id=55675edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=55675r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=55675r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=55675r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=55675r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=55675r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=55675r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=55675r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=55675r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=55675r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=55675r=support
Expected behavior:
https://bugs.php.net/fix.php?id=55675r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=55675r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=55675r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=55675r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=55675r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=55675r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=55675r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=55675r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=55675r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=55675r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=55675r=mysqlcfg
Bug #55650 [Csd-Bgs]: !empty returns false positive if subkey not set, but not if _GET is set manually
Edit report at https://bugs.php.net/bug.php?id=55650edit=1
ID: 55650
Updated by: cataphr...@php.net
Reported by:chris dot wisefool at gmail dot com
Summary:!empty returns false positive if subkey not set, but
not if _GET is set manually
-Status: Closed
+Status: Bogus
Type: Bug
Package:Built-in web server
Operating System: Windows 6.1 build 7600 i586
PHP Version:5.3.8
Block user comment: N
Private report: N
Previous Comments:
[2011-09-09 07:06:27] chris dot wisefool at gmail dot com
After slightly changing my code example to:
?php
var_dump($_GET);
if (!empty($_GET['search']['filter']))
echo 'SEARCH FILTER PARAM WAS NOT PROVIDED!';
$_GET = array('search'='1');
var_dump($_GET);
if (!empty($_GET['search']['filter']))
echo 'SEARCH FILTER PARAM WAS NOT PROVIDED!';
The results do seem consistent with the behavior as explained in #27677 (I see
that the behavior didn't occur when set manually because I was setting 'search'
to 1 NOT '1' and the subscripting behavior only occurred with strings.
So it seems the behavior is correct per PHP's documentation, just not my
assumptions based on that documentation. It means to test for a subkey you have
to use the longer !empty($_GET['search']) array_key_exists('filter',
$_GET['search']) is_array($_GET['search']['filter']), but hey, that's life :)
So I'm closing the bug.
[2011-09-09 06:42:33] chris dot wisefool at gmail dot com
Reworded bug summary to be more descriptive and succinct
[2011-09-09 06:39:54] chris dot wisefool at gmail dot com
Either the form munged part of my data (unlikely) or I pasted it in wrong. The
line after
if (!empty($_GET['search']['filter'])) echo 'SEARCH FILTER PARAM WAS PROVIDED!';
should be
$_GET = array('search'=1);
if (!empty($_GET['search']['filter']))
echo 'SEARCH FILTER PARAM WAS NOT PROVIDED!';
I'd edit it, but it seems you can't: you can only add comments...
[2011-09-09 06:29:54] chris dot wisefool at gmail dot com
Description:
Running on PHP Version 5.3.5, EasyPHP Server Apache.
The test code on my system shows SEARCH FILTER PARAM WAS PROVIDED if
?search=1
is passed for the query string but curiously not if ?search[a]=1 is provided.
Based on some other bug reports (#27677) I thought maybe the behavior was
correct,
but if so then it seems a bug that when _GET is manually set to the same value
instead of set by PHP parsing the query string, that it gives different
results.
So it seems a bug either way. :)
Test script:
---
?php
# Assume http://somesite/?search=1
if (!empty($_GET['search']['filter'])) echo 'SEARCH FILTER PARAM WAS PROVIDED!';
# The REALLY odd thing is if I do this it does give the expected results:
$_GET
if (!empty($_GET['search']['filter']))
echo 'SEARCH FILTER PARAM WAS NOT PROVIDED!';
?php
# The following (which obviously should be run as a separate script)
# demonstrates that the $_GET array seems the same in both cases
# It seems like empty() is somehow seeing the _GET array as set by PHP
# and the manually set _GET array as different when containing identical
# contents!
# It seems very odd to me!
var_dump($_GET);
if (!empty($_GET['search']['filter']))
echo 'SEARCH FILTER PARAM WAS NOT PROVIDED!';
$_GET = array('search'=1);
var_dump($_GET);
if (!empty($_GET['search']['filter']))
echo 'SEARCH FILTER PARAM WAS NOT PROVIDED!';
Expected result:
SEARCH FILTER PARAM WAS PROVIDED if ?search[filter]=1 provided
No SEARCH FILTER PARAM WAS PROVIDED if ?search=1
Actual result:
--
SEARCH FILTER PARAM WAS PROVIDED if ?search=1 or ?search[filter]=1 provided
--
Edit this bug report at https://bugs.php.net/bug.php?id=55650edit=1
Bug #50480 [Com]: memory leak with eval()
Edit report at https://bugs.php.net/bug.php?id=50480edit=1
ID: 50480
Comment by: horsarias at hotmail dot com
Reported by:lesjno at free dot fr
Summary:memory leak with eval()
Status: Open
Type: Bug
Package:Scripting Engine problem
Operating System: *
PHP Version:5.3.1
Block user comment: N
Private report: N
New Comment:
Hi, my php console process reaches the memory limit after some days of hard
work but the only suspect that i find in de code is the eval. using linux
with php 5.3.6 ( in my code, the eval function is HEAVALY usted with HEAVY
arrays being evaluated)
Bye
Previous Comments:
[2010-05-27 13:26:46] letssurf at gmail dot com
PHP Versions:
-
Tested as broken with
5.2.6
5.3.2
Reproduce code:
---
?php
// working code, runs for ever
$code = 'return false;';
while(true) {
$result = eval($code);
$mem = memory_get_peak_usage(true);
var_dump($result, $mem);
}
?php
// broken code, dies due to memory limit being reached
$code = 'some invalid php code';
while(true) {
$result = eval($code);
$mem = memory_get_peak_usage(true);
var_dump($result, $mem);
}
Expected result:
A var_dump of false and the peak memory usage, not increasing.
Actual result:
--
A var_dump of false and the peak memory usage keeps increasing.
[2010-04-26 10:09:45] lesjno at free dot fr
I've just tried the PHP 5.3.2 release but the memory leak remains.
The test script is the following :
CODE :
--
$status=;
$ch=\$result=true;; // a chain with a good php syntax
$memory_used1 = memory_get_usage();
$status = @eval($ch) ;
$memory_used2 = memory_get_usage();
echo chain to eval : \$ch\ == status = ;
var_dump($status);
echo BR;
echo bmemory difference = .($memory_used2-$memory_used1).BRBR/b\n;
$ch=abcdef; // a chain with a bad php syntaxe
$memory_used1 = memory_get_usage();
$status = @eval($ch) ;
$memory_used2 = memory_get_usage();
echo chain to eval : \$ch\ == status = ;
var_dump($status);
echo BR;
echo bmemory difference = .($memory_used2-$memory_used1).BR/b\n;
Actual result:
--
chain to eval : $result=true; == status = NULL
memory difference = 512
chain to eval : abcdef == status = bool(false)
memory difference = 8632
Expected result:
--
chain to eval : $result=true; == status = NULL
memory difference = 0
chain to eval : abcdef == status = bool(false)
memory difference = 0
[2010-04-25 20:39:15] fel...@php.net
Please try using this snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
[2009-12-24 01:00:01] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to Open.
[2009-12-22 08:59:14] lesjno at free dot fr
Hello jani,
I have a loop to update a database from an excel file. So, for each excel row I
will apply several tests and initializations specified in a configuration file.
The configuration file depend on the user profile. The eval() function is used,
for example, for data initialization : the configuration file can give a data
or a code. For example a specific date field can take a fix date (2009-01-01)
or can be computed. So, for example, I can found in a configuration file :
for a user category : $field_init = '2009-01-01' ;
for another user category : $field_init = 'return date(Y-m-d);' ;
I will use the following code :
$data = @eval($field_init) ; if ($data===false) $data=$field_init;
It's only an example but there are a lot of others eval() like this for each
excel row treatment.
An excel file can have more than 5 rows ... so the memory leak is growing
up till the system error ...
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=50480
--
Edit this bug report at https://bugs.php.net/bug.php?id=50480edit=1
Req #42664 [Com]: PDO::FETCH_CLASSTYPE is not useful for abstracting code.
Edit report at https://bugs.php.net/bug.php?id=42664edit=1
ID: 42664
Comment by: restlesslythought at gmail dot com
Reported by:jdriddle_producer at yahoo dot como
Summary:PDO::FETCH_CLASSTYPE is not useful for abstracting
code.
Status: Open
Type: Feature/Change Request
Package:PDO related
Operating System: *
PHP Version:5.2.4
Block user comment: N
Private report: N
New Comment:
You actually don't have to list out all the column names. You can just use *
again.
This works perfectly:
$query = SELECT `classType`, `$tableName`.* from $tableName;
Previous Comments:
[2007-09-13 19:29:15] jdriddle_producer at yahoo dot como
After additional thought, it might be better to add this functionality to
PDOStatement-fetchObject() instead. That way there would be no chance of
mucking up PDOStatement- fetch() with the added parameters.
[2007-09-13 18:37:49] jdriddle_producer at yahoo dot como
Description:
Currently, the PDO::FETCH_CLASSTYPE option is used with PDO::FETCH_CLASS in
$result-fetch() in order to create an object based upon a classname determined
by data in the table. Unfortunately, the method looks for the FIRST COLUMN in
the result. This is counter to common relational database design.
The only way to currently work around this and get at the desired functionality
is to abandon the common 'SELECT * from $tableName' construct that is so useful
in abstraction, and use custom 'SELECT classType, col2,col3,... from
_tableName_' for each query.
I suggest that the PDO::FETCH_CLASSTYPE option be changed to take an optional
parameter, $colName, for the column name to look for the class name in. The
current behavior would remain as the default.
This would allow:
$objArray = [];
$query = SELECT * from $tableName;
$result = $dbh-query($query);
$count = $result-rowCount();
for($i=0;$i$count;$i+=1)
{
$objArray[] = $result-fetch(PDO::FETCH_CLASS |
PDO::FETCH_CLASSTYPE,classType);
}
Or similar construct.
--
Edit this bug report at https://bugs.php.net/bug.php?id=42664edit=1
Bug #55067 [Com]: MySQL doesn't support compression
Edit report at https://bugs.php.net/bug.php?id=55067edit=1 ID: 55067 Comment by: belov1985 at gmail dot com Reported by:belov1985 at gmail dot com Summary:MySQL doesn't support compression Status: Closed Type: Bug Package:MySQLi related Operating System: FreeBSD 8.2 PHP Version:5.3.6 Assigned To:ahristov Block user comment: N Private report: N New Comment: Download php5.3-201109122030 root./configure --help | grep mysqlnd-compression --disable-mysqlnd-compression-support Seems ok... root ./configure --enable-mysqlnd --with-mysql=mysqlnd --with-mysqli=mysqlnd make ... checking whether to enable mysqlnd... yes checking whether to disable compressed protocol support in mysqlnd... yes ... after building: root sapi/cli/php -i mysqlnd mysqlnd = enabled Version = mysqlnd 5.0.8-dev - 20102224 - $Revision: 310735 $ Compression = not supported Not fixed :( Previous Comments: [2011-09-02 13:20:52] and...@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/. For Windows: http://windows.php.net/snapshots/ Thank you for the report, and for helping us make PHP better. Thanks for your report. Fix will appear in 5.3.9 [2011-07-20 10:25:25] u...@php.net Andrey, can you have a look? You've been the last one working on the config9.m4. Seems buggy. [2011-06-29 09:46:55] belov1985 at gmail dot com Description: Version mysqlnd 5.0.8-dev - 20102224 - $Revision: 308673 $ Compression not supported PHP build info: ./configure --with-layout=GNU --localstatedir=/var --with-config-file-scan-dir=/usr/local/etc/php --disable-all --enable-libxml --with-pcre-regex=/usr/local --with-zlib-dir=/usr --program-prefix= --with-mysql=mysqlnd --with-mysqli=mysqlnd --with-mcrypt --with-curl --with-jpeg-dir=/usr/local/lib/ --with-freetype-dir=/usr/local/include/freetype2/ --with-png-dir=/usr/local/lib/ --with-iconv-dir=/usr/local/lib --with-libxml-dir=/usr/local/include/ --with-libxml-dir=/usr/local --with-gd --with-bz2 --with-pcre-regex --with-iconv --with-ttf --with-zlib --with-sqlite3 --enable-session --enable-json --enable-gd-native-ttf --enable-inline-optimization --enable-mbstring --enable-xml --enable-dom --enable-simplexml --enable-fpm --with-fpm-user=www --with-fpm-group=www --with-regex=php --with-zend-vm=CALL --disable-ipv6 --prefix=/usr/local --mandir=/usr/local/man --infodir=/usr/local/info/ Some strange info i get, when do ./configure --help --disable-mysqlnd-compression-support Enable support for the MySQL compressed protocol in mysqlnd :) -- Edit this bug report at https://bugs.php.net/bug.php?id=55067edit=1
Bug #55067 [Com]: MySQL doesn't support compression
Edit report at https://bugs.php.net/bug.php?id=55067edit=1 ID: 55067 Comment by: belov1985 at gmail dot com Reported by:belov1985 at gmail dot com Summary:MySQL doesn't support compression Status: Closed Type: Bug Package:MySQLi related Operating System: FreeBSD 8.2 PHP Version:5.3.6 Assigned To:ahristov Block user comment: N Private report: N New Comment: root ./configure --enable-mysqlnd --with-mysql=mysqlnd --with-mysqli=mysqlnd --disable-mysqlnd-compression-support ... checking whether to enable mysqlnd... yes checking whether to disable compressed protocol support in mysqlnd... no ... but result is the same: mysqlnd mysqlnd = enabled Version = mysqlnd 5.0.8-dev - 20102224 - $Revision: 310735 $ Compression = not supported Previous Comments: [2011-09-12 22:03:33] belov1985 at gmail dot com Download php5.3-201109122030 root./configure --help | grep mysqlnd-compression --disable-mysqlnd-compression-support Seems ok... root ./configure --enable-mysqlnd --with-mysql=mysqlnd --with-mysqli=mysqlnd make ... checking whether to enable mysqlnd... yes checking whether to disable compressed protocol support in mysqlnd... yes ... after building: root sapi/cli/php -i mysqlnd mysqlnd = enabled Version = mysqlnd 5.0.8-dev - 20102224 - $Revision: 310735 $ Compression = not supported Not fixed :( [2011-09-02 13:20:52] and...@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/. For Windows: http://windows.php.net/snapshots/ Thank you for the report, and for helping us make PHP better. Thanks for your report. Fix will appear in 5.3.9 [2011-07-20 10:25:25] u...@php.net Andrey, can you have a look? You've been the last one working on the config9.m4. Seems buggy. [2011-06-29 09:46:55] belov1985 at gmail dot com Description: Version mysqlnd 5.0.8-dev - 20102224 - $Revision: 308673 $ Compression not supported PHP build info: ./configure --with-layout=GNU --localstatedir=/var --with-config-file-scan-dir=/usr/local/etc/php --disable-all --enable-libxml --with-pcre-regex=/usr/local --with-zlib-dir=/usr --program-prefix= --with-mysql=mysqlnd --with-mysqli=mysqlnd --with-mcrypt --with-curl --with-jpeg-dir=/usr/local/lib/ --with-freetype-dir=/usr/local/include/freetype2/ --with-png-dir=/usr/local/lib/ --with-iconv-dir=/usr/local/lib --with-libxml-dir=/usr/local/include/ --with-libxml-dir=/usr/local --with-gd --with-bz2 --with-pcre-regex --with-iconv --with-ttf --with-zlib --with-sqlite3 --enable-session --enable-json --enable-gd-native-ttf --enable-inline-optimization --enable-mbstring --enable-xml --enable-dom --enable-simplexml --enable-fpm --with-fpm-user=www --with-fpm-group=www --with-regex=php --with-zend-vm=CALL --disable-ipv6 --prefix=/usr/local --mandir=/usr/local/man --infodir=/usr/local/info/ Some strange info i get, when do ./configure --help --disable-mysqlnd-compression-support Enable support for the MySQL compressed protocol in mysqlnd :) -- Edit this bug report at https://bugs.php.net/bug.php?id=55067edit=1
Req #39771 [Com]: DOMDocument-saveHTML does not accept an optional DOMNode like saveXML
Edit report at https://bugs.php.net/bug.php?id=39771edit=1 ID: 39771 Comment by: jbolter at gmail dot com Reported by:dave dot lane at gmx dot net Summary:DOMDocument-saveHTML does not accept an optional DOMNode like saveXML Status: Closed Type: Feature/Change Request Package:*General Issues Operating System: Linux PHP Version:5.2.0 Assigned To:cataphract Block user comment: N Private report: N New Comment: I am running PHP 5.3.6 but still get this error: PHP Warning: DOMDocument::saveHTML() expects exactly 0 parameters, 1 given Any ideas? Previous Comments: [2011-01-18 20:56:11] cataphr...@php.net Automatic comment from SVN on behalf of cataphract Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=307562 Log: - Fixed wrong function call in original commit to FR #39771. [2011-01-18 20:45:54] cataphr...@php.net Implemented for PHP 5.3 and trunk. [2011-01-18 20:45:40] cataphr...@php.net Automatic comment from SVN on behalf of cataphract Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=307561 Log: - Implemented FR #39771 (Made DOMDocument::saveHTML accept an optional DOMNode like DOMDocument::saveXML). [2006-12-07 19:34:19] dave dot lane at gmx dot net Description: DOMDocument-saveHTML does not accept an optional DOMNode like DOMDocument-saveXML. In saveXML this functionality is implemented using xmlNodeDump. libxml2 offers the html equivalent htmlNodeDump. Is there a good reason why this is not implemented? -- Edit this bug report at https://bugs.php.net/bug.php?id=39771edit=1
Bug #55660 [Fbk]: SplFixedArray::fromArray causing segmentation fault 11
Edit report at https://bugs.php.net/bug.php?id=55660edit=1
ID: 55660
Updated by: larue...@php.net
Reported by:rewilliams at crystaltech dot com
Summary:SplFixedArray::fromArray causing segmentation fault
11
Status: Feedback
Type: Bug
Package:Reproducible crash
Operating System: Mac OS X 10.7.1
PHP Version:5.3.8
Block user comment: N
Private report: N
New Comment:
Please try using this snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
Hi, I still can not reproduce with your data.csv, could you try with the
5.3-trunk?
Previous Comments:
[2011-09-12 18:05:53] rewilliams at crystaltech dot com
laruence@: I just caught that you stated your test file had 1005 lines. I'm not
sure if you misread what I wrote or if you mistyped what you tested, but the
test file I used was 10005 lines - you're off by an order of magnitude.
I uploaded my file to Dropbox. You can grab it here:
http://dl.dropbox.com/u/9434155/data.csv
If you're able to grab it and attach it to the bug or make it available
someplace more permanent, that would be great.
[2011-09-12 18:00:42] rewilliams at crystaltech dot com
FWIW, I just reproduced it on a Linux server running 5.3.4. I'm working on
getting
a backtrace, but I need to build a debug version of PHP first.
[2011-09-10 03:59:47] larue...@php.net
Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php for *NIX and
http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32
Once you have generated a backtrace, please submit it to this bug
report and change the status back to Open. Thank you for helping
us make PHP better.
I can not reproduce it with a test csv file(1005 line, 13 cloumns) with 5.3
trunk
[2011-09-09 21:32:23] rewilliams at crystaltech dot com
Hmm, I don't see how to upload reproduction scripts. The script is below; I'll
leave the data
file to the tester. I created a simple CSV file that had 10,005 lines of 13
columns each, where
the value of every column is the alphabet. It included one trailing blank line
and used CRLF line
endings.
Here's the script:
?php
ini_set('display_errors', 1);
ini_set('error_reporting', E_ALL | E_STRICT);
class NmsObj {
static public function ImportData($whichOption) {
$fileObj = new SplFileObject('TestData.csv');
$fileObj-setFlags(SplFileObject::SKIP_EMPTY |
SplFileObject::DROP_NEW_LINE |
SplFileObject::READ_CSV);
$return = array();
foreach ($fileObj as $oneLine) {
$return[] = new stdClass();
} //foreach
switch ($whichOption) {
case 1:
$return = array_slice($return, 0, );
$result = SplFixedArray::fromArray($return);
//we get here
return $result;
break;
case 2:
$return = array_slice($return, 0, 1);
$result = SplFixedArray::fromArray($return);
//we won't get here - get Segmentation fault:
11
return $result;
break;
} //switch
} //ImportData
} //NmsObj
//$dataSet1 = NmsObj::ImportData(1);
$dataSet1 = NmsObj::ImportData(2);
echo Done!\n;
?
[2011-09-09 21:26:12] rewilliams at crystaltech dot com
Description:
I created a script that uses SplFileObject to iterate over a CSV file. As it
goes, it creates a new object with each line's data and adds the object to an
array. Running it with 10k or more lines crashes with a Segmentation fault:
11
error message, while anything up to 9,999 lines works well. Adjusting PHP's
memory limit had no effect.
I've attached a partial reduction to this bug. It seems like I really need the
elements of the SplFileObject and the class for each line, as skipping either
one of those (even when the resulting array is much larger than 10k items)
causes the failure to disappear. I'm not sure exactly what the trigger is,
however. My reduction includes a sample CSV file of just over 10k lines, and
though it still uses SplFileObject and a per-line
