Bug #49013 [NoF->ReO]: SOAPClient interprets the parameters array incorrectly
Edit report at https://bugs.php.net/bug.php?id=49013&edit=1
ID: 49013
Updated by: cwei...@php.net
Reported by:egos at biz-club dot biz
Summary:SOAPClient interprets the parameters array
incorrectly
-Status: No Feedback
+Status: Re-Opened
Type: Bug
Package:SOAP related
Operating System: debian Lenny
-PHP Version:5.2.6
+PHP Version:5.5.1
Block user comment: N
Private report: N
New Comment:
We can reproduce the issue on PHP 5.1, see the files at http://p.cweiske.de/53:
SoapClient: http://p.cweiske.de/53/raw/soapclienttest.php
WSDL: http://p.cweiske.de/53/raw/test.wsdl
We give an associative array of parameters:
$arguments = array(
'password' => 'password-value',
'username' => 'username-value',
);
But the SOAP request has the values in wrong order:
password-value
username-value
Previous Comments:
[2009-08-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-08-03 15:17:46] j...@php.net
Please try using this snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
[2009-07-22 07:20:03] egos at biz-club dot biz
Description:
on Debian Lenny (php 5.2.6.dfsg.1-1+lenny3) i run the simple call.
please, take a look at var_dump of the parameters variable and at the generated
xml code
Before xml is generated, it sorts the parameters, so that values loose bindings
to the keys of the array.
Reproduce code:
---
$client->__soapCall("updateMonitoring", $parameters);
var_dump($parameters);
echo "";
echo " REQUEST:\n" . $client->__getLastRequest() . "\n";
Expected result:
correct xml, based on $parameters. Here,s the var_dump of it $parameters I put
there
["login"]=>
string(4) "***"
["password"]=>
string(32) "***"
["monitoring_id"]=>
string(5) "18700"
["plan_budget_total"]=>
string(2) "70"
["plan_budget_navigation"]=>
string(1) "0"
["plan_pay"]=>
string(2) "25"
["total"]=>
int(66)
["task_training"]=>
int(0)
["without_preliminary_examination"]=>
int(0)
["without_competition"]=>
int(0)
["city_0_59"]=>
int(0)
["city_60_100"]=>
int(0)
["city_101_110"]=>
int(0)
["city_111_120"]=>
int(0)
["city_121_130"]=>
int(0)
["city_131_140"]=>
int(0)
["city_141_150"]=>
int(1)
["city_151_160"]=>
int(1)
["city_161_170"]=>
int(2)
["city_171_180"]=>
int(0)
["city_181_190"]=>
int(2)
["city_191_200"]=>
int(2)
["city_201_210"]=>
int(5)
["city_211_220"]=>
int(3)
["city_221_230"]=>
int(1)
["city_231_240"]=>
int(8)
["city_241_250"]=>
int(1)
["city_251_260"]=>
int(4)
["city_261_270"]=>
int(2)
["city_271_280"]=>
int(5)
["city_281_290"]=>
int(5)
["city_291_300"]=>
int(3)
["city_301_310"]=>
int(10)
["city_311_320"]=>
int(3)
["city_321_330"]=>
int(2)
["city_331_340"]=>
int(2)
["city_341_400"]=>
int(1)
["country_0_59"]=>
int(0)
["country_60_100"]=>
int(0)
["country_101_110"]=>
int(0)
["country_111_120"]=>
int(0)
["country_121_130"]=>
int(0)
["country_131_140"]=>
int(0)
["country_141_150"]=>
int(0)
["country_151_160"]=>
int(0)
["country_161_170"]=>
int(0)
["country_171_180"]=>
int(0)
["country_181_190"]=>
int(0)
["country_191_200"]=>
int(0)
["country_201_210"]=>
int(1)
["country_211_220"]=>
int(1)
["country_221_230"]=>
int(0)
["country_231_240"]=>
int(0)
["country_241_250"]=>
int(1)
["country_251_260"]=>
int(0)
["country_261_270"]=>
int(0)
["country_271_280"]=>
int(0)
["country_281_290"]=>
int(0)
["country_291_300"]=>
int(0)
["country_301_310"]=>
int(0)
["country_311_320"]=>
int(0)
["country_321_330"]=>
int(0)
["country_331_340"]=>
int(0)
["country_341_400"]=>
int(0)
}
Actual result:
--
http://schemas.xmlsoap.org/soap/envelope/";
xmlns:ns1="urn:abiturient" xmlns:xsd="http://www.w3.org/2001/XMLSchema";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/";
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/";>**187007002566011202253181425531032211100100
--
Edit this bug report at https://bugs.php.net/bug.php?id=49013&edit=1
Bug #64589 [Nab]: SOAP arrays with non-sequentially indexed keys ignored
Edit report at https://bugs.php.net/bug.php?id=64589&edit=1 ID: 64589 Updated by: cwei...@php.net Reported by:cwei...@php.net Summary:SOAP arrays with non-sequentially indexed keys ignored Status: Not a bug Type: Bug Package:SOAP related Operating System: Linux PHP Version:5.5.0beta1 Assigned To:dmitry Block user comment: N Private report: N New Comment: I understand the reasoning that the data cannot be transferred without data loss. But I'd like to get notified about that the data I want to send cannot be sent and will be ignored - an E_WARNING for example. Currently, I also suffer a data loss - and it goes unnoticed. Previous Comments: [2013-04-09 10:43:13] dmi...@php.net This is the expected behavior. The value you are passing in brokenStrings does not conform to WSDL specification (it can't be transferred without data lose). You may use Apache Map extension to pass array with indexes. [2013-04-05 09:32:11] cwei...@php.net Description: When passing a non-sequentially numerically indexed array to a SOAPClient method, it gets ignored as "empty". Test script: --- http://p.cweiske.de/35 Expected result: foo foo2 Actual result: -- -- Edit this bug report at https://bugs.php.net/bug.php?id=64589&edit=1
Bug #64739 [Opn]: Invalid Title and Author data returned
Edit report at https://bugs.php.net/bug.php?id=64739&edit=1
ID: 64739
Updated by: cwei...@php.net
Reported by:php-qa at sebastianmendel dot de
Summary:Invalid Title and Author data returned
Status: Open
Type: Bug
Package:EXIF related
Operating System: Linux
PHP Version:5.4.14
Block user comment: N
Private report: N
New Comment:
Reason is probably that the exif data were stored on a PowerPC Mac and have big
endianess.
Previous Comments:
[2013-04-30 07:06:21] php-qa at sebastianmendel dot de
Description:
exif_read_data returns invalid Titel and Author data.
ExifTool cli returns valid data.
Test script:
---
php-5.4.14 -r
"var_dump(exif_read_data('http://sebastianmendel.de/php/exif_segmentation_fault/test.jpg'));"
Expected result:
["Title"]=>
string(8) "55845364"
["Author"]=>
string(13) "100420.00"
Actual result:
--
["Title"]=>
string(8) ""
["Author"]=>
string(13) "?"
--
Edit this bug report at https://bugs.php.net/bug.php?id=64739&edit=1
Req #42197 [Nab->Opn]: header() cannot be used after echo on CLI
Edit report at https://bugs.php.net/bug.php?id=42197&edit=1
ID: 42197
Updated by: cwei...@php.net
Reported by:cwei...@php.net
Summary:header() cannot be used after echo on CLI
-Status: Not a bug
+Status: Open
Type: Feature/Change Request
Package:*General Issues
Operating System: Linux
PHP Version:5.2.4RC1
Block user comment: N
Private report: N
New Comment:
Using ob_start() is a workaround, not a fix. Also, error messages are hidden
when using ob_start().
Previous Comments:
[2013-06-27 22:41:26] yohg...@php.net
Just use ob_start().
$ ./sapi/cli/php
a
[2007-08-04 14:03:29] j...@php.net
Reclassified.
[2007-08-03 09:53:44] cwei...@php.net
Description:
When issuing a header() call in a php command line script (php cli) after I
used 'echo', the message 'headers already sent' pops up.
It should be possible to use header(), session_id_generate() and other session
related functions after outputting something on CLI - since headers are not
sent on cli.
(The use case we have is unit-testing packages on cli)
Reproduce code:
---
Expected result:
a
Actual result:
--
a
Warning: Cannot modify header information - headers already sent by (output
started at /data/cvs/pear/sessionbug.php:2) in /data/cvs/pear/sessionbug.php on
line 3
Call Stack:
0.0003 83688 1. {main}() /data/cvs/pear/sessionbug.php:0
0.0006 83988 2. header() /data/cvs/pear/sessionbug.php:3
--
Edit this bug report at https://bugs.php.net/bug.php?id=42197&edit=1
Req #40288 [Opn->Csd]: how to check if a file is includable or not includable
Edit report at https://bugs.php.net/bug.php?id=40288&edit=1
ID: 40288
Updated by: cwei...@php.net
Reported by:ironoxid at libero dot it
Summary:how to check if a file is includable or not
includable
-Status: Open
+Status: Closed
Type: Feature/Change Request
-Package:Feature/Change Request
+Package:*General Issues
Operating System: irrelevant
PHP Version:5.2.0
-Assigned To:
+Assigned To:cweiske
Block user comment: N
Private report: N
New Comment:
stream_resolve_include_path() does what you want (from PHP 5.3.2 on).
Previous Comments:
[2007-01-30 13:48:10] ironoxid at libero dot it
Description:
Actually there is a difference between read and include authorization: I can't
read a file, but, at the same time, I can include it (read about
safe_mode_include_dir).
Unfortunately there is no way to check if I can include a file or not.
Actually the only way to do this is perform an include, and this is not always
what we want to do.
Reproduce code:
---
function check_plugins($pluginsFromConfig) {
foreach($pluginsFromConfig As $filepath) {
if(is_includable($filepath)===false) {
trigger_error('plugin not found',E_USER_ERROR);
exit;
}
else echo 'plugin -bla- -bla- exists';
}
}
Expected result:
We expect to know if a file can be included, without include it.
Actual result:
--
Function is_includable doesn't exist. We tried to use file_exists, etc. but are
limited by safe_mode restrictions.
Documentation say that we can use is_readable for ignore safe_mode restriction
but it doesn't work and if it will work it will be logically wrong.
--
Edit this bug report at https://bugs.php.net/bug.php?id=40288&edit=1
#50159 [Opn]: wrong working directory in symlinked files
ID: 50159 Updated by: cwei...@php.net Reported By: cwei...@php.net Status: Open Bug Type: *General Issues -Operating System: +Operating System: debian 5.0 PHP Version: 5.3.1RC3 New Comment: sapi is fastcgi Previous Comments: [2009-11-12 16:43:52] j...@php.net See also bug #49456 [2009-11-12 16:24:55] paj...@php.net Related to #49456. Which is expected given the changes applied to realpath and related functions. [2009-11-12 15:39:14] cwei...@php.net Description: getcwd() and the current working directory does not work correctly anymore on php 5.3.0 and 5.3.1RCx when executing a symlinked file. In php versions before 5.3.0, the current working directory of a file was the directory below the document root of the web server. in 5.3.0, it's the target directory of the symlinked file. Imagine the following file layout: /var/www/host/ - webserver document root /var/www/host/config.php /var/www/host/index.php - symlink to /usr/share/app/index.php When opening index.php, getcwd() returns /usr/share/app/ in 5.3.0 and 5.3.1rc(1|2|3), while it returned /var/www/host/ on 5.2.x. This change causes real problems because now it is impossible to share application code easily among installations! -- Edit this bug report at http://bugs.php.net/?id=50159&edit=1
#50159 [Asn]: wrong working directory in symlinked files
ID: 50159 Updated by: cwei...@php.net Reported By: cwei...@php.net Status: Assigned Bug Type: *General Issues Operating System: * PHP Version: 5.3.1RC3 Assigned To: dmitry New Comment: I reverted <@Jani_> svn diff -r263054:263055 with patch -R, but that did not help. I still get the symlink directory reported when running Previous Comments: [2009-11-12 17:02:06] j...@php.net Dmitry, I think this patch of yours caused this: http://svn.php.net/viewvc?view=revision&revision=263055 Any comments? [2009-11-12 16:44:52] j...@php.net See also bug #46814 (reported for 5.2.8 actually..) [2009-11-12 16:44:40] cwei...@php.net sapi is fastcgi [2009-11-12 16:43:52] j...@php.net See also bug #49456 [2009-11-12 16:24:55] paj...@php.net Related to #49456. Which is expected given the changes applied to realpath and related functions. 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/50159 -- Edit this bug report at http://bugs.php.net/?id=50159&edit=1
#50159 [Fbk->Opn]: wrong working directory in symlinked files
ID: 50159
Updated by: cwei...@php.net
Reported By: cwei...@php.net
-Status: Feedback
+Status: Open
Bug Type: *General Issues
Operating System: *
PHP Version: 5.3.1RC3
New Comment:
@srina...@php.net:
Applying that patch to 5.3.1 fixes the problem for me!
Previous Comments:
[2009-11-18 09:46:11] srina...@php.net
hi,
in my quick investigation, i think the issue is we are doing chdir to
the absolute path of given uri (which is a change in behavior compared
to 5.2).
here is a rough draft like patch that seems to alleviate this problem.
[srir...@tim-vm2]'PHP_5_3'>svn diff main/fopen_wrappers.c
Index: main/fopen_wrappers.c
===
--- main/fopen_wrappers.c (revision 290898)
+++ main/fopen_wrappers.c (working copy)
@@ -386,7 +386,7 @@
#ifndef PHP_WIN32
struct stat st;
#endif
- char *path_info, *filename;
+ char *path_info, *filename, *orig_filename;
int length;
filename = SG(request_info).path_translated;
@@ -455,6 +455,7 @@
} /* if doc_root && path_info */
if (filename) {
+ orig_filename = estrdup(filename);
filename = zend_resolve_path(filename,
strlen(filename) TSRMLS_CC);
}
@@ -488,8 +489,15 @@
STR_FREE(SG(request_info).path_translated); /* for same
reason as above */
SG(request_info).path_translated = filename;
- file_handle->filename = SG(request_info).path_translated;
- file_handle->free_filename = 0;
+ if (orig_filename) {
+ file_handle->filename = orig_filename;
+ file_handle->free_filename = 1;
+ }
+ else {
+ file_handle->filename =
SG(request_info).path_translated;
+ file_handle->free_filename = 0;
+ }
+
file_handle->handle.fp = fp;
file_handle->type = ZEND_HANDLE_FP;
applying this patch , seems to work. af course, more thought need to
go on this before this can be committed.
[2009-11-13 08:36:53] j...@php.net
So no need to ask Dmitry then. :)
[2009-11-12 22:24:59] cwei...@php.net
I reverted
<@Jani_> svn diff -r263054:263055
with patch -R, but that did not help. I still get the symlink directory
reported when running
[2009-11-12 17:02:06] j...@php.net
Dmitry, I think this patch of yours caused this:
http://svn.php.net/viewvc?view=revision&revision=263055
Any comments?
[2009-11-12 16:44:52] j...@php.net
See also bug #46814 (reported for 5.2.8 actually..)
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/50159
--
Edit this bug report at http://bugs.php.net/?id=50159&edit=1
#47194 [Opn->Asn]: documentation workflow change
ID: 47194 Updated by: cwei...@php.net Reported By: samm...@php.net -Status: Open +Status: Assigned Bug Type:Feature/Change Request PHP Version: 5.2.8 -Assigned To: +Assigned To: cweiske Previous Comments: [2009-01-22 21:31:39] samm...@php.net Description: Translations can among others have the status "working". A file can have the status "working" for one of two reasons: 1. The file is outdated and needs revision. 2. A translator is currently working on this file, but the work is not yet completed. In any case this file is clearly not ready to be published and should not be included in a full build for the manual in this language. Omitting files with status "working" from the build will also considerably speed up the build process. To manage these files and coordinate translation efforts, a list of files with status "working" needs to be created before the manual build. Also, during this preprocessing phase files that are outdated need to be identified and set to status working. A file is outdated when 1. its version number is different from the version number of its corrosponding en version number AND 2. the file has not been touched for more than days. will be defined for each language in a separate file and is dependent on the policy of the translation team for that language. The following changes to the build process are requested: 1. Check for files that are outdated and set the status flag for outdated files to "working". 2. Generate a list of files (ascii, one full pathname per line) that have the status "working". 3. Change the build to omit files with status "working", maybe using the file from step 2 as an exclude list. -- Edit this bug report at http://bugs.php.net/?id=47194&edit=1
#47194 [Asn]: documentation workflow change
ID: 47194 Updated by: cwei...@php.net Reported By: samm...@php.net Status: Assigned Bug Type:Feature/Change Request PHP Version: 5.2.8 Assigned To: cweiske New Comment: http://tmp.cweiske.de/phpdoc-broken-files.diff Previous Comments: [2009-01-22 21:31:39] samm...@php.net Description: Translations can among others have the status "working". A file can have the status "working" for one of two reasons: 1. The file is outdated and needs revision. 2. A translator is currently working on this file, but the work is not yet completed. In any case this file is clearly not ready to be published and should not be included in a full build for the manual in this language. Omitting files with status "working" from the build will also considerably speed up the build process. To manage these files and coordinate translation efforts, a list of files with status "working" needs to be created before the manual build. Also, during this preprocessing phase files that are outdated need to be identified and set to status working. A file is outdated when 1. its version number is different from the version number of its corrosponding en version number AND 2. the file has not been touched for more than days. will be defined for each language in a separate file and is dependent on the policy of the translation team for that language. The following changes to the build process are requested: 1. Check for files that are outdated and set the status flag for outdated files to "working". 2. Generate a list of files (ascii, one full pathname per line) that have the status "working". 3. Change the build to omit files with status "working", maybe using the file from step 2 as an exclude list. -- Edit this bug report at http://bugs.php.net/?id=47194&edit=1
#34657 [Bgs]: If you get a communication problem when loading the WSDL, it fatal's
ID: 34657
Updated by: cwei...@php.net
Reported By: gareth at wsys dot co dot uk
Status: Bogus
Bug Type: SOAP related
Operating System: Windows, Linux
PHP Version: 5.1.6
Assigned To: dmitry
New Comment:
http://bugs.xdebug.org/view.php?id=249
Previous Comments:
[2007-03-30 10:10:52] dmi...@php.net
This is a XDEBUG issue, ext/soap may fix nothing.
[2007-03-26 15:41:48] justin dot hendrickson+pear at gmail dot com
Work around:
try {
if(!...@file_get_contents($wsdl)) {
throw new SoapFault('Server', 'No WSDL found at ' . $wsdl);
}
$soap = new SoapClient($wsdl);
// ...
} catch(SoapFault $e) {
// ...
}
[2007-03-15 10:24:30] craigf at togetheragency dot co dot uk
Contrary to my previous post, the error is not platform specific, but
rather, a conflict with the xdebug module. With xdebug enabled, the
soapfault does not get raised. Using xdebug_disable() prior to the
try/catch block will result in the expected result of a catch with
soapfault.
Warnings still exist, but can be disabled with error_reporting() prior
to the try/catch as with xdebug.
[2007-03-14 23:01:35] craigf at togetheragency dot co dot uk
5.2.2-dev as of today (and 5.2.1) on windows is not raising a SoapFault
exception regardless of if exceptions is true or false, as stated by
jhendric. However, 5.2.1 on FreeBSD 4 (installed from ports) is raising
an uncaught SoapFault exception as was stated by gareth . So it appears
to be platform specific. In both cases, 3 additional warnings are
raised.
IIS:
Warning: SoapClient::SoapClient(): php_network_getaddresses:
getaddrinfo failed: No such host is known. in c:\web\test.php on line 2
Warning: SoapClient::SoapClient(h^tp://some.random.host/test.wsdl):
failed to open stream: No such file or directory in c:\web\test.php on
line 2
Warning: SoapClient::SoapClient(): I/O warning : failed to load
external entity "h^tp://some.random.host/test.wsdl" in c:\web\test.php
on line 2
Fatal error: SOAP-ERROR: Parsing WSDL: Couldn't load from
'h^tp://some.random.host/test.wsdl' in c:\web\test.php on line 2
FreeBSD 4:
Warning: SoapClient::SoapClient(): php_network_getaddresses:
getaddrinfo failed: No address associated with hostname in
/usr/home/www/test.php on line 2
Warning: SoapClient::SoapClient(h^tp://some.random.host/test.wsdl):
failed to open stream: Unknown error: 0 in /usr/home/www/test.php on
line 2
Warning: SoapClient::SoapClient(): I/O warning : failed to load
external entity "h^tp://some.random.host/test.wsdl" in
/usr/home/www/test.php on line 2
Fatal error: Uncaught SoapFault exception: [WSDL] SOAP-ERROR: Parsing
WSDL: Couldn't load from 'h^tp://some.random.host/test.wsdl' in
/usr/home/www/test.php:2 Stack trace: #0 /usr/home/www/test.php(2):
SoapClient->SoapClient('h^tp://some.ran...') #1 {main} thrown in
/usr/home/www/test.php on line 2
Note: had to replace http due to spam filter.
[2007-02-21 17:25:59] lsm...@php.net
In general nothing in ext/soap should be fatal if its not within the
control of the local php application. This means missing WSDL, changes
to the WSDL etc. All of this needs to be catchable in some way or
another (exception, returning false .. etc).
Also if an exception is thrown no warnings should be thrown for the
same issue.
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/34657
--
Edit this bug report at http://bugs.php.net/?id=34657&edit=1
#47302 [Opn->Csd]: Problem with downloading pear
ID: 47302 Updated by: cwei...@php.net Reported By: jakub at 31337 dot pl -Status: Open +Status: Closed Bug Type: PHAR related Operating System: Slackware PHP Version: 5.3CVS-2009-02-04 (snap) New Comment: Thank you for your bug report. This issue has already been fixed in the latest released version of PHP, which you can download at http://www.php.net/downloads.php Previous Comments: [2009-02-04 18:33:38] bio at artcradle dot com reproduced on ubuntu 8.04 too. [2009-02-04 11:48:56] jakub at 31337 dot pl Description: Installing PEAR environment: /usr/local/php5.3/lib/php/ --2009-02-04 12:35:45-- http://pear.php.net/install-pear-nozlib.phar Translacja pear.php.net... 78.129.214.25 £±czenie siê z pear.php.net|78.129.214.25|:80... po³±czono. ¯±danie HTTP wys³ano, oczekiwanie na odpowied¼... 404 Not Found 2009-02-04 12:35:45 B£¡D 404: Not Found. -- Edit this bug report at http://bugs.php.net/?id=47302&edit=1
#50159 [Csd]: wrong working directory in symlinked files
ID: 50159
Updated by: cwei...@php.net
Reported By: cwei...@php.net
Status: Closed
Bug Type: Scripting Engine problem
Operating System: *
PHP Version: 5.3.1RC3
Assigned To: dmitry
New Comment:
Thanks!
Previous Comments:
[2009-11-30 14:21:38] dmi...@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.
[2009-11-30 14:21:23] s...@php.net
Automatic comment from SVN on behalf of dmitry
Revision: http://svn.php.net/viewvc/?view=revision&revision=291496
Log: Fixed bug #50159 (wrong working directory in symlinked files)
[2009-11-22 17:58:11] cwei...@php.net
@srina...@php.net:
Applying that patch to 5.3.1 fixes the problem for me!
[2009-11-18 09:46:11] srina...@php.net
hi,
in my quick investigation, i think the issue is we are doing chdir to
the absolute path of given uri (which is a change in behavior compared
to 5.2).
here is a rough draft like patch that seems to alleviate this problem.
[srir...@tim-vm2]'PHP_5_3'>svn diff main/fopen_wrappers.c
Index: main/fopen_wrappers.c
===
--- main/fopen_wrappers.c (revision 290898)
+++ main/fopen_wrappers.c (working copy)
@@ -386,7 +386,7 @@
#ifndef PHP_WIN32
struct stat st;
#endif
- char *path_info, *filename;
+ char *path_info, *filename, *orig_filename;
int length;
filename = SG(request_info).path_translated;
@@ -455,6 +455,7 @@
} /* if doc_root && path_info */
if (filename) {
+ orig_filename = estrdup(filename);
filename = zend_resolve_path(filename,
strlen(filename) TSRMLS_CC);
}
@@ -488,8 +489,15 @@
STR_FREE(SG(request_info).path_translated); /* for same
reason as above */
SG(request_info).path_translated = filename;
- file_handle->filename = SG(request_info).path_translated;
- file_handle->free_filename = 0;
+ if (orig_filename) {
+ file_handle->filename = orig_filename;
+ file_handle->free_filename = 1;
+ }
+ else {
+ file_handle->filename =
SG(request_info).path_translated;
+ file_handle->free_filename = 0;
+ }
+
file_handle->handle.fp = fp;
file_handle->type = ZEND_HANDLE_FP;
applying this patch , seems to work. af course, more thought need to
go on this before this can be committed.
[2009-11-13 08:36:53] j...@php.net
So no need to ask Dmitry then. :)
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/50159
--
Edit this bug report at http://bugs.php.net/?id=50159&edit=1
#40608 [Fbk]: break within foreach causes strange behaviour
ID: 40608 Updated by: [EMAIL PROTECTED] Reported By: eric dot broersma at phil dot uu dot nl Status: Feedback Bug Type: Arrays related Operating System: Sun Solaris PHP Version: 5.2.1 New Comment: I cannot reproduce this on Gentoo with 5.2.1 Previous Comments: [2007-03-20 16:40:30] [EMAIL PROTECTED] I wasn't feeling spunky enough to mark the bug "closed", though... figured I'd better leave that to the real PHP devs... [2007-03-20 16:35:58] [EMAIL PROTECTED] My bad... pretending to be a dev myself there, by selecting the "Quick Fix" option to "notify" the original bug submitter (and all readers) about the snapshot option. [2007-03-19 20:48:54] [EMAIL PROTECTED] Are you asking yourself to try fresh snapshot? Or did you click wrong link? [2007-03-19 20:40:35] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.2-win32-latest.zip [2007-03-19 19:55:06] [EMAIL PROTECTED] Tested this example against the 5.2 snapshot (php5.2-win32-200703191630.zip) from php.net, and it works properly. So, looks like it has been fixed on the 5.2 branch after 5.2.1 was released. 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/40608 -- Edit this bug report at http://bugs.php.net/?id=40608&edit=1
#40608 [Fbk->Opn]: break within foreach causes strange behaviour
ID: 40608 Updated by: [EMAIL PROTECTED] Reported By: eric dot broersma at phil dot uu dot nl -Status: Feedback +Status: Open Bug Type: Arrays related Operating System: Sun Solaris PHP Version: 5.2.1 Previous Comments: [2007-03-23 07:53:12] [EMAIL PROTECTED] I cannot reproduce this on Gentoo with 5.2.1 [2007-03-20 16:40:30] [EMAIL PROTECTED] I wasn't feeling spunky enough to mark the bug "closed", though... figured I'd better leave that to the real PHP devs... [2007-03-20 16:35:58] [EMAIL PROTECTED] My bad... pretending to be a dev myself there, by selecting the "Quick Fix" option to "notify" the original bug submitter (and all readers) about the snapshot option. [2007-03-19 20:48:54] [EMAIL PROTECTED] Are you asking yourself to try fresh snapshot? Or did you click wrong link? [2007-03-19 20:40:35] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.2-win32-latest.zip 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/40608 -- Edit this bug report at http://bugs.php.net/?id=40608&edit=1
#40608 [Opn->Fbk]: break within foreach causes strange behaviour
ID: 40608 Updated by: [EMAIL PROTECTED] Reported By: eric dot broersma at phil dot uu dot nl -Status: Open +Status: Feedback Bug Type: Arrays related Operating System: Sun Solaris PHP Version: 5.2.1 Previous Comments: [2007-03-23 07:53:12] [EMAIL PROTECTED] I cannot reproduce this on Gentoo with 5.2.1 [2007-03-20 16:40:30] [EMAIL PROTECTED] I wasn't feeling spunky enough to mark the bug "closed", though... figured I'd better leave that to the real PHP devs... [2007-03-20 16:35:58] [EMAIL PROTECTED] My bad... pretending to be a dev myself there, by selecting the "Quick Fix" option to "notify" the original bug submitter (and all readers) about the snapshot option. [2007-03-19 20:48:54] [EMAIL PROTECTED] Are you asking yourself to try fresh snapshot? Or did you click wrong link? [2007-03-19 20:40:35] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.2-win32-latest.zip 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/40608 -- Edit this bug report at http://bugs.php.net/?id=40608&edit=1
#36487 [Bgs->Opn]: object === same object mismatch
ID: 36487
Updated by: [EMAIL PROTECTED]
Reported By: xxoes at nw7 dot de
-Status: Bogus
+Status: Open
Bug Type: *General Issues
Operating System: windows & linux
PHP Version: 5.1.2
New Comment:
As far as I see that, the objects *are* identical.
They equal === as long as they are not in the process of being
destroyed - but as soon as the destroying process is begun, they don't
equal any more although they are still equal
Previous Comments:
[2006-02-23 08:05:56] xxoes at nw7 dot de
Sorry but i don't understand!
Thats are the same objects and the same instances, and === doesn't
matched!
It works fine if a call $obj->__destruct === is true, but not if this
function is called by php on exit.
[2006-02-22 16:42:39] [EMAIL PROTECTED]
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
For === to return true on object comparison both objects must be
instances of the same class and refer to the exact same internal
object.
[2006-02-22 15:04:40] xxoes at nw7 dot de
This is not PHP-GTK related.
If you replace GtkObject with DOMElement you get the same result.
[2006-02-22 14:33:03] xxoes at nw7 dot de
Description:
Although the objects have the same object id after destruction, "==="
doesn't equal them any more.
I try:
$abc = new abc();
$obj = new bla();
and:
$abc = new abc();
$obj = new bla();
both the same result.
This does not happen when you remove "extends GtkObject" from the class
signature.
Reproduce code:
---
xparent->remove($this);
}
}
class abc {
function __destruct() {
echo "abc::__destruct()\r\n";
}
function put($obj) {
$this->obj = $obj;
$obj->xparent = $this;
}
function remove($obj) {
echo "Object matched?: ".($this->obj === $obj)."\r\n";
echo $this->obj." ".$obj."\r\n";
}
}
$abc = new abc();
$obj = new bla();
$abc->put($obj);
?>
Expected result:
That the operation $this->obj === $obj is true.
Actual result:
--
$this->obj and $obj mismatch.
--
Edit this bug report at http://bugs.php.net/?id=36487&edit=1
#40899 [NEW]: memory leak when nesting list()
From: cweiske at cweiske dot de
Operating system: Linux
PHP version: 5.2.1
PHP Bug Type: Arrays related
Bug description: memory leak when nesting list()
Description:
I get memory leaks when nesting list() statements to assign array
variables to local variables. I get no leaks if list() is not nested.
Reproduce code:
---
php -a
Interactive shell
php > list(list($a,$b),$c)=array(array('a','b'),'c');
php > quit
Expected result:
Nothing.
Actual result:
--
[Fri Mar 23 08:28:26 2007] Script: '-'
/var/tmp/portage/dev-lang/php-5.2.1-r3/work/php-5.2.1/Zend/zend_vm_execute.h(3533)
: Freeing 0x08923060 (16 bytes), script=-
Last leak repeated 1 time
[Fri Mar 23 08:28:26 2007] Script: '-'
/var/tmp/portage/dev-lang/php-5.2.1-r3/work/php-5.2.1/Zend/zend_vm_execute.h(6308)
: Freeing 0x0892323C (16 bytes), script=-
[Fri Mar 23 08:28:26 2007] Script: '-'
/var/tmp/portage/dev-lang/php-5.2.1-r3/work/php-5.2.1/Zend/zend_vm_execute.h(3578)
: Freeing 0x08923620 (44 bytes), script=-
/var/tmp/portage/dev-lang/php-5.2.1-r3/work/php-5.2.1/Zend/zend_API.c(819)
: Actual location (location was relayed)
Last leak repeated 1 time
[Fri Mar 23 08:28:26 2007] Script: '-'
/var/tmp/portage/dev-lang/php-5.2.1-r3/work/php-5.2.1/Zend/zend_variables.h(45)
: Freeing 0x089236C4 (2 bytes), script=-
/var/tmp/portage/dev-lang/php-5.2.1-r3/work/php-5.2.1/Zend/zend_variables.c(120)
: Actual location (location was relayed)
Last leak repeated 1 time
[Fri Mar 23 08:28:26 2007] Script: '-'
/var/tmp/portage/dev-lang/php-5.2.1-r3/work/php-5.2.1/Zend/zend_vm_execute.h(3564)
: Freeing 0x089236F4 (35 bytes), script=-
/var/tmp/portage/dev-lang/php-5.2.1-r3/work/php-5.2.1/Zend/zend_hash.c(388)
: Actual location (location was relayed)
Last leak repeated 1 time
=== Total 9 memory leaks detected ===
--
Edit bug report at http://bugs.php.net/?id=40899&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=40899&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=40899&r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=40899&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=40899&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=40899&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=40899&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=40899&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=40899&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=40899&r=support
Expected behavior:http://bugs.php.net/fix.php?id=40899&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=40899&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=40899&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=40899&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=40899&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=40899&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=40899&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=40899&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=40899&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=40899&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=40899&r=mysqlcfg
