Bug #51594 [Fbk-Opn]: open_basedir reports fatal error within allowed path
Edit report at http://bugs.php.net/bug.php?id=51594edit=1 ID: 51594 User updated by: daniel at produktion203 dot se Reported by: daniel at produktion203 dot se Summary: open_basedir reports fatal error within allowed path -Status: Feedback +Status: Open Type: Bug Package: Safe Mode/open_basedir Operating System: FreeBSD 8.0-RELEASE-p2 PHP Version: 5.3.2 New Comment: Sorry but i only have live servers to work with so im not able to test this out anywhere :\ So my bugtracking help kind of ends when coming to installing new versions. But im guessing if it works for you it probably will for me too when the new version is released. Previous Comments: [2010-04-22 02:15:07] fel...@php.net Please try using this snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ [2010-04-19 00:01:37] daniel at produktion203 dot se Description: There seems to be some problem with open_basedir in php 5.3.2 for freebsd, i used the 5.2 branch before and the exact same config worked fine then. open_basedir reports failure eventhough im within the allowed paths Include paths in php.ini: include_path = .:/usr/local/share/pear:/usr/local/lib/php/include Testhost in apache: VirtualHost *:80 DocumentRoot /home/customers/produktion203/testin.se ServerName testin.se php_admin_value open_basedir /home/customers/produktion203/testin.se:/usr/local/share/pear:/usr/local/lib/php/include:/var/tmp /VirtualHost Test script: --- ?php phpinfo(); Expected result: Show the phpinfo(); Actual result: -- Warning: Unknown: open_basedir restriction in effect. File() is not within the allowed path(s): (/home/customers/produktion203/testin.se:/usr/local/share/pear:/usr/local/lib/php/include:/var/tmp) in Unknown on line 0 Fatal error: Can't load /home/customers/produktion203/testin.se/nfo.php, open_basedir restriction. in Unknown on line 0 -- Edit this bug report at http://bugs.php.net/bug.php?id=51594edit=1
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: ywliu at hotmail 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 can confirm this one: 1. On CentOS 5.4 2. Apache Worker MPM. 3. With mysqlnd, it wouldn't trigger segfault. But with external mysql library (my own build of 5.0.81) , it segfaults. So looks like maybe it's the combination of worker MPM with the external mysql library. ywliu Previous Comments: [2010-04-19 18:54:48] remco at maxserv dot nl I can confirm that this problem exists. Compiled with apache MPM-prefork, everything went fine. Switched to MPM-worker, breaks at the same point as mentioned in this report. (Debian, Linux KPI 2.6.26-2-686 #1 SMP Tue Mar 9 17:35:51 UTC 2010 i686 GNU/Linux) Configure used for apache: ./configure --prefix=/usr/local/apache2 --enable-so --enable-auth-digest --enable-cache --enable-deflate --enable-expires --enable-headers --enable-info --enable-logio --enable-mime-magic --enable-proxy --enable-rewrite --enable-speling --enable-ssl --enable-unique-id --with-mpm=worker Configure used for PHP: './configure' '--prefix=/usr/lib/php5' '--host=x86-pc-linux-gnu' '--mandir=/usr/lib/php5/man' '--infodir=/usr/lib/php5/info' '--sysconfdir=/etc' '--cache-file=./config.cache' '--with-libdir=lib' '--with-pcre-regex=/usr' '--enable-cli' '--with-apxs2=/usr/bin/apxs2' '--with-config-file-path=/etc/php/apache2-php5' '--with-config-file-scan-dir=/etc/php/apache2-php5/ext-active' '--with-pear' '--enable-bcmath' '--with-bz2' '--enable-calendar' '--with-curl' '--with-curlwrappers' '--enable-exif' '--enable-ftp' '--with-gettext' '--without-gmp' '--with-kerberos' '--enable-mbstring' '--with-mcrypt' '--with-mhash' '--with-mssql' '--with-openssl' '--with-openssl-dir=/usr' '--disable-pcntl' '--without-pgsql' '--without-pspell' '--without-recode' '--disable-shmop' '--with-snmp' '--enable-soap' '--enable-sockets' '--without-sybase-ct' '--disable-sysvmsg' '--disable-sysvsem' '--disable-sysvshm' '--without-tidy' '--disable-wddx' '--with-xmlrpc' '--with-xsl' '--enable-zip' '--with-zlib' '--disable-debug' '--without-enchant' '--disable-intl' '--enable-phar' '--enable-dba' '--without-cdb' '--without-db4' '--disable-flatfile' '--with-gdbm' '--disable-inifile' '--without-qdbm' '--with-freetype-dir=/usr' '--with-t1lib=/usr' '--disable-gd-jis-conv' '--with-jpeg-dir=/usr' '--with-png-dir=/usr' '--with-xpm-dir=/usr' '--with-gd' '--with-imap' '--with-imap-ssl' '--with-ldap' '--without-ldap-sasl' '--with-mysql=/usr/local/mysql' '--with-mysql-sock=/var/run/mysqld/mysqld.sock' '--with-mysqli=/usr/bin/mysql_config' '--with-unixODBC=/usr' '--without-adabas' '--without-birdstep' '--without-dbmaker' '--without-empress' '--without-esoob' '--without-ibm-db2' '--without-iodbc' '--without-sapdb' '--without-solid' '--with-pdo-dblib' '--with-pdo-mysql=/usr' '--with-pdo-odbc=unixODBC,/usr' '--without-pdo-pgsql' '--with-readline' '--without-libedit' '--without-mm' '--without-sqlite' Building without phar works, but then 'make install' fails with a segmentation fault as well. [2010-04-09 23:18:38] holderm at lycos dot com 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 [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 // ):
[PHP-BUG] Bug #51630 [NEW]: Can't call userland functions from __sleep()
From:
Operating system: Windows XP SP2
PHP version: 5.2.13
Package: Session related
Bug Type: Bug
Bug description:Can't call userland functions from __sleep()
Description:
Prior to v5.2.10 you could call userland functions in the magic method
__sleep(). Now in 5.2.10, .11, .12 and .13 I just get a fatal error
undefined
function when I try to do so.
I've tested this in 5.3.2 and it works correctly as it does in 5.2.9 and
before.
This is running on the standard 5.2.13 TS VS6 build and my session
configuration
is:
[Session]
session.save_handler = files
session.save_path = c:/php/tmp
session.use_cookies = 1
session.use_only_cookies = 1
session.name = sID
session.auto_start = 0
session.cookie_lifetime = 0
session.cookie_path = /
session.cookie_domain =
session.cookie_httponly =
session.serialize_handler = php
session.gc_probability = 1
session.gc_divisor = 1000
session.gc_maxlifetime = 9000
session.bug_compat_42 = 0
session.bug_compat_warn = 1
session.referer_check =
session.entropy_length = 0
session.entropy_file =
session.cache_limiter = nocache
session.cache_expire = 180
session.use_trans_sid = 0
session.hash_function = 0
session.hash_bits_per_character = 5
url_rewriter.tags =
a=href,area=href,frame=src,input=src,form=,fieldset=,iframe=src
Test script:
---
?php
function inc ($foo) {
return ($foo + 1);
}
class foo {
function __construct() {
$this-bar = 0;
}
function __sleep() {
$this-bar = inc($this-bar);
return array('bar');
}
public $bar;
}
session_start();
if (!isset($_SESSION['foo'])) {
$_SESSION['foo'] = new foo();
}
$foo = $_SESSION['foo'];
echo foo-bar = .$foo-bar.br;
?
Expected result:
As you refresh the page given by the script, you should just see the number
increment each time with no errors generated.
Actual result:
--
In 5.2.13, after refreshing the page you get:
Fatal error: Call to undefined function inc() in C:\test\sleeptest.php on
line 12
This worked correctly in 5.2.9 and before, and also works in 5.3.2
--
Edit bug report at http://bugs.php.net/bug.php?id=51630edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=51630r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=51630r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=51630r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=51630r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=51630r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=51630r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=51630r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=51630r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=51630r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=51630r=support
Expected behavior:
http://bugs.php.net/fix.php?id=51630r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=51630r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=51630r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=51630r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51630r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=51630r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=51630r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=51630r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=51630r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=51630r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=51630r=mysqlcfg
Req #51629 [Opn-Csd]: CURLOPT_FOLLOWLOCATION error message is misleading
Edit report at http://bugs.php.net/bug.php?id=51629edit=1
ID: 51629
Updated by: paj...@php.net
Reported by: brad at njoe dot com
Summary: CURLOPT_FOLLOWLOCATION error message is misleading
-Status: Open
+Status: Closed
Type: Feature/Change Request
Package: Safe Mode/open_basedir
Operating System: N/A
PHP Version: 5.3.2
-Assigned To:
+Assigned To: pajoye
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-22 10:58:09] paj...@php.net
Automatic comment from SVN on behalf of pajoye
Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=298299
Log: - Bug #51629, CURLOPT_FOLLOWLOCATION error message is misleading
[2010-04-22 07:08:07] brad at njoe dot com
Description:
The following error message is semantically wrong (and for the newbies
that
aren't familiar with PHP, very misleading/confusing):
Warning: curl_setopt() [function.curl-setopt]: CURLOPT_FOLLOWLOCATION
can not be
activated when in safe_mode or an open_basedir is set in file on line
line
From a purely grammatical standpoint, that error message is saying that
one of
the following conditions caused the error: either you're in safe_mode,
or an
open_basedir option was set in file. The in file on line line
that
directly follows the open_basedir bit makes it sound like one should
look for
something dealing with open_basedir in file in order to resolve the
error
(assuming they aren't in safe mode).
This situation actually happened on a PHP support community I'm a member
of. I
only mention this to show that I'm not simply quibbling over
semantics/grammar
but rather trying to clarify a misleading error message.
Test script:
---
?php
ini_set('open_basedir', '/'); // for testing purposes
$ch = curl_init();
curl_setopt($ch, CURLOPT_FOLLOWLOCATION, 1);
Expected result:
No output.
Actual result:
--
PHP Warning: curl_setopt(): CURLOPT_FOLLOWLOCATION cannot be activated
when in
safe_mode or an open_basedir is set in G:\php\test.php on line 6
--
Edit this bug report at http://bugs.php.net/bug.php?id=51629edit=1
[PHP-BUG] Bug #51631 [NEW]: MySQLi query result depend on browser
From: Operating system: Windows/Linux PHP version: 5.3.2 Package: MySQLi related Bug Type: Bug Bug description:MySQLi query result depend on browser Description: I have in MySQL Table with columns price DECIMAL(6,2), issm tinyint, cnt int When I run request SELECT IF(issm=1, ROUND(price/cnt, 6), price) AS price, issm with mysqli i get 12,00 1 12,00 0 in Opera and Chrome but i get 12,00 1 12,00 0 in mozilla and IE -- Edit bug report at http://bugs.php.net/bug.php?id=51631edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=51631r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=51631r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=51631r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=51631r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=51631r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=51631r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=51631r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=51631r=needscript Try newer version: http://bugs.php.net/fix.php?id=51631r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=51631r=support Expected behavior: http://bugs.php.net/fix.php?id=51631r=notwrong Not enough info: http://bugs.php.net/fix.php?id=51631r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=51631r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=51631r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51631r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=51631r=dst IIS Stability: http://bugs.php.net/fix.php?id=51631r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=51631r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=51631r=float No Zend Extensions: http://bugs.php.net/fix.php?id=51631r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=51631r=mysqlcfg
[PHP-BUG] Bug #51632 [NEW]: filter_var fails to validate correct URL
From: Operating system: FreeBSD PHP version: 5.3.2 Package: Unknown/Other Function Bug Type: Bug Bug description:filter_var fails to validate correct URL Description: Function filter_var seems to change it behavior when PHP upgraded from 5.2.4 to 5.3.2. The next example work fine in 5.24 but fail in 5.3.2. This problem was described in Bug #51305 (filter_var fails if domain name contain -) and reported to be fixed in 5.2.13, but it is bubble again in 5.3.2 : Test script: --- ?php $P = 'http://m-zharkikh.livejournal.com/26556.html'; echo filter_var($P, FILTER_VALIDATE_URL, FILTER_FLAG_SCHEME_REQUIRED); Expected result: http://m-zharkikh.livejournal.com/26556.html, so URL is valid Actual result: -- false, so URL provided evaluated as invalid -- Edit bug report at http://bugs.php.net/bug.php?id=51632edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=51632r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=51632r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=51632r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=51632r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=51632r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=51632r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=51632r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=51632r=needscript Try newer version: http://bugs.php.net/fix.php?id=51632r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=51632r=support Expected behavior: http://bugs.php.net/fix.php?id=51632r=notwrong Not enough info: http://bugs.php.net/fix.php?id=51632r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=51632r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=51632r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51632r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=51632r=dst IIS Stability: http://bugs.php.net/fix.php?id=51632r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=51632r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=51632r=float No Zend Extensions: http://bugs.php.net/fix.php?id=51632r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=51632r=mysqlcfg
Bug #51632 [Opn-Fbk]: filter_var fails to validate correct URL
Edit report at http://bugs.php.net/bug.php?id=51632edit=1 ID: 51632 Updated by: degeb...@php.net Reported by: zharkikh at i dot com dot ua Summary: filter_var fails to validate correct URL -Status: Open +Status: Feedback Type: Bug Package: Unknown/Other Function Operating System: FreeBSD PHP Version: 5.3.2 New Comment: Please try using this snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ PHP 5.3.2 was released on March 4, and the #51305 was fixed on March 3. It probably didn't make it into the release. It works for me on 5.3.3-dev built a few days ago. Previous Comments: [2010-04-22 11:52:00] zharkikh at i dot com dot ua Description: Function filter_var seems to change it behavior when PHP upgraded from 5.2.4 to 5.3.2. The next example work fine in 5.24 but fail in 5.3.2. This problem was described in Bug #51305 (filter_var fails if domain name contain -) and reported to be fixed in 5.2.13, but it is bubble again in 5.3.2 : Test script: --- ?php $P = 'http://m-zharkikh.livejournal.com/26556.html'; echo filter_var($P, FILTER_VALIDATE_URL, FILTER_FLAG_SCHEME_REQUIRED); Expected result: http://m-zharkikh.livejournal.com/26556.html, so URL is valid Actual result: -- false, so URL provided evaluated as invalid -- Edit this bug report at http://bugs.php.net/bug.php?id=51632edit=1
[PHP-BUG] Req #51633 [NEW]: Accept post input of multiple fields with the same name
From: Operating system: Ubuntu PHP version: 5.2.13 Package: HTTP related Bug Type: Feature/Change Request Bug description:Accept post input of multiple fields with the same name Description: I currently have to handle post data which is submitted as multipart/form-data and has multiple fields with the same name. The latter means I can't use $_POST (I only get the last of the fields with the same name) and the former means I can't use php://input or $HTTP_RAW_POST_DATA. According to http://www.w3.org/MarkUp/html-spec/html-spec_8.html#SEC8.1.2.3 it's fine to have multiple fields with the same name. The obvious answer to my problem would be to append [] to the end of the field names so that PHP parses them into an array. But in this case I don't have control over the data source. And in fact the HTML4.01 specification says at http://www.w3.org/TR/html4/types.html#h-6.2 'ID and NAME tokens must begin with a letter ([A-Za-z]) and may be followed by any number of letters, digits ([0-9]), hyphens (-), underscores (_), colons (:), and periods (.)' So putting [] at the end of field names is actually against the HTML specification so it seems bad to require them. So I have two suggestions here (let me know if I should file a separate request for the latter): 1. Whenever there is more than one field with the same name make an array, rather than only when the field name ends in []. This could of course cause issues with existing scripts which are being passed multiple values when they don't expect it or which are relying on a later field with the same name overwriting an earlier one, but I would wager that this is rare. 2. I could work around this right now if I could get php://input or $HTTP_RAW_POST_DATA, only they're not available since it's multipart/form-data. Why shouldn't the raw post data be available when it's encoded this way? It'd make it possible to work around broken post data (in this case as far as I can see the post data is fine according to the spec but I can imagine having to deal with actual broken data). -- Edit bug report at http://bugs.php.net/bug.php?id=51633edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=51633r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=51633r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=51633r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=51633r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=51633r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=51633r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=51633r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=51633r=needscript Try newer version: http://bugs.php.net/fix.php?id=51633r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=51633r=support Expected behavior: http://bugs.php.net/fix.php?id=51633r=notwrong Not enough info: http://bugs.php.net/fix.php?id=51633r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=51633r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=51633r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51633r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=51633r=dst IIS Stability: http://bugs.php.net/fix.php?id=51633r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=51633r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=51633r=float No Zend Extensions: http://bugs.php.net/fix.php?id=51633r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=51633r=mysqlcfg
[PHP-BUG] Bug #51634 [NEW]: Can't post multiple fields with the same name
From: Operating system: Ubuntu PHP version: 5.2.13 Package: cURL related Bug Type: Bug Bug description:Can't post multiple fields with the same name Description: With CLI curl I can run curl -F test=value -F test=value --trace-ascii trace http://localhost/test.php and in the file trace I see that it posted multipart/form-data with two fields called test with content value. I need this same behaviour from PHP. But the only way at present, it seems, to add form fields to the curl handle (and have them transmit as multipart/form-data) is to use curl_setopt($ch, CURLOPT_POSTFIELDS, $data) where $data is an array of name-value pairs. Obviously I can't have two pairs in this array with the same name. I've tried array(name = array(val1, val2)) but that posts the string Array as the value for field name. I've tried array(name[] = array(val1, val2)) but that posts the string Array as the value for field name[] (PHP then parses this into an array but only val2 is in it.) I've tried array(name[] = val1, name[] = val2) but of course that doesn't work since as soon as that array is initialized it's only got one element -- the second overwrote the first. I think allowing array(name = array(val1, val2)) would be the best solution. (And brackets should not be added to the end of name unless specified.) -- Edit bug report at http://bugs.php.net/bug.php?id=51634edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=51634r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=51634r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=51634r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=51634r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=51634r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=51634r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=51634r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=51634r=needscript Try newer version: http://bugs.php.net/fix.php?id=51634r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=51634r=support Expected behavior: http://bugs.php.net/fix.php?id=51634r=notwrong Not enough info: http://bugs.php.net/fix.php?id=51634r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=51634r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=51634r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51634r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=51634r=dst IIS Stability: http://bugs.php.net/fix.php?id=51634r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=51634r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=51634r=float No Zend Extensions: http://bugs.php.net/fix.php?id=51634r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=51634r=mysqlcfg
Bug #51634 [Opn]: Can't post multiple fields with the same name
Edit report at http://bugs.php.net/bug.php?id=51634edit=1 ID: 51634 User updated by: bart at tremby dot net Reported by: bart at tremby dot net Summary: Can't post multiple fields with the same name Status: Open Type: Bug Package: cURL related Operating System: Ubuntu PHP Version: 5.2.13 New Comment: Where I said 'PHP then parses this into an array but only val2 is in it.' I meant Array, not val2. Previous Comments: [2010-04-22 15:06:01] bart at tremby dot net Description: With CLI curl I can run curl -F test=value -F test=value --trace-ascii trace http://localhost/test.php and in the file trace I see that it posted multipart/form-data with two fields called test with content value. I need this same behaviour from PHP. But the only way at present, it seems, to add form fields to the curl handle (and have them transmit as multipart/form-data) is to use curl_setopt($ch, CURLOPT_POSTFIELDS, $data) where $data is an array of name-value pairs. Obviously I can't have two pairs in this array with the same name. I've tried array(name = array(val1, val2)) but that posts the string Array as the value for field name. I've tried array(name[] = array(val1, val2)) but that posts the string Array as the value for field name[] (PHP then parses this into an array but only val2 is in it.) I've tried array(name[] = val1, name[] = val2) but of course that doesn't work since as soon as that array is initialized it's only got one element -- the second overwrote the first. I think allowing array(name = array(val1, val2)) would be the best solution. (And brackets should not be added to the end of name unless specified.) -- Edit this bug report at http://bugs.php.net/bug.php?id=51634edit=1
[PHP-BUG] Bug #51635 [NEW]: casting json objects to array
From:
Operating system: Windows
PHP version: 5.2.13
Package: JSON related
Bug Type: Bug
Bug description:casting json objects to array
Description:
We use this array:
array(2) { [1]= int(100) [2]= int(200) }
When a array will be encoded into a json string, php converts integer
indexes t o strings:
string(17) {1:100,2:200}
When php decodes the json string back, it will be an object:
object(stdClass)#1 (2) { [1]= int(100) [2]= int(200) }
To avoid the problem that you not can acces integer indexes of a object you
must cast the object to an array:
array(2) { [1]= int(100) [2]= int(200) }
Now the indexes become strings instead of integers, which you cannot
access:
$arr2[1] = NULL
The json_decode function should convert indexes back to integer, if they
are a string number, like php always does when you create an array.
Test script:
---
$arr = array(1=100,2=200,1=100,2=200);
$json = json_encode($arr);
$arr2 = (array)json_decode($json);
var_dump($arr2);
var_dump($arr2[1]);
var_dump($arr2[1]);
Expected result:
array(4) {
[1]=
int(100)
[2]=
int(200)
}
int(100)
int(100)
Actual result:
--
array(4) {
[1]=
int(100)
[2]=
int(200)
}
NULL
NULL
--
Edit bug report at http://bugs.php.net/bug.php?id=51635edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=51635r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=51635r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=51635r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=51635r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=51635r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=51635r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=51635r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=51635r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=51635r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=51635r=support
Expected behavior:
http://bugs.php.net/fix.php?id=51635r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=51635r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=51635r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=51635r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51635r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=51635r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=51635r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=51635r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=51635r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=51635r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=51635r=mysqlcfg
Bug #51634 [Opn]: Can't post multiple fields with the same name
Edit report at http://bugs.php.net/bug.php?id=51634edit=1 ID: 51634 Updated by: fel...@php.net Reported by: bart at tremby dot net Summary: Can't post multiple fields with the same name Status: Open Type: Bug Package: cURL related Operating System: Ubuntu PHP Version: 5.2.13 New Comment: You can use: array(name[0] = val1, name[1] = val2) Previous Comments: [2010-04-22 15:07:56] bart at tremby dot net Where I said 'PHP then parses this into an array but only val2 is in it.' I meant Array, not val2. [2010-04-22 15:06:01] bart at tremby dot net Description: With CLI curl I can run curl -F test=value -F test=value --trace-ascii trace http://localhost/test.php and in the file trace I see that it posted multipart/form-data with two fields called test with content value. I need this same behaviour from PHP. But the only way at present, it seems, to add form fields to the curl handle (and have them transmit as multipart/form-data) is to use curl_setopt($ch, CURLOPT_POSTFIELDS, $data) where $data is an array of name-value pairs. Obviously I can't have two pairs in this array with the same name. I've tried array(name = array(val1, val2)) but that posts the string Array as the value for field name. I've tried array(name[] = array(val1, val2)) but that posts the string Array as the value for field name[] (PHP then parses this into an array but only val2 is in it.) I've tried array(name[] = val1, name[] = val2) but of course that doesn't work since as soon as that array is initialized it's only got one element -- the second overwrote the first. I think allowing array(name = array(val1, val2)) would be the best solution. (And brackets should not be added to the end of name unless specified.) -- Edit this bug report at http://bugs.php.net/bug.php?id=51634edit=1
Bug #51634 [Opn]: Can't post multiple fields with the same name
Edit report at http://bugs.php.net/bug.php?id=51634edit=1 ID: 51634 User updated by: bart at tremby dot net Reported by: bart at tremby dot net Summary: Can't post multiple fields with the same name Status: Open Type: Bug Package: cURL related Operating System: Ubuntu PHP Version: 5.2.13 New Comment: That works when posting to PHP because of the way PHP handles the names but what it's actually posting is name name[0], value val1 name name[1], value val2 Any system but PHP as far as I know (I'm posting to a Java-based system and I don't have control over it) keeps them as they are -- two separate entities called name[0] and name[1]. There's nothing in the HTTP specification which says anything about array indices -- as far as I can tell that's purely PHP's invention. PHP which decides they're the same thing and knocks off the brackets. The system I'm posting to expects them to be posted with the same name. (The spec says this is fine -- see http://www.w3.org/MarkUp/html-spec/html-spec_8.html#SEC8.1.2.3). The CLI example I gave in the OP does this; the PHP example you just gave does not. Previous Comments: [2010-04-22 15:53:32] fel...@php.net You can use: array(name[0] = val1, name[1] = val2) [2010-04-22 15:07:56] bart at tremby dot net Where I said 'PHP then parses this into an array but only val2 is in it.' I meant Array, not val2. [2010-04-22 15:06:01] bart at tremby dot net Description: With CLI curl I can run curl -F test=value -F test=value --trace-ascii trace http://localhost/test.php and in the file trace I see that it posted multipart/form-data with two fields called test with content value. I need this same behaviour from PHP. But the only way at present, it seems, to add form fields to the curl handle (and have them transmit as multipart/form-data) is to use curl_setopt($ch, CURLOPT_POSTFIELDS, $data) where $data is an array of name-value pairs. Obviously I can't have two pairs in this array with the same name. I've tried array(name = array(val1, val2)) but that posts the string Array as the value for field name. I've tried array(name[] = array(val1, val2)) but that posts the string Array as the value for field name[] (PHP then parses this into an array but only val2 is in it.) I've tried array(name[] = val1, name[] = val2) but of course that doesn't work since as soon as that array is initialized it's only got one element -- the second overwrote the first. I think allowing array(name = array(val1, val2)) would be the best solution. (And brackets should not be added to the end of name unless specified.) -- Edit this bug report at http://bugs.php.net/bug.php?id=51634edit=1
Bug #51635 [Opn-Bgs]: casting json objects to array
Edit report at http://bugs.php.net/bug.php?id=51635edit=1
ID: 51635
Updated by: johan...@php.net
Reported by: joel dot gaehwiler at bluewin dot ch
Summary: casting json objects to array
-Status: Open
+Status: Bogus
Type: Bug
Package: JSON related
Operating System: Windows
PHP Version: 5.2.13
New Comment:
This is expected, javaScript arrays are zero-indexed so your PHP array
can't be represented as a javaScript array and has to be converted to an
object. When converting an object back PHP defaults to objects. But you
can use the second param for json_decode().
For the inaccessible keys which are the result then there's another
report already. So that part is duplicate.
Previous Comments:
[2010-04-22 15:49:33] joel dot gaehwiler at bluewin dot ch
Description:
We use this array:
array(2) { [1]= int(100) [2]= int(200) }
When a array will be encoded into a json string, php converts integer
indexes t o strings:
string(17) {1:100,2:200}
When php decodes the json string back, it will be an object:
object(stdClass)#1 (2) { [1]= int(100) [2]= int(200) }
To avoid the problem that you not can acces integer indexes of a object
you must cast the object to an array:
array(2) { [1]= int(100) [2]= int(200) }
Now the indexes become strings instead of integers, which you cannot
access:
$arr2[1] = NULL
The json_decode function should convert indexes back to integer, if they
are a string number, like php always does when you create an array.
Test script:
---
$arr = array(1=100,2=200,1=100,2=200);
$json = json_encode($arr);
$arr2 = (array)json_decode($json);
var_dump($arr2);
var_dump($arr2[1]);
var_dump($arr2[1]);
Expected result:
array(4) {
[1]=
int(100)
[2]=
int(200)
}
int(100)
int(100)
Actual result:
--
array(4) {
[1]=
int(100)
[2]=
int(200)
}
NULL
NULL
--
Edit this bug report at http://bugs.php.net/bug.php?id=51635edit=1
[PHP-BUG] Bug #51636 [NEW]: openssl_random_pseudo_bytes() painfully slow
From: Operating system: Windows PHP version: 5.3.2 Package: OpenSSL related Bug Type: Bug Bug description:openssl_random_pseudo_bytes() painfully slow Description: Whenever I execute the following command: openssl_random_pseudo_bytes(1); // or any other number PHP will process the function call for like a minute. I am using Windows 7, and it is affected by both x86 and x64 systems. I do not see a problem on Linux, though. Test script: --- $random = openssl_random_pseudo_bytes(1, $strong); Expected result: The random generation should happen within a blink of an eye. -- Edit bug report at http://bugs.php.net/bug.php?id=51636edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=51636r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=51636r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=51636r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=51636r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=51636r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=51636r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=51636r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=51636r=needscript Try newer version: http://bugs.php.net/fix.php?id=51636r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=51636r=support Expected behavior: http://bugs.php.net/fix.php?id=51636r=notwrong Not enough info: http://bugs.php.net/fix.php?id=51636r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=51636r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=51636r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51636r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=51636r=dst IIS Stability: http://bugs.php.net/fix.php?id=51636r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=51636r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=51636r=float No Zend Extensions: http://bugs.php.net/fix.php?id=51636r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=51636r=mysqlcfg
Bug #51576 [Asn-Fbk]: compile failure on zend_float.c
Edit report at http://bugs.php.net/bug.php?id=51576edit=1 ID: 51576 Updated by: csei...@php.net Reported by: i2r at pacbell dot net Summary: compile failure on zend_float.c -Status: Assigned +Status: Feedback Type: Bug Package: Compile Failure Operating System: AIX 5.3 PHP Version: 5.3.2 Assigned To: cseiler New Comment: Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to Open. Thank you for your interest in PHP. Since I don't have Visual Age myself, I'd appreciate it if you could provide the following pieces of information: * On which operating system are you using Visual Age? * Which steps did you take to compile PHP? configure make? If so, with which configure options? Previous Comments: [2010-04-22 02:14:42] ka...@php.net Christian, here is some feedback for the rounding patch ;-) [2010-04-16 23:02:21] i2r at pacbell dot net version of zend_float.c /* $Id: zend_float.c 293155 2010-01-05 20:46:53Z sebastian $ */ [2010-04-16 21:39:59] i2r at pacbell dot net Description: Compiler IBM visual age ver 6 .../php-5.3.2/Zend/zend_float.c, line 33.9: 1506-579 (W) The __asm directive is ignored. .../php-5.3.2/Zend/zend_float.c, line 34.9: 1506-579 (W) The __asm directive is ignored. .../php-5.3.2/Zend/zend_float.c, line 44.10: 1506-276 (S) Syntax error: possible missing 'while'? .../php-5.3.2/Zend/zend_float.c, line 48.17: 1506-579 (W) The __asm directive is ignored. .../php-5.3.2/Zend/zend_float.c, line 51.9: 1506-276 (S) Syntax error: possible missing 'while'? .../php-5.3.2/Zend/zend_float.c, line 55.1: 1506-276 (S) Syntax error: possible missing 'while'? .../php-5.3.2/Zend/zend_float.c, line 62.9: 1506-579 (W) The __asm directive is ignored. .../php-5.3.2/Zend/zend_float.c, line 64.10: 1506-204 (S) Unexpected end of file. make: *** [Zend/zend_float.lo] Error 1 -- Edit this bug report at http://bugs.php.net/bug.php?id=51576edit=1
Bug #51624 [Com]: Gallery2 causing segfault when trying to update.
Edit report at http://bugs.php.net/bug.php?id=51624edit=1
ID: 51624
Comment by: Fedora at famillecollet dot com
Reported by: zulcss at ubuntu dot com
Summary: Gallery2 causing segfault when trying to update.
Status: Feedback
Type: Bug
Package: Reproducible crash
Operating System: Ubuntu/Linux
PHP Version: 5.3.2
New Comment:
I just try gallery2 with 201004221630 snapshot (5.3.3-dev).
No crash encountered.
Just need to found the fix in subversion.
Previous Comments:
[2010-04-21 16:52:58] fel...@php.net
Please try using this snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
[2010-04-21 14:10:18] zulcss at ubuntu dot com
Description:
Hi,
This bug was recently reported on launchpad at
http://bugs.launchpad.net/bugs/567043. I have included the gdb backtrace
with this bug report.
Regards
chuck
Expected result:
Not to crash.
Actual result:
--
#0 0x7fe478493d02 in memcpy () from /lib/libc.so.6
No symbol table info available.
#1 0x00677ff8 in _estrndup (s=0x4d0050 Address
0x4d0050 out of bounds, length=90) at
/usr/include/bits/string3.h:52
No locals.
#2 0x0069459b in _zval_copy_ctor_func (zvalue=0x1f84ca8) at
/build/buildd/php5-5.3.2/Zend/zend_variables.c:126
tmp = 0x1ecb470
original_ht = 0x1ecb470
#3 0x7fe4752b0f68 in zif_mysqli_options (ht=33049848,
return_value=0x1f84c58, return_value_ptr=0x5a, this_ptr=0x4d0050,
return_value_used=17) at
/build/buildd/php5-5.3.2/Zend/zend_variables.h:45
mysql_link = 0x1f84ca8
mysql_value = 0x5
mysql_option = 33049648
l_value = 0
expected_type = 33049848
#4 0x006e598a in zend_do_fcall_common_helper_SPEC
(execute_data=0x142a390) at
/build/buildd/php5-5.3.2/Zend/zend_vm_execute.h:313
opline = 0x15c7698
should_change_scope = 0 '\000'
#5 0x006bcc70 in execute (op_array=0x11d7080) at
/build/buildd/php5-5.3.2/Zend/zend_vm_execute.h:104
ret = 33049848
execute_data = 0x142a390
nested = 0 '\000'
original_in_execution = 1 '\001'
#6 0x0068ab94 in zend_call_function (fci=0x7fff6ab02fd0,
fci_cache=0x141f840) at
/build/buildd/php5-5.3.2/Zend/zend_execute_API.c:947
i = 17
original_return_value = 0x141f6f0
calling_symbol_table = 0x1938398
original_op_array = 0x19cf630
original_opline_ptr = incomplete type
current_scope = 0x1db96c0
current_called_scope = 0x1938398
calling_scope = 0x0
called_scope = 0x141f6f0
current_this = 0x0
execute_data = {opline = 0x0, function_state = {function = 0x0,
arguments = 0x1949408}, fbc = 0x141fe68, called_scope = 0x0, op_array =
0x0, object = 0x0, Ts = 0x1956490, CVs = 0x141f938, symbol_table =
0x141f8d8,
prev_execute_data = 0x0, old_error_reporting = 0x141f840,
nested = 0 '\000', original_return_value = 0x1, current_scope =
0x141e228, current_called_scope = 0x1938398, current_this = 0x1938398,
current_object = 0x1db92d0,
call_opline = 0x0}
#7 0x005cd107 in zif_call_user_func_array (ht=33049848,
return_value=0x1db8eb8, return_value_ptr=0x5a, this_ptr=0x1,
return_value_used=17) at
/build/buildd/php5-5.3.2/ext/standard/basic_functions.c:4782
params = 0x0
retval_ptr = 0x141f840
fci = {size = 6082823, function_table = 0x48, function_name =
0x1927c28, symbol_table = 0x1a58120, retval_ptr_ptr = 0x0, param_count =
1789931600, params = 0x3, object_ptr = 0x1da2868, no_separation = 144
'\220'}
fci_cache = {initialized = 176 '\260', function_handler = 0x1,
calling_scope = 0x1949408, called_scope = 0x1927bf8, object_ptr =
0x1927bf8}
#8 0x006e598a in zend_do_fcall_common_helper_SPEC
(execute_data=0x141f840) at
/build/buildd/php5-5.3.2/Zend/zend_vm_execute.h:313
opline = 0x19d4418
should_change_scope = 0 '\000'
#9 0x006bcc70 in execute (op_array=0x19cf630) at
/build/buildd/php5-5.3.2/Zend/zend_vm_execute.h:104
ret = 33049848
execute_data = 0x141f840
nested = 0 '\000'
original_in_execution = 0 '\000'
#10 0x0069499d in zend_execute_scripts (type=0,
retval=0x7fff6ab03210, file_count=3) at
/build/buildd/php5-5.3.2/Zend/zend.c:1266
files = 0x7fff6ab031e8
i = 1
file_handle = 0x7fff6ab05810
orig_op_array = 0x0
orig_retval_ptr_ptr = 0xd8fd30
#11 0x00640608 in php_execute_script (primary_file=0x1888) at
/build/buildd/php5-5.3.2/main/main.c:2288
__orig_bailout = 0x0
__bailout = {{__jmpbuf = {0, 0, 0, 0, 2, 0, 6040, 0},
__mask_was_saved =
Bug #51632 [Fbk]: filter_var fails to validate correct URL
Edit report at http://bugs.php.net/bug.php?id=51632edit=1 ID: 51632 Updated by: ras...@php.net Reported by: zharkikh at i dot com dot ua Summary: filter_var fails to validate correct URL Status: Feedback Type: Bug Package: Unknown/Other Function Operating System: FreeBSD PHP Version: 5.3.2 New Comment: This was fixed in svn a while ago. Previous Comments: [2010-04-22 12:45:00] degeb...@php.net Please try using this snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ PHP 5.3.2 was released on March 4, and the #51305 was fixed on March 3. It probably didn't make it into the release. It works for me on 5.3.3-dev built a few days ago. [2010-04-22 11:52:00] zharkikh at i dot com dot ua Description: Function filter_var seems to change it behavior when PHP upgraded from 5.2.4 to 5.3.2. The next example work fine in 5.24 but fail in 5.3.2. This problem was described in Bug #51305 (filter_var fails if domain name contain -) and reported to be fixed in 5.2.13, but it is bubble again in 5.3.2 : Test script: --- ?php $P = 'http://m-zharkikh.livejournal.com/26556.html'; echo filter_var($P, FILTER_VALIDATE_URL, FILTER_FLAG_SCHEME_REQUIRED); Expected result: http://m-zharkikh.livejournal.com/26556.html, so URL is valid Actual result: -- false, so URL provided evaluated as invalid -- Edit this bug report at http://bugs.php.net/bug.php?id=51632edit=1
Bug #51397 [Com]: Math calculation bug
Edit report at http://bugs.php.net/bug.php?id=51397edit=1
ID: 51397
Comment by: whatrevolution at yahoo dot com
Reported by: emanuel dot dejanu at humaninfo dot ro
Summary: Math calculation bug
Status: Verified
Type: Bug
Package: Scripting Engine problem
Operating System: FREEBSD LINUX
PHP Version: 5.2.13
New Comment:
My answer to myhash('CL6.1.7'): 229416432419738
PHP Version 5.2.10-2ubuntu6.4
System Linux 2.6.31-20-generic x86_64
Build Date Jan 6 2010 22:36:47
Server API Apache 2.0 Handler
PHP API 20041225
PHP Extension 20060613
Zend Extension 220060519
Debug Build no
Thread Safety disabled
Zend Memory Manager enabled
Apache/2.2.12 (Ubuntu)
Previous Comments:
[2010-03-26 11:56:42] f...@php.net
Verified with 5.2.13 on Debian (default configure)
Verified in the Debian 5.2.6+lenny4 PHP (just for completeness)
Correct result with 5.3.2 on Gentoo
[2010-03-26 08:20:19] emanuel dot dejanu at humaninfo dot ro
Description:
I have used the code from the test script on my development machine
(Windows Professional 7 32bit) with php 5.2.12 and is working correctly
but when I have deployed on my production machine that is FreeBSD 6.3
32bit with the same php version 5.2.12 is giving wrong results
(-2147483593). I also run this on other production machine that is
RedHat 5 32bit with php 5.2.6 and is also giving wrong results
(-2147483593).
I can not test with php 5.2.13 on production machines (virtual
hosting).
On windows is giving the correctly result (754303898) with PHP 5.2.12
and PHP 5.3.1. I am running in 32bit platform on all machines.
---
PHP_INT_SIZE: 4
System = FreeBSD somehost.com 6.3-RELEASE FreeBSD 6.3-RELEASE #6: Wed
Oc
t 21 09:32:42 MDT 2009 r...@fc:/usr/src/sys/i386/compile/VKERN i386
Build Date = Mar 3 2010 12:51:00
Configure Command = './configure' '--with-layout=GNU'
'--with-config-file-sca
n-dir=/usr/local/etc/php' '--disable-all' '--enable-libxml'
'--with-libxml-dir=/
usr/local' '--enable-reflection' '--program-prefix=' '--enable-fastcgi'
'--with-
apxs2=/usr/local/sbin/apxs' '--with-regex=php' '--with-zend-vm=CALL'
'--prefix=/
usr/local' '--mandir=/usr/local/man' '--infodir=/usr/local/info/'
'--build=i386-
portbld-freebsd6.3'
Server API = Command Line Interface
Virtual Directory Support = disabled
Configuration File (php.ini) Path = /usr/local/etc
Loaded Configuration File = /usr/local/etc/php.ini
Scan this dir for additional .ini files = /usr/local/etc/php
additional .ini files parsed = /usr/local/etc/php/extensions.ini
PHP API = 20041225
PHP Extension = 20060613
Zend Extension = 220060519
Debug Build = no
Test script:
---
function myhash($key) {
$h = 5381;
$l = strlen($key);
for($i = 0; $i $l; ++$i) {
$h = (($h 5) + $h) ^ ord($key[$i]);
}
return $h;
}
$h = myhash('CL6.1.7');
if ($h != 754303898)
echo bug\n;
echo $h . \n;
Expected result:
754303898
Actual result:
--
bug
-2147483593
--
Edit this bug report at http://bugs.php.net/bug.php?id=51397edit=1
Bug #51506 [Com]: Realpath failed on linux Server for version 5.2.10 ?
Edit report at http://bugs.php.net/bug.php?id=51506edit=1 ID: 51506 Comment by: whatrevolution at yahoo dot com Reported by: mastershepper at gmail dot com Summary: Realpath failed on linux Server for version 5.2.10 ? Status: Open Type: Bug Package: Apache2 related Operating System: Linux PHP Version: 5.2.13 New Comment: Code: ?php var_dump( realpath( dirname( __FILE__ ) ) ); echo \n; var_dump( realpath( '../' ) ); echo \n; var_dump( realpath( '../../' ) ); ? Result: string '/var/www/php_bugs' (length=17) string '/var/www' (length=8) string '/var' (length=4) PHP Version 5.2.10-2ubuntu6.4 System Linux 2.6.31-20-generic x86_64 Build Date Jan 6 2010 22:36:47 Server API Apache 2.0 Handler PHP API 20041225 PHP Extension 20060613 Zend Extension 220060519 Debug Build no Thread Safety disabled Zend Memory Manager enabled Apache/2.2.12 (Ubuntu) Previous Comments: [2010-04-09 09:51:02] mastershepper at gmail dot com 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. [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 #51363 [Com]: Fatal error raised by var_export() not caught by error handler
Edit report at http://bugs.php.net/bug.php?id=51363edit=1
ID: 51363
Comment by: whatrevolution at yahoo dot com
Reported by: daan at react dot com
Summary: Fatal error raised by var_export() not caught by error
handler
Status: Assigned
Type: Bug
Package: Scripting Engine problem
Operating System: Debian Etch
PHP Version: 5.2.13
Assigned To: derick
New Comment:
I am curious if the bug OP expects the var_export() output to never
end... ever? I do, because it is a recursive reference, so I'm puzzled
that this is considered a bug.
However, perhaps the solution would be to not throw a fatal error, but
throw a notice or warning and/or provide some way of telling
var_export() how deep to print.
array ( 0 = array ( 0 = array ( 0 = array ( 0 = array (
( ! ) Fatal error: Nesting level too deep - recursive dependency? in
/var/www/php_bugs/var_export_recursion_test.php on line 36
Call Stack
# TimeMemory FunctionLocation
1 0.0004 108776 {main}( ) ../var_export_recursion_test.php:0
2 0.0004 109968 var_export ( ) ../var_export_recursion_test.php:36
PHP Version 5.2.10-2ubuntu6.4
System Linux 2.6.31-20-generic x86_64
Build Date Jan 6 2010 22:36:47
Server API Apache 2.0 Handler
PHP API 20041225
PHP Extension 20060613
Zend Extension 220060519
Debug Build no
Thread Safety disabled
Zend Memory Manager enabled
Apache/2.2.12 (Ubuntu)
Previous Comments:
[2010-03-23 12:58:59] daan at react dot com
Description:
When a fatal error is raised by var_export() when trying to export a
resursive array, it is not caught by a user php error handler.
Test script:
---
function myErrorHandler($errno, $errstr, $errfile, $errline)
{
var_dump($errno, $errstr, $errfile, $errline);
/* Don't execute PHP internal error handler */
return true;
}
set_error_handler(myErrorHandler);
$recursive = array();
$recursive[] = $recursive;
var_export($recursive);
Expected result:
The var_dumped variables
Actual result:
--
array ( 0 = array ( 0 = array ( 0 = array ( 0 = array (
Fatal error: Nesting level too deep - recursive dependency? in test.php
on line x
--
Edit this bug report at http://bugs.php.net/bug.php?id=51363edit=1
Bug #51435 [Opn-Csd]: Missing ifdefs / logic bug in crypt code cause compile errors
Edit report at http://bugs.php.net/bug.php?id=51435edit=1 ID: 51435 Updated by: fel...@php.net Reported by: j...@php.net Summary: Missing ifdefs / logic bug in crypt code cause compile errors -Status: Open +Status: Closed Type: Bug Package: Compile Failure Operating System: Ubuntu 9.10 PHP Version: 5.3.2 -Assigned To: +Assigned To: felipe 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-22 22:54:37] fel...@php.net Automatic comment from SVN on behalf of felipe Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=298345 Log: - Fixed bug #51435 (Missing ifdefs / logic bug in crypt code cause compile errors) [2010-03-30 12:05:14] j...@php.net Description: In ext/standard/config.m4, the following line causes conditional definition of the PHP_SHA256_CRYPT and PHP_SHA512_CRYPT constants: if test $ac_cv_crypt_blowfish = no || test $ac_cv_crypt_des = no || test $ac_cv_crypt_ext_des = no || test x$php_crypt_r = x0; then Because these symbols are used unconditionally in ext/standard/crypt.c, this can cause PHP to fail to compile. In the near-term, the compile bug can be fixed as follows: #ifdef PHP_SHA256_CRYPT REGISTER_LONG_CONSTANT(CRYPT_SHA256, PHP_SHA256_CRYPT, CONST_CS | CONST_PERSISTENT); #endif #ifdef PHP_SHA512_CRYPT REGISTER_LONG_CONSTANT(CRYPT_SHA512, PHP_SHA512_CRYPT, CONST_CS | CONST_PERSISTENT); #endif However, the m4 logic should probably be revisited at some point. -- Edit this bug report at http://bugs.php.net/bug.php?id=51435edit=1
[PHP-BUG] Bug #51640 [NEW]: Fwrite writes twice a text
From: Operating system: Windows XP PHP version: 5.3.2 Package: Filesystem function related Bug Type: Bug Bug description:Fwrite writes twice a text Description: I'm having troubles with fwrite() function. It is writing twice a text I just need to write once. I searched in google for the same problem, and I found the same bug reported here : http://bugs.php.net/bug.php?id=21916, and here : http://bugs.php.net/bug.php?id=16225, but neither of both was solved. This is how it writes into the file : First Second Hello world! Hello world! Third As you can see, the string hello world! is writed twice, and that should not happen. Also, and this is weird, the line fwrite($op, $lastLine); prints the text correctly, just once... Test script: --- $file = test.txt; $string = Hello world!\r\n; $op = fopen($file,r+); $exp = explode(\n, fread($op, filesize($file))); $lastLine = end($exp); fseek($op, -strlen($lastLine), SEEK_END); fwrite($op, $string); fwrite($op, $lastLine); fclose($op); Expected result: The text should be writed just once. -- Edit bug report at http://bugs.php.net/bug.php?id=51640edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=51640r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=51640r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=51640r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=51640r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=51640r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=51640r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=51640r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=51640r=needscript Try newer version: http://bugs.php.net/fix.php?id=51640r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=51640r=support Expected behavior: http://bugs.php.net/fix.php?id=51640r=notwrong Not enough info: http://bugs.php.net/fix.php?id=51640r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=51640r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=51640r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51640r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=51640r=dst IIS Stability: http://bugs.php.net/fix.php?id=51640r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=51640r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=51640r=float No Zend Extensions: http://bugs.php.net/fix.php?id=51640r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=51640r=mysqlcfg
Bug #50829 [Com]: php.ini directive pdo_mysql.default_socket is ignored
Edit report at http://bugs.php.net/bug.php?id=50829edit=1 ID: 50829 Comment by: gnoodl at gmail dot com Reported by: giovanni at giacobbi dot net Summary: php.ini directive pdo_mysql.default_socket is ignored Status: Closed Type: Bug Package: PDO related Operating System: Linux PHP Version: 5.3.2RC1 New Comment: In which stable version does this fix appear. I've just upgraded to PHP 5.3.2 and whilst pdo_mysql.default_socket is returned correctly via ini_get(), attempting to make a connection results in the following exception SQLSTATE[HY000] [2002] Can't connect to local MySQL server through socket '/tmp/mysql.sock' FYI, my socket file resides at /var/lib/mysql/mysql.sock Previous Comments: [2010-03-24 17:49:55] paul at boxuk dot com this, or a problem relating to this fix appears to be seg-faulting the pdo_mysql module on startup in ZTS mode bug #51216 is related commenting out REGISTER_INI_ENTRIES() in ext/pdo_mysql/pdo_mysql.c:68 php startup prevents the seg-fault configure line -- ./configure --enable-maintainer-zts --with-mysql --with-mysqli=mysqlnd --enable- pdo --with-pdo-mysql gdb output -- gdb sapi/cli/php GNU gdb Fedora (6.8-37.el5) This GDB was configured as i386-redhat-linux-gnu... (gdb) run Starting program: /php-5.3.2/sapi/cli/php [Thread debugging using libthread_db enabled] [New Thread 0xb7f776c0 (LWP 491)] [New Thread 0xb7d0db90 (LWP 494)] [Thread 0xb7d0db90 (LWP 494) exited] Program received signal SIGSEGV, Segmentation fault. 0x08347ff5 in zend_startup_module_ex (module=0x98d2720, tsrm_ls=0x98b7050) at /opt/BoxUK/install/php-5.3.2/Zend/zend_API.c:1618 1618EG(current_module) = NULL; module-name at this point is pdo_mysql [2010-02-03 21:00:21] s...@php.net Automatic comment from SVN on behalf of pajoye Revision: http://svn.php.net/viewvc/?view=revisionrevision=294469 Log: Fixed bug #50829 (php.ini directive pdo_mysql.default_socket is ignored) [2010-01-26 13:15:59] il...@php.net This bug has been fixed in SVN. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. [2010-01-26 13:15:57] s...@php.net Automatic comment from SVN on behalf of iliaa Revision: http://svn.php.net/viewvc/?view=revisionrevision=294040 Log: Fixed bug #50829 (php.ini directive pdo_mysql.default_socket is ignored) [2010-01-24 14:03:53] giovanni at giacobbi dot net Description: The php.ini pdo_mysql.default_socket seems to be ignored. see related (closed) bug #49306 Reproduce code: --- php -d pdo_mysql.default_socket=ciao -r 'var_dump(ini_get(pdo_mysql.default_socket));' Expected result: string(4) ciao Actual result: -- bool(false) -- Edit this bug report at http://bugs.php.net/bug.php?id=50829edit=1
[PHP-BUG] Bug #51641 [NEW]: Adding namespace with addAttribute() adds spurious xmlns:xmlns attribute
From:
Operating system: All
PHP version: 5.2.13
Package: SimpleXML related
Bug Type: Bug
Bug description:Adding namespace with addAttribute() adds spurious xmlns:xmlns
attribute
Description:
If you add a new namespace to a document root with addAttribute(), the
function incorrectly also tries to add a namespace for the new namespace,
resulting in a spurious xmlns:xmlns attribute.
Add attribute called foo:bar
xmlns:foo=namespace-url foo:bar=value -- correct
Add attribute called xmlns:bar
xmlns:xmlns=namespace-url xmlns:bar=namespace-url -- incorrect
A special case is thus needed to ensure that, if the attribute name starts
with xmlns:, a namespace is not added for it:
xmlns:bar=namespace-url -- correct
Alternatively, a new function for adding namespaces to a document?
Test script:
---
?php
$xml = new SimpleXMLElement('office:document-content
xmlns:office=urn:oasis:names:tc:opendocument:xmlns:office:1.0/');
$xml-addAttribute('xmlns:ooow', 'http://openoffice.org/2004/writer',
'http://openoffice.org/2004/writer');
echo $xml-asXML();
?
Expected result:
?xml version=1.0?
office:document-content
xmlns:office=urn:oasis:names:tc:opendocument:xmlns:office:1.0
xmlns:ooow=http://openoffice.org/2004/writer/
Actual result:
--
?xml version=1.0?
office:document-content
xmlns:office=urn:oasis:names:tc:opendocument:xmlns:office:1.0
xmlns:xmlns=http://openoffice.org/2004/writer;
xmlns:ooow=http://openoffice.org/2004/writer/
--
Edit bug report at http://bugs.php.net/bug.php?id=51641edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=51641r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=51641r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=51641r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=51641r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=51641r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=51641r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=51641r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=51641r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=51641r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=51641r=support
Expected behavior:
http://bugs.php.net/fix.php?id=51641r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=51641r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=51641r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=51641r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51641r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=51641r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=51641r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=51641r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=51641r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=51641r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=51641r=mysqlcfg
Bug #47877 [Com]: ALERT - canary mismatch on efree() - heap overflow detected
Edit report at http://bugs.php.net/bug.php?id=47877edit=1 ID: 47877 Comment by: caesium at gmail dot com Reported by: leif at neland dot dk Summary: ALERT - canary mismatch on efree() - heap overflow detected Status: No Feedback Type: Bug Package: MSSQL related Operating System: Debian 5 PHP Version: 5.2.9 New Comment: nick at ihighteam dot com's solution works. I have a rather large dataset I am iterating through and ran into this issue. I can confirm that Nicks solution is a suitable workaround. Thanks Nick! Previous Comments: [2009-08-13 22:16:18] nick at ihighteam dot com I found a solution here and it works for me! http://www.nabble.com/-Bug-41297--NEW:-PHP-Suhosin-Patch-creates-a-problem-with-mssql_query%28%29-when-selecting-a-smalldatetime-field-td17693263.html Steps to Reproduce: 1. Use the default configuration of PHP with the mssql-extension. 2. create a sql-statement that selects a smalldatetimevalue from a MSSQL-Database or use the Script at the end of this report. 3. the Script dies in the mssql_query()-function Solution: I found the following solution that works for me: 1. Open /etc/php.ini 2. Decomment the line mssql.datetimeconvert = On and change it to mssql.datetimeconvert = Off 3. Restart Apache 4. The Problem dissappears [2009-07-10 03:11:23] synec dot net at gmail dot com I checked extension.ini and remove some lines. #extension=oci8.so #extension=recode.so #extension=pdo_oci.so and then works fine. [2009-07-10 02:30:53] synec dot net at gmail dot com run 'php -v' on CLI. ALERT - canary mismatch on efree() - heap overflow detected (attacker 'REMOTE_ADDR not set', file 'unknown') Install php v5.2.10 by FreeBSD ports. Using options are 'CLI, CGI, APACHE, SUHOSIN, MULTIBYTE, IPV6, MAILHEAD, REDIRECT, DISCARD, FASTCGI, PATHINFO' [2009-04-11 01:00:00] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to Open. [2009-04-03 03:00:29] ka...@php.net Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with ?php and ends with ?, is max. 10-20 lines long and does not require any external resources such as databases, etc. If the script requires a database to demonstrate the issue, please make sure it creates all necessary tables, stored procedures etc. Please avoid embedding huge scripts into the report. Aswell as a backtrace would help give some insight on the matter for the maintainer 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=47877 -- Edit this bug report at http://bugs.php.net/bug.php?id=47877edit=1
Bug #49139 [Com]: proc_open requires double quotes
Edit report at http://bugs.php.net/bug.php?id=49139edit=1
ID: 49139
Comment by: xandrani at googlemail dot com
Reported by: david dot gausmann at measx dot com
Summary: proc_open requires double quotes
Status: Open
Type: Bug
Package: Program Execution
Operating System: win32 only - Windows XP SP3
PHP Version: 5.3.0
New Comment:
Something similar fails for me... but even worse!
$Command = 'c:\program files\doxygen\bin\doxygen.exe
C:\fred\doxyfile'
$DescriptorSpecification = array
(
0 = array('pipe', 'r'),
1 = array('pipe', 'w'),
2 = array('pipe', 'w')
);
$Resource = proc_open($Command, $DescriptorSpecification, $Pipes, null,
$_ENV);
I get the error:
'c:\program' is not recognized as an internal or external command,
operable program or batch file.
This works on exec() so not sure what's going on.
Previous Comments:
[2009-08-03 13:09:56] david dot gausmann at measx dot com
Description:
The command, which shall be executed via proc_open, must be put in
double quotes.
This bug was on functions like system, exec, ...
It seems not to be fixed on proc_open.
Reproduce code:
---
--- script1.php ---
?php
//Works fine
echo 1.\r\n;
system('C:\php\php.exe C:\php\script2.php');
//FAILS!
echo 2.\r\n;
$arPipes = array();
$rProcess = proc_open('C:\php\php.exe C:\php\script2.php',
array(array('pipe', 'r'), array('pipe', 'w'),
array('pipe', 'w')), $arPipes);
if($rProcess !== false)
{
$nExitCode = -1;
do
{
while(!feof($arPipes[1]))
{
echo fread($arPipes[1], 1024);
flush();
}
$array = proc_get_status($rProcess);
if(!$array)
break;
} while($array['running']);
fclose($arPipes[0]);
fclose($arPipes[1]);
fclose($arPipes[2]);
proc_close($rProcess);
}
//Works fine (double quotes added)
echo 3.\r\n;
$arPipes = array();
$rProcess = proc_open('C:\php\php.exe C:\php\script2.php',
array(array('pipe', 'r'), array('pipe', 'w'),
array('pipe', 'w')), $arPipes);
if($rProcess !== false)
{
$nExitCode = -1;
do
{
while(!feof($arPipes[1]))
{
echo fread($arPipes[1], 1024);
flush();
}
$array = proc_get_status($rProcess);
if(!$array)
break;
} while($array['running']);
fclose($arPipes[0]);
fclose($arPipes[1]);
fclose($arPipes[2]);
proc_close($rProcess);
}
?
---script2.php---
?php
echo Lorem ipsum\r\n;
exit(0);
?
Expected result:
1.
Lorem ipsum
2.
Lorem ipsum
3.
The third call of proc_open should fail, the second one should work.
Actual result:
--
1.
Lorem ipsum
2.
3.
Lorem ipsum
The second call of proc_open should fails, but the third one works.
--
Edit this bug report at http://bugs.php.net/bug.php?id=49139edit=1
Bug #49139 [Com]: proc_open requires double quotes
Edit report at http://bugs.php.net/bug.php?id=49139edit=1
ID: 49139
Comment by: xandrani at googlemail dot com
Reported by: david dot gausmann at measx dot com
Summary: proc_open requires double quotes
Status: Open
Type: Bug
Package: Program Execution
Operating System: win32 only - Windows XP SP3
PHP Version: 5.3.0
New Comment:
The double backward slashes didn't show correctly... but they are in my
code.
Previous Comments:
[2010-04-23 02:20:33] xandrani at googlemail dot com
Something similar fails for me... but even worse!
$Command = 'c:\program files\doxygen\bin\doxygen.exe
C:\fred\doxyfile'
$DescriptorSpecification = array
(
0 = array('pipe', 'r'),
1 = array('pipe', 'w'),
2 = array('pipe', 'w')
);
$Resource = proc_open($Command, $DescriptorSpecification, $Pipes, null,
$_ENV);
I get the error:
'c:\program' is not recognized as an internal or external command,
operable program or batch file.
This works on exec() so not sure what's going on.
[2009-08-03 13:09:56] david dot gausmann at measx dot com
Description:
The command, which shall be executed via proc_open, must be put in
double quotes.
This bug was on functions like system, exec, ...
It seems not to be fixed on proc_open.
Reproduce code:
---
--- script1.php ---
?php
//Works fine
echo 1.\r\n;
system('C:\php\php.exe C:\php\script2.php');
//FAILS!
echo 2.\r\n;
$arPipes = array();
$rProcess = proc_open('C:\php\php.exe C:\php\script2.php',
array(array('pipe', 'r'), array('pipe', 'w'),
array('pipe', 'w')), $arPipes);
if($rProcess !== false)
{
$nExitCode = -1;
do
{
while(!feof($arPipes[1]))
{
echo fread($arPipes[1], 1024);
flush();
}
$array = proc_get_status($rProcess);
if(!$array)
break;
} while($array['running']);
fclose($arPipes[0]);
fclose($arPipes[1]);
fclose($arPipes[2]);
proc_close($rProcess);
}
//Works fine (double quotes added)
echo 3.\r\n;
$arPipes = array();
$rProcess = proc_open('C:\php\php.exe C:\php\script2.php',
array(array('pipe', 'r'), array('pipe', 'w'),
array('pipe', 'w')), $arPipes);
if($rProcess !== false)
{
$nExitCode = -1;
do
{
while(!feof($arPipes[1]))
{
echo fread($arPipes[1], 1024);
flush();
}
$array = proc_get_status($rProcess);
if(!$array)
break;
} while($array['running']);
fclose($arPipes[0]);
fclose($arPipes[1]);
fclose($arPipes[2]);
proc_close($rProcess);
}
?
---script2.php---
?php
echo Lorem ipsum\r\n;
exit(0);
?
Expected result:
1.
Lorem ipsum
2.
Lorem ipsum
3.
The third call of proc_open should fail, the second one should work.
Actual result:
--
1.
Lorem ipsum
2.
3.
Lorem ipsum
The second call of proc_open should fails, but the third one works.
--
Edit this bug report at http://bugs.php.net/bug.php?id=49139edit=1
Req #50388 [Opn-Fbk]: MySQL safe mode support
Edit report at http://bugs.php.net/bug.php?id=50388edit=1 ID: 50388 Updated by: ka...@php.net Reported by: orcan at nbcs dot rutgers dot edu Summary: MySQL safe mode support -Status: Open +Status: Feedback Type: Feature/Change Request -Package: Feature/Change Request +Package: *General Issues Operating System: solaris PHP Version: 5.3SVN-2009-12-04 (SVN) New Comment: Hi Could you please re-upload the patch to the bug tracker and change the status back to 'Open' when done? The patch does not seems to be accessible. Previous Comments: [2010-03-19 23:44:27] orcan at nbcs dot rutgers dot edu Ping? Is this the right place to submit patches? What else do I need to do to get noticed? [2009-12-04 17:31:36] orcan at nbcs dot rutgers dot edu Sorry, I couldn't attach the patch (is there a way?). Here is a link to it: http://pastebin.ca/1702061 [2009-12-04 17:28:33] orcan at nbcs dot rutgers dot edu Description: We, at Rutgers, need mysql safe mode support in mysqli. I have made this patch that can be applied to the current svn. Please consider applying it. Thanks. -- Edit this bug report at http://bugs.php.net/bug.php?id=50388edit=1
Bug #51632 [Fbk-Dup]: filter_var fails to validate correct URL
Edit report at http://bugs.php.net/bug.php?id=51632edit=1 ID: 51632 Updated by: ahar...@php.net Reported by: zharkikh at i dot com dot ua Summary: filter_var fails to validate correct URL -Status: Feedback +Status: Duplicate Type: Bug Package: Unknown/Other Function Operating System: FreeBSD PHP Version: 5.3.2 New Comment: To confirm, this didn't make 5.3.2. It should be in 5.3.3. Closing duplicate: the original bug is bug #51192. Previous Comments: [2010-04-22 21:48:45] ras...@php.net This was fixed in svn a while ago. [2010-04-22 12:45:00] degeb...@php.net Please try using this snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ PHP 5.3.2 was released on March 4, and the #51305 was fixed on March 3. It probably didn't make it into the release. It works for me on 5.3.3-dev built a few days ago. [2010-04-22 11:52:00] zharkikh at i dot com dot ua Description: Function filter_var seems to change it behavior when PHP upgraded from 5.2.4 to 5.3.2. The next example work fine in 5.24 but fail in 5.3.2. This problem was described in Bug #51305 (filter_var fails if domain name contain -) and reported to be fixed in 5.2.13, but it is bubble again in 5.3.2 : Test script: --- ?php $P = 'http://m-zharkikh.livejournal.com/26556.html'; echo filter_var($P, FILTER_VALIDATE_URL, FILTER_FLAG_SCHEME_REQUIRED); Expected result: http://m-zharkikh.livejournal.com/26556.html, so URL is valid Actual result: -- false, so URL provided evaluated as invalid -- Edit this bug report at http://bugs.php.net/bug.php?id=51632edit=1
