Bug #52463 [Dup]: SimpleXml ignores attributes
Edit report at http://bugs.php.net/bug.php?id=52463&edit=1 ID: 52463 User updated by:circus2 at freenet dot de Reported by:circus2 at freenet dot de Summary:SimpleXml ignores attributes Status: Duplicate Type: Bug Package:SimpleXML related Operating System: Win7 Home Premium GER PHP Version:5.3.3 Block user comment: N New Comment: I'm not concerned about var_dump(). I think more of json_encode() which has the same issues. I use json_encode/json_decode to transform a SimpleXml object to an array. print_r(json_decode(json_encode($xml), true))); Previous Comments: [2010-07-27 23:10:27] ras...@php.net This is a known cosmetic issue in var_dump(). If you actually iterate through the object it works fine. [2010-07-27 21:26:21] circus2 at freenet dot de Description: I have a short xml and the attributes for the second node are not available. Test script: --- $xml = ' myValue '; var_dump(simplexml_load_string($xml)); Expected result: Array ( [value] => Array ( [0] => Array ( [...@attributes] => Array ( [type] => string [key] => name ) ) [1] => Array ( [...@attributes] => Array ( [type] => string [key] => name ) [0] => myValue ) ) ) Or something similar. Actual result: -- Array ( [value] => Array ( [0] => Array ( [...@attributes] => Array ( [type] => string [key] => name ) ) [1] => myValue ) ) -- Edit this bug report at http://bugs.php.net/bug.php?id=52463&edit=1
[PHP-BUG] Bug #52465 [NEW]: Some Thing Wrong With The debug_backtrace()
From:
Operating system: Windows Vista
PHP version: 5.3.3
Package: Scripting Engine problem
Bug Type: Bug
Bug description:Some Thing Wrong With The debug_backtrace()
Description:
Did you see the Output of the script?
but why the type of "method a" was "->" it must be "::"!
because I use it with the static method...
maybe it isn't a bug but it's really a big problem to me
AND. I'm poor at English~~~... Please forgive me~
Test script:
---
class R{
function a(){
print_r(debug_backtrace());
}
}
class X{
function b(){
R::a();
}
}
$A = new X;
echo $A->b();
Expected result:
Array
(
[0] => Array
(
[file] => G:\Site\Test2\1.php
[line] => 11
[function] => a
[class] => R
[object] => X Object
(
)
[type] => ->
[args] => Array
(
)
)
[1] => Array
(
[file] => G:\Site\Test2\1.php
[line] => 15
[function] => b
[class] => X
[object] => X Object
(
)
[type] => ->
[args] => Array
(
)
)
)
--
Edit bug report at http://bugs.php.net/bug.php?id=52465&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=52465&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=52465&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=52465&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=52465&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=52465&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=52465&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=52465&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=52465&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=52465&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=52465&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=52465&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=52465&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=52465&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=52465&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52465&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=52465&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=52465&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=52465&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=52465&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=52465&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=52465&r=mysqlcfg
Bug #45712 [Com]: $something == NaN returns true with 5.3, false with 5.2.*
Edit report at http://bugs.php.net/bug.php?id=45712&edit=1
ID: 45712
Comment by: jwvdveer at gmail dot com
Reported by:for-bugs at hnw dot jp
Summary:$something == NaN returns true with 5.3, false with
5.2.*
Status: Closed
Type: Bug
Package:Variables related
Operating System: *
PHP Version:5.2CVS, 5.3CVS, 6CVS (2008-08-05)
Assigned To:tony2001
Block user comment: N
New Comment:
Please, reopen this bug. It's not working in PHP 5.3.3 on Windows
platform (released at 2010-07-21).
The behaviour of a comparison to NAN is the same as noted here.
It's not just a `me too`, but this thread shouln't have been closed.
Previous Comments:
[2008-08-07 08:36:33] tony2...@php.net
This bug has been fixed in CVS.
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.
[2008-08-07 07:37:04] tony2...@php.net
I'm testing a patch for it.
[2008-08-05 12:52:06] for-bugs at hnw dot jp
NaN is not exact number. So, NaN should not equals itself. Additionaly,
NaN == NaN is false in C. You can see behavior of C as follows.
$ cat nan.c
int main() {double d;d=(-1e300*1e300)/(1e300*1e300);if (d==d) return 1;
else return 2;}
$ gcc nan.c; ./a.out; echo $?
2
$
[2008-08-05 12:33:17] j...@php.net
That $nan == $nan should be true. (like it is with 5.3)
[2008-08-05 02:39:58] for-bugs at hnw dot jp
Description:
There is == operator's problem dealing with NaN(Not a Number) in PHP
5.3.0alpha1. This behavior is different with PHP 5.0.0-5.2.6, so this is
compatibility problem.
Reproduce code:
---
http://bugs.php.net/bug.php?id=45712&edit=1
[PHP-BUG] Bug #52464 [NEW]: spl_autoload_register() can use protected/private methods if called from class
From:
Operating system: Windows 7, Linux Slackware
PHP version: 5.3.3
Package: SPL related
Bug Type: Bug
Bug description:spl_autoload_register() can use protected/private methods if
called from class
Description:
If spl_autoload_register() is called from class method, SPL autoloader can
use private and protected methods, although SPL is not a part of this
class. It works well if spl_autoload_register() is called from somewhere
else.
Test script:
---
__construct()
#2 {main}
thrown in test.php on line 5
Actual result:
--
CallbackTest::publicCallback
CallbackTest::protectedCallback
CallbackTest::privateCallback
PHP Fatal error: Class 'AutoloadTest' not found in test.php on line 19
--
Edit bug report at http://bugs.php.net/bug.php?id=52464&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=52464&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=52464&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=52464&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=52464&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=52464&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=52464&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=52464&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=52464&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=52464&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=52464&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=52464&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=52464&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=52464&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=52464&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52464&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=52464&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=52464&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=52464&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=52464&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=52464&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=52464&r=mysqlcfg
Bug #51991 [Csd]: spl_autoload and *nix support with namespace
Edit report at http://bugs.php.net/bug.php?id=51991&edit=1 ID: 51991 Updated by: fel...@php.net Reported by:grummfy at gmail dot com Summary:spl_autoload and *nix support with namespace Status: Closed Type: Bug Package:SPL related Operating System: linux, mac, *nix PHP Version:5.3.2 Assigned To:felipe Block user comment: N New Comment: Exactly. You can implement your custom autoload to behaves as you want. The lowercased stuff is good for some people, but is not the desired for others. Previous Comments: [2010-07-27 20:05:46] xstansa at gmail dot com Are you saying that I'll have to rename all my php file names to be lowercase on Linux to use spl_autoload? [2010-07-27 03:34:20] fel...@php.net Hi, I forgot to say... the path that will be tried to be found it is lowercased. i.e. my/framework/test.php See bug #52406 Thanks. [2010-07-27 02:58:24] xstansa at gmail dot com I've already checked that using phpinfo(). It is PHP 5.3.3. [2010-07-26 23:54:29] fel...@php.net Hi, make sure you are using the right version... (phpversion()) [2010-07-26 23:01:53] xstansa at gmail dot com I just upgraded to PHP 5.3.3 and this bug still persists. Tested on Linux (Cent OS 5.5) with PHP 5.3.3. Same Test Script and result as the original bug. 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 http://bugs.php.net/bug.php?id=51991 -- Edit this bug report at http://bugs.php.net/bug.php?id=51991&edit=1
Req #52461 [Opn->Asn]: phpinfo() corrections/improvments
Edit report at http://bugs.php.net/bug.php?id=52461&edit=1 ID: 52461 Updated by: ka...@php.net Reported by:virsacer at web dot de Summary:phpinfo() corrections/improvments -Status: Open +Status: Assigned Type: Feature/Change Request Package:*General Issues PHP Version:5.3.3 -Assigned To: +Assigned To:kalle Block user comment: N New Comment: Assigning this to myself, the changes to $ and single quotes should go in trunk if any imo Previous Comments: [2010-07-27 20:03:35] virsacer at web dot de Description: 1.+2. Show "PHP Variables" with leading "$" and use single quotes. 3. "Windows 7" and "Windows Server 2008 R2" are "Unknow Windows version" because checking for NT 6.2 instead of 6.1 4. Incomplete doctype and missing xmlns. -- Edit this bug report at http://bugs.php.net/bug.php?id=52461&edit=1
Bug #52436 [Asn->Csd]: Compile error if systems do not have stdint.h
Edit report at http://bugs.php.net/bug.php?id=52436&edit=1 ID: 52436 Updated by: srina...@php.net Reported by:hiropontepocon at gmail dot com Summary:Compile error if systems do not have stdint.h -Status: Assigned +Status: Closed Type: Bug Package:Compile Failure Operating System: Solaris8 PHP Version:5.2.14 Assigned To:srinatar Block user comment: N Previous Comments: [2010-07-27 23:42:24] srina...@php.net Automatic comment from SVN on behalf of srinatar Revision: http://svn.php.net/viewvc/?view=revision&revision=301625 Log: - Fixed bug #52436 (Compile error in pcre if systems do not have stdint.h) # PCRE's config.h can very well reuse the definitions made available from # PHP's configure script output available within php_config.h [2010-07-27 19:13:39] hiropontepocon at gmail dot com > in quick look, patching pcrelib/pcre_internal.h in this way, seems to help Patch works fine. Thanks! By the way, Is the following code correct? ext/pcre/pcrelib/config.h: ã»ã»ã» /* Define to 1 if you have the header file. */ #ifndef HAVE_STDINT_H #define HAVE_STDINT_H 1 #endif [2010-07-27 17:42:22] paj...@php.net Pls apply it as long as it works on linux too :) [2010-07-27 17:39:24] hiropontepocon at gmail dot com php-5.2.13 â OK php-5.2.14 â Compile Failed php-5.3.2 â OK php-5.3.3 â Compile Failed [2010-07-27 04:32:04] srina...@php.net in quick look, patching pcrelib/pcre_internal.h in this way, seems to help --- ext/pcre/pcrelib/pcre_internal.h.ORIG Wed Jun 2 15:31:21 2010 +++ ext/pcre/pcrelib/pcre_internal.hWed Jun 2 15:38:08 2010 @@ -193,10 +193,10 @@ by "configure". */ #ifdef PHP_WIN32 #include "win32/php_stdint.h" -#elif HAVE_STDINT_H -#include #elif HAVE_INTTYPES_H #include +#elif HAVE_STDINT_H +#include #endif 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 http://bugs.php.net/bug.php?id=52436 -- Edit this bug report at http://bugs.php.net/bug.php?id=52436&edit=1
Bug #52463 [Opn->Dup]: SimpleXml ignores attributes
Edit report at http://bugs.php.net/bug.php?id=52463&edit=1 ID: 52463 Updated by: ras...@php.net Reported by:circus2 at freenet dot de Summary:SimpleXml ignores attributes -Status: Open +Status: Duplicate Type: Bug Package:SimpleXML related Operating System: Win7 Home Premium GER PHP Version:5.3.3 Block user comment: N New Comment: This is a known cosmetic issue in var_dump(). If you actually iterate through the object it works fine. Previous Comments: [2010-07-27 21:26:21] circus2 at freenet dot de Description: I have a short xml and the attributes for the second node are not available. Test script: --- $xml = ' myValue '; var_dump(simplexml_load_string($xml)); Expected result: Array ( [value] => Array ( [0] => Array ( [...@attributes] => Array ( [type] => string [key] => name ) ) [1] => Array ( [...@attributes] => Array ( [type] => string [key] => name ) [0] => myValue ) ) ) Or something similar. Actual result: -- Array ( [value] => Array ( [0] => Array ( [...@attributes] => Array ( [type] => string [key] => name ) ) [1] => myValue ) ) -- Edit this bug report at http://bugs.php.net/bug.php?id=52463&edit=1
Req #41670 [Com]: ReflectionProperty class in reflection api lacks getDefaultValue method
Edit report at http://bugs.php.net/bug.php?id=41670&edit=1 ID: 41670 Comment by: rasmus at mindplay dot dk Reported by:killgec at gmail dot com Summary:ReflectionProperty class in reflection api lacks getDefaultValue method Status: Open Type: Feature/Change Request Package:Feature/Change Request PHP Version:5.2.3 Block user comment: N New Comment: Yep, missing for me too - this is one of the two missing features holding back some of the really cool stuff you could do with reflection... there are no good workarounds for this, it really needs to be fixed. Previous Comments: [2010-06-01 02:37:28] jonwage at gmail dot com I could use this feature as well. [2009-05-06 08:35:47] no2spam at chello dot nl This would be very useful for me. Especially for code generation [2007-06-12 11:45:45] killgec at gmail dot com Description: ReflectionProperty class in reflection api lacks getDefaultValue method. So there is no way to find out if a property in a class examined with reflection API has a default value, and what this value is. -- Edit this bug report at http://bugs.php.net/bug.php?id=41670&edit=1
Req #40457 [Com]: ReflectionProperty lacks method getStartLine() / getEndLine()
Edit report at http://bugs.php.net/bug.php?id=40457&edit=1
ID: 40457
Comment by: rasmus at mindplay dot dk
Reported by:ralph at smashlabs dot com
Summary:ReflectionProperty lacks method getStartLine() /
getEndLine()
Status: Open
Type: Feature/Change Request
Package:Feature/Change Request
Operating System: Linux 2.6
PHP Version:5.2.1
Block user comment: N
New Comment:
Yes, this is missing for me too. Badly.
Trying to work around this by manually scanning the source code for the
property definition would be a huuuge PITA... :-(
Previous Comments:
[2007-02-13 04:40:08] ralph at smashlabs dot com
Description:
Simply put, when getting a property (in the same manner as a method)
from a class, ReflectionProperty lacks the ability (as does the
ReflectionClass) to retrieve a line number from where the property was
defined.
- Properties [1] {
Property [ protected $_Id ]
}
- Methods [3] {
Method [ public method get ] {
@@
/home/webdeveloper/vhosts/zdiis2.dev/development/modeling/models/ZDISubmission.php
11 - 14
- Parameters [1] {
Parameter #0 [ $identifiers = Array ]
}
}
--
Edit this bug report at http://bugs.php.net/bug.php?id=40457&edit=1
[PHP-BUG] Bug #52463 [NEW]: SimpleXml ignores attributes
From: Operating system: Win7 Home Premium GER PHP version: 5.3.3 Package: SimpleXML related Bug Type: Bug Bug description:SimpleXml ignores attributes Description: I have a short xml and the attributes for the second node are not available. Test script: --- $xml = ' myValue '; var_dump(simplexml_load_string($xml)); Expected result: Array ( [value] => Array ( [0] => Array ( [...@attributes] => Array ( [type] => string [key] => name ) ) [1] => Array ( [...@attributes] => Array ( [type] => string [key] => name ) [0] => myValue ) ) ) Or something similar. Actual result: -- Array ( [value] => Array ( [0] => Array ( [...@attributes] => Array ( [type] => string [key] => name ) ) [1] => myValue ) ) -- Edit bug report at http://bugs.php.net/bug.php?id=52463&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=52463&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=52463&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=52463&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=52463&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=52463&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=52463&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=52463&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=52463&r=needscript Try newer version: http://bugs.php.net/fix.php?id=52463&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=52463&r=support Expected behavior: http://bugs.php.net/fix.php?id=52463&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=52463&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=52463&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=52463&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52463&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=52463&r=dst IIS Stability: http://bugs.php.net/fix.php?id=52463&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=52463&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=52463&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=52463&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=52463&r=mysqlcfg
Bug #52458 [Com]: spl_object_hash() has strange behaviors with SimpleXML
Edit report at http://bugs.php.net/bug.php?id=52458&edit=1
ID: 52458
Comment by: runpac314 at gmail dot com
Reported by:ivan dot enderlin at hoa-project dot net
Summary:spl_object_hash() has strange behaviors with
SimpleXML
Status: Open
Type: Bug
Package:SimpleXML related
PHP Version:5.3SVN-2010-07-27 (SVN)
Block user comment: N
New Comment:
The hash is partially computed with the object handle the zval is
pointing to.
In the above test script, zvals are destroyed when f() and g() return
because
they are not referenced anywhere else.
When accessing a sxe property through a dim read (->), a new zval with a
type
IS_OBJECT is created and it's given a new object handle. These object
handles
are cycling depending on the availability in the store.
I do not think it's a bug. It's just how SimpleXML gives access to the
internal
libxml nodes to the user.
There are 2 kinds of hash below. One for each variable ($a and $b). Both
are
different objects even if the
underlying libxml node pointer is the same.
$a = $sxe->p;
$b = $sxe->p[0];
var_dump(f($a));
var_dump(f($a));
var_dump(f($b));
var_dump(f($b));
var_dump(f($b));
var_dump(f($b));
var_dump(f($b));
var_dump(f($b));
Previous Comments:
[2010-07-27 16:01:24] ivan dot enderlin at hoa-project dot net
Description:
Hey :-),
spl_object_hash() has strange behaviors with SimpleXML.
You know that SimpleXMLElement uses properties to access to its children
collection and array-access to reach a specific child into this
collection.
So, if we want to reach an element, we have to do: $sxe->element[0] for
example. Unfortunately, it appears to always return a ânew objectâ
according to spl_object_hash(). Please, see the code below.
You can notice that $sxe->p has sometimes the same has than $sxe-p[0].
And why $sxe-p[0] has most of the time a different hash?
Test script:
---
' . "\n\n" .
'' . "\n" .
' Foobar' . "\n" .
'';
$sxe = simplexml_load_string($xml);
function f ( $e ) {
return spl_object_hash($e);
}
var_dump(f($sxe->p));
var_dump(f($sxe->p));
var_dump(f($sxe->p[0]));
var_dump(f($sxe->p[0]));
var_dump(f($sxe->p[0]));
var_dump(f($sxe->p[0]));
var_dump(f($sxe->p[0]));
var_dump(f($sxe->p[0]));
echo "\n" . 'Light!' . "\n\n";
function g ( $e ) {
return substr(f($e), 14, 2);
}
var_dump(g($sxe->p));
var_dump(g($sxe->p));
var_dump(g($sxe->p[0]));
var_dump(g($sxe->p[0]));
var_dump(g($sxe->p[0]));
var_dump(g($sxe->p[0]));
var_dump(g($sxe->p[0]));
var_dump(g($sxe->p[0]));
Expected result:
string(32) "5cddd92f2401191e"
string(32) "5cddd92f2401191e"
string(32) "5cddd9292401191e"
string(32) "5cddd9292401191e"
string(32) "5cddd9292401191e"
string(32) "5cddd9292401191e"
string(32) "5cddd9292401191e"
string(32) "5cddd9292401191e"
Light!
string(2) "2f"
string(2) "2f"
string(2) "29"
string(2) "29"
string(2) "29"
string(2) "29"
string(2) "29"
string(2) "29"
Actual result:
--
string(32) "5cddd92f2401191e"
string(32) "5cddd92f2401191e"
string(32) "5cddd9292401191e"
string(32) "5cddd92e2401191e"
string(32) "5cddd92f2401191e"
string(32) "5cddd9292401191e"
string(32) "5cddd92e2401191e"
string(32) "5cddd92f2401191e"
Light!
string(2) "2f" // p
string(2) "2f" // p, same hash, oof
string(2) "29" // p[0], ok
string(2) "2e" // p[0], huh?
string(2) "2f" // p[0], has the hash that p⦠why?
string(2) "29" // p[0], like the first p[0]
string(2) "2e" // p[0], we have a loop here
string(2) "2f" // p[0], definitively, we have a loop.
--
Edit this bug report at http://bugs.php.net/bug.php?id=52458&edit=1
Bug #51991 [Com]: spl_autoload and *nix support with namespace
Edit report at http://bugs.php.net/bug.php?id=51991&edit=1 ID: 51991 Comment by: xstansa at gmail dot com Reported by:grummfy at gmail dot com Summary:spl_autoload and *nix support with namespace Status: Closed Type: Bug Package:SPL related Operating System: linux, mac, *nix PHP Version:5.3.2 Assigned To:felipe Block user comment: N New Comment: Are you saying that I'll have to rename all my php file names to be lowercase on Linux to use spl_autoload? Previous Comments: [2010-07-27 03:34:20] fel...@php.net Hi, I forgot to say... the path that will be tried to be found it is lowercased. i.e. my/framework/test.php See bug #52406 Thanks. [2010-07-27 02:58:24] xstansa at gmail dot com I've already checked that using phpinfo(). It is PHP 5.3.3. [2010-07-26 23:54:29] fel...@php.net Hi, make sure you are using the right version... (phpversion()) [2010-07-26 23:01:53] xstansa at gmail dot com I just upgraded to PHP 5.3.3 and this bug still persists. Tested on Linux (Cent OS 5.5) with PHP 5.3.3. Same Test Script and result as the original bug. [2010-06-04 02:44:01] grummfy at gmail dot com 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 http://bugs.php.net/bug.php?id=51991 -- Edit this bug report at http://bugs.php.net/bug.php?id=51991&edit=1
[PHP-BUG] Req #52461 [NEW]: phpinfo() corrections/improvments
From: Operating system: PHP version: 5.3.3 Package: *General Issues Bug Type: Feature/Change Request Bug description:phpinfo() corrections/improvments Description: 1.+2. Show "PHP Variables" with leading "$" and use single quotes. 3. "Windows 7" and "Windows Server 2008 R2" are "Unknow Windows version" because checking for NT 6.2 instead of 6.1 4. Incomplete doctype and missing xmlns. -- Edit bug report at http://bugs.php.net/bug.php?id=52461&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=52461&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=52461&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=52461&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=52461&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=52461&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=52461&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=52461&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=52461&r=needscript Try newer version: http://bugs.php.net/fix.php?id=52461&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=52461&r=support Expected behavior: http://bugs.php.net/fix.php?id=52461&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=52461&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=52461&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=52461&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52461&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=52461&r=dst IIS Stability: http://bugs.php.net/fix.php?id=52461&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=52461&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=52461&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=52461&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=52461&r=mysqlcfg
Bug #52436 [Com]: Compile error if systems do not have stdint.h
Edit report at http://bugs.php.net/bug.php?id=52436&edit=1 ID: 52436 Comment by: hiropontepocon at gmail dot com Reported by:hiropontepocon at gmail dot com Summary:Compile error if systems do not have stdint.h Status: Assigned Type: Bug Package:Compile Failure Operating System: Solaris8 PHP Version:5.2.14 Assigned To:srinatar Block user comment: N New Comment: > in quick look, patching pcrelib/pcre_internal.h in this way, seems to help Patch works fine. Thanks! By the way, Is the following code correct? ext/pcre/pcrelib/config.h: ã»ã»ã» /* Define to 1 if you have the header file. */ #ifndef HAVE_STDINT_H #define HAVE_STDINT_H 1 #endif Previous Comments: [2010-07-27 17:42:22] paj...@php.net Pls apply it as long as it works on linux too :) [2010-07-27 17:39:24] hiropontepocon at gmail dot com php-5.2.13 â OK php-5.2.14 â Compile Failed php-5.3.2 â OK php-5.3.3 â Compile Failed [2010-07-27 04:32:04] srina...@php.net in quick look, patching pcrelib/pcre_internal.h in this way, seems to help --- ext/pcre/pcrelib/pcre_internal.h.ORIG Wed Jun 2 15:31:21 2010 +++ ext/pcre/pcrelib/pcre_internal.hWed Jun 2 15:38:08 2010 @@ -193,10 +193,10 @@ by "configure". */ #ifdef PHP_WIN32 #include "win32/php_stdint.h" -#elif HAVE_STDINT_H -#include #elif HAVE_INTTYPES_H #include +#elif HAVE_STDINT_H +#include #endif [2010-07-27 00:46:18] ka...@php.net Does this happen with older versions, or 5.3 for you? [2010-07-25 06:38:13] hiropontepocon at gmail dot com Description: $ ./configure ã»ã»ã» $ grep -i stdint main/php_config.h /* Define if you have the header file. */ /* #undef HAVE_STDINT_H */ $ make ã»ã»ã» /bin/ksh /tmp/php-5.2.14/libtool --silent --preserve-dup-deps --mode=compile gcc -I/tmp/php-5.2.14/ext/pcre/pcrelib -Iext/pcre/ -I/tmp/php-5.2.14/ext/pcre/ -DPHP_ATOM_INC -I/tmp/php-5.2.14/include -I/tmp/php-5.2.14/main -I/tmp/php-5.2.14 -I/tmp/php-5.2.14/ext/date/lib -I/usr/include/libxml2 -I/tmp/php-5.2.14/TSRM -I/tmp/php-5.2.14/Zend -D_POSIX_PTHREAD_SEMANTICS -I/usr/include -g -O2 -c /tmp/php-5.2.14/ext/pcre/pcrelib/pcre_chartables.c -o ext/pcre/pcrelib/pcre_chartables.lo In file included from /tmp/php-5.2.14/ext/pcre/pcrelib/pcre_chartables.c:25: /tmp/php-5.2.14/ext/pcre/pcrelib/pcre_internal.h:198:20: stdint.h: No such file or directory make: *** [ext/pcre/pcrelib/pcre_chartables.lo] Error 1 -- Edit this bug report at http://bugs.php.net/bug.php?id=52436&edit=1
Bug #52436 [Fbk->Asn]: Compile error if systems do not have stdint.h
Edit report at http://bugs.php.net/bug.php?id=52436&edit=1 ID: 52436 Updated by: paj...@php.net Reported by:hiropontepocon at gmail dot com Summary:Compile error if systems do not have stdint.h -Status: Feedback +Status: Assigned Type: Bug Package:Compile Failure Operating System: Solaris8 PHP Version:5.2.14 -Assigned To: +Assigned To:srinatar Block user comment: N New Comment: Pls apply it as long as it works on linux too :) Previous Comments: [2010-07-27 17:39:24] hiropontepocon at gmail dot com php-5.2.13 â OK php-5.2.14 â Compile Failed php-5.3.2 â OK php-5.3.3 â Compile Failed [2010-07-27 04:32:04] srina...@php.net in quick look, patching pcrelib/pcre_internal.h in this way, seems to help --- ext/pcre/pcrelib/pcre_internal.h.ORIG Wed Jun 2 15:31:21 2010 +++ ext/pcre/pcrelib/pcre_internal.hWed Jun 2 15:38:08 2010 @@ -193,10 +193,10 @@ by "configure". */ #ifdef PHP_WIN32 #include "win32/php_stdint.h" -#elif HAVE_STDINT_H -#include #elif HAVE_INTTYPES_H #include +#elif HAVE_STDINT_H +#include #endif [2010-07-27 00:46:18] ka...@php.net Does this happen with older versions, or 5.3 for you? [2010-07-25 06:38:13] hiropontepocon at gmail dot com Description: $ ./configure ã»ã»ã» $ grep -i stdint main/php_config.h /* Define if you have the header file. */ /* #undef HAVE_STDINT_H */ $ make ã»ã»ã» /bin/ksh /tmp/php-5.2.14/libtool --silent --preserve-dup-deps --mode=compile gcc -I/tmp/php-5.2.14/ext/pcre/pcrelib -Iext/pcre/ -I/tmp/php-5.2.14/ext/pcre/ -DPHP_ATOM_INC -I/tmp/php-5.2.14/include -I/tmp/php-5.2.14/main -I/tmp/php-5.2.14 -I/tmp/php-5.2.14/ext/date/lib -I/usr/include/libxml2 -I/tmp/php-5.2.14/TSRM -I/tmp/php-5.2.14/Zend -D_POSIX_PTHREAD_SEMANTICS -I/usr/include -g -O2 -c /tmp/php-5.2.14/ext/pcre/pcrelib/pcre_chartables.c -o ext/pcre/pcrelib/pcre_chartables.lo In file included from /tmp/php-5.2.14/ext/pcre/pcrelib/pcre_chartables.c:25: /tmp/php-5.2.14/ext/pcre/pcrelib/pcre_internal.h:198:20: stdint.h: No such file or directory make: *** [ext/pcre/pcrelib/pcre_chartables.lo] Error 1 -- Edit this bug report at http://bugs.php.net/bug.php?id=52436&edit=1
Bug #52436 [Com]: Compile error if systems do not have stdint.h
Edit report at http://bugs.php.net/bug.php?id=52436&edit=1 ID: 52436 Comment by: hiropontepocon at gmail dot com Reported by:hiropontepocon at gmail dot com Summary:Compile error if systems do not have stdint.h Status: Feedback Type: Bug Package:Compile Failure Operating System: Solaris8 PHP Version:5.2.14 Block user comment: N New Comment: php-5.2.13 â OK php-5.2.14 â Compile Failed php-5.3.2 â OK php-5.3.3 â Compile Failed Previous Comments: [2010-07-27 04:32:04] srina...@php.net in quick look, patching pcrelib/pcre_internal.h in this way, seems to help --- ext/pcre/pcrelib/pcre_internal.h.ORIG Wed Jun 2 15:31:21 2010 +++ ext/pcre/pcrelib/pcre_internal.hWed Jun 2 15:38:08 2010 @@ -193,10 +193,10 @@ by "configure". */ #ifdef PHP_WIN32 #include "win32/php_stdint.h" -#elif HAVE_STDINT_H -#include #elif HAVE_INTTYPES_H #include +#elif HAVE_STDINT_H +#include #endif [2010-07-27 00:46:18] ka...@php.net Does this happen with older versions, or 5.3 for you? [2010-07-25 06:38:13] hiropontepocon at gmail dot com Description: $ ./configure ã»ã»ã» $ grep -i stdint main/php_config.h /* Define if you have the header file. */ /* #undef HAVE_STDINT_H */ $ make ã»ã»ã» /bin/ksh /tmp/php-5.2.14/libtool --silent --preserve-dup-deps --mode=compile gcc -I/tmp/php-5.2.14/ext/pcre/pcrelib -Iext/pcre/ -I/tmp/php-5.2.14/ext/pcre/ -DPHP_ATOM_INC -I/tmp/php-5.2.14/include -I/tmp/php-5.2.14/main -I/tmp/php-5.2.14 -I/tmp/php-5.2.14/ext/date/lib -I/usr/include/libxml2 -I/tmp/php-5.2.14/TSRM -I/tmp/php-5.2.14/Zend -D_POSIX_PTHREAD_SEMANTICS -I/usr/include -g -O2 -c /tmp/php-5.2.14/ext/pcre/pcrelib/pcre_chartables.c -o ext/pcre/pcrelib/pcre_chartables.lo In file included from /tmp/php-5.2.14/ext/pcre/pcrelib/pcre_chartables.c:25: /tmp/php-5.2.14/ext/pcre/pcrelib/pcre_internal.h:198:20: stdint.h: No such file or directory make: *** [ext/pcre/pcrelib/pcre_chartables.lo] Error 1 -- Edit this bug report at http://bugs.php.net/bug.php?id=52436&edit=1
Bug #52284 [Ver]: Reproducible crash using curl_multi functions with FTP
Edit report at http://bugs.php.net/bug.php?id=52284&edit=1
ID: 52284
Updated by: paj...@php.net
Reported by:ahar...@php.net
Summary:Reproducible crash using curl_multi functions with
FTP
Status: Verified
Type: Bug
Package:cURL related
Operating System: Ubuntu 10.04 (and others)
PHP Version:5.3SVN-2010-07-08 (SVN)
Block user comment: N
New Comment:
@srinata
I don't think there is a release after 7.21.0. We have to wait for it :)
Previous Comments:
[2010-07-27 16:49:14] srina...@php.net
Ok, been debugging this since morning for fun. As Pierre mentioned
earlier, this
bug turns out to be a libcurl bug and a recent commit within libcurl
fixes the
underlying multi handler issue.
now, ubuntu has not shipped with recent versions of libcurl yet. so, you
will
need to manually download libcurl from below: and install to say
/usr/local
http://curl.haxx.se/snapshots/
once this new curl is installed, you will need to recompile php with
--with-
curl=/usr/local
if this satisfies ur concern, then we can close this bug.
hope this helps.
[2010-07-27 07:48:00] profy dot net at gmail dot com
Reproduced every time when call test script.
Test script:
---
$url) {
$curly[$id] = curl_init();
curl_setopt($curly[$id], CURLOPT_URL, $url);
curl_setopt($curly[$id], CURLOPT_RETURNTRANSFER, true);
// I've add this opt to speed up request, bug appearing
with or
without this line
curl_setopt($curly[$id], CURLOPT_NOBODY, true);
curl_multi_add_handle($mh, $curly[$id]);
}
$running = null;
do {
$status = curl_multi_exec($mh, $running);
usleep(1000);
} while($status == CURLM_CALL_MULTI_PERFORM || $running);
foreach ($curly as $id => $c) {
$result[$id] = curl_multi_getcontent($c);
curl_multi_remove_handle($mh, $c);
curl_close($c);
}
curl_multi_close($mh);
return $result;
}
$urls = array(
"4358521" =>
"ftp://ftp.ea.com/pub/ea/patches/nfs-underground/pc/en-uk/NFSU_EUROPE_PATCH_4.exe";,
"7458288" =>
"ftp://ftp.nero.com/software/plugins/WMAPlugin20937.exe";,
);
echo "";
print_R(multi_request($urls));
echo "";
[2010-07-27 04:57:11] srina...@php.net
able to reproduce this issue. here is the stack trace:
(gdb) where
#0 0x00520a58 in curl_write_header (data=0x18d3b78 "221
Goodbye.\r\nomplete.\r", size=1, nmemb=14, ctx=0x1876e58)
at
/home/sriramn/dev/php-src/branches/PHP_5_3/ext/curl/interface.c:1123
#1 0x7f106e187c26 in ?? () from /usr/lib/libcurl.so.4
#2 0x7f106e1885ad in ?? () from /usr/lib/libcurl.so.4
#3 0x7f106e18b2ed in ?? () from /usr/lib/libcurl.so.4
#4 0x7f106e18c64f in ?? () from /usr/lib/libcurl.so.4
#5 0x7f106e18c792 in ?? () from /usr/lib/libcurl.so.4
#6 0x7f106e18e9b2 in ?? () from /usr/lib/libcurl.so.4
#7 0x7f106e1a4813 in curl_multi_cleanup () from
/usr/lib/libcurl.so.4
#8 0x00527208 in _php_curl_multi_close (rsrc=0x1871970) at
/home/sriramn/dev/php-src/branches/PHP_5_3/ext/curl/multi.c:327
#9 0x007f246e in list_entry_destructor (ptr=0x1871970) at
/home/sriramn/dev/php-src/branches/PHP_5_3/Zend/zend_list.c:184
#10 0x007efa3b in zend_hash_del_key_or_index (ht=0xe1eaf0,
arKey=0x0, nKeyLength=0, h=4, flag=1) at
/home/sriramn/dev/php-src/branches/PHP_5_3/Zend/zend_hash.c:497
#11 0x007f1fa0 in _zend_list_delete (id=4) at
/home/sriramn/dev/php-src/branches/PHP_5_3/Zend/zend_list.c:58
#12 0x005271d5 in zif_curl_multi_close (ht=1,
return_value=0x187a140, return_value_ptr=0x0, this_ptr=0x0,
return_value_used=0)
at /home/sriramn/dev/php-src/branches/PHP_5_3/ext/curl/multi.c:319
[2010-07-21 13:11:10] profy dot net at gmail dot com
Sorry for bothering you, but I see now that bug still exists. My code
already had a workaround for that issue and I not disabled it when
testing against latest version (5.3.3RC3 and libcurl 7.21.0). Now
I've tested again with truly parallel 5 ftp requests and it is still
failing as it was with PHP 5.2.13 on Win XP SP3
[2010-07-21 12:39:00] paj...@php.net
Was a libCurl issue, fixed in latest release.
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report onli
Bug #48755 [Bgs]: There is no php5isapi.dll in zip or msi distribution
Edit report at http://bugs.php.net/bug.php?id=48755&edit=1 ID: 48755 Updated by: paj...@php.net Reported by:rclerkin at gmail dot com Summary:There is no php5isapi.dll in zip or msi distribution Status: Bogus Type: Bug Package:*General Issues Operating System: Windows PHP Version:5.3.0 Block user comment: N New Comment: Use fastcgi, as documented. Previous Comments: [2010-07-27 16:12:05] faifuhi at gmail dot com I downloaded the latest version from PHP website (.zip version) and to my surprise, php5isapi.dll is not included in the package. What now? [2009-07-01 14:24:17] rclerkin at gmail dot com I just found that isapi has been dropped. Please ignore this while I go and figure out how to set up php on iis6 without using the methods that proliferate the net. [2009-07-01 14:08:05] rclerkin at gmail dot com Description: After extracting the zip file php-5.3.0-Win32-VC9-x86.zip or after installing the MSI package php-5.3.0-Win32-VC9-x86.msi there is no file called php5isapi.dll. The source files for php5isapi are included in the source archive so it would appear that the binaries did not complile correctly. -- Edit this bug report at http://bugs.php.net/bug.php?id=48755&edit=1
Bug #52452 [Fbk->Csd]: Curl cannt work
Edit report at http://bugs.php.net/bug.php?id=52452&edit=1 ID: 52452 Updated by: paj...@php.net Reported by:bluephp at gmail dot com Summary:Curl cannt work -Status: Feedback +Status: Closed Type: Bug Package:cURL related Operating System: windows 2003 server PHP Version:5.2.14 -Assigned To: +Assigned To:pajoye Block user comment: N Previous Comments: [2010-07-27 16:57:07] jean-yves dot deleze at crealp dot vs dot ch I experienced the same problem with the binaries released on the 22nd of july (build date : 2010-07-21). A workaround was to add the zlib library (version 1.2.3) into the system path or into the PHP directory (with filename zlib.dll, not zlib1.dll). The binaries at http://windows.php.net/releases/ (build date : 2010-07-27) work like expected, without any zlib.dll related error. [2010-07-27 12:05:44] paj...@php.net Please try again using the binaries at http://windows.php.net/releases/ [2010-07-27 08:34:56] bluephp at gmail dot com Description: The problem happened just after I updated php_5.2.13 to php_5.2.14. You known, the php_5.2.13 is working well. I rename D:\php to D:\php_5.2.13,and rename D:\php_5.2.14 to D:\php ,and copy D:\php_5.2.13\php.ini to D:\php .Then restart IIS. When php_5.2.14 is running, I run the Test script , it didnot work. The D:\php\error.log said about "not loading the php_curl.dll". But the D:\php\ext\php_curl.dll is existing and the D:\php\php.ini options of php_curl.dll is open. Then I run D:\php\php.exe -m, it still didnot work. Alert window said about "the zlib.dll is error". I found the size of php_curl.dll in php_5.2.14 is small than in php_5.2.13. But other files in D:\php\ext is same of size. -- Edit this bug report at http://bugs.php.net/bug.php?id=52452&edit=1
Bug #52452 [Com]: Curl cannt work
Edit report at http://bugs.php.net/bug.php?id=52452&edit=1 ID: 52452 Comment by: jean-yves dot deleze at crealp dot vs dot ch Reported by:bluephp at gmail dot com Summary:Curl cannt work Status: Feedback Type: Bug Package:cURL related Operating System: windows 2003 server PHP Version:5.2.14 Block user comment: N New Comment: I experienced the same problem with the binaries released on the 22nd of july (build date : 2010-07-21). A workaround was to add the zlib library (version 1.2.3) into the system path or into the PHP directory (with filename zlib.dll, not zlib1.dll). The binaries at http://windows.php.net/releases/ (build date : 2010-07-27) work like expected, without any zlib.dll related error. Previous Comments: [2010-07-27 12:05:44] paj...@php.net Please try again using the binaries at http://windows.php.net/releases/ [2010-07-27 08:34:56] bluephp at gmail dot com Description: The problem happened just after I updated php_5.2.13 to php_5.2.14. You known, the php_5.2.13 is working well. I rename D:\php to D:\php_5.2.13,and rename D:\php_5.2.14 to D:\php ,and copy D:\php_5.2.13\php.ini to D:\php .Then restart IIS. When php_5.2.14 is running, I run the Test script , it didnot work. The D:\php\error.log said about "not loading the php_curl.dll". But the D:\php\ext\php_curl.dll is existing and the D:\php\php.ini options of php_curl.dll is open. Then I run D:\php\php.exe -m, it still didnot work. Alert window said about "the zlib.dll is error". I found the size of php_curl.dll in php_5.2.14 is small than in php_5.2.13. But other files in D:\php\ext is same of size. -- Edit this bug report at http://bugs.php.net/bug.php?id=52452&edit=1
Bug #52284 [Ver]: Reproducible crash using curl_multi functions with FTP
Edit report at http://bugs.php.net/bug.php?id=52284&edit=1
ID: 52284
Updated by: srina...@php.net
Reported by:ahar...@php.net
Summary:Reproducible crash using curl_multi functions with
FTP
Status: Verified
Type: Bug
Package:cURL related
Operating System: Ubuntu 10.04 (and others)
PHP Version:5.3SVN-2010-07-08 (SVN)
Block user comment: N
New Comment:
Ok, been debugging this since morning for fun. As Pierre mentioned
earlier, this
bug turns out to be a libcurl bug and a recent commit within libcurl
fixes the
underlying multi handler issue.
now, ubuntu has not shipped with recent versions of libcurl yet. so, you
will
need to manually download libcurl from below: and install to say
/usr/local
http://curl.haxx.se/snapshots/
once this new curl is installed, you will need to recompile php with
--with-
curl=/usr/local
if this satisfies ur concern, then we can close this bug.
hope this helps.
Previous Comments:
[2010-07-27 07:48:00] profy dot net at gmail dot com
Reproduced every time when call test script.
Test script:
---
$url) {
$curly[$id] = curl_init();
curl_setopt($curly[$id], CURLOPT_URL, $url);
curl_setopt($curly[$id], CURLOPT_RETURNTRANSFER, true);
// I've add this opt to speed up request, bug appearing
with or
without this line
curl_setopt($curly[$id], CURLOPT_NOBODY, true);
curl_multi_add_handle($mh, $curly[$id]);
}
$running = null;
do {
$status = curl_multi_exec($mh, $running);
usleep(1000);
} while($status == CURLM_CALL_MULTI_PERFORM || $running);
foreach ($curly as $id => $c) {
$result[$id] = curl_multi_getcontent($c);
curl_multi_remove_handle($mh, $c);
curl_close($c);
}
curl_multi_close($mh);
return $result;
}
$urls = array(
"4358521" =>
"ftp://ftp.ea.com/pub/ea/patches/nfs-underground/pc/en-uk/NFSU_EUROPE_PATCH_4.exe";,
"7458288" =>
"ftp://ftp.nero.com/software/plugins/WMAPlugin20937.exe";,
);
echo "";
print_R(multi_request($urls));
echo "";
[2010-07-27 04:57:11] srina...@php.net
able to reproduce this issue. here is the stack trace:
(gdb) where
#0 0x00520a58 in curl_write_header (data=0x18d3b78 "221
Goodbye.\r\nomplete.\r", size=1, nmemb=14, ctx=0x1876e58)
at
/home/sriramn/dev/php-src/branches/PHP_5_3/ext/curl/interface.c:1123
#1 0x7f106e187c26 in ?? () from /usr/lib/libcurl.so.4
#2 0x7f106e1885ad in ?? () from /usr/lib/libcurl.so.4
#3 0x7f106e18b2ed in ?? () from /usr/lib/libcurl.so.4
#4 0x7f106e18c64f in ?? () from /usr/lib/libcurl.so.4
#5 0x7f106e18c792 in ?? () from /usr/lib/libcurl.so.4
#6 0x7f106e18e9b2 in ?? () from /usr/lib/libcurl.so.4
#7 0x7f106e1a4813 in curl_multi_cleanup () from
/usr/lib/libcurl.so.4
#8 0x00527208 in _php_curl_multi_close (rsrc=0x1871970) at
/home/sriramn/dev/php-src/branches/PHP_5_3/ext/curl/multi.c:327
#9 0x007f246e in list_entry_destructor (ptr=0x1871970) at
/home/sriramn/dev/php-src/branches/PHP_5_3/Zend/zend_list.c:184
#10 0x007efa3b in zend_hash_del_key_or_index (ht=0xe1eaf0,
arKey=0x0, nKeyLength=0, h=4, flag=1) at
/home/sriramn/dev/php-src/branches/PHP_5_3/Zend/zend_hash.c:497
#11 0x007f1fa0 in _zend_list_delete (id=4) at
/home/sriramn/dev/php-src/branches/PHP_5_3/Zend/zend_list.c:58
#12 0x005271d5 in zif_curl_multi_close (ht=1,
return_value=0x187a140, return_value_ptr=0x0, this_ptr=0x0,
return_value_used=0)
at /home/sriramn/dev/php-src/branches/PHP_5_3/ext/curl/multi.c:319
[2010-07-21 13:11:10] profy dot net at gmail dot com
Sorry for bothering you, but I see now that bug still exists. My code
already had a workaround for that issue and I not disabled it when
testing against latest version (5.3.3RC3 and libcurl 7.21.0). Now
I've tested again with truly parallel 5 ftp requests and it is still
failing as it was with PHP 5.2.13 on Win XP SP3
[2010-07-21 12:39:00] paj...@php.net
Was a libCurl issue, fixed in latest release.
[2010-07-21 12:31:14] profy dot net at gmail dot com
I've tested with latest PHP5.3.3RC3 downloaded from
http://windows.php.net/qa/ and it works fine now with 5 FTP and 3 HTTP
parallel requests using curl_multi_* functions. This request failed
before. cURL version is 7.21.0. It seems bug is fixed in latest curl.
Bug #48755 [Com]: There is no php5isapi.dll in zip or msi distribution
Edit report at http://bugs.php.net/bug.php?id=48755&edit=1 ID: 48755 Comment by: faifuhi at gmail dot com Reported by:rclerkin at gmail dot com Summary:There is no php5isapi.dll in zip or msi distribution Status: Bogus Type: Bug Package:*General Issues Operating System: Windows PHP Version:5.3.0 Block user comment: N New Comment: I downloaded the latest version from PHP website (.zip version) and to my surprise, php5isapi.dll is not included in the package. What now? Previous Comments: [2009-07-01 14:24:17] rclerkin at gmail dot com I just found that isapi has been dropped. Please ignore this while I go and figure out how to set up php on iis6 without using the methods that proliferate the net. [2009-07-01 14:08:05] rclerkin at gmail dot com Description: After extracting the zip file php-5.3.0-Win32-VC9-x86.zip or after installing the MSI package php-5.3.0-Win32-VC9-x86.msi there is no file called php5isapi.dll. The source files for php5isapi are included in the source archive so it would appear that the binaries did not complile correctly. -- Edit this bug report at http://bugs.php.net/bug.php?id=48755&edit=1
[PHP-BUG] Bug #52458 [NEW]: spl_object_hash() has strange behaviors with SimpleXML
From:
Operating system:
PHP version: 5.3SVN-2010-07-27 (SVN)
Package: SimpleXML related
Bug Type: Bug
Bug description:spl_object_hash() has strange behaviors with SimpleXML
Description:
Hey :-),
spl_object_hash() has strange behaviors with SimpleXML.
You know that SimpleXMLElement uses properties to access to its children
collection and array-access to reach a specific child into this
collection.
So, if we want to reach an element, we have to do: $sxe->element[0] for
example. Unfortunately, it appears to always return a ânew objectâ
according to spl_object_hash(). Please, see the code below.
You can notice that $sxe->p has sometimes the same has than $sxe-p[0]. And
why $sxe-p[0] has most of the time a different hash?
Test script:
---
' . "\n\n" .
'' . "\n" .
' Foobar' . "\n" .
'';
$sxe = simplexml_load_string($xml);
function f ( $e ) {
return spl_object_hash($e);
}
var_dump(f($sxe->p));
var_dump(f($sxe->p));
var_dump(f($sxe->p[0]));
var_dump(f($sxe->p[0]));
var_dump(f($sxe->p[0]));
var_dump(f($sxe->p[0]));
var_dump(f($sxe->p[0]));
var_dump(f($sxe->p[0]));
echo "\n" . 'Light!' . "\n\n";
function g ( $e ) {
return substr(f($e), 14, 2);
}
var_dump(g($sxe->p));
var_dump(g($sxe->p));
var_dump(g($sxe->p[0]));
var_dump(g($sxe->p[0]));
var_dump(g($sxe->p[0]));
var_dump(g($sxe->p[0]));
var_dump(g($sxe->p[0]));
var_dump(g($sxe->p[0]));
Expected result:
string(32) "5cddd92f2401191e"
string(32) "5cddd92f2401191e"
string(32) "5cddd9292401191e"
string(32) "5cddd9292401191e"
string(32) "5cddd9292401191e"
string(32) "5cddd9292401191e"
string(32) "5cddd9292401191e"
string(32) "5cddd9292401191e"
Light!
string(2) "2f"
string(2) "2f"
string(2) "29"
string(2) "29"
string(2) "29"
string(2) "29"
string(2) "29"
string(2) "29"
Actual result:
--
string(32) "5cddd92f2401191e"
string(32) "5cddd92f2401191e"
string(32) "5cddd9292401191e"
string(32) "5cddd92e2401191e"
string(32) "5cddd92f2401191e"
string(32) "5cddd9292401191e"
string(32) "5cddd92e2401191e"
string(32) "5cddd92f2401191e"
Light!
string(2) "2f" // p
string(2) "2f" // p, same hash, oof
string(2) "29" // p[0], ok
string(2) "2e" // p[0], huh?
string(2) "2f" // p[0], has the hash that p⦠why?
string(2) "29" // p[0], like the first p[0]
string(2) "2e" // p[0], we have a loop here
string(2) "2f" // p[0], definitively, we have a loop.
--
Edit bug report at http://bugs.php.net/bug.php?id=52458&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=52458&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=52458&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=52458&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=52458&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=52458&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=52458&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=52458&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=52458&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=52458&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=52458&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=52458&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=52458&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=52458&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=52458&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52458&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=52458&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=52458&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=52458&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=52458&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=52458&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=52458&r=mysqlcfg
Bug #52403 [Com]: imagettfbbox/imagettftext "Could not read font" error
Edit report at http://bugs.php.net/bug.php?id=52403&edit=1 ID: 52403 Comment by: h...@php.net Reported by:h...@php.net Summary:imagettfbbox/imagettftext "Could not read font" error Status: Open Type: Bug Package:GD related Operating System: CentOS4 PHP Version:5.2.13 Block user comment: Y New Comment: To clarify: Expected result: Warning: imagettfbbox() [function.imagettfbbox]: Invalid font file in /home/share/www/dev/test/php/imagettfbbox.php on line 4 What PHP version? 5.2.13 Does font 'Vera.ttf' exist? Yes Is font 'Vera.ttf' readable? Yes Actual result: -- Warning: imagettfbbox() [function.imagettfbbox]: Could not read font in /home/share/www/dev/test/php/imagettfbbox.php on line 4 What PHP version? 5.2.13 Does font 'Vera.ttf' exist? Yes Is font 'Vera.ttf' readable? Yes Previous Comments: [2010-07-27 10:57:18] h...@php.net Excuse me, but this is -NOT- the same bug. Just because it's simply related does not make it the same. The problem here is the error, not the TTF files, which is the problem described in the other bug report. Please check and try again. [2010-07-27 01:04:09] ka...@php.net Same issue as in bug #52404 [2010-07-22 14:24:49] h...@php.net Description: Using the Vera.ttf font, which is part of the Image_Text PEAR package results in an odd error... The font can be found here: http://svn.php.net/viewvc/pear/packages/Image_Text/trunk/tests/Vera.ttf?view=log The error given by imagettfbbox() is "Could not read font". When tested with is_readable(), the font is indeed readable. When opening the Vera.ttf font file in windows, it produces the following error: "The requested file Vera.ttf was not a valid font file." It would appear that the file may well be corrupt, not that it "could not read". This error lead to a very confusing situation... I propose that the error should be more descriptive. Instead of "Could not read font", consider "Invalid font file". Test script: --- What PHP version? ".phpversion(); $read = file_exists($font)?'Yes':'No'; echo "\nDoes font '$font' exist? ".$read; $read = is_readable($font)?'Yes':'No'; echo "\nIs font '$font' readable? ".$read; ?> Expected result: Warning: imagettfbbox() [function.imagettfbbox]: Could not read font in /home/share/www/dev/test/php/imagettfbbox.php on line 4 Actual result: -- Warning: imagettfbbox() [function.imagettfbbox]: Could not read font in /home/share/www/dev/test/php/imagettfbbox.php on line 4 What PHP version? 5.2.13 Does font 'Vera.ttf' exist? Yes Is font 'Vera.ttf' readable? Yes -- Edit this bug report at http://bugs.php.net/bug.php?id=52403&edit=1
Bug #48216 [Com]: PHP Fatal error: SOAP-ERROR: Parsing WSDL: Extra content at the end of the doc
Edit report at http://bugs.php.net/bug.php?id=48216&edit=1
ID: 48216
Comment by: derek dot ethier at humber dot ca
Reported by:mark at everytruckjob dot com
Summary:PHP Fatal error: SOAP-ERROR: Parsing WSDL: Extra
content at the end of the doc
Status: Open
Type: Bug
Package:SOAP related
Operating System: CentOs 5.3
PHP Version:5.3.0RC2
Block user comment: N
New Comment:
I'm experiencing the same issue with the following WSDL file:
https://qa.everbridge.net/ws3/services/WebServices3?wsdl
I'm using 5.2.13 on Windows Server 2008.
Here is the XML parsing error:
object(LibXMLError)#1 (6) {
["level"]=>
int(3)
["code"]=>
int(5)
["column"]=>
int(5)
["message"]=>
string(41) "Extra content at the end of the document
"
["file"]=>
string(56) "https://qa.everbridge.net/ws3/services/WebServices3?wsdl";
["line"]=>
int(537)
}
Previous Comments:
[2010-04-29 19:08:59] eaf at oyatel dot no
Wow, this is bad, still not fixed in PHP 5.3.2.
Can this please be fixed for PHP 5.3.3?
[2010-04-01 01:33:11] roy dot laurie at gmail dot com
Also, this is the current workaround that I'm using to get around this:
//+ral HACK: v5.3.x / libxml - http://bugs.php.net/bug.php?id=48216
//- $soapClient = new SoapClient("{$serviceUri}?wsdl", $soapOptions);
$tmpWsdlPath = tempnam(sys_get_temp_dir(), 'wsdl');
copy("{$serviceUri}?wsdl", $tmpWsdlPath);
$soapClient = new SoapClient($tmpWsdlPath, $soapOptions);
[2010-04-01 01:11:25] roy dot laurie at gmail dot com
Verified in 5.3.2 against the Yahoo! EWS service.
HTTP/1.1 200 OK
Date: Wed, 31 Mar 2010 23:04:51 GMT
p3p: policyref="http://p3p.yahoo.com/w3c/p3p.xml";, CP="CAO DSP COR CUR
ADM DEV TAI PSA PSD IVAi IVDi CONi TELo OTPi OUR DELi SAMi OTRi UNRi
PUBi IND PHY ONL UNI PUR FIN COM NAV INT DEM CNT STA POL HEA PRE GOV"
Connection: close
Transfer-Encoding: chunked
Content-Type: text/xml;charset=utf-8
PHP 5.3.2 (cli) (built: Mar 5 2010 15:08:05)
Copyright (c) 1997-2010 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
with eAccelerator v0.9.6, Copyright (c) 2004-2010 eAccelerator, by
eAccelerator
with Xdebug v2.0.5, Copyright (c) 2002-2008, by Derick Rethans
[2010-01-11 15:46:45] mike dot hall at twistdigital dot co dot uk
I'm having the same issue, also using chunked-encoding.
Date: Mon, 11 Jan 2010 15:44:23 GMT
Last-Modified: Fri, 09 Oct 2009 13:49:56 GMT
Accept-Ranges: bytes
Content-Type: text/xml
Cache-Control: private
Content-Encoding: gzip
Transfer-Encoding: chunked
[2010-01-08 20:02:28] mike at pixor dot net
I downloaded the 1/6/10 5.3.3-dev snapshot and was still having issues
with SOAP WSDL file parsing. 5.2.12 works fine. Please keep this issue
open.
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
http://bugs.php.net/bug.php?id=48216
--
Edit this bug report at http://bugs.php.net/bug.php?id=48216&edit=1
Bug #52393 [Fbk->Csd]: __destructor of parameter object called on return
Edit report at http://bugs.php.net/bug.php?id=52393&edit=1 ID: 52393 User updated by:r dot spliet at student dot tudelft dot nl Reported by:r dot spliet at student dot tudelft dot nl Summary:__destructor of parameter object called on return -Status: Feedback +Status: Closed Type: Bug Package:Class/Object related Operating System: Fedora 13 PHP Version:5.3.2 Block user comment: N New Comment: My apologies. My problems were not related to class destruction on itself, but on the behaviour of mysql_connect(). A different object's destructor was (correctly) called, leading to the confusion. debug_print_backtrace() confirmed PHP's behaviour is correct and documented. Previous Comments: [2010-07-27 01:05:11] ka...@php.net Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , is max. 10-20 lines long and does not require any external resources such as databases, etc. If the script requires a database to demonstrate the issue, please make sure it creates all necessary tables, stored procedures etc. Please avoid embedding huge scripts into the report. [2010-07-21 20:23:48] r dot spliet at student dot tudelft dot nl Description: The situation is as following: class mysqlControl holds a MySQL connection. This class has a __destruct() method to close this connection properly Class x has one of these mysqlControl objects as a private variable. Class y has a method to represent itself in a MySQL way, and needs to escape a string. For this it needs the mysqlControl that class X holds. Now what happens is that Class x calls Class y's method to represent itself in some form that's useful to query MySQL. As a parameter to y's method X gives it's mysqlControl. Before y's method actually starts executing, mysqlControl's destructor is called. This means the connection is closed, and everything breaks. Expected result: I expected method y to not call mysqlControl's destructor but just uses the mysqlControl given and forgets about it. Actual result: -- mysqlControl's destructor gets called, breaking the mysql_real_escape_string() method before it could be used by class Y's method. -- Edit this bug report at http://bugs.php.net/bug.php?id=52393&edit=1
Req #52453 [Com]: Connection charset seems arbitrary
Edit report at http://bugs.php.net/bug.php?id=52453&edit=1 ID: 52453 Comment by: gerben at asystance dot nl Reported by:jeroen at asystance dot nl Summary:Connection charset seems arbitrary Status: Open Type: Feature/Change Request Package:MySQLi related Operating System: Linux PHP Version:5.3.3 Block user comment: N New Comment: I connected to the same remote database from a Windows/WAMP system and got exactly the same results. Previous Comments: [2010-07-27 12:09:15] jeroen at asystance dot nl BTW: when I make the same connection as in the first example, but use the mysql CLI client instead of php, I get mysql> SHOW VARIABLES LIKE 'character_set%'; +--++ | Variable_name| Value | +--++ | character_set_client | latin1 | | character_set_connection | latin1 | | character_set_database | utf8 | | character_set_filesystem | binary | | character_set_results| latin1 | | character_set_server | utf8 | | character_set_system | utf8 | | character_sets_dir | /usr/share/mysql/charsets/ | +--++ So PHP's mysql_connect() behaves differently from mysql cli! [2010-07-27 11:00:11] jeroen at asystance dot nl Description: The connection_charset used by a mysql/mysqli connection seems arbitrary - at least I cannot figure out how it is determined. The documentation provides no clues as to which charset is used by default. I've tried connecting to different mysql servers from different shell servers and can't figure out how the default charset is determined. As to find out which one is used, open a mysql/mysqli (procedural or object-oriented doesn't matter) connection and use mysql_client_encoding() / mysqli_get_charset() or "SHOW VARIABLES LIKE 'character_set%';" to find out. This probably is just a documentation problem, but maybe the default could be chosen more sensibly: for example, the mysql server database's charset seems the most sensible default. For example, connecting from a shell that has en_US.UTF-8 as locale, I get: character_set_client: utf8 character_set_connection: utf8 character_set_database: utf8 character_set_filesystem: binary character_set_results: utf8 character_set_server: utf8 character_set_system: utf8 character_sets_dir: /usr/share/mysql/charsets/ Switching to en_US.iso88591 doesn't change anything. So it would seem some server setting determines the charset, right? However, connecting to the same mysql server from another system (though from intranet instead of internet), I get: character_set_client: latin1 character_set_connection: latin1 character_set_database: utf8 character_set_filesystem: binary character_set_results: latin1 character_set_server: utf8 character_set_system: utf8 character_sets_dir: /usr/share/mysql/charsets/ Again, the client locale doesn't influence this. -- Edit this bug report at http://bugs.php.net/bug.php?id=52453&edit=1
Req #52453 [Com]: Connection charset seems arbitrary
Edit report at http://bugs.php.net/bug.php?id=52453&edit=1 ID: 52453 Comment by: jeroen at asystance dot nl Reported by:jeroen at asystance dot nl Summary:Connection charset seems arbitrary Status: Open Type: Feature/Change Request Package:MySQLi related Operating System: Linux PHP Version:5.3.3 Block user comment: N New Comment: BTW: when I make the same connection as in the first example, but use the mysql CLI client instead of php, I get mysql> SHOW VARIABLES LIKE 'character_set%'; +--++ | Variable_name| Value | +--++ | character_set_client | latin1 | | character_set_connection | latin1 | | character_set_database | utf8 | | character_set_filesystem | binary | | character_set_results| latin1 | | character_set_server | utf8 | | character_set_system | utf8 | | character_sets_dir | /usr/share/mysql/charsets/ | +--++ So PHP's mysql_connect() behaves differently from mysql cli! Previous Comments: [2010-07-27 11:00:11] jeroen at asystance dot nl Description: The connection_charset used by a mysql/mysqli connection seems arbitrary - at least I cannot figure out how it is determined. The documentation provides no clues as to which charset is used by default. I've tried connecting to different mysql servers from different shell servers and can't figure out how the default charset is determined. As to find out which one is used, open a mysql/mysqli (procedural or object-oriented doesn't matter) connection and use mysql_client_encoding() / mysqli_get_charset() or "SHOW VARIABLES LIKE 'character_set%';" to find out. This probably is just a documentation problem, but maybe the default could be chosen more sensibly: for example, the mysql server database's charset seems the most sensible default. For example, connecting from a shell that has en_US.UTF-8 as locale, I get: character_set_client: utf8 character_set_connection: utf8 character_set_database: utf8 character_set_filesystem: binary character_set_results: utf8 character_set_server: utf8 character_set_system: utf8 character_sets_dir: /usr/share/mysql/charsets/ Switching to en_US.iso88591 doesn't change anything. So it would seem some server setting determines the charset, right? However, connecting to the same mysql server from another system (though from intranet instead of internet), I get: character_set_client: latin1 character_set_connection: latin1 character_set_database: utf8 character_set_filesystem: binary character_set_results: latin1 character_set_server: utf8 character_set_system: utf8 character_sets_dir: /usr/share/mysql/charsets/ Again, the client locale doesn't influence this. -- Edit this bug report at http://bugs.php.net/bug.php?id=52453&edit=1
Bug #52452 [Opn->Fbk]: Curl cannt work
Edit report at http://bugs.php.net/bug.php?id=52452&edit=1 ID: 52452 Updated by: paj...@php.net Reported by:bluephp at gmail dot com Summary:Curl cannt work -Status: Open +Status: Feedback Type: Bug Package:cURL related Operating System: windows 2003 server PHP Version:5.2.14 Block user comment: N New Comment: Please try again using the binaries at http://windows.php.net/releases/ Previous Comments: [2010-07-27 08:34:56] bluephp at gmail dot com Description: The problem happened just after I updated php_5.2.13 to php_5.2.14. You known, the php_5.2.13 is working well. I rename D:\php to D:\php_5.2.13,and rename D:\php_5.2.14 to D:\php ,and copy D:\php_5.2.13\php.ini to D:\php .Then restart IIS. When php_5.2.14 is running, I run the Test script , it didnot work. The D:\php\error.log said about "not loading the php_curl.dll". But the D:\php\ext\php_curl.dll is existing and the D:\php\php.ini options of php_curl.dll is open. Then I run D:\php\php.exe -m, it still didnot work. Alert window said about "the zlib.dll is error". I found the size of php_curl.dll in php_5.2.14 is small than in php_5.2.13. But other files in D:\php\ext is same of size. -- Edit this bug report at http://bugs.php.net/bug.php?id=52452&edit=1
Bug #52454 [Opn->Asn]: Relative dates and getTimestamp increments by one day
Edit report at http://bugs.php.net/bug.php?id=52454&edit=1
ID: 52454
Updated by: der...@php.net
Reported by:ben dot davies at stickyeyes dot com
Summary:Relative dates and getTimestamp increments by one
day
-Status: Open
+Status: Assigned
Type: Bug
Package:Date/time related
Operating System: Windows 7 Professional
PHP Version:5.3.3
-Assigned To:
+Assigned To:derick
Block user comment: N
Previous Comments:
[2010-07-27 11:46:01] ben dot davies at stickyeyes dot com
Description:
If you create a DateTime object using a relative date string of "this
week +6 days", when calling getTimestamp on the datetime object, the
date is mysteriously increments by one day. However, if you seperately
modify the datetime using 'this week', then '+6 days', it works
correctly.
Where is the additional day comeing from, and why is it only applied
when calling format('U') DOESNT increment the datetime by 1 day. Wierd!
Here is a work around:
$endOfWeek = new DateTime();
$endOfWeek->modify('this week');
$endOfWeek->modify('+6 days');
echo $endOfWeek->format('Y-m-d H:m:s')."\n";
echo $endOfWeek->format('U')."\n";
/* Thar she blows! */
echo $endOfWeek->getTimestamp()."\n";
echo $endOfWeek->format('Y-m-d H:m:s')."\n";
Test script:
---
$endOfWeek = new DateTime();
$endOfWeek->modify('this week +6 days');
echo $endOfWeek->format('Y-m-d H:m:s')."\n";
echo $endOfWeek->format('U')."\n";
/* Thar she blows! */
echo $endOfWeek->getTimestamp()."\n";
echo $endOfWeek->format('Y-m-d H:m:s')."\n";
Expected result:
DateTime should stay the same after a call to getTimestamp (surely
getTimestamp should be safe from side effects)
--
Edit this bug report at http://bugs.php.net/bug.php?id=52454&edit=1
[PHP-BUG] Bug #52454 [NEW]: Relative dates and getTimestamp increments by one day
From:
Operating system: Windows 7 Professional
PHP version: 5.3.3
Package: Date/time related
Bug Type: Bug
Bug description:Relative dates and getTimestamp increments by one day
Description:
If you create a DateTime object using a relative date string of "this week
+6 days", when calling getTimestamp on the datetime object, the date is
mysteriously increments by one day. However, if you seperately modify the
datetime using 'this week', then '+6 days', it works correctly.
Where is the additional day comeing from, and why is it only applied when
calling format('U') DOESNT increment the datetime by 1 day. Wierd!
Here is a work around:
$endOfWeek = new DateTime();
$endOfWeek->modify('this week');
$endOfWeek->modify('+6 days');
echo $endOfWeek->format('Y-m-d H:m:s')."\n";
echo $endOfWeek->format('U')."\n";
/* Thar she blows! */
echo $endOfWeek->getTimestamp()."\n";
echo $endOfWeek->format('Y-m-d H:m:s')."\n";
Test script:
---
$endOfWeek = new DateTime();
$endOfWeek->modify('this week +6 days');
echo $endOfWeek->format('Y-m-d H:m:s')."\n";
echo $endOfWeek->format('U')."\n";
/* Thar she blows! */
echo $endOfWeek->getTimestamp()."\n";
echo $endOfWeek->format('Y-m-d H:m:s')."\n";
Expected result:
DateTime should stay the same after a call to getTimestamp (surely
getTimestamp should be safe from side effects)
--
Edit bug report at http://bugs.php.net/bug.php?id=52454&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=52454&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=52454&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=52454&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=52454&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=52454&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=52454&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=52454&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=52454&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=52454&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=52454&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=52454&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=52454&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=52454&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=52454&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52454&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=52454&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=52454&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=52454&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=52454&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=52454&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=52454&r=mysqlcfg
[PHP-BUG] Req #52453 [NEW]: Connection charset seems arbitrary
From: Operating system: Linux PHP version: 5.3.3 Package: MySQLi related Bug Type: Feature/Change Request Bug description:Connection charset seems arbitrary Description: The connection_charset used by a mysql/mysqli connection seems arbitrary - at least I cannot figure out how it is determined. The documentation provides no clues as to which charset is used by default. I've tried connecting to different mysql servers from different shell servers and can't figure out how the default charset is determined. As to find out which one is used, open a mysql/mysqli (procedural or object-oriented doesn't matter) connection and use mysql_client_encoding() / mysqli_get_charset() or "SHOW VARIABLES LIKE 'character_set%';" to find out. This probably is just a documentation problem, but maybe the default could be chosen more sensibly: for example, the mysql server database's charset seems the most sensible default. For example, connecting from a shell that has en_US.UTF-8 as locale, I get: character_set_client: utf8 character_set_connection: utf8 character_set_database: utf8 character_set_filesystem: binary character_set_results: utf8 character_set_server: utf8 character_set_system: utf8 character_sets_dir: /usr/share/mysql/charsets/ Switching to en_US.iso88591 doesn't change anything. So it would seem some server setting determines the charset, right? However, connecting to the same mysql server from another system (though from intranet instead of internet), I get: character_set_client: latin1 character_set_connection: latin1 character_set_database: utf8 character_set_filesystem: binary character_set_results: latin1 character_set_server: utf8 character_set_system: utf8 character_sets_dir: /usr/share/mysql/charsets/ Again, the client locale doesn't influence this. -- Edit bug report at http://bugs.php.net/bug.php?id=52453&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=52453&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=52453&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=52453&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=52453&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=52453&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=52453&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=52453&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=52453&r=needscript Try newer version: http://bugs.php.net/fix.php?id=52453&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=52453&r=support Expected behavior: http://bugs.php.net/fix.php?id=52453&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=52453&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=52453&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=52453&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52453&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=52453&r=dst IIS Stability: http://bugs.php.net/fix.php?id=52453&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=52453&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=52453&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=52453&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=52453&r=mysqlcfg
Bug #52403 [Dup->Opn]: imagettfbbox/imagettftext "Could not read font" error
Edit report at http://bugs.php.net/bug.php?id=52403&edit=1 ID: 52403 Updated by: h...@php.net Reported by:h...@php.net Summary:imagettfbbox/imagettftext "Could not read font" error -Status: Duplicate +Status: Open Type: Bug Package:GD related Operating System: CentOS4 PHP Version:5.2.13 Block user comment: Y New Comment: Excuse me, but this is -NOT- the same bug. Just because it's simply related does not make it the same. The problem here is the error, not the TTF files, which is the problem described in the other bug report. Please check and try again. Previous Comments: [2010-07-27 01:04:09] ka...@php.net Same issue as in bug #52404 [2010-07-22 14:24:49] h...@php.net Description: Using the Vera.ttf font, which is part of the Image_Text PEAR package results in an odd error... The font can be found here: http://svn.php.net/viewvc/pear/packages/Image_Text/trunk/tests/Vera.ttf?view=log The error given by imagettfbbox() is "Could not read font". When tested with is_readable(), the font is indeed readable. When opening the Vera.ttf font file in windows, it produces the following error: "The requested file Vera.ttf was not a valid font file." It would appear that the file may well be corrupt, not that it "could not read". This error lead to a very confusing situation... I propose that the error should be more descriptive. Instead of "Could not read font", consider "Invalid font file". Test script: --- What PHP version? ".phpversion(); $read = file_exists($font)?'Yes':'No'; echo "\nDoes font '$font' exist? ".$read; $read = is_readable($font)?'Yes':'No'; echo "\nIs font '$font' readable? ".$read; ?> Expected result: Warning: imagettfbbox() [function.imagettfbbox]: Could not read font in /home/share/www/dev/test/php/imagettfbbox.php on line 4 Actual result: -- Warning: imagettfbbox() [function.imagettfbbox]: Could not read font in /home/share/www/dev/test/php/imagettfbbox.php on line 4 What PHP version? 5.2.13 Does font 'Vera.ttf' exist? Yes Is font 'Vera.ttf' readable? Yes -- Edit this bug report at http://bugs.php.net/bug.php?id=52403&edit=1
Bug #52448 [Opn]: ext/curl/tests/curl_error_basic.phpt fail
Edit report at http://bugs.php.net/bug.php?id=52448&edit=1 ID: 52448 User updated by:glen at delfi dot ee Reported by:glen at delfi dot ee Summary:ext/curl/tests/curl_error_basic.phpt fail Status: Open Type: Bug Package:cURL related Operating System: PLD Linux PHP Version:5.3.3 Block user comment: N New Comment: to further illustrate that the error cames from curl library and is dependant on curl library version: $ curl fakeURL curl: (6) Couldn't resolve host 'fakeURL' $ curl --version curl 7.18.2 (i686-pld-linux-gnu) libcurl/7.18.2 OpenSSL/0.9.7m zlib/1.2.4 libidn/1.10 libssh2/0.18 Protocols: tftp ftp telnet dict ldap http file https ftps scp sftp Features: GSS-Negotiate IDN IPv6 Largefile NTLM SSL libz $ curl fakeURL curl: (6) Could not resolve host: fakeURL (Domain name not found) $ curl --version curl 7.21.0 (x86_64-pld-linux-gnu) libcurl/7.21.0 GnuTLS/2.10.0 zlib/1.2.5 c- ares/1.6.0 libidn/1.19 libssh2/1.2.5 librtmp/2.2e Protocols: dict file ftp ftps http https imap imaps ldap ldaps pop3 pop3s rtmp rtsp scp sftp smtp smtps telnet tftp Features: AsynchDNS GSS-Negotiate IDN IPv6 Largefile NTLM SSL libz Previous Comments: [2010-07-27 10:09:27] glen at delfi dot ee this concrete test test for library error code when trying to connect to unresolvable host. plz look the test code. and library error string pattern has changed, so either it must be updated (like i suggested a patch), or make it support various error formats. i.e the link you gave suggested how to setup webserver for tests, but this test does not connect to test webserver! [2010-07-27 04:34:58] srina...@php.net pl. look at the test script carefully. there is instruction on how to run this test script and also available at http://wiki.php.net/qa/temp/ext/curl if this convinces u ,pl. move this bug to bogus. [2010-07-26 20:03:16] glen at delfi dot ee Description: the curl library error string has changed, trivial patch fixes that tested with curl version = 7.21.0 DIFF 002+ Error: Could not resolve host: fakeURL (Domain name not found) 002- Error: Couldn't resolve host 'fakeURL' Test script: --- $ TEST_PHP_EXECUTABLE=$(which php) php run-tests.php --show-all ext/curl/tests/curl_error_basic.phpt = PHP : /usr/bin/php PHP_SAPI: cli PHP_VERSION : 5.3.3 ZEND_VERSION: 2.3.0 PHP_OS : Linux - Linux carme-pld-i686 2.6.34.1-3 #1 SMP Tue Jul 6 16:15:11 CEST 2010 i686 INI actual : /etc/php/php-cli.ini More .INIs : /etc/php/conf.d/PCRE.ini,/etc/php/conf.d/SPL.ini,/etc/php/conf.d/bcmath.ini,/etc/php/conf.d/bz2.ini,/etc/php/conf.d/calendar.ini,/etc/php/conf.d/ctype.ini,/etc/php/conf.d/curl.ini,/etc/php/conf.d/dba.ini,/etc/php/conf.d/dom.ini,/etc/php/conf.d/ftp.ini,/etc/php/conf.d/gd.ini,/etc/php/conf.d/gettext.ini,/etc/php/conf.d/iconv.ini,/etc/php/conf.d/imap.ini,/etc/php/conf.d/ldap.ini,/etc/php/conf.d/mbstring.ini,/etc/php/conf.d/mcrypt.ini,/etc/php/conf.d/mysql.ini,/etc/php/conf.d/openssl.ini,/etc/php/conf.d/pgsql.ini,/etc/php/conf.d/posix.ini,/etc/php/conf.d/simplexml.ini,/etc/php/conf.d/soap.ini,/etc/php/conf.d/sockets.ini,/etc/php/conf.d/tidy.ini,/etc/php/conf.d/xml.ini,/etc/php/conf.d/xmlrpc.ini,/etc/php/conf.d/zlib.ini CWD : /home/users/glen/rpm/BUILD.i686-linux/php-5.3.3 Extra dirs : VALGRIND: Not used = Running selected tests. TEST 1/1 [ext/curl/tests/curl_error_basic.phpt] SKIP DONE TEST http://wiki.php.net/qa/temp/ext/curl */ // Fake URL to trigger an error $url = "fakeURL"; echo "== Testing curl_error with a fake URL ==\n"; // cURL handler $ch = curl_init($url); ob_start(); // start output buffering curl_exec($ch); echo "Error: " . curl_error($ch); curl_close($ch); ?> DONE OUT == Testing curl_error with a fake URL == Error: Could not resolve host: fakeURL (Domain name not found) DONE EXP == Testing curl_error with a fake URL == Error: Couldn't resolve host 'fakeURL' DONE DIFF 002+ Error: Could not resolve host: fakeURL (Domain name not found) 002- Error: Couldn't resolve host 'fakeURL' DONE FAIL curl_error() function - basic test for curl_error using a fake url [ext/curl/tests/curl_error_basic.phpt] = Number of tests :1 1 Tests skipped :0 ( 0.0%) --
Bug #52448 [Opn]: ext/curl/tests/curl_error_basic.phpt fail
Edit report at http://bugs.php.net/bug.php?id=52448&edit=1 ID: 52448 User updated by:glen at delfi dot ee Reported by:glen at delfi dot ee Summary:ext/curl/tests/curl_error_basic.phpt fail Status: Open Type: Bug Package:cURL related Operating System: PLD Linux PHP Version:5.3.3 Block user comment: N New Comment: this concrete test test for library error code when trying to connect to unresolvable host. plz look the test code. and library error string pattern has changed, so either it must be updated (like i suggested a patch), or make it support various error formats. i.e the link you gave suggested how to setup webserver for tests, but this test does not connect to test webserver! Previous Comments: [2010-07-27 04:34:58] srina...@php.net pl. look at the test script carefully. there is instruction on how to run this test script and also available at http://wiki.php.net/qa/temp/ext/curl if this convinces u ,pl. move this bug to bogus. [2010-07-26 20:03:16] glen at delfi dot ee Description: the curl library error string has changed, trivial patch fixes that tested with curl version = 7.21.0 DIFF 002+ Error: Could not resolve host: fakeURL (Domain name not found) 002- Error: Couldn't resolve host 'fakeURL' Test script: --- $ TEST_PHP_EXECUTABLE=$(which php) php run-tests.php --show-all ext/curl/tests/curl_error_basic.phpt = PHP : /usr/bin/php PHP_SAPI: cli PHP_VERSION : 5.3.3 ZEND_VERSION: 2.3.0 PHP_OS : Linux - Linux carme-pld-i686 2.6.34.1-3 #1 SMP Tue Jul 6 16:15:11 CEST 2010 i686 INI actual : /etc/php/php-cli.ini More .INIs : /etc/php/conf.d/PCRE.ini,/etc/php/conf.d/SPL.ini,/etc/php/conf.d/bcmath.ini,/etc/php/conf.d/bz2.ini,/etc/php/conf.d/calendar.ini,/etc/php/conf.d/ctype.ini,/etc/php/conf.d/curl.ini,/etc/php/conf.d/dba.ini,/etc/php/conf.d/dom.ini,/etc/php/conf.d/ftp.ini,/etc/php/conf.d/gd.ini,/etc/php/conf.d/gettext.ini,/etc/php/conf.d/iconv.ini,/etc/php/conf.d/imap.ini,/etc/php/conf.d/ldap.ini,/etc/php/conf.d/mbstring.ini,/etc/php/conf.d/mcrypt.ini,/etc/php/conf.d/mysql.ini,/etc/php/conf.d/openssl.ini,/etc/php/conf.d/pgsql.ini,/etc/php/conf.d/posix.ini,/etc/php/conf.d/simplexml.ini,/etc/php/conf.d/soap.ini,/etc/php/conf.d/sockets.ini,/etc/php/conf.d/tidy.ini,/etc/php/conf.d/xml.ini,/etc/php/conf.d/xmlrpc.ini,/etc/php/conf.d/zlib.ini CWD : /home/users/glen/rpm/BUILD.i686-linux/php-5.3.3 Extra dirs : VALGRIND: Not used = Running selected tests. TEST 1/1 [ext/curl/tests/curl_error_basic.phpt] SKIP DONE TEST http://wiki.php.net/qa/temp/ext/curl */ // Fake URL to trigger an error $url = "fakeURL"; echo "== Testing curl_error with a fake URL ==\n"; // cURL handler $ch = curl_init($url); ob_start(); // start output buffering curl_exec($ch); echo "Error: " . curl_error($ch); curl_close($ch); ?> DONE OUT == Testing curl_error with a fake URL == Error: Could not resolve host: fakeURL (Domain name not found) DONE EXP == Testing curl_error with a fake URL == Error: Couldn't resolve host 'fakeURL' DONE DIFF 002+ Error: Could not resolve host: fakeURL (Domain name not found) 002- Error: Couldn't resolve host 'fakeURL' DONE FAIL curl_error() function - basic test for curl_error using a fake url [ext/curl/tests/curl_error_basic.phpt] = Number of tests :1 1 Tests skipped :0 ( 0.0%) Tests warned:0 ( 0.0%) ( 0.0%) Tests failed:1 (100.0%) (100.0%) Expected fail :0 ( 0.0%) ( 0.0%) Tests passed:0 ( 0.0%) ( 0.0%) - Time taken :0 seconds = = FAILED TEST SUMMARY - curl_error() function - basic test for curl_error using a fake url [ext/curl/tests/curl_error_basic.phpt] = -- Edit this bug report at http://bugs.php.net/bug.php?id=52448&edit=1
Bug #52245 [Bgs->Opn]: Private member of parent class accessible from child class.
Edit report at http://bugs.php.net/bug.php?id=52245&edit=1
ID: 52245
User updated by:phpamid at gmail dot com
Reported by:phpamid at gmail dot com
Summary:Private member of parent class accessible from child
class.
-Status: Bogus
+Status: Open
Type: Bug
Package:*General Issues
Operating System: Windows 7 x64
PHP Version:5.3.2
Block user comment: N
New Comment:
Could you please answer to my questions?
Previous Comments:
[2010-07-14 09:25:32] phpamid at gmail dot com
1) Answer for your question "Are you looking for protected elements?" is
"Bug #52245 Private member of parent class accessible from child
class."
2) Why you say that show_private_member() belongs to Parent class, if it
is inherited by its Child? In addition, I redefined the private member
in Child class - then, according to the paradigm of OOP polimoryizm, the
method should return a value of Child private member, otherwise all you
have said is contrary to OOP, in particular, to polymorphism.
[2010-07-08 13:00:41] johan...@php.net
You are calling show_private_member(). That method belongs to Father and
therefore has access to Father's private elements. The method has no
access to other class's private elements. Are you looking for protected
elements?
[2010-07-04 15:11:05] phpamid at gmail dot com
as for your code:
class A
{
private $a = "a";
}
class B extends A
{
private $a = "b"; // is this an error?
}
i think every class has own private member, so there is no error.
Ok, I got you.
I hope that this issue will be clarified.
Thank you for discussion.
[2010-07-04 14:32:12] giorgio dot liscio at email dot it
in fact if you use protected instead of private it works as expected
but the "private" issue should be clarified, i think
* i'm sorry for the second post
[2010-07-04 14:26:04] giorgio dot liscio at email dot it
sure i know i don't need to override the method with the same one in the
new class to fix this problem
in the parent class the field is private... so theoretically i can not
access the member in the derived class
class A
{
private $a = "a";
}
class B extends A
{
private $a = "b"; // is this an error?
}
it probably is, and maybe php should throw an 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
http://bugs.php.net/bug.php?id=52245
--
Edit this bug report at http://bugs.php.net/bug.php?id=52245&edit=1
