Req #51525 [Opn->Bgs]: Getting a node with a - in it
Edit report at http://bugs.php.net/bug.php?id=51525&edit=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 echo $channel->display-name; Notice: Use of undefined constant name - assumed 'name' Test script: --- DR1 DK $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=51525&edit=1
Bug->Req #51525 [Opn]: Getting a node with a - in it
Edit report at http://bugs.php.net/bug.php?id=51525&edit=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 echo $channel->display-name; Notice: Use of undefined constant name - assumed 'name' Test script: --- DR1 DK $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=51525&edit=1
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=45150&edit=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=45150&edit=1
[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 echo $channel->display-name; Notice: Use of undefined constant name - assumed 'name' Test script: --- DR1 DK $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=51525&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=51525&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=51525&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=51525&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=51525&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=51525&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=51525&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=51525&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=51525&r=needscript Try newer version: http://bugs.php.net/fix.php?id=51525&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=51525&r=support Expected behavior: http://bugs.php.net/fix.php?id=51525&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=51525&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=51525&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=51525&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51525&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=51525&r=dst IIS Stability: http://bugs.php.net/fix.php?id=51525&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=51525&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=51525&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=51525&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=51525&r=mysqlcfg
[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=51524&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=51524&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=51524&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=51524&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=51524&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=51524&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=51524&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=51524&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=51524&r=needscript Try newer version: http://bugs.php.net/fix.php?id=51524&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=51524&r=support Expected behavior: http://bugs.php.net/fix.php?id=51524&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=51524&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=51524&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=51524&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51524&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=51524&r=dst IIS Stability: http://bugs.php.net/fix.php?id=51524&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=51524&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=51524&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=51524&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=51524&r=mysqlcfg
Req #51001 [Com]: Always shows stack trace when a Fatal error occurs
Edit report at http://bugs.php.net/bug.php?id=51001&edit=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 : getTraceAsString(); } ?> Reproduce code: --- 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=51001&edit=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: --- Expected result: The total amount of a memory usage should be at least + 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=51523&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=51523&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=51523&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=51523&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=51523&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=51523&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=51523&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=51523&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=51523&r=needscript Try newer version: http://bugs.php.net/fix.php?id=51523&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=51523&r=support Expected behavior: http://bugs.php.net/fix.php?id=51523&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=51523&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=51523&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=51523&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51523&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=51523&r=dst IIS Stability: http://bugs.php.net/fix.php?id=51523&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=51523&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=51523&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=51523&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=51523&r=mysqlcfg
Bug #51522 [Bgs]: function floor
Edit report at http://bugs.php.net/bug.php?id=51522&edit=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=51522&edit=1
Bug #51522 [Opn->Bgs]: function floor
Edit report at http://bugs.php.net/bug.php?id=51522&edit=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=51522&edit=1
[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=51522&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=51522&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=51522&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=51522&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=51522&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=51522&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=51522&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=51522&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=51522&r=needscript Try newer version: http://bugs.php.net/fix.php?id=51522&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=51522&r=support Expected behavior: http://bugs.php.net/fix.php?id=51522&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=51522&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=51522&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=51522&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51522&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=51522&r=dst IIS Stability: http://bugs.php.net/fix.php?id=51522&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=51522&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=51522&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=51522&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=51522&r=mysqlcfg
Bug #51216 [Com]: Segmentation fault when compiling PHP with PHAR
Edit report at http://bugs.php.net/bug.php?id=51216&edit=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 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 ./build_precommand.php ll ext/phar/phar.php -rw-r--r-- 1 lmpjob lmpjob 351 Apr 7 16:10 ext/phar/phar.php /app/psoft/devl/packages/php/php-5.3.2/ hdlmpdu4/blk10.1/dev > ll ext/phar/phar/phar.php -rwxr-xr-x 1 lmpjob lmpjob 992 Aug 1 2008 ext/phar/phar/phar.php /app/psoft/devl/packages/php/php-5.3.2/ hdlmpdu4/blk10.1/dev > cat ext/phar/phar.php ext/phar/phar.php My configure options were: /app/psoft/devl/packages/php/php-5.3.2/ hdlmpdu4/blk10.1/dev > cat config.nice #! /bin/sh # # Created by configure './configure' \ '--prefix=/app/psoft/scripts/pkg/php5' \ '--enable-cli' \ '--disable-cgi' \ '--with-bz2' \ '--with-zlib' \ '--with-png-dir=/app/psoft/scripts/pkg/png-1.4.1' \ '--with-gd' \ '--with-oci8=/app/oracle/product/10.2.0' \ "$@" [2010-03-30 17:39:38] tony at tonybibbs dot com Same issue on 32bit Ubuntu 9.10 [2010-03-26 00:16:11] mm_half3 at yahoo dot com For what it is worth, I had the same issue on Solaris 10 sparc, compiling with gcc-4.3.1, and php-5.32 (tried with stable release and latest development src). Further research found other solaris types getting segmentation faults during php 5.2.xx make test, see http://bugs.php.net/bug.php?id=47824&edit=1 . Which I also could reproduce. Setting CFLAGS=-O1, got php5.32 to compile and make test successfully with phar, and 5.2.xx to compile without fatal errors. The seg fault is probably not a php issue, but something in the gcc version. The make test looks like all the tests run, but there is an issue when the Test Summary is done for both: WARNED TEST SUMMARY - via [ext/pdo_sqlite/tests/common.phpt] SQLite PDO Common: Bug #34630 (inserting streams as LOBs) [ext/pdo_sqlite/tests/bug_34630.phpt] (warn: XFAIL section but test passes) via [ext/sqlite/tests/pdo/common.phpt] SQLite2 PDO Common: Bug #34630 (inserting streams as LOBs) [ext/sqlite/tests/pdo/bug_34630.phpt] (warn: XFAIL section but test passes) = You may have found a problem in PHP. We would like to send this report automatically to the PHP QA team, to give us a better understanding of how the test cases are doing. If you don't want to send it immediately, you can choose "s" to save the report to a file that you can send us later. Do you want to send this report now? [Yns]: s Please send /tmp/php-5.3.2/php_
Bug #51216 [Com]: Segmentation fault when compiling PHP with PHAR
Edit report at http://bugs.php.net/bug.php?id=51216&edit=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 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 ./build_precommand.php ll ext/phar/phar.php -rw-r--r-- 1 lmpjob lmpjob 351 Apr 7 16:10 ext/phar/phar.php /app/psoft/devl/packages/php/php-5.3.2/ hdlmpdu4/blk10.1/dev > ll ext/phar/phar/phar.php -rwxr-xr-x 1 lmpjob lmpjob 992 Aug 1 2008 ext/phar/phar/phar.php /app/psoft/devl/packages/php/php-5.3.2/ hdlmpdu4/blk10.1/dev > cat ext/phar/phar.php ext/phar/phar.php My configure options were: /app/psoft/devl/packages/php/php-5.3.2/ hdlmpdu4/blk10.1/dev > cat config.nice #! /bin/sh # # Created by configure './configure' \ '--prefix=/app/psoft/scripts/pkg/php5' \ '--enable-cli' \ '--disable-cgi' \ '--with-bz2' \ '--with-zlib' \ '--with-png-dir=/app/psoft/scripts/pkg/png-1.4.1' \ '--with-gd' \ '--with-oci8=/app/oracle/product/10.2.0' \ "$@" [2010-03-30 17:39:38] tony at tonybibbs dot com Same issue on 32bit Ubuntu 9.10 [2010-03-26 00:16:11] mm_half3 at yahoo dot com For what it is worth, I had the same issue on Solaris 10 sparc, compiling with gcc-4.3.1, and php-5.32 (tried with stable release and latest development src). Further research found other solaris types getting segmentation faults during php 5.2.xx make test, see http://bugs.php.net/bug.php?id=47824&edit=1 . Which I also could reproduce. Setting CFLAGS=-O1, got php5.32 to compile and make test successfully with phar, and 5.2.xx to compile without fatal errors. The seg fault is probably not a php issue, but something in the gcc version. The make test looks like all the tests run, but there is an issue when the Test Summary is done for both: WARNED TEST SUMMARY - via [ext/pdo_sqlite/tests/common.phpt] SQLite PDO Common: Bug #34630 (inserting streams as LOBs) [ext/pdo_sqlite/tests/bug_34630.phpt] (warn: XFAIL section but test passes) via [ext/sqlite/tests/pdo/common.phpt] SQLite2 PDO Common: Bug #34630 (inserting streams as LOBs) [ext/sqlite/tests/pdo/bug_34630.phpt] (warn: XFAIL section but test passes) = You may have found a problem in PHP. We would like to send this report automatically to the PHP QA team, to give us a better understanding of how the test cases are doing. If you don't want to send it immediately, you can choose "s" to save the report to a file that you can send us later. Do you want to send this report now? [Yns]: s Please send /tmp/php-5.3.2/php_test_results_20100325_2040.txt to qa-repo...@lists.php.net manually, thank you. [2010-03-24 17:51:27] paul at boxuk dot com i can also reproduce this, i believe it's something to do with the fix for bug #50829 amended that bug with the details 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=51216 -- Edit this bug report at http://bugs.php.net/bug.php?id=51216&edit=1
Bug #45826 [Com]: serialize of ArrayObject causes segmentation fault
Edit report at http://bugs.php.net/bug.php?id=45826&edit=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=0
Bug #51518 [Com]: should add to zero, but gets 1.1102230246252E-16 instead
Edit report at http://bugs.php.net/bug.php?id=51518&edit=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 ---
Bug #51518 [Bgs]: should add to zero, but gets 1.1102230246252E-16 instead
Edit report at http://bugs.php.net/bug.php?id=51518&edit=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=51518&edit=1
Bug #51518 [Bgs]: should add to zero, but gets 1.1102230246252E-16 instead
Edit report at http://bugs.php.net/bug.php?id=51518&edit=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=51518&edit=1
Bug #51521 [Csd->Bgs]: XMLReader doesn't open files via stream_wrapper
Edit report at http://bugs.php.net/bug.php?id=51521&edit=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: Thank you root= #text=Thank you root= Actual result: -- PHP_VERSION: 5.3.0 XML: Thank you 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=51521&edit=1
Bug #51521 [Opn->Csd]: XMLReader doesn't open files via stream_wrapper
Edit report at http://bugs.php.net/bug.php?id=51521&edit=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: Thank you root= #text=Thank you root= Actual result: -- PHP_VERSION: 5.3.0 XML: Thank you 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=51521&edit=1
Bug #51521 [Opn]: XMLReader doesn't open files via stream_wrapper
Edit report at http://bugs.php.net/bug.php?id=51521&edit=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: Thank you root= #text=Thank you root= Actual result: -- PHP_VERSION: 5.3.0 XML: Thank you 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=51521&edit=1
Bug #51521 [Opn]: XMLReader doesn't open files via stream_wrapper
Edit report at http://bugs.php.net/bug.php?id=51521&edit=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: Thank you root= #text=Thank you root= Actual result: -- PHP_VERSION: 5.3.0 XML: Thank you 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=51521&edit=1
Doc #51502 [Com]: imagecreatefromjpeg no image
Edit report at http://bugs.php.net/bug.php?id=51502&edit=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=51502&edit=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=51436&edit=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=51436&edit=1
Bug #50918 [Com]: Access violation in php.exe (Bug #49626 redux)
Edit report at http://bugs.php.net/bug.php?id=50918&edit=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=50918&edit=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=51436&edit=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=51436&edit=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=51436&edit=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=51436&edit=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=51436&edit=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=revision&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=51436&edit=1
Bug #31326 [Com]: Object Destruction Order
Edit report at http://bugs.php.net/bug.php?id=31326&edit=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: 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: --- aVar = $pMe; echo str_repeat("",$ident)."[".$this->aVar."]"; $ident++; } function __destruct() { global $ident; $ident--; echo str_repeat("",$ident)."[/".$this->aVar."]"; } } $v1 = new Tag("tag1"); $v2 = new Tag("tag2"); $v3 = new Tag("tag3"); echo ''; ?> 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=31326&edit=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: Thank you root= #text=Thank you root= Actual result: -- PHP_VERSION: 5.3.0 XML: Thank you 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=51521&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=51521&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=51521&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=51521&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=51521&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=51521&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=51521&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=51521&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=51521&r=needscript Try newer version: http://bugs.php.net/fix.php?id=51521&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=51521&r=support Expected behavior: http://bugs.php.net/fix.php?id=51521&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=51521&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=51521&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=51521&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51521&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=51521&r=dst IIS Stability: http://bugs.php.net/fix.php?id=51521&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=51521&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=51521&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=51521&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=51521&r=mysqlcfg
Bug #36795 [Opn->Bgs]: Inappropriate "unterminated entity reference" in DOMElement->setAttribute
Edit report at http://bugs.php.net/bug.php?id=36795&edit=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. $safe_value = preg_replace('/&(?!\w+;)/', '&', $value); return $sxml->addChild($name, $safe_value); 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+;)/', '&', $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->b = "& < ' "; // doesn't work, requires encoding: $a = simplexml_load_string('test'); $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("&", "&", "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=36795&edit=1
Bug #50828 [Opn->Csd]: DOMNotation is not subclass of DOMNode
Edit report at http://bugs.php.net/bug.php?id=50828&edit=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=revision&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=50828&edit=1
Bug #50555 [Com]: Cannot retrieve output parameter from stored procedure
Edit report at http://bugs.php.net/bug.php?id=50555&edit=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=50555&edit=1
Bug #51506 [Fbk->Opn]: Realpath failed on linux Server for version 5.2.10 ?
Edit report at http://bugs.php.net/bug.php?id=51506&edit=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=51506&edit=1
Bug #51248 [Com]: Segmentation fault in mysql_fetch_array
Edit report at http://bugs.php.net/bug.php?id=51248&edit=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
Bug #51517 [Opn->Csd]: Node attributes lost when it has both attributes and value
Edit report at http://bugs.php.net/bug.php?id=51517&edit=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 = << test value 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=51517&edit=1