Bug #49143 [Com]: is_callable() and unnecessary backslash
Edit report at http://bugs.php.net/bug.php?id=49143edit=1
ID: 49143
Comment by: abca_b_cabcom at hotmail dot com
Reported by: david at grudl dot com
Summary: is_callable() and unnecessary backslash
Status: Open
Type: Bug
Package: Class/Object related
Operating System: *
PHP Version: 5.3.0
New Comment:
hi david, you are not in a namespace it is just a classname.
Previous Comments:
[2009-08-04 11:24:35] david at grudl dot com
The two same class invokes autoloader with different class name (maybe
better term is non-canonicalized class name).
This means: every autoloader must call $name = ltrim($name, \).
defined() removes leading \ automatically, is_callable and
method_exists do not.
[2009-08-04 11:16:07] j...@php.net
Yes, which problem..? I don't see any errors.
[2009-08-04 00:34:46] david at grudl dot com
Tested with 5.3.1-dev (Sun, 02 Aug 2009 18:53:57 +), problem still
exists.
[2009-08-03 16:19:59] david at grudl dot com
Description:
is_callable() and method_exists() may invoke autoloader with
unnecessary namespace backslash.
\My\MyClass::func() is the same as My\MyClass::func().
Reproduce code:
---
function __autoload($name)
{
echo $name;
}
is_callable('\My\MyClass::func'); // ERROR
is_callable('My\MyClass::func'); // OK
method_exists('\My\MyClass', 'func'); // ERROR
method_exists('My\MyClass', 'func'); // OK
// defined works well:
defined('\My\MyClass::CONST'); // OK
defined('My\MyClass::CONST'); // OK
Expected result:
My\MyClass
My\MyClass
My\MyClass
My\MyClass
My\MyClass
My\MyClass
Actual result:
--
\My\MyClass
My\MyClass
\My\MyClass
My\MyClass
My\MyClass
My\MyClass
--
Edit this bug report at http://bugs.php.net/bug.php?id=49143edit=1
Bug #51517 [Opn-Csd]: Node attributes lost when it has both attributes and value
Edit report at http://bugs.php.net/bug.php?id=51517edit=1 ID: 51517 User updated by: zhangxc83 at sohu dot com Reported by: zhangxc83 at sohu dot com Summary: Node attributes lost when it has both attributes and value -Status: Open +Status: Closed Type: Bug Package: SimpleXML related Operating System: Linux 2.6.18-92.el5 PHP Version: 5.3.2 New Comment: It works. Thanks a lot. Previous Comments: [2010-04-09 04:35:33] ras...@php.net They are not lost. It is just a deficiency in print_r walking from the root node. Try this: print_r($xml-report); [2010-04-09 04:31:01] zhangxc83 at sohu dot com Description: AS Test Scripts below: Test script: --- $xml = EOT ?xml version=1.0 encoding=UTF-8? root report id=testidtest value/report /root EOT; $xml = new \SimpleXMLElement(trim($xml)); print_r($xml); Expected result: .SimpleXMLElement Object ( [report] = .SimpleXMLElement Object ( [...@attributes] = Array ( [id] = testid ) [0] = test value ) ) Actual result: -- .SimpleXMLElement Object ( [report] = test value ) -- Edit this bug report at http://bugs.php.net/bug.php?id=51517edit=1
Bug #51248 [Com]: Segmentation fault in mysql_fetch_array
Edit report at http://bugs.php.net/bug.php?id=51248edit=1 ID: 51248 Comment by: mbecc...@php.net Reported by: mbecc...@php.net Summary: Segmentation fault in mysql_fetch_array Status: Feedback Type: Bug Package: MySQL related Operating System: FreeBSD 6.2 PHP Version: 5.3.2 Assigned To: mysql New Comment: I've been able to test the drush script with a newly compiled 5.3.2 w/ mysqlnd and it appears that the segmentation fault is gone. Is there any way I can trace what happens with libmysql? i.e. libmysql: $ /usr/local/bin/php ~/bin/drush/drush.php dis twitter The following projects will be disabled: twitter Do you really want to continue? (y/n): y Segmentation fault: 11 (core dumped) mysqlnd: $ /array1/compile/php-5.3.2-apache/sapi/cli/php -d mysqlnd.debug=t:o,/tmp/mysqlnd.trace ~/bin/drush/drush.php dis twitter The following projects will be disabled: twitter Do you really want to continue? (y/n): y twitter was disabled successfully. [ok] Previous Comments: [2010-04-08 16:57:29] mbecc...@php.net I've been using libmysql, but IIRC I've also tried mysqlnd and had the same result. As soon as I have time, I'll try to make a test build with mysqlnd and generate the trace file. [2010-04-08 16:50:54] and...@php.net Do you use libmysql or mysqlnd as the underlying library? if mysqlnd then can you try a debug build and put into your php.ini : mysqlnd.debug=t:o,/tmp/mysqlnd.trace . Then please mail me the trace file because it won't be small. Thanks! Andrey [2010-03-29 21:03:43] mgarrison at alienz dot net I'm also able to reproduce this but with custom code, replicated with 5.3.2 and php5.3-201003291630 on a CentOS 4.8 box. Doesn't happen in php 5.2.12. (gdb) bt #0 0x7fdcc37cdac3 in zend_fetch_resource (passed_id=0x7fffd484e6a0, default_id=-1, resource_type_name=0x7fdcc3a8ce08 MySQL result, found_resource_type=0x0, num_resource_types=1) at /usr/src/php-5.3.2/Zend/zend_list.c:127 #1 0x7fdcc3651846 in php_mysql_fetch_hash (ht=2, return_value=0x7fdcbf0e2970, return_value_ptr=Variable return_value_ptr is not available. ) at /usr/src/php-5.3.2/ext/mysql/php_mysql.c:1944 #2 0x7fdcc3651dcb in zif_mysql_fetch_array (ht=-729487712, return_value=0x, return_value_ptr=0x7fdcc37cd9cf, this_ptr=0x0, return_value_used=1) at /usr/src/php-5.3.2/ext/mysql/php_mysql.c:2105 #3 0x7fdcc37e2c62 in zend_do_fcall_common_helper_SPEC (execute_data=0x7fdcc2b34310) at /usr/src/php-5.3.2/Zend/zend_vm_execute.h:313 #4 0x7fdcc37e2089 in execute (op_array=0x7fdcbf4841c8) at /usr/src/php- 5.3.2/Zend/zend_vm_execute.h:104 #5 0x7fdcc37c0345 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /usr/src/php-5.3.2/Zend/zend.c:1194 #6 0x7fdcc376e67d in php_execute_script (primary_file=0x7fffd4850da0) at /usr/src/php-5.3.2/main/main.c:2260 #7 0x7fdcc3845d12 in apache_php_module_main (r=Variable r is not available. ) at /usr/src/php-5.3.2/sapi/apache/sapi_apache.c:53 #8 0x7fdcc38468ce in send_php (r=0xcec3d0, display_source_mode=0, filename=0x0) at /usr/src/php-5.3.2/sapi/apache/mod_php5.c:682 #9 0x7fdcc3846ac3 in send_parsed_php (r=0x7fffd484e6a0) at /usr/src/php- 5.3.2/sapi/apache/mod_php5.c:697 #10 0x004428e4 in ap_invoke_handler () #11 0x0045a74e in process_request_internal () #12 0x0045ac19 in ap_internal_redirect () #13 0x7fdcc3ee7f7c in mod_gzip_redir1_handler () from /var/www/libexec/mod_gzip.so #14 0x7fdcc3ee61eb in mod_gzip_handler () from /var/www/libexec/mod_gzip.so #15 0x004428e4 in ap_invoke_handler () #16 0x0045a74e in process_request_internal () #17 0x0045a7a3 in ap_process_request () #18 0x00450a06 in child_main () #19 0x00450cf1 in make_child () #20 0x0045109e in perform_idle_server_maintenance () #21 0x004516c3 in standalone_main () #22 0x00451cb7 in main () [2010-03-09 20:20:13] mbecc...@php.net Description: I've been asked to publish a Drupal based website on my 5.3.2 box, but every page call triggers a segmentation fault. Replicated with 5.3.1 as well. I've been able to test an old 5.2.8 and the issue is gone. I can't attach a reproduce code, but I will try to gather more information in the next few days. For now I'm attaching the backtrace. Actual result: -- Program received signal SIGSEGV, Segmentation fault. 0x8518a7c3 in zend_fetch_resource (passed_id=0x7fffcc50, default_id=-1, resource_type_name=0x855c3d6f MySQL result,
Bug #51506 [Fbk-Opn]: Realpath failed on linux Server for version 5.2.10 ?
Edit report at http://bugs.php.net/bug.php?id=51506edit=1 ID: 51506 User updated by: mastershepper at gmail dot com Reported by: mastershepper at gmail dot com Summary: Realpath failed on linux Server for version 5.2.10 ? -Status: Feedback +Status: Open Type: Bug Package: Apache2 related Operating System: Linux PHP Version: 5.2.13 New Comment: Hi, the php version is now up to date (5.2.13) and still have the problem. I tried many realpath(), the absloute path of the web directory ios the following one : /home/.sites/38/site52/web I thought that realpath( '/home/.sites/38/site52/web' ) should works fine, but it return me false, like any other realpath I'm asking (like realpath( '/' ) which is working well on my IIS environment). I also tried to set the include path with this line : set_include_path(get_include_path() . PATH_SEPARATOR . '/home/.sites/38/site52/web'); But it still not working fine. Is there anything I missed ? I'm probably wrong but I don't see where. Thanks for your help. Previous Comments: [2010-04-08 11:15:41] paj...@php.net You can test locally as well, or in a VM using the same linux version that you have on your prod server. [2010-04-08 11:12:25] mastershepper at gmail dot com __FILE__ is just a test, the actuel drupal core use realpath on dynamic paths and it always return false. The actual production environment is an external one so I'm not able to change the php version. I will ask for it and update this report when it will be done (only if it could be done, unfortunately) Thanks for your help. [2010-04-08 11:02:07] paj...@php.net __FILE__ is already an absolute path, I don't see why you would do that in the 1st place. However, if you can reproduce the realpath problem with other paths as well, then I suspect a bug on your linux version. Can you try with 5.2.13 pls? [2010-04-08 10:47:47] mastershepper at gmail dot com Description: hi, I met an issue using a drupal CMS. I received an error warning: move_uploaded_file() [function.move-uploaded-file]: Unable to access in /home/.sites/38/site52/web/includes/file.inc on line 572. I have several web environement, one for coding the website (with IIS 6 and PHP 5.2.3), on for production (with Linux, Apache 2.0 and PHP 5.2.10). I have no issue on my development server with IIS (same files, same database). when I run the following line of code : var_dump( realpath( dirname( __FILE__ ) ) ); Under IIS: string(44) D:\inetpub\vhosts\dev.***.com\httpdocs Under Apache: bool(false) Did I miss something ? Best regards, Denis. Test script: --- var_dump( realpath( dirname( __FILE__ ) ) ); Expected result: I wish that this function gives me the real path to let drupal copy some files from the administration. -- Edit this bug report at http://bugs.php.net/bug.php?id=51506edit=1
Bug #50555 [Com]: Cannot retrieve output parameter from stored procedure
Edit report at http://bugs.php.net/bug.php?id=50555edit=1 ID: 50555 Comment by: a at exampl dot com Reported by: david dot wright at opticsplanet dot com Summary: Cannot retrieve output parameter from stored procedure Status: Open Type: Bug Package: PDO related Operating System: 2.6.24-24-server PHP Version: 5.3.1 New Comment: For fucks sake would anybody already fix this? It's not the only report about this issue in the tracker. Previous Comments: [2009-12-22 22:09:39] david dot wright at opticsplanet dot com Description: I cannot retrieve an output parameter from a stored procedure (in my case on SQL Server 2005--am using PDO_DBLIB. Reproduce code: --- PHP Code: --- /** SNIP. Set up a valid $db here! **/ $return_value = 999; $sth = $db-prepare(EXEC dbo.opsp_Test ?); $sth-bindParam(1, $return_value, PDO::PARAM_STR | PDO::PARAM_INPUT_OUTPUT, 4); $sth-execute(); echo $return_value\n; Stored Procedure -- CREATE PROCEDURE opsp_Test @TheOutputValue int OUTPUT AS BEGIN SET @TheOutputValue = 11 END Expected result: output should be: 11 Actual result: -- Output is 999 ($return_value unchanged) -- Edit this bug report at http://bugs.php.net/bug.php?id=50555edit=1
Bug #50828 [Opn-Csd]: DOMNotation is not subclass of DOMNode
Edit report at http://bugs.php.net/bug.php?id=50828edit=1
ID: 50828
Updated by: rricha...@php.net
Reported by: xuecan at gmail dot com
Summary: DOMNotation is not subclass of DOMNode
-Status: Open
+Status: Closed
Type: Bug
Package: DOM XML related
Operating System: *
PHP Version: 5.*, 6
-Assigned To:
+Assigned To: rrichards
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/.
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2010-04-09 13:34:36] rricha...@php.net
Automatic comment from SVN on behalf of rrichards
Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=297744
Log: fix bug #50828 (DOMNotation is not subclass of DOMNode)
[2010-01-24 13:37:23] xuecan at gmail dot com
Description:
DOMNotation is not subclass of DOMNode but it should be.
Reproduce code:
---
var_dump(is_subclass_of('DOMNotation', 'DOMNode'));
Expected result:
bool(true)
Actual result:
--
bool(false)
--
Edit this bug report at http://bugs.php.net/bug.php?id=50828edit=1
Bug #36795 [Opn-Bgs]: Inappropriate unterminated entity reference in DOMElement-setAttribute
Edit report at http://bugs.php.net/bug.php?id=36795edit=1
ID: 36795
Updated by: rricha...@php.net
Reported by: john at carney dot id dot au
Summary: Inappropriate unterminated entity reference in
DOMElement-setAttribute
-Status: Open
+Status: Bogus
Type: Bug
Package: DOM XML related
Operating System: *
PHP Version: 5.*, 6
New Comment:
Behavior as defined by DOM specs. No warnings are issued are from either
of the 2
examples in the reproduced code.
addChild() method described in later reports works are defined by specs.
Use the
simplexml property accessors for auto escaping.
Previous Comments:
[2010-02-04 18:23:10] jalday at delivery dot com
Still seeing this issue...
$order_x-addChild('location', '1st 52nd');
gives Warning: SimpleXMLElement::addChild(): unterminated entity
reference
If I run it as
$order_x-addChild('location', htmlspecialchars('1st 52nd'));
I have no problems.
[2009-10-22 16:28:09] gary dot malcolm at gmail dot com
I'm running PHP 5.2.9 on Linux and this bug is still alive and well
making SimpleXml absolutely inappropriate for XML communications between
systems.
code
$safe_value = preg_replace('/(?!\w+;)/', 'amp;', $value);
return $sxml-addChild($name, $safe_value);
/code
Is just plain wrong. I'm communicating user input directly to a bank as
I can't know how the third party will parse their xml.
[2008-04-03 23:15:04] rob at electronicinsight dot com
A little hack to get around this bug:
function safe_add_child($sxml, $name, $value) {
$safe_value = preg_replace('/(?!\w+;)/', 'amp;', $value);
return $sxml-addChild($name, $safe_value);
}
[2008-02-08 20:09:37] moshe at varien dot com
PHP 5.2.4
Looks like the problem appears when there's node already exists being
overwritten
// works ok, doesn't require encoding:
$a = simplexml_load_string('a/');
$a-b = ' ;
// doesn't work, requires encoding:
$a = simplexml_load_string('abtest/b/a');
$a-b = ' ;
// doesn't work, always requires encoding
$a-addChild('b', ');
$a-addAttribute('b', ');
// works ok, never requires encoding
$a['b'] = ';
[2007-11-27 14:03:55] oscar at cdcovers dot to
I tried the workaround below and it seems to work:
$xml-addChild('element', '');
$xml-element = str_replace(, amp;, value of the element);
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=36795
--
Edit this bug report at http://bugs.php.net/bug.php?id=36795edit=1
[PHP-BUG] Bug #51521 [NEW]: XMLReader doesn't open files via stream_wrapper
From: Operating system: Linux i686 PHP version: 5.3.2 Package: XML Reader Bug Type: Bug Bug description:XMLReader doesn't open files via stream_wrapper Description: XMLReader generates the error when tries to open files via stream_wrapper. Works for 5.2.12 Test script: --- http://niakhaichyk.org/xmlreader.bug.txt Expected result: PHP_VERSION: 5.3.0 XML: ?xml version=1.0 encoding=UTF-8?rootThank you/root root= #text=Thank you root= Actual result: -- PHP_VERSION: 5.3.0 XML: ?xml version=1.0 encoding=UTF-8?rootThank you/root Warning: XMLReader::open() [xmlreader.open]: Unable to open source data in /var/www/vidunia/public/xmlreader.bug.php on line 12 Warning: XMLReader::read() [xmlreader.read]: Load Data before trying to read in /var/www/vidunia/public/xmlreader.bug.php on line 13 -- Edit bug report at http://bugs.php.net/bug.php?id=51521edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=51521r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=51521r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=51521r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=51521r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=51521r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=51521r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=51521r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=51521r=needscript Try newer version: http://bugs.php.net/fix.php?id=51521r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=51521r=support Expected behavior: http://bugs.php.net/fix.php?id=51521r=notwrong Not enough info: http://bugs.php.net/fix.php?id=51521r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=51521r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=51521r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51521r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=51521r=dst IIS Stability: http://bugs.php.net/fix.php?id=51521r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=51521r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=51521r=float No Zend Extensions: http://bugs.php.net/fix.php?id=51521r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=51521r=mysqlcfg
Bug #31326 [Com]: Object Destruction Order
Edit report at http://bugs.php.net/bug.php?id=31326edit=1
ID: 31326
Comment by: spidgorny at gmail dot com
Reported by: sir dot gallahad at gmail dot com
Summary: Object Destruction Order
Status: No Feedback
Type: Bug
Package: Scripting Engine problem
Operating System: Linux
PHP Version: 5.0.2
New Comment:
Hi,
I wonder why it's being not addressed for such a long time. This seems
an important bug to me. Consider:
?php
class Index {
var $user;
function __destruct() {
if ($GLOBALS['i']-user === $this) {
// update preferences in DB
}
}
}
$i = new Index();
?
This works counter-intuitive and $GLOBALS['i'] is UNSET at the time the
__destruct is called. The destructor is supposed to be called BEFORE the
object itself is destroyed. Please change the order to FILO.
Previous Comments:
[2006-08-23 17:56:45] richardkmiller at gmail dot com
This defect has affected me as well. I like the suggestion of
ebenblues: destroy objects in order of references pointing to
them (lowest to highest). The LIFO suggestion by sir dot
gallahad would also solve my problem,
[2005-06-09 17:09:11] ebenblues at yahoo dot com
I believe this is a bug in PHP's garbage collection. The ordering in
which __destruct methods are called can be very important when objects
contain instances of other objects as class variables. I have run into
problems because of the simple order that PHP uses to call __destruct
methods.
The order in which objects are destroyed should be determined by the
number of references left which point to the object (I believe Java does
something like this). In general, the Zend engine should use something
like the following algorithm for garbage collection:
foreach (object left to destroy) {
if(no references point at this object) {
call object's __destruct method
destroy object
}
}
The only hole in this algorithm is that an object that contains a
reference to itself will never be destroyed and cause an endless loop in
the algorithm above. These types of objects should be destroyed last.
The above algorithm can be easily modified to achieve this. Please
address this issue with PHP garbage collection. Thanks!
[2005-03-20 18:05:49] sni...@php.net
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to Open. Thank you.
[2005-02-28 21:05:52] sni...@php.net
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
[2004-12-28 20:27:18] sir dot gallahad at gmail dot com
Description:
First of all. It's not a bug. It's a sugestion to give more stability to
the engine.
When the Zend Engine reaches the end of a script page it cleans up the
classes that have been created.
Nowadays it cleans up in the order the classes have been created.
I suggest that it would be a safer routine to destroy a class following
a heap of objects (first in last out).
It would help some nesting routines, not mentioning the memory
allocation.
Reproduce code:
---
?
$ident = 0;
class Tag {
public $aVar;
function __construct( $pMe ) {
global $ident;
$this-aVar = $pMe;
echo
str_repeat(nbsp;nbsp;nbsp;nbsp;,$ident).[.$this-aVar.]br;
$ident++;
}
function __destruct() {
global $ident;
$ident--;
echo
str_repeat(nbsp;nbsp;nbsp;nbsp;,$ident).[/.$this-aVar.]br;
}
}
$v1 = new Tag(tag1);
$v2 = new Tag(tag2);
$v3 = new Tag(tag3);
echo 'brbr';
?
Expected result:
[tag1]
[tag2]
[tag3]
[/tag3]
[/tag2]
[/tag1]
Actual result:
--
[tag1]
[tag2]
[tag3]
[/tag1]
[/tag2]
[/tag3]
--
Edit this bug report at http://bugs.php.net/bug.php?id=31326edit=1
Bug #51436 [Com]: LCG entropy fix insufficient, uniqid leaks entropy, leads to weak session IDs
Edit report at http://bugs.php.net/bug.php?id=51436edit=1 ID: 51436 Comment by: crrodriguez at opensuse dot org Reported by: andreas at andreas dot org Summary: LCG entropy fix insufficient, uniqid leaks entropy, leads to weak session IDs Status: Assigned Type: Bug Package: *Encryption and hash functions Operating System: all PHP Version: 5.3.2 Assigned To: pajoye New Comment: I think uniqid() should also use zend_mm_random()-like random value when more_entropy is set to true instead of the LCG ... Previous Comments: [2010-04-07 17:44:16] paj...@php.net And assigned to me, almost done with the patch we discussed. [2010-04-07 17:43:49] paj...@php.net Well, the easiest to backport something now and here is to use the given settings. You can do it right now. [2010-04-07 17:21:47] andreas at andreas dot org I strongly suggest backporting. Also, the fact that uniqid() values are predictable too needs addressing. [2010-03-31 20:30:53] ras...@php.net I have switched the default in trunk to either /dev/urandom or /dev/arandom if it exists. We actually already had a check for it in Zend for the zend_mm_random() function, Whether we backport this to 5.3 or just improve the documentation for that setting is up to Johannes, I think. [2010-03-31 20:03:18] ras...@php.net Automatic comment from SVN on behalf of rasmus Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=297232 Log: Set session.entropy_file to /dev/urandom or /dev/arandom by default if present at compile-time. Addresses part of bug #51436 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=51436 -- Edit this bug report at http://bugs.php.net/bug.php?id=51436edit=1
Bug #51436 [Asn]: LCG entropy fix insufficient, uniqid leaks entropy, leads to weak session IDs
Edit report at http://bugs.php.net/bug.php?id=51436edit=1 ID: 51436 Updated by: paj...@php.net Reported by: andreas at andreas dot org Summary: LCG entropy fix insufficient, uniqid leaks entropy, leads to weak session IDs Status: Assigned Type: Bug Package: *Encryption and hash functions Operating System: all PHP Version: 5.3.2 Assigned To: pajoye New Comment: That's the idea but not using zend's mm which is incomplete. Previous Comments: [2010-04-09 17:51:14] crrodriguez at opensuse dot org I think uniqid() should also use zend_mm_random()-like random value when more_entropy is set to true instead of the LCG ... [2010-04-07 17:44:16] paj...@php.net And assigned to me, almost done with the patch we discussed. [2010-04-07 17:43:49] paj...@php.net Well, the easiest to backport something now and here is to use the given settings. You can do it right now. [2010-04-07 17:21:47] andreas at andreas dot org I strongly suggest backporting. Also, the fact that uniqid() values are predictable too needs addressing. [2010-03-31 20:30:53] ras...@php.net I have switched the default in trunk to either /dev/urandom or /dev/arandom if it exists. We actually already had a check for it in Zend for the zend_mm_random() function, Whether we backport this to 5.3 or just improve the documentation for that setting is up to Johannes, I think. 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=51436 -- Edit this bug report at http://bugs.php.net/bug.php?id=51436edit=1
Bug #51436 [Com]: LCG entropy fix insufficient, uniqid leaks entropy, leads to weak session IDs
Edit report at http://bugs.php.net/bug.php?id=51436edit=1 ID: 51436 Comment by: crrodriguez at opensuse dot org Reported by: andreas at andreas dot org Summary: LCG entropy fix insufficient, uniqid leaks entropy, leads to weak session IDs Status: Assigned Type: Bug Package: *Encryption and hash functions Operating System: all PHP Version: 5.3.2 Assigned To: pajoye New Comment: I think trying RAND_pseudo_bytes() if -lcrypto is found in the system first and then your_own_function ight be a suitable approach. Previous Comments: [2010-04-09 18:18:32] paj...@php.net That's the idea but not using zend's mm which is incomplete. [2010-04-09 17:51:14] crrodriguez at opensuse dot org I think uniqid() should also use zend_mm_random()-like random value when more_entropy is set to true instead of the LCG ... [2010-04-07 17:44:16] paj...@php.net And assigned to me, almost done with the patch we discussed. [2010-04-07 17:43:49] paj...@php.net Well, the easiest to backport something now and here is to use the given settings. You can do it right now. [2010-04-07 17:21:47] andreas at andreas dot org I strongly suggest backporting. Also, the fact that uniqid() values are predictable too needs addressing. 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=51436 -- Edit this bug report at http://bugs.php.net/bug.php?id=51436edit=1
Bug #50918 [Com]: Access violation in php.exe (Bug #49626 redux)
Edit report at http://bugs.php.net/bug.php?id=50918edit=1
ID: 50918
Comment by: bugs-php-net at onethumb dot com
Reported by: hardon at online dot no
Summary: Access violation in php.exe (Bug #49626 redux)
Status: Assigned
Type: Bug
Package: Reproducible crash
Operating System: win32 only - Windows
PHP Version: 5.3.1
Assigned To: pajoye
New Comment:
I'm experiencing this bug (or something extremely similar) on PHP v5.3.2
on
CentOS 5.4.
Essentially, if I build PHP with --enable-maintainer-zts (for use with
Apache's
worker mpm) and try to load any extensions, PHP instantly segfaults at
/ext/date/php_date.c:844 in guess_timezone() when it tries to call
DATEG(timezone):
(gdb) run
Starting program: /home/onethumb/zts/php-5.3.2/sapi/cli/php
[Thread debugging using libthread_db enabled]
[New Thread 0x2b1fea7adc00 (LWP 20681)]
Program received signal SIGSEGV, Segmentation fault.
0x0042ab9d in guess_timezone (tzdb=0xea1f60, tsrm_ls=0x1f370500)
at
/home/onethumb/zts/php-5.3.2/ext/date/php_date.c:844
844 if (DATEG(timezone) (strlen(DATEG(timezone)) 0)) {
I have date.timezone properly set in php.ini. Running without any
extensions
confirms.
Hardcoding guess_timezone() to return a valid timezone simply moves the
crash
farther into php_date, to the next DATEG() call in timezone caching.
Extensions I've tried include very common PECL extensions like zip, apc,
and
memcached, among others. Adding any extension = line to php.ini
appears to
trigger this crash.
Previous Comments:
[2010-03-31 12:31:48] paj...@php.net
Let me try to give Derick a bt and details about the crash.
[2010-03-18 09:02:02] progunster at gmail dot com
Well, after reboot I can't reproduce it anymore.
So, what i did:
1.) Installed httpd-2.2.15-win32-x86-openssl-0.9.8m-r2.msi
It Works!
2.) Changed httpd.conf, to disable http and enable https (also created
self-signed certificates)
3.) Installed PHP from php-5.3.2-Win32-VC6-x86.msi
Right after that httpd.exe was crashing on start. After reboot it all
went gone.
On another computer it was the same.
[2010-03-17 16:05:53] paj...@php.net
When does this crash happen exactly? As you seem to be able to reproduce
it, always, I would like to know how :)
[2010-03-17 15:43:30] progunster at gmail dot com
Added
date.timezone = Europe/Kiev
to [Date] section of php.ini, it didn't helped.
Same error, same place.
[2010-03-17 15:01:48] paj...@php.net
btw, it is not windows specific, crashes occur on other platform as
well.
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=50918
--
Edit this bug report at http://bugs.php.net/bug.php?id=50918edit=1
Bug #51436 [Asn]: LCG entropy fix insufficient, uniqid leaks entropy, leads to weak session IDs
Edit report at http://bugs.php.net/bug.php?id=51436edit=1 ID: 51436 Updated by: paj...@php.net Reported by: andreas at andreas dot org Summary: LCG entropy fix insufficient, uniqid leaks entropy, leads to weak session IDs Status: Assigned Type: Bug Package: *Encryption and hash functions Operating System: all PHP Version: 5.3.2 Assigned To: pajoye New Comment: RAND_pseudo_bytes does pretty much the same anyway, but I would prefer to give a possible not to use openssl first. Also this exact function may not be crypto safe. It is not a problem for the session but that will then not solve the need of a crypto safe function. Previous Comments: [2010-04-09 18:41:56] crrodriguez at opensuse dot org I think trying RAND_pseudo_bytes() if -lcrypto is found in the system first and then your_own_function ight be a suitable approach. [2010-04-09 18:18:32] paj...@php.net That's the idea but not using zend's mm which is incomplete. [2010-04-09 17:51:14] crrodriguez at opensuse dot org I think uniqid() should also use zend_mm_random()-like random value when more_entropy is set to true instead of the LCG ... [2010-04-07 17:44:16] paj...@php.net And assigned to me, almost done with the patch we discussed. [2010-04-07 17:43:49] paj...@php.net Well, the easiest to backport something now and here is to use the given settings. You can do it right now. 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=51436 -- Edit this bug report at http://bugs.php.net/bug.php?id=51436edit=1
Doc #51502 [Com]: imagecreatefromjpeg no image
Edit report at http://bugs.php.net/bug.php?id=51502edit=1 ID: 51502 Comment by: minirop at hotmail dot com Reported by: minirop at hotmail dot com Summary: imagecreatefromjpeg no image Status: Feedback Type:Documentation Problem Package: Unknown/Other Function PHP Version: Irrelevant New Comment: on this page : http://fr2.php.net/manual/fr/function.imagecreatefromjpeg.php see what I've got : http://img25.xooimage.com/files/2/2/4/sans-titre-1-1ad2504.png Previous Comments: [2010-04-09 00:45:36] degeb...@php.net Where did you find that link? What page and on what mirror? It works fine for me on the fr2 mirror. [2010-04-07 22:40:29] minirop at hotmail dot com Description: the image that show the example doesn't exist : http://fr2.php.net/manual/fr/images/21009b70229598c6a80eef8b45bf282b- image.imagecreatefromjpeg.jpg -- Edit this bug report at http://bugs.php.net/bug.php?id=51502edit=1
Bug #51521 [Opn]: XMLReader doesn't open files via stream_wrapper
Edit report at http://bugs.php.net/bug.php?id=51521edit=1 ID: 51521 User updated by: andrey at niakhaichyk dot org Reported by: andrey at niakhaichyk dot org Summary: XMLReader doesn't open files via stream_wrapper Status: Open Type: Bug Package: XML Reader Operating System: Linux i686 -PHP Version: 5.3.2 +PHP Version: 5.3.0 New Comment: Tested on old PHP version Previous Comments: [2010-04-09 16:58:19] andrey at niakhaichyk dot org Description: XMLReader generates the error when tries to open files via stream_wrapper. Works for 5.2.12 Test script: --- http://niakhaichyk.org/xmlreader.bug.txt Expected result: PHP_VERSION: 5.3.0 XML: ?xml version=1.0 encoding=UTF-8?rootThank you/root root= #text=Thank you root= Actual result: -- PHP_VERSION: 5.3.0 XML: ?xml version=1.0 encoding=UTF-8?rootThank you/root Warning: XMLReader::open() [xmlreader.open]: Unable to open source data in /var/www/vidunia/public/xmlreader.bug.php on line 12 Warning: XMLReader::read() [xmlreader.read]: Load Data before trying to read in /var/www/vidunia/public/xmlreader.bug.php on line 13 -- Edit this bug report at http://bugs.php.net/bug.php?id=51521edit=1
Bug #51521 [Opn]: XMLReader doesn't open files via stream_wrapper
Edit report at http://bugs.php.net/bug.php?id=51521edit=1 ID: 51521 User updated by: andrey at niakhaichyk dot org Reported by: andrey at niakhaichyk dot org Summary: XMLReader doesn't open files via stream_wrapper Status: Open Type: Bug Package: XML Reader Operating System: Linux i686 PHP Version: 5.3.0 New Comment: Cannot reproduce for PHP 5.3.2 Win x32. Seems to was fixed. Previous Comments: [2010-04-09 19:56:54] andrey at niakhaichyk dot org Tested on old PHP version [2010-04-09 16:58:19] andrey at niakhaichyk dot org Description: XMLReader generates the error when tries to open files via stream_wrapper. Works for 5.2.12 Test script: --- http://niakhaichyk.org/xmlreader.bug.txt Expected result: PHP_VERSION: 5.3.0 XML: ?xml version=1.0 encoding=UTF-8?rootThank you/root root= #text=Thank you root= Actual result: -- PHP_VERSION: 5.3.0 XML: ?xml version=1.0 encoding=UTF-8?rootThank you/root Warning: XMLReader::open() [xmlreader.open]: Unable to open source data in /var/www/vidunia/public/xmlreader.bug.php on line 12 Warning: XMLReader::read() [xmlreader.read]: Load Data before trying to read in /var/www/vidunia/public/xmlreader.bug.php on line 13 -- Edit this bug report at http://bugs.php.net/bug.php?id=51521edit=1
Bug #51521 [Opn-Csd]: XMLReader doesn't open files via stream_wrapper
Edit report at http://bugs.php.net/bug.php?id=51521edit=1 ID: 51521 User updated by: andrey at niakhaichyk dot org Reported by: andrey at niakhaichyk dot org Summary: XMLReader doesn't open files via stream_wrapper -Status: Open +Status: Closed Type: Bug Package: XML Reader Operating System: Linux i686 PHP Version: 5.3.0 New Comment: Cannot reproduce in 5.3.2 Previous Comments: [2010-04-09 19:58:26] andrey at niakhaichyk dot org Cannot reproduce for PHP 5.3.2 Win x32. Seems to was fixed. [2010-04-09 19:56:54] andrey at niakhaichyk dot org Tested on old PHP version [2010-04-09 16:58:19] andrey at niakhaichyk dot org Description: XMLReader generates the error when tries to open files via stream_wrapper. Works for 5.2.12 Test script: --- http://niakhaichyk.org/xmlreader.bug.txt Expected result: PHP_VERSION: 5.3.0 XML: ?xml version=1.0 encoding=UTF-8?rootThank you/root root= #text=Thank you root= Actual result: -- PHP_VERSION: 5.3.0 XML: ?xml version=1.0 encoding=UTF-8?rootThank you/root Warning: XMLReader::open() [xmlreader.open]: Unable to open source data in /var/www/vidunia/public/xmlreader.bug.php on line 12 Warning: XMLReader::read() [xmlreader.read]: Load Data before trying to read in /var/www/vidunia/public/xmlreader.bug.php on line 13 -- Edit this bug report at http://bugs.php.net/bug.php?id=51521edit=1
Bug #51521 [Csd-Bgs]: XMLReader doesn't open files via stream_wrapper
Edit report at http://bugs.php.net/bug.php?id=51521edit=1 ID: 51521 Updated by: paj...@php.net Reported by: andrey at niakhaichyk dot org Summary: XMLReader doesn't open files via stream_wrapper -Status: Closed +Status: Bogus Type: Bug Package: XML Reader Operating System: Linux i686 PHP Version: 5.3.0 Previous Comments: [2010-04-09 19:59:13] andrey at niakhaichyk dot org Cannot reproduce in 5.3.2 [2010-04-09 19:58:26] andrey at niakhaichyk dot org Cannot reproduce for PHP 5.3.2 Win x32. Seems to was fixed. [2010-04-09 19:56:54] andrey at niakhaichyk dot org Tested on old PHP version [2010-04-09 16:58:19] andrey at niakhaichyk dot org Description: XMLReader generates the error when tries to open files via stream_wrapper. Works for 5.2.12 Test script: --- http://niakhaichyk.org/xmlreader.bug.txt Expected result: PHP_VERSION: 5.3.0 XML: ?xml version=1.0 encoding=UTF-8?rootThank you/root root= #text=Thank you root= Actual result: -- PHP_VERSION: 5.3.0 XML: ?xml version=1.0 encoding=UTF-8?rootThank you/root Warning: XMLReader::open() [xmlreader.open]: Unable to open source data in /var/www/vidunia/public/xmlreader.bug.php on line 12 Warning: XMLReader::read() [xmlreader.read]: Load Data before trying to read in /var/www/vidunia/public/xmlreader.bug.php on line 13 -- Edit this bug report at http://bugs.php.net/bug.php?id=51521edit=1
Bug #51518 [Bgs]: should add to zero, but gets 1.1102230246252E-16 instead
Edit report at http://bugs.php.net/bug.php?id=51518edit=1
ID: 51518
User updated by: krenshala at koboldi dot net
Reported by: krenshala at koboldi dot net
Summary: should add to zero, but gets 1.1102230246252E-16
instead
Status: Bogus
Type: Bug
Package: Math related
Operating System: Multiple
PHP Version: 5.2.13
New Comment:
tested it on my system at home and was able to reproduce it.
$ php --version
PHP 5.2.13-pl0-gentoo (cli) (built: Apr 9 2010 03:35:37)
Copyright (c) 1997-2010 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2010 Zend Technologies
$ cat test.php
echo 0.9 - 0.9 returns .(0.9 - 0.9).\n;
echo 0.9 + (-3 * .3) returns .(0.9 + (-3 * .3)).\n;
echo -0.9 + (3 * .3) returns .(-0.9 + (3 * .3)).\n;
echo 0.8 + (-3 * .3) returns .(0.8 + (-3 * .3)).\n;
$ php test.php
0.9 - 0.9 returns 0
0.9 + (-3 * .3) returns 1.11022302463E-16
-0.9 + (3 * .3) returns -1.11022302463E-16
0.8 + (-3 * .3) returns -0.1
Also, I can understand the multiplication increasing the precision used,
from 1 to 3 significant digits in the function above. Jumping from 1E-3
to 1E-16 seems a bit much to me, however. I'm reading the Floating
Point doc you linked Rasmus in case it does address the issue. From the
little of it I've read so far it does seem to address at least some of
what is happening here.
My concern is with the differences between the output of the different
lines in my new script (this comment). Assuming it is due to the
floating point operation rounding/approximations mentioned in the doc,
I'm assuming the difference shows up due to the multiplication.
... off to finish reading the Floating Point doc.
Previous Comments:
[2010-04-09 05:12:28] ras...@php.net
The fix here is to decide on your precision and do:
$output = round(0.9 + ($input * 0.3), 2); // 2-decimal precision
[2010-04-09 05:05:12] ras...@php.net
Floating point values have a limited precision. Hence a value might
not have the same string representation after any processing. That also
includes writing a floating point value in your script and directly
printing it without any mathematical operations.
If you would like to know more about floats and what IEEE
754 is, read this:
http://docs.sun.com/source/806-3568/ncg_goldberg.html
Thank you for your interest in PHP.
.
[2010-04-09 05:03:27] krenshala at koboldi dot net
Description:
Math error for code that should be returning zero, but instead returns
1.1102230246252E-16 on multiple systems using multiple versions of PHP.
The problem is that when the input value is -3 the output value should
be zero: 0.9 + (-3 * 0.3) = 0.9 - 0.9 = 0. If the calculated value is
non-zero the error does not occur.
I first saw the error on a WinXP (Home SP3, 32bit) system running PHP
5.2.9-1, but it also shows up on a MAC (10.6.2) with PHP 5.3.0
installed. I'm in the process of upgrading PHP (to 5.2.13) on my Gentoo
box to test it there but haven't had a chance to do so yet.
Test script:
---
my_function(-3);
function my_function($input){
$output = 1;
if($input = 0)
$output = 0.9 + ($input * 0.3);
// the above should give 0.9 - 0.9 = 0
echo Verifying values: 0.9 - .($input * 0.3). is supposed to be
zero?\n;
echo Input: $input\tOutput: $output\n;
return $output;
}
Expected result:
should have received zero (0).
Actual result:
--
actually received: 1.1102230246252E-16
--
Edit this bug report at http://bugs.php.net/bug.php?id=51518edit=1
Bug #51518 [Bgs]: should add to zero, but gets 1.1102230246252E-16 instead
Edit report at http://bugs.php.net/bug.php?id=51518edit=1
ID: 51518
Updated by: ras...@php.net
Reported by: krenshala at koboldi dot net
Summary: should add to zero, but gets 1.1102230246252E-16
instead
Status: Bogus
Type: Bug
Package: Math related
Operating System: Multiple
PHP Version: 5.2.13
New Comment:
The important thing to take away from that doc is that computers can not
store
fractions accurately in an efficient manner. They are much better and
faster at
dealing with integers. In your particular example where you are using
0.3, that
is one of many fractions that a computer cannot represent. It is
actually
stored as 0.299988897769753748434595763683319091796875 which
is very
close to 0.3, but if you start doing math on it and any sort of exact
comparisons, it simply won't work. You can see this with this simple
code:
ini_set('precision',64);
echo 0.3;
Previous Comments:
[2010-04-09 20:40:58] krenshala at koboldi dot net
tested it on my system at home and was able to reproduce it.
$ php --version
PHP 5.2.13-pl0-gentoo (cli) (built: Apr 9 2010 03:35:37)
Copyright (c) 1997-2010 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2010 Zend Technologies
$ cat test.php
echo 0.9 - 0.9 returns .(0.9 - 0.9).\n;
echo 0.9 + (-3 * .3) returns .(0.9 + (-3 * .3)).\n;
echo -0.9 + (3 * .3) returns .(-0.9 + (3 * .3)).\n;
echo 0.8 + (-3 * .3) returns .(0.8 + (-3 * .3)).\n;
$ php test.php
0.9 - 0.9 returns 0
0.9 + (-3 * .3) returns 1.11022302463E-16
-0.9 + (3 * .3) returns -1.11022302463E-16
0.8 + (-3 * .3) returns -0.1
Also, I can understand the multiplication increasing the precision used,
from 1 to 3 significant digits in the function above. Jumping from 1E-3
to 1E-16 seems a bit much to me, however. I'm reading the Floating
Point doc you linked Rasmus in case it does address the issue. From the
little of it I've read so far it does seem to address at least some of
what is happening here.
My concern is with the differences between the output of the different
lines in my new script (this comment). Assuming it is due to the
floating point operation rounding/approximations mentioned in the doc,
I'm assuming the difference shows up due to the multiplication.
... off to finish reading the Floating Point doc.
[2010-04-09 05:12:28] ras...@php.net
The fix here is to decide on your precision and do:
$output = round(0.9 + ($input * 0.3), 2); // 2-decimal precision
[2010-04-09 05:05:12] ras...@php.net
Floating point values have a limited precision. Hence a value might
not have the same string representation after any processing. That also
includes writing a floating point value in your script and directly
printing it without any mathematical operations.
If you would like to know more about floats and what IEEE
754 is, read this:
http://docs.sun.com/source/806-3568/ncg_goldberg.html
Thank you for your interest in PHP.
.
[2010-04-09 05:03:27] krenshala at koboldi dot net
Description:
Math error for code that should be returning zero, but instead returns
1.1102230246252E-16 on multiple systems using multiple versions of PHP.
The problem is that when the input value is -3 the output value should
be zero: 0.9 + (-3 * 0.3) = 0.9 - 0.9 = 0. If the calculated value is
non-zero the error does not occur.
I first saw the error on a WinXP (Home SP3, 32bit) system running PHP
5.2.9-1, but it also shows up on a MAC (10.6.2) with PHP 5.3.0
installed. I'm in the process of upgrading PHP (to 5.2.13) on my Gentoo
box to test it there but haven't had a chance to do so yet.
Test script:
---
my_function(-3);
function my_function($input){
$output = 1;
if($input = 0)
$output = 0.9 + ($input * 0.3);
// the above should give 0.9 - 0.9 = 0
echo Verifying values: 0.9 - .($input * 0.3). is supposed to be
zero?\n;
echo Input: $input\tOutput: $output\n;
return $output;
}
Expected result:
should have received zero (0).
Actual result:
--
actually received: 1.1102230246252E-16
--
Edit this bug report at http://bugs.php.net/bug.php?id=51518edit=1
Bug #51518 [Com]: should add to zero, but gets 1.1102230246252E-16 instead
Edit report at http://bugs.php.net/bug.php?id=51518edit=1
ID: 51518
Comment by: krenshala at koboldi dot net
Reported by: krenshala at koboldi dot net
Summary: should add to zero, but gets 1.1102230246252E-16
instead
Status: Bogus
Type: Bug
Package: Math related
Operating System: Multiple
PHP Version: 5.2.13
New Comment:
That, and the problem with storing 0.1 in binary. I think those two
issues are where my problem came from.
Thank you for your time and the information. Hopefully this report (I
won't call it a bug anymore ;) will help others as well since I did not
see anything that matched it when searching before I submitted.
Previous Comments:
[2010-04-09 20:47:32] ras...@php.net
The important thing to take away from that doc is that computers can not
store
fractions accurately in an efficient manner. They are much better and
faster at
dealing with integers. In your particular example where you are using
0.3, that
is one of many fractions that a computer cannot represent. It is
actually
stored as 0.299988897769753748434595763683319091796875 which
is very
close to 0.3, but if you start doing math on it and any sort of exact
comparisons, it simply won't work. You can see this with this simple
code:
ini_set('precision',64);
echo 0.3;
[2010-04-09 20:40:58] krenshala at koboldi dot net
tested it on my system at home and was able to reproduce it.
$ php --version
PHP 5.2.13-pl0-gentoo (cli) (built: Apr 9 2010 03:35:37)
Copyright (c) 1997-2010 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2010 Zend Technologies
$ cat test.php
echo 0.9 - 0.9 returns .(0.9 - 0.9).\n;
echo 0.9 + (-3 * .3) returns .(0.9 + (-3 * .3)).\n;
echo -0.9 + (3 * .3) returns .(-0.9 + (3 * .3)).\n;
echo 0.8 + (-3 * .3) returns .(0.8 + (-3 * .3)).\n;
$ php test.php
0.9 - 0.9 returns 0
0.9 + (-3 * .3) returns 1.11022302463E-16
-0.9 + (3 * .3) returns -1.11022302463E-16
0.8 + (-3 * .3) returns -0.1
Also, I can understand the multiplication increasing the precision used,
from 1 to 3 significant digits in the function above. Jumping from 1E-3
to 1E-16 seems a bit much to me, however. I'm reading the Floating
Point doc you linked Rasmus in case it does address the issue. From the
little of it I've read so far it does seem to address at least some of
what is happening here.
My concern is with the differences between the output of the different
lines in my new script (this comment). Assuming it is due to the
floating point operation rounding/approximations mentioned in the doc,
I'm assuming the difference shows up due to the multiplication.
... off to finish reading the Floating Point doc.
[2010-04-09 05:12:28] ras...@php.net
The fix here is to decide on your precision and do:
$output = round(0.9 + ($input * 0.3), 2); // 2-decimal precision
[2010-04-09 05:05:12] ras...@php.net
Floating point values have a limited precision. Hence a value might
not have the same string representation after any processing. That also
includes writing a floating point value in your script and directly
printing it without any mathematical operations.
If you would like to know more about floats and what IEEE
754 is, read this:
http://docs.sun.com/source/806-3568/ncg_goldberg.html
Thank you for your interest in PHP.
.
[2010-04-09 05:03:27] krenshala at koboldi dot net
Description:
Math error for code that should be returning zero, but instead returns
1.1102230246252E-16 on multiple systems using multiple versions of PHP.
The problem is that when the input value is -3 the output value should
be zero: 0.9 + (-3 * 0.3) = 0.9 - 0.9 = 0. If the calculated value is
non-zero the error does not occur.
I first saw the error on a WinXP (Home SP3, 32bit) system running PHP
5.2.9-1, but it also shows up on a MAC (10.6.2) with PHP 5.3.0
installed. I'm in the process of upgrading PHP (to 5.2.13) on my Gentoo
box to test it there but haven't had a chance to do so yet.
Test script:
---
my_function(-3);
function my_function($input){
$output = 1;
if($input = 0)
$output = 0.9 + ($input * 0.3);
// the above should give 0.9 - 0.9 = 0
echo Verifying values: 0.9 - .($input * 0.3). is supposed to be
zero?\n;
echo Input: $input\tOutput: $output\n;
return $output;
}
Expected result:
should have received zero (0).
Actual result:
--
actually received: 1.1102230246252E-16
--
Edit
Bug #45826 [Com]: serialize of ArrayObject causes segmentation fault
Edit report at http://bugs.php.net/bug.php?id=45826edit=1
ID: 45826
Comment by: marcelovt at gmail dot com
Reported by: kevin dot armenat at googlemail dot com
Summary: serialize of ArrayObject causes segmentation fault
Status: Closed
Type: Bug
Package: SPL related
Operating System: *
PHP Version: 5.3CVS, 6CVS (2008-08-15)
Assigned To: colder
New Comment:
Hi, I still have a problem using serialize, works fine in 5.2.
addenum:
I have a objectToJson function that uses serialize, if the object has a
arrayObject class within, the error occurs.
Code:
-
$serial = serialize( $object ) ;
$serial = preg_replace( '/O:\d+:.+?/' ,'a' , $serial ) ;
if( preg_match_all( '/s:\d+:\\0.+?\\0(.+?)/' , $serial, $ms,
PREG_SET_ORDER )) {
foreach( $ms as $m ) {
$serial = str_replace( $m[0], 's:'. strlen( $m[1] ) . ':'.$m[1] .
'', $serial ) ;
}
}
return @unserialize( $serial ) ;
Previous Comments:
[2008-08-25 18:41:14] col...@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-15 00:49:22] j...@php.net
Works fine with 5.2CVS, crash with anything greater.
[2008-08-15 00:44:01] kevin dot armenat at googlemail dot com
You still need this short code to reproduce the error, its related to
the ArrayObject, not to the User defined Classes.
$x = new ArrayObject();
$x-append($x);
serialize($x);
[2008-08-15 00:14:14] kevin dot armenat at googlemail dot com
Description:
Serialize causes a segmentation fault if you try to serialize an object
(A) which contains an object (B) which references to object A.
Its still working with PHP 5.2.4, but it crashes with PHP 5.3.0alpha1.
Reproduce code:
---
class A {
private $bList;
public function __construct() {
$this-bList = new ArrayObject();
}
public function addB(B $b) {
$this-bList-append($b);
}
}
class B {
private $parentA;
public function __construct(A $parentA) {
$this-parentA = $parentA;
}
}
$a = new A();
$b = new B($a);
$a-addB($b);
echo serialize($a);
Expected result:
The serialized Object of the class A
Actual result:
--
#0 0xb744b8a8 in _zend_mm_alloc_int (heap=0x81e0db8, size=20) at
/home/kevin/php-5.3.0alpha1/Zend/zend_alloc.c:1743
#1 0xb745c821 in zend_call_function (fci=0xbf15f148,
fci_cache=0xbf15f16c) at
/home/kevin/php-5.3.0alpha1/Zend/zend_execute_API.c:894
#2 0xb747b018 in zend_call_method (object_pp=0xbf15f200,
obj_ce=0x824bfc8, fn_proxy=0x824c0dc, function_name=0xb77311f0
serialize,
function_name_len=9, retval_ptr_ptr=0xbf15f1ec, param_count=0,
arg1=0x0, arg2=0x0)
at /home/kevin/php-5.3.0alpha1/Zend/zend_interfaces.c:89
#3 0xb747b26d in zend_user_serialize (object=0x82f1164,
buffer=0xbf15f28c, buf_len=0xbf15f278, data=0xbf15f570)
at /home/kevin/php-5.3.0alpha1/Zend/zend_interfaces.c:414
#4 0xb73dc722 in php_var_serialize_intern (buf=0xbf15f5a8,
struc=0x82f1164, var_hash=0xbf15f570)
at /home/kevin/php-5.3.0alpha1/ext/standard/var.c:694
#5 0xb73dc497 in php_var_serialize_intern (buf=0xbf15f5a8,
struc=0x82f0f88, var_hash=0xbf15f570)
at /home/kevin/php-5.3.0alpha1/ext/standard/var.c:795
#6 0xb73dc497 in php_var_serialize_intern (buf=0xbf15f5a8,
struc=0x82f1300, var_hash=0xbf15f570)
at /home/kevin/php-5.3.0alpha1/ext/standard/var.c:795
#7 0xb73dc497 in php_var_serialize_intern (buf=0xbf15f5a8,
struc=0x82f128c, var_hash=0xbf15f570)
at /home/kevin/php-5.3.0alpha1/ext/standard/var.c:795
#8 0xb73de049 in php_var_serialize (buf=0xbf15f5a8, struc=0x82f11e4,
var_hash=0xbf15f570)
at /home/kevin/php-5.3.0alpha1/ext/standard/var.c:814
#9 0xb72f0838 in zim_spl_Array_serialize (ht=0, return_value=0x8568bbc,
return_value_ptr=0xbf15f79c, this_ptr=0x82f1164,
return_value_used=1) at
/home/kevin/php-5.3.0alpha1/ext/spl/spl_array.c:1491
#10 0xb745c891 in zend_call_function (fci=0xbf15f6f8,
fci_cache=0xbf15f71c) at
Bug #51216 [Com]: Segmentation fault when compiling PHP with PHAR
Edit report at http://bugs.php.net/bug.php?id=51216edit=1
ID: 51216
Comment by: holderm at lycos dot com
Reported by: dtm2mcs at gmail dot com
Summary: Segmentation fault when compiling PHP with PHAR
Status: Open
Type: Bug
Package: PHAR related
Operating System: Ubuntu 6.04 + CentOS 5.4
PHP Version: 5.3.2
New Comment:
I've got a workaround. The problem seems to be that the
build_precommand.php script cannot run on systems that do not have a
working version of php.
I think the Makefile is doing this for me already but just to be sure I
tried changing the shebang from #!/usr/bin/php to my local
#!/app/psoft/devl/packages/php/php-5.3.2/sapi/cli/php (based on what I
thought the Makefile was doing). I kept running it from the command
line and getting things like this (I was adding my own debugging info on
lines that begin with // ):
/app/psoft/devl/packages/php/php-5.3.2/ext/phar/
hdlmpdu4/blk10.1/dev ./build_precommand.php
?php
/** @file phar.php
* @ingroup Phar
* @brief class Phar Pre Command
* @author Marcus Boerger
* @date2007 - 2008
*
* Phar Command
*/
foreach(array(SPL, Reflection, Phar) as $ext) {
if (!extension_loaded($ext)) {
echo $argv[0] requires PHP extension $ext.\n;
exit(1);
}
}
if (!class_exists('DirectoryTreeIterator', 0))
{
// name == DirectoryTreeIterator
// file(dirname('__FILE__') . '/phar/' .
strtolower('DirectoryTreeIterator') . '.inc');
// g == __FILE__/phar/$name.inc
Segmentation Fault(coredump)
Finally I decided to bring over a working php executable from another
server and give it a try:
/app/psoft/devl/packages/php/php-5.3.2/ext/phar/
hdlmpdu4/blk10.1/dev which php
/app/psoft/devl/bin/php
/app/psoft/devl/packages/php/php-5.3.2/ext/phar/
hdlmpdu4/blk10.1/dev /app/psoft/devl/bin/php --version
PHP 5.0.2 (cli) (built: Oct 21 2004 17:00:20)
Copyright (c) 1997-2004 The PHP Group
Zend Engine v2.0.2, Copyright (c) 1998-2004 Zend Technologies
/app/psoft/devl/packages/php/php-5.3.2/ext/phar/
hdlmpdu4/blk10.1/dev ./build_precommand.php
?php
/** @file phar.php
* @ingroup Phar
* @brief class Phar Pre Command
* @author Marcus Boerger
* @date2007 - 2008
*
* Phar Command
*/
foreach(array(SPL, Reflection, Phar) as $ext) {
if (!extension_loaded($ext)) {
echo $argv[0] requires PHP extension $ext.\n;
exit(1);
}
}
if (!class_exists('DirectoryTreeIterator', 0))
{
// name == DirectoryTreeIterator
// file(dirname('__FILE__') . '/phar/' .
strtolower('DirectoryTreeIterator') . '.inc');
// g == __FILE__/phar/$name.inc
// f == Array
// f == Array
// c == 53
/** @file directorytreeiterator.inc
* @ingroup Examples
* @brief class DirectoryTreeIterator
* @author Marcus Boerger
* @date2003 - 2008
*
* SPL - Standard PHP Library
*/
/** @ingroup Examples
* @brief DirectoryIterator to generate ASCII graphic directory trees
* @author Marcus Boerger
* @version 1.1
*/
class DirectoryTreeIterator extends RecursiveIteratorIterator
{
/** Construct from a path.
* @param $path directory to iterate
*/
function __construct($path)
So, the problem is that the php executable that's built as an interem
version for running the build_precommand.php script is not able to use
the strtolower() function or the dirname() function (as far as my
testing got, it bombed on each of those isolated cases).
I was able to make a kludge workaround by modifing the Makefile
replacing $(PHP_PHARCMD_EXECUTABLE) with my executable, but the next
step failed (target ext/phar/phar.phar:). So I had to disable phar.
Previous Comments:
[2010-04-09 00:22:37] holderm at lycos dot com
The problem is in build_precommand.php. When I run it it gets to the
open curly brace and churns for a couple seconds, then it Seg faults.
I'm not sure how to fix it but will try changing it.
/app/psoft/devl/packages/php/php-5.3.2/ext/phar/
hdlmpdu4/blk10.1/dev ./build_precommand.php
?php
/** @file phar.php
* @ingroup Phar
* @brief class Phar Pre Command
* @author Marcus Boerger
* @date2007 - 2008
*
* Phar Command
*/
foreach(array(SPL, Reflection, Phar) as $ext) {
if (!extension_loaded($ext)) {
echo $argv[0] requires PHP extension $ext.\n;
exit(1);
}
}
if (!class_exists('DirectoryTreeIterator', 0))
{
Segmentation Fault(coredump)
[2010-04-07 23:34:47] holderm at lycos dot com
I'm getting the same thing with Solaris 10 and gcc 4.4.3. It seems the
Makefile is not generating a full ext/phar/phar.php (when compared to
ext/phar/phar/phar.php). The code ends with an open curly brace:
Bug #51216 [Com]: Segmentation fault when compiling PHP with PHAR
Edit report at http://bugs.php.net/bug.php?id=51216edit=1
ID: 51216
Comment by: holderm at lycos dot com
Reported by: dtm2mcs at gmail dot com
Summary: Segmentation fault when compiling PHP with PHAR
Status: Open
Type: Bug
Package: PHAR related
Operating System: Ubuntu 6.04 + CentOS 5.4
PHP Version: 5.3.2
New Comment:
It looks like it's more than a phar problem. I can build it rith phar
disabled but it still won't run anything other than the --version
option.
Build complete.
Don't forget to run 'make test'.
/app/psoft/devl/packages/php/php-5.3.2/
hdlmpdu4/blk10.1/dev make test
Build complete.
Don't forget to run 'make test'.
Segmentation Fault - core dumped
make: [test] Error 139 (ignored)
/app/psoft/devl/packages/php/php-5.3.2/
hdlmpdu4/blk10.1/dev ll ./sapi/cli/php
-rwxr-xr-x 1 lmpjob lmpjob 18524408 Apr 9 16:25 ./sapi/cli/php
/app/psoft/devl/packages/php/php-5.3.2/
hdlmpdu4/blk10.1/dev ./sapi/cli/php --version
PHP 5.3.2 (cli) (built: Apr 8 2010 18:07:52)
Copyright (c) 1997-2010 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
Previous Comments:
[2010-04-09 22:21:18] holderm at lycos dot com
I've got a workaround. The problem seems to be that the
build_precommand.php script cannot run on systems that do not have a
working version of php.
I think the Makefile is doing this for me already but just to be sure I
tried changing the shebang from #!/usr/bin/php to my local
#!/app/psoft/devl/packages/php/php-5.3.2/sapi/cli/php (based on what I
thought the Makefile was doing). I kept running it from the command
line and getting things like this (I was adding my own debugging info on
lines that begin with // ):
/app/psoft/devl/packages/php/php-5.3.2/ext/phar/
hdlmpdu4/blk10.1/dev ./build_precommand.php
?php
/** @file phar.php
* @ingroup Phar
* @brief class Phar Pre Command
* @author Marcus Boerger
* @date2007 - 2008
*
* Phar Command
*/
foreach(array(SPL, Reflection, Phar) as $ext) {
if (!extension_loaded($ext)) {
echo $argv[0] requires PHP extension $ext.\n;
exit(1);
}
}
if (!class_exists('DirectoryTreeIterator', 0))
{
// name == DirectoryTreeIterator
// file(dirname('__FILE__') . '/phar/' .
strtolower('DirectoryTreeIterator') . '.inc');
// g == __FILE__/phar/$name.inc
Segmentation Fault(coredump)
Finally I decided to bring over a working php executable from another
server and give it a try:
/app/psoft/devl/packages/php/php-5.3.2/ext/phar/
hdlmpdu4/blk10.1/dev which php
/app/psoft/devl/bin/php
/app/psoft/devl/packages/php/php-5.3.2/ext/phar/
hdlmpdu4/blk10.1/dev /app/psoft/devl/bin/php --version
PHP 5.0.2 (cli) (built: Oct 21 2004 17:00:20)
Copyright (c) 1997-2004 The PHP Group
Zend Engine v2.0.2, Copyright (c) 1998-2004 Zend Technologies
/app/psoft/devl/packages/php/php-5.3.2/ext/phar/
hdlmpdu4/blk10.1/dev ./build_precommand.php
?php
/** @file phar.php
* @ingroup Phar
* @brief class Phar Pre Command
* @author Marcus Boerger
* @date2007 - 2008
*
* Phar Command
*/
foreach(array(SPL, Reflection, Phar) as $ext) {
if (!extension_loaded($ext)) {
echo $argv[0] requires PHP extension $ext.\n;
exit(1);
}
}
if (!class_exists('DirectoryTreeIterator', 0))
{
// name == DirectoryTreeIterator
// file(dirname('__FILE__') . '/phar/' .
strtolower('DirectoryTreeIterator') . '.inc');
// g == __FILE__/phar/$name.inc
// f == Array
// f == Array
// c == 53
/** @file directorytreeiterator.inc
* @ingroup Examples
* @brief class DirectoryTreeIterator
* @author Marcus Boerger
* @date2003 - 2008
*
* SPL - Standard PHP Library
*/
/** @ingroup Examples
* @brief DirectoryIterator to generate ASCII graphic directory trees
* @author Marcus Boerger
* @version 1.1
*/
class DirectoryTreeIterator extends RecursiveIteratorIterator
{
/** Construct from a path.
* @param $path directory to iterate
*/
function __construct($path)
So, the problem is that the php executable that's built as an interem
version for running the build_precommand.php script is not able to use
the strtolower() function or the dirname() function (as far as my
testing got, it bombed on each of those isolated cases).
I was able to make a kludge workaround by modifing the Makefile
replacing $(PHP_PHARCMD_EXECUTABLE) with my executable, but the next
step failed (target ext/phar/phar.phar:). So I had to disable phar.
[2010-04-09 00:22:37] holderm at lycos dot com
The problem is in build_precommand.php. When I run it it gets to the
open curly brace and churns for a couple seconds, then it Seg faults.
I'm not sure
[PHP-BUG] Bug #51522 [NEW]: function floor
From: Operating system: windows PHP version: 5.2.13 Package: *General Issues Bug Type: Bug Bug description:function floor Description: example: $value=30.40; $comision=5; $val_comision=($value*(1/(1-($comision/100)))-$value); $suma=$val_comision + $value; $value_acreditado=floor($suma); $value_acreditado=31 // wrong result but the correct answere is 32 Test script: --- example: $value=30.40; $comision=5; $val_comision=($value*(1/(1-($comision/100)))-$value); $suma=$val_comision + $value; $value_acreditado=floor($suma); $value_acreditado=31 // wrong result but the correct answere is 32 Expected result: correct answere is 32 Actual result: -- $value_acreditado=31 -- Edit bug report at http://bugs.php.net/bug.php?id=51522edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=51522r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=51522r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=51522r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=51522r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=51522r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=51522r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=51522r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=51522r=needscript Try newer version: http://bugs.php.net/fix.php?id=51522r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=51522r=support Expected behavior: http://bugs.php.net/fix.php?id=51522r=notwrong Not enough info: http://bugs.php.net/fix.php?id=51522r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=51522r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=51522r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51522r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=51522r=dst IIS Stability: http://bugs.php.net/fix.php?id=51522r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=51522r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=51522r=float No Zend Extensions: http://bugs.php.net/fix.php?id=51522r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=51522r=mysqlcfg
Bug #51522 [Opn-Bgs]: function floor
Edit report at http://bugs.php.net/bug.php?id=51522edit=1 ID: 51522 Updated by: paj...@php.net Reported by: adrianoepn at hotmail dot com Summary: function floor -Status: Open +Status: Bogus Type: Bug Package: *General Issues Operating System: windows PHP Version: 5.2.13 New Comment: Floating point values have a limited precision. Hence a value might not have the same string representation after any processing. That also includes writing a floating point value in your script and directly printing it without any mathematical operations. If you would like to know more about floats and what IEEE 754 is, read this: http://docs.sun.com/source/806-3568/ncg_goldberg.html Thank you for your interest in PHP. Previous Comments: [2010-04-10 00:19:18] adrianoepn at hotmail dot com Description: example: $value=30.40; $comision=5; $val_comision=($value*(1/(1-($comision/100)))-$value); $suma=$val_comision + $value; $value_acreditado=floor($suma); $value_acreditado=31 // wrong result but the correct answere is 32 Test script: --- example: $value=30.40; $comision=5; $val_comision=($value*(1/(1-($comision/100)))-$value); $suma=$val_comision + $value; $value_acreditado=floor($suma); $value_acreditado=31 // wrong result but the correct answere is 32 Expected result: correct answere is 32 Actual result: -- $value_acreditado=31 -- Edit this bug report at http://bugs.php.net/bug.php?id=51522edit=1
Bug #51522 [Bgs]: function floor
Edit report at http://bugs.php.net/bug.php?id=51522edit=1 ID: 51522 Updated by: ras...@php.net Reported by: adrianoepn at hotmail dot com Summary: function floor Status: Bogus Type: Bug Package: *General Issues Operating System: windows PHP Version: 5.2.13 New Comment: And to fix your code, use: $suma=$val_comision + $value; $value_acreditado=floor(round($suma,2)); Previous Comments: [2010-04-10 00:27:34] paj...@php.net Floating point values have a limited precision. Hence a value might not have the same string representation after any processing. That also includes writing a floating point value in your script and directly printing it without any mathematical operations. If you would like to know more about floats and what IEEE 754 is, read this: http://docs.sun.com/source/806-3568/ncg_goldberg.html Thank you for your interest in PHP. [2010-04-10 00:19:18] adrianoepn at hotmail dot com Description: example: $value=30.40; $comision=5; $val_comision=($value*(1/(1-($comision/100)))-$value); $suma=$val_comision + $value; $value_acreditado=floor($suma); $value_acreditado=31 // wrong result but the correct answere is 32 Test script: --- example: $value=30.40; $comision=5; $val_comision=($value*(1/(1-($comision/100)))-$value); $suma=$val_comision + $value; $value_acreditado=floor($suma); $value_acreditado=31 // wrong result but the correct answere is 32 Expected result: correct answere is 32 Actual result: -- $value_acreditado=31 -- Edit this bug report at http://bugs.php.net/bug.php?id=51522edit=1
[PHP-BUG] Bug #51523 [NEW]: Memory leak on fread()
From:
Operating system: Linux
PHP version: Irrelevant
Package: Performance problem
Bug Type: Bug
Bug description:Memory leak on fread()
Description:
The problem is the fread() uses a normal amount of a memory. But there are
too many unallocated anonymous memory pages.
So if the file size 2G the script may cause eating up to 2G of RAM. But
the script's runtime memory is 5M.
The problem is occured even if:
$fp = fopen($file, rb);
while(!feof($fp))
fread($fp, 1024);
fclose($fp);
After that the memory isn't released so we have a garbadge in the memory.
Test script:
---
?php
$file = A.very.big.file.avi;
ob_start();
$fp = fopen($file, wb);
if ($fp)
{
while(!feof($fp))
{
echo(fread($fp, 1024));
if (ob_get_length())
{
ob_flush();
flush();
ob_end_flush();
}
}
fclose($fp);
@ob_flush();
@flush();
@ob_end_flush();
@ob_end_clean();
}
?
Expected result:
The total amount of a memory usage should be at least php script runtime
memory usage + 1024 (+ some buffer (up to 8192)). But not almost all the
physical memory (0...unlimited)
--
Edit bug report at http://bugs.php.net/bug.php?id=51523edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=51523r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=51523r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=51523r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=51523r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=51523r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=51523r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=51523r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=51523r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=51523r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=51523r=support
Expected behavior:
http://bugs.php.net/fix.php?id=51523r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=51523r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=51523r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=51523r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51523r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=51523r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=51523r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=51523r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=51523r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=51523r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=51523r=mysqlcfg
Req #51001 [Com]: Always shows stack trace when a Fatal error occurs
Edit report at http://bugs.php.net/bug.php?id=51001edit=1
ID: 51001
Comment by: a at b dot c dot de
Reported by: abdallah at gmx dot com
Summary: Always shows stack trace when a Fatal error occurs
Status: Open
Type: Feature/Change Request
Package: Feature/Change Request
Operating System: Windows 7
PHP Version: 5.3.1
New Comment:
An observation from me:
A stack trace is dumped in the event of a fatal error (depending on the
error reporting level); but it's only when an uncaught exception reaches
the top of the call stack without being handled that such an error
occurs. If it is caught, then it's not an uncaught exception and
therefore not a Fatal error.
Previous Comments:
[2010-02-10 20:05:24] abdallah at gmx dot com
Description:
Always shows stack trace when a Fatal error occurs without having to do
always something like this :
?php
function test() {
throw new Exception;
}
try {
test();
} catch(Exception $e) {
echo $e-getTraceAsString();
}
?
Reproduce code:
---
?php
function test() {
throw new Exception;
}
try {
test();
} catch(Exception $e) {
echo $e-getTraceAsString();
}
?
Expected result:
#0 /home/bjori/tmp/ex.php(7): test()
#1 {main}
Actual result:
--
nothin'
--
Edit this bug report at http://bugs.php.net/bug.php?id=51001edit=1
[PHP-BUG] Bug #51524 [NEW]: Class static method confusion
From: Operating system: Windows 7/64 PHP version: 5.3.2 Package: Scripting Engine problem Bug Type: Bug Bug description:Class static method confusion Description: If I use public method as static in a method of a second function, this send $this from second class, don't of the first. Test script: --- http://codepad.org/8hW4Qtbo Expected result: array 0 = string 'static' (length=6) 1 = int 1 array 0 = string 'object' (length=6) 1 = object(test)[2] 2 = int 1 array 0 = string 'static' (length=6) 1 = int 1 array 0 = string 'object' (length=6) 1 = object(test)[3] OKAY 2 = int 1 Actual result: -- array 0 = string 'static' (length=6) 1 = int 1 array 0 = string 'object' (length=6) 1 = object(test)[2] 2 = int 1 array 0 = string 'static' (length=6) 1 = int 1 array 0 = string 'object' (length=6) 1 = object(test2)[3] WHY test2 IF DON'T? 2 = int 1 -- Edit bug report at http://bugs.php.net/bug.php?id=51524edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=51524r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=51524r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=51524r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=51524r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=51524r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=51524r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=51524r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=51524r=needscript Try newer version: http://bugs.php.net/fix.php?id=51524r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=51524r=support Expected behavior: http://bugs.php.net/fix.php?id=51524r=notwrong Not enough info: http://bugs.php.net/fix.php?id=51524r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=51524r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=51524r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51524r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=51524r=dst IIS Stability: http://bugs.php.net/fix.php?id=51524r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=51524r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=51524r=float No Zend Extensions: http://bugs.php.net/fix.php?id=51524r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=51524r=mysqlcfg
[PHP-BUG] Bug #51525 [NEW]: Getting a node with a - in it
From:
Operating system: Windows
PHP version: 5.2.13
Package: SimpleXML related
Bug Type: Bug
Bug description:Getting a node with a - in it
Description:
If a XML node have a - in it you can't get the data from it
display-name
echo $channel-display-name;
Notice: Use of undefined constant name - assumed 'name'
Test script:
---
?xml version=1.0 encoding=UTF-8 ?
tv generator-info-name=www.ontv.dk/xmltv
channel id=www.ontv.dk/tv/1
display-name lang=dkDR1 DK/display-name
/channel
/tv
$xml = simplexml_load_string($xml);
$channels = $this-xml-xpath('//channel');
foreach($channels AS $channel) {
echo $channel-display-name;
}
Expected result:
DR1 DK
Actual result:
--
Notice: Use of undefined constant name - assumed 'name'
--
Edit bug report at http://bugs.php.net/bug.php?id=51525edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=51525r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=51525r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=51525r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=51525r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=51525r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=51525r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=51525r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=51525r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=51525r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=51525r=support
Expected behavior:
http://bugs.php.net/fix.php?id=51525r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=51525r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=51525r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=51525r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51525r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=51525r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=51525r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=51525r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=51525r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=51525r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=51525r=mysqlcfg
Bug #45150 [Com]: MySQL functions cannot be used with 5.3.x on Vista when using localhost
Edit report at http://bugs.php.net/bug.php?id=45150edit=1 ID: 45150 Comment by: buana95 at yahoo dot com Reported by: conor dot kerr_php at dev dot ceon dot net Summary: MySQL functions cannot be used with 5.3.x on Vista when using localhost Status: Bogus Type: Bug Package: MySQL related Operating System: Windows Vista PHP Version: 5.3CVS-2008-07-23 (snap) New Comment: Same issue on Windows XP SP3 and PHP 5.3.1 with mysqlnd 5.0.5-dev - 081106 - $Revision: 289630 $. Work fine when using *libmysql.dll, but can not connect to database when using *mysqlnd.dll (tested on mysql, mysqli, and PDO extension). *** From MySQL website: they have resolved the issue by looping to all available IP (IPv4 - IPv6) and return the first successful connection. So, it's must be from PHP streams that fail to resolve IPv6. Never test on newer PHP version. Sorry. Previous Comments: [2010-04-05 07:52:30] telstra at dark-media dot net Had the same problem on Windows Server 2008 R2 had to edit the hosts file and un comment out the 127.0.0.1 localhost Was stumbled for a while after upgrading from 5.2 to 5.3, this might not be a bug with PHP but its something that is going to cause issues. [2010-03-16 13:55:28] achurkin at gmail dot com Same on Windows 7 Home Edition. In PHP version 5.2.9 on same system everything works fine. [2010-03-05 20:51:16] paj...@php.net That's not a bug, please refer to the dozen other reports about that. [2010-03-05 20:46:38] changeorders at gmail dot com Fresh install of PHP 5.3.x on Server 2008. Same problem. Had to comment out the IPv6 entry for localhost in the hosts file. This is still a bug. [2008-07-23 13:27:36] conor dot kerr_php at dev dot ceon dot net Okay, I've looked into this further and tested with PHP5.2.6 on the same setup and get the same problem. I've seen a few bugs in the database which refer to this same localhost/127.0.0.1 issue. I agree that it's not a PHP issue. However, it will become a serious enough issue for people when they move to 5.3 from a previous version as many PHP-based open source software packages use localhost as their default database server host. A lot of people will waste a lot of time unless it is made prevalent somewhere that: 127.0.0.1 should be used instead of localhost on Vista OR: the line ::1 localhost should be commented out in the hosts file for Vista: #::1 localhost Where is the best place to put this information? At the very least, it should be part of the upgrade notes for 5.3 as, I'm willing to bet, many PHP developers haven't previously used streams and this issue will not have affected them until they upgrade to 5.3, at which point MySQL will constantly time out on them because it does use streams and therefore is susceptible to this windoze bug. Hopefully there are no Badly configured OS is not a PHP bug - Bogus-type replies to this, that would not be helpful for the PHP community at large! This information needs to be made prevalent somewhere regarding 5.3. Thanks, I hope I've been of help to some others! All the best... Conor http://ceon.net 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=45150 -- Edit this bug report at http://bugs.php.net/bug.php?id=45150edit=1
Bug-Req #51525 [Opn]: Getting a node with a - in it
Edit report at http://bugs.php.net/bug.php?id=51525edit=1
ID: 51525
User updated by: martin at aarhof dot eu
Reported by: martin at aarhof dot eu
Summary: Getting a node with a - in it
Status: Open
-Type: Bug
+Type: Feature/Change Request
Package: SimpleXML related
Operating System: Windows
PHP Version: 5.2.13
New Comment:
Solution is
echo $channel-{display-name};
Could this be fixed so you dont need the {} ?
Previous Comments:
[2010-04-10 03:56:21] martin at aarhof dot eu
Description:
If a XML node have a - in it you can't get the data from it
display-name
echo $channel-display-name;
Notice: Use of undefined constant name - assumed 'name'
Test script:
---
?xml version=1.0 encoding=UTF-8 ?
tv generator-info-name=www.ontv.dk/xmltv
channel id=www.ontv.dk/tv/1
display-name lang=dkDR1 DK/display-name
/channel
/tv
$xml = simplexml_load_string($xml);
$channels = $this-xml-xpath('//channel');
foreach($channels AS $channel) {
echo $channel-display-name;
}
Expected result:
DR1 DK
Actual result:
--
Notice: Use of undefined constant name - assumed 'name'
--
Edit this bug report at http://bugs.php.net/bug.php?id=51525edit=1
Req #51525 [Opn-Bgs]: Getting a node with a - in it
Edit report at http://bugs.php.net/bug.php?id=51525edit=1
ID: 51525
Updated by: ahar...@php.net
Reported by: martin at aarhof dot eu
Summary: Getting a node with a - in it
-Status: Open
+Status: Bogus
Type: Feature/Change Request
Package: SimpleXML related
Operating System: Windows
PHP Version: 5.2.13
New Comment:
Given that - already has another meaning in PHP, no, not really.
Previous Comments:
[2010-04-10 04:12:47] martin at aarhof dot eu
Solution is
echo $channel-{display-name};
Could this be fixed so you dont need the {} ?
[2010-04-10 03:56:21] martin at aarhof dot eu
Description:
If a XML node have a - in it you can't get the data from it
display-name
echo $channel-display-name;
Notice: Use of undefined constant name - assumed 'name'
Test script:
---
?xml version=1.0 encoding=UTF-8 ?
tv generator-info-name=www.ontv.dk/xmltv
channel id=www.ontv.dk/tv/1
display-name lang=dkDR1 DK/display-name
/channel
/tv
$xml = simplexml_load_string($xml);
$channels = $this-xml-xpath('//channel');
foreach($channels AS $channel) {
echo $channel-display-name;
}
Expected result:
DR1 DK
Actual result:
--
Notice: Use of undefined constant name - assumed 'name'
--
Edit this bug report at http://bugs.php.net/bug.php?id=51525edit=1
