#30920 [Opn->Bgs]: SimpleXML : tags with "xs:" prefix
ID: 30920 Updated by: [EMAIL PROTECTED] Reported By: hieu at laposte dot net -Status: Open +Status: Bogus Bug Type: XML related Operating System: windows xp PHP Version: 5.0.2 New Comment: print_r and var_dump don't work reliably on simplexml objects... do *not* use them or even rely on them... And see http://www.zend.com/php5/articles/php5-simplexml.php for more info about SimpleXML and Namespaces Previous Comments: [2004-11-27 17:55:59] hieu at laposte dot net Description: When the xml file contains this "xs:" prefix, the file is not correctly parsed. Reproduce code: --- The XML file is : http://www.w3.org/2001/XMLSchema"; xmlns:msdata="urn:schemas-microsoft-com:xml-msdata"> data:IsDataSet="true"; msdata:Locale="fr-FR";> ... Php 5 code : $oXml = simplexml_load_file($sFileName); print_r($oXml->element); // doesn't work, nothing printed... PS : this code works correctly : $oXml = simplexml_load_file($sFileName); $aXml = get_object_vars($oXml); print_r($aXml['element']); // ok i can now access the "element". Expected result: SimpleXMLElement Object ( [complexType] => SimpleXMLElement Object ( . ) ) Actual result: -- SimpleXMLElement Object ( ) -- Edit this bug report at http://bugs.php.net/?id=30920&edit=1
#30346 [Opn]: arrayAcces & using $this
ID: 30346
Updated by: [EMAIL PROTECTED]
Reported By: profic at kursknet dot ru
Status: Open
Bug Type: Zend Engine 2 problem
Operating System: *
PHP Version: 5.0.2
New Comment:
Well, no, not exactly. HEAD segfaults for me with this code:
Starting program: /home/dev/php-src/sapi/cli/php -f /www/index.php
Z
Warning: String is not zero-terminated (ZZ└ë▐*)
(source: /home/dev/php-src/Zend/zend_variables.h:35) in /www/index.php
on line 12
[Sun Nov 28 15:28:18 2004] Script: '/www/index.php'
---
/home/dev/php-src/Zend/zend_vm_execute.h(6619) : Block 0xBFFFB4D8
status:
/home/dev/php-src/Zend/zend_execute.h(64) : Actual location (location
was relayed)
Beginning: Overrun (magic=0x0069, expected=0x7312F8DC)
Program received signal SIGSEGV, Segmentation fault.
0x4207c5ac in memcpy () from /lib/tls/libc.so.6
(gdb) bt
#0 0x4207c5ac in memcpy () from /lib/tls/libc.so.6
#1 0x081bb0af in _mem_block_check (ptr=0xbfffb4fc, silent=0,
__zend_filename=0x8291260 "/home/dev/php-src/Zend/zend_vm_execute.h",
__zend_lineno=6619,
__zend_orig_filename=0x828c000
"/home/dev/php-src/Zend/zend_execute.h", __zend_orig_lineno=64) at
/home/dev/php-src/Zend/zend_alloc.c:737
#2 0x081bb07b in _mem_block_check (ptr=0xbfffb4fc, silent=1,
__zend_filename=0x8291260 "/home/dev/php-src/Zend/zend_vm_execute.h",
__zend_lineno=6619,
__zend_orig_filename=0x828c000
"/home/dev/php-src/Zend/zend_execute.h", __zend_orig_lineno=64) at
/home/dev/php-src/Zend/zend_alloc.c:729
#3 0x081ba0de in _efree (ptr=0xbfffb4fc, __zend_filename=0x8291260
"/home/dev/php-src/Zend/zend_vm_execute.h", __zend_lineno=6619,
__zend_orig_filename=0x828c000
"/home/dev/php-src/Zend/zend_execute.h", __zend_orig_lineno=64) at
/home/dev/php-src/Zend/zend_alloc.c:287
#4 0x081ca5ca in safe_free_zval_ptr_rel (p=0xbfffb4fc,
__zend_filename=0x8291260 "/home/dev/php-src/Zend/zend_vm_execute.h",
__zend_lineno=6619,
__zend_orig_filename=0x828bb20
"/home/dev/php-src/Zend/zend_execute_API.c", __zend_orig_lineno=392) at
zend_execute.h:64
#5 0x081c77ac in _zval_ptr_dtor (zval_ptr=0xbfffb428,
__zend_filename=0x8291260 "/home/dev/php-src/Zend/zend_vm_execute.h",
__zend_lineno=6619)
at /home/dev/php-src/Zend/zend_execute_API.c:392
#6 0x0820d6c1 in ZEND_ECHO_SPEC_VAR_HANDLER (execute_data=0xbfffb810)
at zend_vm_execute.h:6619
#7 0x081fc5ad in execute (op_array=0x834bca4) at zend_vm_execute.h:58
#8 0x081d59fa in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /home/dev/php-src/Zend/zend.c:1053
#9 0x0818d3ca in php_execute_script (primary_file=0xbfffdc20) at
/home/dev/php-src/main/main.c:1635
#10 0x0824fc2f in main (argc=3, argv=0xbfffdcb4) at
/home/dev/php-src/sapi/cli/php_cli.c:943
In the same time, 5_0 works fine, printing "page_show".
Previous Comments:
[2004-10-26 20:27:57] [EMAIL PROTECTED]
Thanks for the script.
The issue is fixed in 5.1 - i'll give 5.0 a try.
[2004-10-26 12:16:41] benneh at gmail dot com
I've just run into this, however I've managed to reduce to a test case
with out extended classes. It should be the same thing as the crash
like yours appears to be caused by concatenating in the array index.
Minimal Testcase :
--
class Post_Header implements ArrayAccess {
public function __construct() { }
public function offsetExists( $offset ) { return false; }
public function offsetGet( $offset ) { return $offset; }
public function offsetSet( $offset, $data ) { }
public function offsetUnset( $offset ) { }
}
$post = new Post_Header;
$id = 'page';
echo $post[$id.'_show'];
Expected Results :
--
Test
Actual Results :
Crashes on the last line
Hope this more minimal testcase helps.
[2004-10-24 14:08:23] [EMAIL PROTECTED]
Segfaults only with 5.0.x.
5.1 works fine (i.e. gives expected result and doesn't segfault).
bt:
Program received signal SIGSEGV, Segmentation fault.
0x08175639 in _efree (ptr=0xbfffcc28) at
/home/dev/php-src_5_0/Zend/zend_alloc.c:281
281 REMOVE_POINTER_FROM_LIST(p);
(gdb) bt
#0 0x08175639 in _efree (ptr=0xbfffcc28) at
/home/dev/php-src_5_0/Zend/zend_alloc.c:281
#1 0x081802b1 in _zval_ptr_dtor (zval_ptr=0xbfffcc28) at
zend_execute.h:61
#2 0x08180ccc in zend_call_function (fci=0xbfffc8c0,
fci_cache=0xbfffc8a0, tsrm_ls=0x82370b0) at zend_execute.h:124
#3 0x0819879f in zend_call_method (object_pp=0xbfffc980,
obj_ce=0x82ea01c, fn_proxy=0x0, function_name=0x81e9cb4 "offsetget",
function_name_len=9,
retval_ptr_ptr=0xbfffc94c, param_count=-1073753328,
arg1=0xbfffcc28, arg2=0x0, tsrm_ls=0x82370b0) at
/home/dev/php-src_5_0/Zend/zend_interfaces.c:79
#4 0x0819b77b in zend_std_read_dimensio
#30346 [Opn->Asn]: arrayAcces & using $this
ID: 30346
Updated by: [EMAIL PROTECTED]
Reported By: profic at kursknet dot ru
-Status: Open
+Status: Assigned
Bug Type: Zend Engine 2 problem
Operating System: *
PHP Version: 5.0.2
-Assigned To:
+Assigned To: helly
Previous Comments:
[2004-11-28 13:31:48] [EMAIL PROTECTED]
Well, no, not exactly. HEAD segfaults for me with this code:
Starting program: /home/dev/php-src/sapi/cli/php -f /www/index.php
Z
Warning: String is not zero-terminated (ZZ└ë▐*)
(source: /home/dev/php-src/Zend/zend_variables.h:35) in /www/index.php
on line 12
[Sun Nov 28 15:28:18 2004] Script: '/www/index.php'
---
/home/dev/php-src/Zend/zend_vm_execute.h(6619) : Block 0xBFFFB4D8
status:
/home/dev/php-src/Zend/zend_execute.h(64) : Actual location (location
was relayed)
Beginning: Overrun (magic=0x0069, expected=0x7312F8DC)
Program received signal SIGSEGV, Segmentation fault.
0x4207c5ac in memcpy () from /lib/tls/libc.so.6
(gdb) bt
#0 0x4207c5ac in memcpy () from /lib/tls/libc.so.6
#1 0x081bb0af in _mem_block_check (ptr=0xbfffb4fc, silent=0,
__zend_filename=0x8291260 "/home/dev/php-src/Zend/zend_vm_execute.h",
__zend_lineno=6619,
__zend_orig_filename=0x828c000
"/home/dev/php-src/Zend/zend_execute.h", __zend_orig_lineno=64) at
/home/dev/php-src/Zend/zend_alloc.c:737
#2 0x081bb07b in _mem_block_check (ptr=0xbfffb4fc, silent=1,
__zend_filename=0x8291260 "/home/dev/php-src/Zend/zend_vm_execute.h",
__zend_lineno=6619,
__zend_orig_filename=0x828c000
"/home/dev/php-src/Zend/zend_execute.h", __zend_orig_lineno=64) at
/home/dev/php-src/Zend/zend_alloc.c:729
#3 0x081ba0de in _efree (ptr=0xbfffb4fc, __zend_filename=0x8291260
"/home/dev/php-src/Zend/zend_vm_execute.h", __zend_lineno=6619,
__zend_orig_filename=0x828c000
"/home/dev/php-src/Zend/zend_execute.h", __zend_orig_lineno=64) at
/home/dev/php-src/Zend/zend_alloc.c:287
#4 0x081ca5ca in safe_free_zval_ptr_rel (p=0xbfffb4fc,
__zend_filename=0x8291260 "/home/dev/php-src/Zend/zend_vm_execute.h",
__zend_lineno=6619,
__zend_orig_filename=0x828bb20
"/home/dev/php-src/Zend/zend_execute_API.c", __zend_orig_lineno=392) at
zend_execute.h:64
#5 0x081c77ac in _zval_ptr_dtor (zval_ptr=0xbfffb428,
__zend_filename=0x8291260 "/home/dev/php-src/Zend/zend_vm_execute.h",
__zend_lineno=6619)
at /home/dev/php-src/Zend/zend_execute_API.c:392
#6 0x0820d6c1 in ZEND_ECHO_SPEC_VAR_HANDLER (execute_data=0xbfffb810)
at zend_vm_execute.h:6619
#7 0x081fc5ad in execute (op_array=0x834bca4) at zend_vm_execute.h:58
#8 0x081d59fa in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /home/dev/php-src/Zend/zend.c:1053
#9 0x0818d3ca in php_execute_script (primary_file=0xbfffdc20) at
/home/dev/php-src/main/main.c:1635
#10 0x0824fc2f in main (argc=3, argv=0xbfffdcb4) at
/home/dev/php-src/sapi/cli/php_cli.c:943
In the same time, 5_0 works fine, printing "page_show".
[2004-10-26 20:27:57] [EMAIL PROTECTED]
Thanks for the script.
The issue is fixed in 5.1 - i'll give 5.0 a try.
[2004-10-26 12:16:41] benneh at gmail dot com
I've just run into this, however I've managed to reduce to a test case
with out extended classes. It should be the same thing as the crash
like yours appears to be caused by concatenating in the array index.
Minimal Testcase :
--
class Post_Header implements ArrayAccess {
public function __construct() { }
public function offsetExists( $offset ) { return false; }
public function offsetGet( $offset ) { return $offset; }
public function offsetSet( $offset, $data ) { }
public function offsetUnset( $offset ) { }
}
$post = new Post_Header;
$id = 'page';
echo $post[$id.'_show'];
Expected Results :
--
Test
Actual Results :
Crashes on the last line
Hope this more minimal testcase helps.
[2004-10-24 14:08:23] [EMAIL PROTECTED]
Segfaults only with 5.0.x.
5.1 works fine (i.e. gives expected result and doesn't segfault).
bt:
Program received signal SIGSEGV, Segmentation fault.
0x08175639 in _efree (ptr=0xbfffcc28) at
/home/dev/php-src_5_0/Zend/zend_alloc.c:281
281 REMOVE_POINTER_FROM_LIST(p);
(gdb) bt
#0 0x08175639 in _efree (ptr=0xbfffcc28) at
/home/dev/php-src_5_0/Zend/zend_alloc.c:281
#1 0x081802b1 in _zval_ptr_dtor (zval_ptr=0xbfffcc28) at
zend_execute.h:61
#2 0x08180ccc in zend_call_function (fci=0xbfffc8c0,
fci_cache=0xbfffc8a0, tsrm_ls=0x82370b0) at zend_execute.h:124
#3 0x0819879f in zend_call_method (object_pp=0xbfffc980,
obj_ce=0x82ea01c, fn_proxy=0x0, function_name=0x81e9cb4 "offsetget",
function_name_len=9,
retval_ptr_ptr=
#30333 [Opn->Fbk]: fscanf() and() not working correctly with other then English language
ID: 30333 Updated by: [EMAIL PROTECTED] Reported By: altuhov at nm dot ru -Status: Open +Status: Feedback Bug Type: Filesystem function related Operating System: WinXP SP2 PHP Version: 5.1.0-dev New Comment: Do you still expirience this problem? Previous Comments: [2004-10-23 16:00:46] profic at nospam dot kursknet dot ru Hm, russian letters converts to it's codes. I think this is even better then looking at ugly characters =) [2004-10-23 15:53:35] profic at nospam dot kursknet dot ru E:\>ver Microsoft Windows XP [Version 5.1.2600] E:\>php -v PHP 5.0.2 (cli) (built: Sep 24 2004 01:25:41) Copyright (c) 1997-2004 The PHP Group Zend Engine v2.0.2, Copyright (c) 1998-2004 Zend Technologies with DBG v2.11.30, (C) 2000,2004, by Dmitri Dmitrienko E:\>chcp 866 Active code page: 866 E:\>php ^Z Array ( [0] => проверка [1] => проверка [2] => проверка ) E:\>chcp 1251 Active code page: 1251 E:\>php ^Z Array ( [0] => пр [1] => в [2] => р ) E:\>php ^Z string(19) "Russian_Russia.1251" Array ( [0] => пр [1] => вер [2] => а ) E:\>php test.php string(19) "Russian_Russia.1251" Array ( [0] => пр [1] => в [2] => р ) E:\> Some comments to listing above: All text here is in cp1251 (windows-1251). There are 2 codepages for russian in windows: cp866 (aka OEM/DOS) and cp1251 (aka ANSI/Windows). As Windows' console can change current input/output codepage on fly, it seems to explain this bug, as with cp866 it works well and it is default console (in which php-cli is runing), but with cp1251 does not. But last 2 examples seems strange as locale is setted exactly. The test.php file is copy of the last inline PHP-code [2004-10-12 19:47:32] altuhov at nm dot ru Yes. Windows-1251. Reproduce code was writed and saved in the "Notepad". [2004-10-12 19:40:43] [EMAIL PROTECTED] Is the russian locale used by winxp the same locale as the one used by the document? [2004-10-07 08:23:18] altuhov at nm dot ru Yes. Windows XP SP2 English version, but Russian locale. 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/30333 -- Edit this bug report at http://bugs.php.net/?id=30333&edit=1
#30329 [Opn->Asn]: Error Fetching http body, No Content-Length, connection closed or chunked data
ID: 30329
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Assigned
Bug Type: SOAP related
Operating System: Solaris 9
PHP Version: 5.0.2
-Assigned To:
+Assigned To: dmitry
Previous Comments:
[2004-10-05 15:02:48] [EMAIL PROTECTED]
incorrect. The EAServer does respond with HTTP/1.0. And in HTTP/1.0 you
can leave out the Content-Length (if unknown), because chunked encoding
cannot be used with 1.0
[2004-10-05 14:50:22] [EMAIL PROTECTED]
I don't think we should add workarounds around other buggy products.
This is violating the RFC iirc.
[2004-10-05 14:45:17] [EMAIL PROTECTED]
The problem also sometimes occurs even with HTTP/1.0. After checking
this, it seems that EAServer does not send a Content-Length! Can we
change this in a way that get_http_body also accepts a zero
content-length?
[2004-10-05 13:57:07] [EMAIL PROTECTED]
Description:
I get the error message "Error Fetching http body, No Content-Length,
connection closed or chunked data [faultcode]" when try to communicate
with Sybase EAServer via SOAP.
When redirecting the web services via a Proxy-Plugin in an iPlanet
webserver everything works ok.
It seems that EAServer sends some bad encoded HTTP body.
When changing the SOAP extension code to only support HTTP/1.0,
everything works.
How about introducing an additional option to SoapClient named
"http_version" that can be set to 1.1 or 1.0 (default 1.1). At this
time "1.1" is hardcoded into php_http.c.
When 1.0 is on, "Connection:" should be assumed as "close".
Something other:
If the extension CURL is used, why not use CURL for sending SOAP
requests?
Reproduce code:
---
SOAP Test
http://ws.pangaea.de:8084/ws/services/WebServices?wsdl",array('trace'=>TRUE));
try {
$res=$ws->metadata("10.1594/PANGAEA/206854");
} catch (SoapFault $sf) {
echo "".print_r($sf)."";
}
echo
"Request".htmlspecialchars($ws->__getLastRequest())."Response".htmlspecialchars($ws->__getLastResponse())."";
echo "Decoded";
print_r($res);
?>
Expected result:
no SoapFault
--
Edit this bug report at http://bugs.php.net/?id=30329&edit=1
#30326 [Opn->Fbk]: "zip_open" cannot open file
ID: 30326
Updated by: [EMAIL PROTECTED]
Reported By: adamsbarker at hotmail dot com
-Status: Open
+Status: Feedback
Bug Type: ZZiplib Related
Operating System: Windows XP
PHP Version: 5.0.2
New Comment:
Please, check that your web-server has all necessary NTFS permissions
to read this file.
Previous Comments:
[2004-10-07 01:13:16] adamsbarker at hotmail dot com
This is how i've done it:
- my home directory is "D:\home"
- both "open_zip.php" AND "abc.zip" are in "D:\home"
- zip_open('D:\home\abc.zip');
- this works perfectly
- zip_open('abc.zip');
- has this error:
Warning: zip_open() [function.zip-open]: Cannot open zip archive
abc.zip in D:\home\open_zip.php on line 3
- echo getcwd(); => produces this:
D:\home
i hope this makes sense :)
[2004-10-06 11:22:00] [EMAIL PROTECTED]
it probably means that the working directory is different then you
think it is. What does echo getcwd(); output?
[2004-10-06 11:19:50] adamsbarker at hotmail dot com
yes, both the "php" and "zip" files are in the same directory... i
completely removed php and got copies of the latest stable version/PECL
extensions for Windows, but still the same problem... this problem seems
to be running throughout the versions, since i first noticed it a couple
of months ago.
[2004-10-06 01:17:29] [EMAIL PROTECTED]
Is the script being ran from the same directory as the one where the
zip file is?
[2004-10-05 02:45:02] adamsbarker at hotmail dot com
Description:
when using the following code:
zip_open('file_name.zip');
i get the following error:
Warning: zip_open() [function.zip-open]: Cannot open zip archive
file_name.zip in C:\test.php on line 1
the "zip file" and "php script" are in the same directory
when i put in the full directory of the zip file, such as
"C:\file_name.zip", the file is opened and everything works as
expected.
i don't think this should be how it works as all other functions (ie,
include()) don't need the full directory!
i am using the latest stable version 5.0.3-dev and PECL extensions
--
Edit this bug report at http://bugs.php.net/?id=30326&edit=1
#30314 [Opn->Csd]: php.ini documentation about E_All/E_Strict confusing.
ID: 30314 Updated by: [EMAIL PROTECTED] Reported By: empx at gmx dot de -Status: Open +Status: Closed Bug Type: Unknown/Other Function Operating System: Windows PHP Version: 5.0.2 New Comment: This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. Previous Comments: [2004-10-05 13:12:50] [EMAIL PROTECTED] The documentation is right (E_ALL doesn't include E_STRICT). Now its up with the developers if they want to change the php.ini file or not. Nuno [2004-10-03 00:20:28] empx at gmx dot de Description: While the online documentation says E_ALL does not include E_STRICT, (which is probably correct :), when you read the docs/examples about error-reporting in the php.ini(-dist/-recommended), you get the impression that E_ALL does include E_STRICT too. Examples: ; E_ALL - All errors and warnings should get updated to something like: ; E_ALL - All errors and warnings, except E_Strict ; - Show all errors, except for notices and coding standards warnings ; ;error_reporting = E_ALL & ~E_NOTICE & ~E_STRICT If E_ALL does not include E_STRICT, then " & ~E_STRICT" shouldn't be needed here, right? regards, Mike -- Edit this bug report at http://bugs.php.net/?id=30314&edit=1
#30264 [Opn->Fbk]: headers_sent() reporting incorrect value
ID: 30264 Updated by: [EMAIL PROTECTED] Reported By: mpn at illearth dot net -Status: Open +Status: Feedback Bug Type: Output Control Operating System: Win NT(2K) PHP Version: 4.3.9 New Comment: I can't reproduce your problem. headers_sent() reports correct value in any situation when running your reproduce script. Previous Comments: [2004-10-01 05:12:14] mpn at illearth dot net OK, yes output buffering in the ini is set to the default of 4096. So based on what I am seeing (i.e. ouput in the browser), the buffer is being flushed at 4096 bytes, however the value of headers_sent() is still FALSE, even though it appears the buffer has been flushed at least once, if not several times at the point of the exit. Now what is even more quirky is I can clean and shutdown all the buffers prior to the exit in the error handler and I will not get any screen output in the browser. When doing this the value of headers_sent() is still FALSE. This suggests the buffer has not been flushed at it's default flush point. So two senarios exist here: 1) Do NOT clean and shutdown the buffers and I get output in the browser up to the point of the fatal error exit in the error handler. The value of headers_sent() is FALSE. 2) Clean and shutdown all buffers at the point of the fatal error exit in the error handler, no output to the browser has been sent. The value of headers_sent() is FALSE. In the first senario, the value of headers_sent() should be TRUE since I am seeing intended output in the browser. [2004-10-01 05:12:14] mpn at illearth dot net OK, yes output buffering in the ini is set to the default of 4096. So based on what I am seeing (i.e. ouput in the browser), the buffer is being flushed at 4096 bytes, however the value of headers_sent() is still FALSE, even though it appears the buffer has been flushed at least once, if not several times at the point of the exit. Now what is even more quirky is I can clean and shutdown all the buffers prior to the exit in the error handler and I will not get any screen output in the browser. When doing this the value of headers_sent() is still FALSE. This suggests the buffer has not been flushed at it's default flush point. So two senarios exist here: 1) Do NOT clean and shutdown the buffers and I get output in the browser up to the point of the fatal error exit in the error handler. The value of headers_sent() is FALSE. 2) Clean and shutdown all buffers at the point of the fatal error exit in the error handler, no output to the browser has been sent. The value of headers_sent() is FALSE. In the first senario, the value of headers_sent() should be TRUE since I am seeing intended output in the browser. [2004-09-30 22:45:44] [EMAIL PROTECTED] If you are using default config you probably have output buffering enabled, which makes PHP buffer output data in 4096 chunks. [2004-09-30 16:11:04] mpn at illearth dot net Let me put this into the context of the problem I am having. I am using a custom error handler. At the error threshold where script execution will exit I need to check if headers had been sent in order to determine if output compression needs to be enabled and buffers cleaned/shutoff. Apparently stacking compressed output buffers (even if they have been "cleaned" of content) is restricted since it destroys the output (i.e. the browser shows compressed output). This may be a bug in itself since according to documentation output buffers are stackable with no mention of any restrictions. So let's take it step by step. 1) script excution starts 2) get support includes 3) start output (i.e. headers are set, ouput buffering started, output content printed/echoed). 4) Trigger a fatal exit error. 5) var_dump the return of headers_sent() and exit prior to sending any error messages to the browser or flushing any buffers. At this point the normal expected output, up to the point of the error, has been sent to the browser, however the value of headers_sent() is still FALSE even though I am looking at the expected output in the browser, with the variable dump value at the bottom of that output where the exit occurs. [2004-09-30 06:34:24] mpn at illearth dot net "When you use compression the entire page is buffered in memory, until end of the request." The second test example does not use any compression and I stated in the first example that the returned result was the same regards of where output buffering was started, or for that matter even used. I agree it is not a "bug" in that it's returning what it should based
#30266 [Asn->Fbk]: Invalid opcode 137/1/8
ID: 30266
Updated by: [EMAIL PROTECTED]
Reported By: sorin at intersol dot ro
-Status: Assigned
+Status: Feedback
Bug Type: Reproducible crash
Operating System: WinXP
PHP Version: 5.0.2
Assigned To: andi
New Comment:
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external
resources such as databases, etc.
If possible, make the script source available online and provide
an URL to it here. Try avoid embedding huge scripts into the report.
Previous Comments:
[2004-09-29 18:24:58] [EMAIL PROTECTED]
Can you please post a working piece of reproducing code? Preferably no
more than 20 lines.
Thanks.
[2004-09-28 20:46:14] sorin at intersol dot ro
Description:
Very basic use test of adodb generate a complete crash on 5.0.2 and
last build PHP 5.1.0-dev (cli) (built: Sep 28 2004 16:26:27)
gives this:
Invalid opcode 137/1/8 in adodb-xmlschema.inc.php.
Runing php with -e parameters makes no difference.
Reproduce code:
---
function _tag_close( &$parser, $tag ) {
>> $this->currentElement = '';
switch( strtoupper( $tag ) ) {
case 'TABLE':
$this->parent->addSQL(
Expected result:
Anything but not a crash?!
--
Edit this bug report at http://bugs.php.net/?id=30266&edit=1
#30161 [Opn->Fbk]: Segmentation fault with exceptions
ID: 30161 Updated by: [EMAIL PROTECTED] Reported By: guth at fiifo dot u-psud dot fr -Status: Open +Status: Feedback Bug Type: Zend Engine 2 problem Operating System: Linux (mandrake 10) PHP Version: 5.0.1 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php5-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.0-win32-latest.zip Can't reproduce the segfault. It doesn't output anything, but doesn't segfault too. Previous Comments: [2004-10-12 10:30:33] guth at fiifo dot u-psud dot fr Same behaviour with the latest cvs (php 5.1.0-dev)... [2004-10-11 07:57:01] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip [2004-10-10 00:29:38] guth at fiifo dot u-psud dot fr In fact, this code segfault if you add : "var_dump($db);" before "echo $db;" Without the var_dump, "echo $db;" prints nothing. [2004-09-20 09:32:51] guth at fiifo dot u-psud dot fr Description: The following code segfaults. Reproduce code: --- Expected result: No segfault but something like that: Rusticus in asino sedet. Actual result: -- FATAL: erealloc(): Unable to allocate 1515872257 bytes [Sat Sep 18 21:18:11 2004] [notice] child pid 3512 exit signal Segmentation fault (11) (gdb) bt #0 0xe410 in ?? () #1 0xbfffcb78 in ?? () #2 0x404354a0 in __JCR_LIST__ () from /usr/local/apache/libexec/libphp5.so #3 0x000b in ?? () #4 0x400c7a76 in kill () from /lib/tls/libc.so.6 #5 0x4038a6ad in _erealloc (ptr=0x81630ec, size=1515872257, allow_failure=0, __zend_filename=0x40402140 "/usr/src/php-5.0.1/main/output.c", __zend_lineno=392, __zend_orig_filename=0x0, __zend_orig_lineno=0) at /usr/src/php-5.0.1/Zend/zend_alloc.c:350 #6 0x4036e2d4 in php_ob_allocate (text_length=1515870810) at /usr/src/php-5.0.1/main/output.c:392 #7 0x4036e1d4 in php_ob_append (text=0x0, text_length=1515870810) at /usr/src/php-5.0.1/main/output.c:598 #8 0x4036d4b1 in php_b_body_write (str=0x0, str_length=1515870810) at /usr/src/php-5.0.1/main/output.c:670 #9 0x4036c149 in php_body_write (str=0x0, str_length=1515870810) at /usr/src/php-5.0.1/main/output.c:119 #10 0x4035da8c in php_body_write_wrapper (str=0x0, str_length=1515870810) at /usr/src/php-5.0.1/main/main.c:1242 #11 0x403a3d0c in zend_print_zval_ex (write_func=0x4035da6b , expr=0xbfffcc70, indent=0) at /usr/src/php-5.0.1/Zend/zend.c:289 #12 0x403a3c8a in zend_print_zval (expr=0x8164f5c, indent=0) at /usr/src/php-5.0.1/Zend/zend.c:270 #13 0x403a341c in zend_print_variable (var=0x8164f5c) at /usr/src/php-5.0.1/Zend/zend_variables.c:168 #14 0x403ca2bd in zend_echo_handler (execute_data=0xbfffce40, opline=0x8169610, op_array=0x8164e6c) at /usr/src/php-5.0.1/Zend/zend_execute.c:1986 #15 0x403c8c96 in execute (op_array=0x8164e6c) at /usr/src/php-5.0.1/Zend/zend_execute.c:1400 #16 0x403a54f5 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /usr/src/php-5.0.1/Zend/zend.c:1061 #17 0x4035e49e in php_execute_script (primary_file=0xb1b0) at /usr/src/php-5.0.1/main/main.c:1627 #18 0x403d4b94 in apache_php_module_main (r=0x815a09c, display_source_mode=0) at /usr/src/php-5.0.1/sapi/apache/sapi_apache.c:54 #19 0x403d5b1f in send_php (r=0x815a09c, display_source_mode=0, filename=0x815aba4 "/www/test.php") at /usr/src/php-5.0.1/sapi/apache/mod_php5.c:622 #20 0x403d5b98 in send_parsed_php (r=0x815a09c) at /usr/src/php-5.0.1/sapi/apache/mod_php5.c:637 #21 0x08071e77 in ap_invoke_handler () #22 0x08086ebd in process_request_internal () #23 0x08086f1c in ap_process_request () #24 0x0807df40 in child_main () #25 0x0807e0e8 in make_child () #26 0x0807e24e in startup_children () #27 0x0807e90e in standalone_main () #28 0x0807f12c in main () -- Edit this bug report at http://bugs.php.net/?id=30161&edit=1
#30188 [Opn->Bgs]: open_basedir check is badly performed under some circumstances
ID: 30188
Updated by: [EMAIL PROTECTED]
Reported By: lists+php at box dot cz
-Status: Open
+Status: Bogus
Bug Type: Filesystem function related
Operating System: Linux (Gentoo, latest)
PHP Version: 5.0.1
New Comment:
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
"When a script tries to open a file with, for example, fopen() or
gzopen(), the location of the file is checked. When the file is outside
the specified directory-tree, PHP will refuse to open it. ->All symbolic
links are resolved, so it's not possible to avoid this restriction with
a symlink.<-"
http://www.php.net/manual/en/features.safe-mode.php#ini.open-basedir
You have to copy file to "/home/wejn/x/docs1/html/" instead of it's
symlink if want open_basedir to work properly.
Previous Comments:
[2004-10-14 12:10:46] lists+php at box dot cz
> > Maybe it would be better to perform open_basedir check
> > just on dirs
> > instead of files (in various filesystem functions)?
> No, because it's sometimes vital to have files in
> open_basedir to allow acces to one specific file without
> the need to put it into a directory for its own.
OK ... but the rest still applies. The code is obviously broken. And
sorry, folks @ php.net ... but if I would ever use PHP in production, I
would expect bugs to be solved in timely fashion, not after 6 months of
waiting as "open" (or even not solved at all).
It imho says all the "right" things about PHP - it's still toy, it has
(almost) no support, nobody really cares about users' aches, ...
It's simply another hack-it-yourself-or-shut-up thingie ... but I'm
probably crying on wrong shoulder here, anyway. :)
[2004-10-14 11:51:28] evp at heise dot de
> Maybe it would be better to perform open_basedir check just
> on dirs
> instead of files (in various filesystem functions)?
No, because it's sometimes vital to have files in open_basedir to allow
acces to one specific file without the need to put it into a directory
for its own.
[2004-09-21 23:50:28] lists+php at box dot cz
Description:
My setup:
document root is: "/home/wejn/x/docs/html/".
While "/home/wejn/x/docs/html/" is symlink to:
"/home/wejn/x/docs1/html/".
I have safe_mode enabled and open_basedir set to
"/home/wejn/x/docs/html:/home/wejn/x/docs1/html".
With this setup I'm unable to perform:
copy("/home/wejn/x/docs/html/x", "/home/wejn/x/docs/html/y");
when "y" doesn't exist. If I touch "y" prior running the
script, everything runs just fine.
IMO, there is problem with symlink resolving code somewhere under
php_check_specific_open_basedir().
It seems to me that more precise location of the bug is somewhere in
virtual_file_ex() regarding the realpath() call.
Maybe it would be better to perform open_basedir check just on dirs
instead of files (in various filesystem functions)?
Btw, this problem exists also in 4.3.8, which makes me think that it's
there for a LONG time ... unnoticed.
W.
Reproduce code:
---
// when all conditions described above are met, this fails:
copy('/home/wejn/x/docs/html/x', '/home/wejn/x/docs/html/y');
Expected result:
no error.
Actual result:
--
Warning: copy() [function.copy]: open_basedir restriction in effect.
File(/home/wejn/x/docs/html/y) is not within the allowed path(s):
(/home/wejn/x/docs/html:/home/wejn/x/docs1/html) in
/home/wejn/x/docs1/html/index.html on line 2
Warning: copy(/home/wejn/x/docs/html/y) [function.copy]: failed to open
stream: Operation not permitted in /home/wejn/x/docs1/html/index.html on
line 2
--
Edit this bug report at http://bugs.php.net/?id=30188&edit=1
#30128 [Opn->Fbk]: segmentation fault in the child class catch
ID: 30128
Updated by: [EMAIL PROTECTED]
Reported By: dankab at infinito dot it
-Status: Open
+Status: Feedback
Bug Type: Zend Engine 2 problem
Operating System: linux
PHP Version: 5.0.1
New Comment:
Please try using this CVS snapshot:
http://snaps.php.net/php5-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.0-win32-latest.zip
Seems to be fixed, please try CVS snapshot.
Previous Comments:
[2004-10-13 22:52:40] [EMAIL PROTECTED]
Not Apache-specific. Here's the backtrace into Zend from the cli:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 182931956288 (LWP 3400)]
zend_std_read_property (object=0x8db218, member=0x8e5680,
type=9213224)
at /local/jorton/php/HEAD64/Zend/zend_object_handlers.c:222
222 use_get = (zobj->ce->__get && !zobj->in_get);
(gdb) where
#0 zend_std_read_property (object=0x8db218, member=0x8e5680,
type=9213224)
at /local/jorton/php/HEAD64/Zend/zend_object_handlers.c:222
#1 0x005cae4e in execute (op_array=0x7fbfff56d8) at
zend_vm_handlers.h:1469
#2 0x005d49ea in execute (op_array=0x7ac168) at
zend_vm_handlers.h:2242
#3 0x00589db4 in zend_execute_scripts (type=8, retval=0x0,
file_count=3)
at /local/jorton/php/HEAD64/Zend/zend.c:1053
#4 0x0055762f in php_execute_script
(primary_file=0x7fbfffb630)
at /local/jorton/php/HEAD64/main/main.c:1635
#5 0x005f104d in main (argc=3, argv=0x7fbfffb798)
at /local/jorton/php/HEAD64/sapi/cli/php_cli.c:943
(gdb) backtrace full
#0 zend_std_read_property (object=0x8db218, member=0x8e5680,
type=9213224)
at /local/jorton/php/HEAD64/Zend/zend_object_handlers.c:222
zobj = (zend_object *) 0x
tmp_member = {value = {lval = 1, dval =
4.9406564584124654e-324, str = {
val = 0x1 , len = 2}, ht = 0x1, obj =
{handle = 1,
handlers = 0x2}}, refcount = 0, type = 0 '\0', is_ref = 0 '\0'}
retval = (zval **) 0x58f2b7
rv = (zval *) 0x0
property_info = (zend_property_info *) 0x
silent = 0
use_get = 0 '\0'
#1 0x005cae4e in execute (op_array=0x7fbfff56d8) at
zend_vm_handlers.h:1469
tmp = {value = {lval = 548682035520, dval =
2.7108494424067858e-312, str = {
val = 0x7fbfff7140 "\030�\n\226*", len = 5723912}, ht =
0x7fbfff7140, obj = {
handle = 3221188928, handlers = 0x575708}}, refcount = 8044200,
type = 0 '\0',
is_ref = 0 '\0'}
execute_data = {opline = 0x8e5630, function_state =
{function_symbol_table = 0x8c7758,
function = 0x8e3da8, reserved = {0x2a962e6758, 0x8e3ed0,
0x2a962e66c0, 0x58}}, fbc = 0x0,
fbc_constructor = 0x8e0430, op_array = 0x8e3da8, object = 0x0, Ts =
0x7fbfff5660,
CVs = 0x7fbfff5650, original_in_execution = 1 '\001', calling_scope =
0x0,
symbol_table = 0x8c7688, prev_execute_data = 0x7fbfff8ff0}
binary_op = (int (*)(zval *, zval *, zval *)) 0
incdec_op = 0
prop_dim = 9328176
type = 0
#2 0x005d49ea in execute (op_array=0x7ac168) at
zend_vm_handlers.h:2242
calling_symbol_table = (HashTable *) 0x7ac168
execute_data = {opline = 0x8e0430, function_state =
{function_symbol_table = 0x8c7688,
function = 0x8e3da8, reserved = {0x56f660, 0x0, 0x2a962e66c0,
0x58}}, fbc = 0x8e3da8,
fbc_constructor = 0x8e3da8, op_array = 0x8dbd48, object = 0x8db218,
Ts = 0x7fbfff7300,
CVs = 0x7fbfff72f0, original_in_execution = 0 '\0', calling_scope =
0x8e3788,
symbol_table = 0x7ac168, prev_execute_data = 0x0}
binary_op = (int (*)(zval *, zval *, zval *)) 0
incdec_op = 0
prop_dim = 9307184
type = 0
#3 0x00589db4 in zend_execute_scripts (type=8, retval=0x0,
file_count=3)
at /local/jorton/php/HEAD64/Zend/zend.c:1053
files = {{gp_offset = 40, fp_offset = 48, overflow_arg_area =
0x7fbfff9280,
reg_save_area = 0x7fbfff9190}}
i = 1
file_handle = (zend_file_handle *) 0x7fbfffb630
orig_op_array = (zend_op_array *) 0x0
local_retval = (zval *) 0x0
#4 0x0055762f in php_execute_script
(primary_file=0x7fbfffb630)
at /local/jorton/php/HEAD64/main/main.c:1635
orig_bailout = {{__jmpbuf = {7993760, 0, 4469120, 0, 0, 0,
548682052688, 6228305},
__mask_was_saved = 0, __saved_mask = {__val = {0
orig_bailout_set = 1 '\001'
prepend_file_p = (zend_file_handle *) 0x0
append_file_p = (zend_file_handle *) 0x0
prepend_file = {type = 0 '\0', filename = 0x0, opened_path =
0x0, handle = {fd = 0,
fp = 0x0, stream = {handle = 0x0, reader = 0, closer = 0,
interactive = 0}},
free_filename = 0 '\0'}
append_file = {type = 0 '\0', filename = 0x0, opened_path =
0x0, handle = {fd = 0,
fp = 0x0, stream = {handle = 0x0, reader = 0, closer = 0,
interactive = 0}},
free_filename = 0 '\0'}
old_c
#30120 [Opn->Fbk]: imagettftext() and imagettf() has superfluous optional parameter
ID: 30120 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: GD related Operating System: Irrelevant PHP Version: 5.0.1 New Comment: I'm not quite sure I understand what are you talking about, Jakub. Could you plz explain how Ilia could add parameter while he made it optional? Previous Comments: [2004-09-16 17:09:03] [EMAIL PROTECTED] Description: Since PHP 4.3.5 (precisely since patch http://cvs.php.net/diff.php/php-src/ext/gd/gd.c?r1=1.279&r2=1.280&ty=u), these two functions has superfluous optional parameter. -- Edit this bug report at http://bugs.php.net/?id=30120&edit=1
#30085 [Opn->Fbk]: Segmentation fault
ID: 30085
Updated by: [EMAIL PROTECTED]
Reported By: guth at fiifo dot u-psud dot fr
-Status: Open
+Status: Feedback
Bug Type: Zend Engine 2 problem
Operating System: Linux (mandrake 10)
PHP Version: 5.0.1
New Comment:
Please try using this CVS snapshot:
http://snaps.php.net/php5-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.0-win32-latest.zip
I cannot reproduce it. Please, try latest CVS snapshot.
Previous Comments:
[2004-09-14 15:53:48] guth at fiifo dot u-psud dot fr
Description:
(sorry for english...)
here is my fifth segmentation fault in PHP 5...
Reproduce code:
---
test = new test; /* An entire mystery, without this
code, no
segmentation fault */
}
public function __destruct() {
fuck();
/*
If you don't like "fuck()" and if you want a segfault,
you can try
with everything that raise a fatal error. Some examples :
- trigger_error("thamer", E_USER_ERROR);
- unset(self::$thamer);
Warning : no fatal error, no segfault :)
*/
}
}
$test = new thamer;
?>
Expected result:
A fatal error (no segmentation fault...).
Actual result:
--
[Mon Sep 13 22:07:42 2004] [error] PHP Fatal error: Call to undefined
function fuck() in /www/test.php on line 13
/www/test.php(13) : Fatal error - Call to undefined function fuck()
[Mon Sep 13 22:07:43 2004] [notice] child pid 4043 exit signal
Segmentation fault (11)
#0 0x082030bc in zend_objects_destroy_object (object=0x83035dc,
handle=2) at /usr/src/php-5.0.1/Zend/zend_objects.c:37
#1 0x08205be0 in zend_objects_store_del_ref (zobject=0x830359c) at
/usr/src/php-5.0.1/Zend/zend_objects_API.c:144
#2 0x081ed016 in _zval_dtor (zvalue=0x830359c,
__zend_filename=0x8260d40
"/usr/src/php-5.0.1/Zend/zend_execute_API.c",
__zend_lineno=391) at /usr/src/php-5.0.1/Zend/zend_variables.c:61
#3 0x081e1850 in _zval_ptr_dtor (zval_ptr=0x83034f0,
__zend_filename=0x8261c60
"/usr/src/php-5.0.1/Zend/zend_variables.c", __zend_lineno=193)
at /usr/src/php-5.0.1/Zend/zend_execute_API.c:391
#4 0x081ed368 in _zval_ptr_dtor_wrapper (zval_ptr=0x83034f0) at
/usr/src/php-5.0.1/Zend/zend_variables.c:193
#5 0x081f68b8 in zend_hash_destroy (ht=0x830fbc4) at
/usr/src/php-5.0.1/Zend/zend_hash.c:519
#6 0x08203322 in zend_objects_free_object_storage (object=0x831702c)
at /usr/src/php-5.0.1/Zend/zend_objects.c:88
#7 0x0820593d in zend_objects_store_free_object_storage
(objects=0x8285204)
at /usr/src/php-5.0.1/Zend/zend_objects_API.c:72
#8 0x081e137f in shutdown_executor () at
/usr/src/php-5.0.1/Zend/zend_execute_API.c:272
#9 0x081ee9b7 in zend_deactivate () at
/usr/src/php-5.0.1/Zend/zend.c:819
#10 0x081a7648 in php_request_shutdown (dummy=0x0) at
/usr/src/php-5.0.1/main/main.c:1212
#11 0x082204ac in main (argc=2, argv=0xb664) at
/usr/src/php-5.0.1/sapi/cli/php_cli.c:1046
--
Edit this bug report at http://bugs.php.net/?id=30085&edit=1
#30075 [Opn->Fbk]: Cannot redeclare function/class
ID: 30075 Updated by: [EMAIL PROTECTED] Reported By: kj at legalizer dot dk -Status: Open +Status: Feedback Bug Type: Zend Engine 2 problem Operating System: WinXP PHP Version: 5CVS-2004-09-13 (dev) New Comment: Please try using this CVS snapshot: http://snaps.php.net/php5-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.0-win32-latest.zip Please supply short but usable reproduce script if you still expirience this problem even with latest CVS snapshot. Previous Comments: [2004-09-27 09:37:15] kj at legalizer dot dk The IIS 6.0 problem is on a Windows 2003 server. [2004-09-27 09:34:29] kj at legalizer dot dk With PHP 5.0.2 and IIS 6.0 I get the same error (without the crash) even if I turn off ISAPI caching. [2004-09-13 16:38:47] kj at legalizer dot dk It looks like I dont get the error if I turn off ISAPI caching. [2004-09-13 16:29:09] kj at legalizer dot dk Description: After installing PHP 5.0.1 (and latest CVS) I get "Cannot redeclare (previously declared in )" errors at random. Then after a few seconds a window pops up with a dllhost.exe error. Saying somthing like "Memory could not be read". And my IIS chrashes. All this do not happen every time i load the page only sometimes. This did not happen in PHP 5.0.0. Im running PHP as ISAPI. Actual result: -- Fatal error: Cannot redeclare db_connect() (previously declared in D:\HTDocs\BEC\includes\database.inc.php:8) in D:\HTDocs\BEC\includes\database.inc.php on line 10 -- Edit this bug report at http://bugs.php.net/?id=30075&edit=1
#30074 [Opn]: apparent symbol table error with extract($blah, EXTR_REFS)
ID: 30074
Updated by: [EMAIL PROTECTED]
Reported By: owen dot beresford at murphx dot com
Status: Open
-Bug Type: Variables related
+Bug Type: Scripting Engine problem
Operating System: linux
PHP Version: 5.0.1
New Comment:
Reduced reproduce code looks like this:
1, 'b'=>$foo), EXTR_REFS);
//extract(array('a'=>1, 'b'=>$foo), EXTR_REFS); // they are not the
same
var_dump(array($b));
?>
Previous Comments:
[2004-09-14 11:10:56] owen dot beresford at murphx dot com
I have noticed my code output has the wrong indexes.
the expected out put should read index 0 and index 1 not index 'a',
index 'b'
bug still present
[2004-09-13 15:47:40] owen dot beresford at murphx dot com
Description:
PHP 5.0.1 (cli) (built: Aug 16 2004 23:07:06),
linux, rh7.3, kernel2.4, libc-2.2.5
The extract function seems incomplete/ broken.
I have a code base which uses arguments arrays, like perl.
Inorder to alter varaibles inside the parameter array in a convient
fashion, I extract the variables at the top of the methods.
Some of the boundary cases don't perform correctly. I have NOT
experienced this under other releases of php, so assume the problem is
induced by the new zend engine.
I am assuming that php 5.0.1 includes prevous fixes for errors reported
against php 4.3.8 and php 5.0.0 (there are closed cases with similar
problems).
This is a small simple case, there are other failures, but this would
exceed the twenty line limit. will post an URL with full senario
The described output ommited some of the english statements for
brevity.
I have not tested this under other operating systems, but this is not a
platform dependant function (well it shouldn't be), and I don't have any
to hand.
in the interests of thoroughness:
Configure Command => './configure' '--prefix=/usr'
'--with-config-file-path=/etc' '--enable-cli' '--disable-cgi'
'--without-pear' '--enable-force-cgi-redirect'
'--with-exec-dir=/usr/bin' '--with-mysql' '--with-curl=/usr/local/lib'
'--with-zlib' '--enable-sockets' '--with-openssl' '--enable-pcntl'
'--enable-libxml' '--enable-shared'
Reproduce code:
---
function x($args) {
$count =extract($args, EXTR_REFS);
echo("inside function x()\n$count items\n");
$count+=10;
echo("altered count to $count\n");
var_dump(array($a, $b));
}
echo("before function x() (second is a null)\n");
$a=array('a'=>1, 'b'=>NULL);
var_dump($a);
x($a);
echo("before function x() (second is undefined variable)\n");
$d=array('a'=>1, 'b'=>NULL);
$e=array('a'=>1, 'b'=>$d['d']);
var_dump($e);
x($e);
Expected result:
array(2) {
["a"]=>
int(1)
["b"]=>
NULL
}
array(2) {
["a"]=>
int(1)
["b"]=>
NULL
}
Actual result:
--
array(2) {
[0]=>
int(1)
[1]=>
NULL
}
array(2) {
[0]=>
int(1)
[1]=>
int(12)
}
--
Edit this bug report at http://bugs.php.net/?id=30074&edit=1
#30080 [Opn]: Passing array or non array of objects
ID: 30080
Updated by: [EMAIL PROTECTED]
Reported By: portfolio at gmx dot co dot uk
Status: Open
-Bug Type: Reproducible crash
+Bug Type: Zend Engine 2 problem
Operating System: XP
PHP Version: 5.0.1
New Comment:
Reproducible only with HEAD & 5.0.x.
Previous Comments:
[2004-09-14 17:55:33] php30080 at pointbeing dot net
Behaviour is reproducible using 5.00 on Fedora Linux (core 2).
There's an ongoing discussion of the behaviour on the Sitepoint forums
here:
http://www.sitepoint.com/forums/showthread.php?t=195284
By way of a summary, it appears that the problems occur when
constructing a number of new objects without assigning them anywhere,
so:
new A( array( new B(), new C())); // fails
$a = new A( array( new B(), new C())); // fine
some_function( array( new B(), new C())); //fine
[2004-09-14 05:44:10] portfolio at gmx dot co dot uk
Description:
When I pass an array of objects without first initializing them with a
variable, I get either a crash or error (Depends on whether if its
array).
Reproduce code:
---
class A {
function A($arrayobj) {
while(list($key, $value) = each($arrayobj)) {
echo $value->spit();
}
}
}
class B {
function spit() {
return 'This is class B' . "\n";
}
}
class C {
function spit() {
return 'This is class C' . "\n";
}
}
new A( array( new B(), new C()));
Expected result:
I got this error:
This is class B
Fatal error: Call to a member function spit() on a non-object in
If I do:
$b = new B; $c = new C;
new A( array($b, $c));
It works but very long winded.
Another bug here causes Apache to crash:
class A
{
function A($value) {
echo $value->spit();
}
}
class B {
function spit() {
return 'This is class B' . "\n";
}
}
new A( new B());
--
Edit this bug report at http://bugs.php.net/?id=30080&edit=1
#30092 [Opn->Fbk]: Segmentation fault when comparing a simplexml object.
ID: 30092
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Feedback
Bug Type: Class/Object related
Operating System: N/A
PHP Version: 5CVS-2004-09-15 (dev)
New Comment:
Please try using this CVS snapshot:
http://snaps.php.net/php5-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.0-win32-latest.zip
Works fine here.
Previous Comments:
[2004-11-25 01:35:49] jeremy at durge dot org
This is still a issue in 5.0.2 but fixed (but not totally better) in
php5-STABLE-200411241330 - although the output is slightly different.
This is my test case:
--
10");
print ($xmlfile->bar < 10);
?>
--
In 5.0.2 (running on Debian unstable), this returns:
--
free(): invalid pointer 0xbfffd584!
Allowed memory size of 8388608 bytes exhausted (tried to allocate 256
bytes)
--
The segfault/memory leak has been fixed since this build (claims to be
5.0.2-0.2), but with the latest stable CVS a message like the following
is still shown:
--
free(): invalid pointer 0xbfffd0b4!
--
If this message is shown depends on the operator being used - if the
second line of code is replaced with 'print ($xmlfile->bar > 10);' then
this error is not produced.
In all cases, converting the number with floatval() or intval() before
the comparison evalutes correctly without error.
[2004-09-15 13:50:28] [EMAIL PROTECTED]
Also known as a Segmentation fault. :)
[2004-09-15 13:47:15] [EMAIL PROTECTED]
Description:
Segmantation fault when comparing a simplexml object.
Reproduce code:
---
param = $param;
if ($this->param < 1) {
echo ('Param is smaller than 1');
}
}
}
$xml = simplexml_load_string('');
$C = new Crash($xml);
?>
Actual result:
--
(gdb) bt
#0 0x4207acfd in free () from /lib/i686/libc.so.6
#1 0x08168b68 in _efree (ptr=0xbfffd460)
at /root/bunldes/php5-STABLE-200408261030/Zend/zend_alloc.c:287
#2 0x08179d06 in compare_function (result=0xbfffd560, op1=0xbfffd460,
op2=0x828e45c)
at
/root/bunldes/php5-STABLE-200408261030/Zend/zend_operators.c:1249
#3 0x0817a519 in is_smaller_function (result=0xbfffd560,
op1=0x828e72c,
op2=0x820d4b8)
at
/root/bunldes/php5-STABLE-200408261030/Zend/zend_operators.c:1476
#4 0x0819e197 in zend_is_smaller_handler (execute_data=0xbfffd580,
opline=0x828e42c, op_array=0x828f5b4)
at /root/bunldes/php5-STABLE-200408261030/Zend/zend_execute.c:1547
#5 0x0819af6c in execute (op_array=0x828f5b4)
at /root/bunldes/php5-STABLE-200408261030/Zend/zend_execute.c:1400
#6 0x081b6cc9 in zend_do_fcall_common_helper
(execute_data=0xbfffd750,
opline=0x828ceb0, op_array=0x82889f4)
at /root/bunldes/php5-STABLE-200408261030/Zend/zend_execute.c:2737
#7 0x081b7085 in zend_do_fcall_by_name_handler
(execute_data=0xbfffd750,
opline=0x828ceb0, op_array=0x82889f4)
at /root/bunldes/php5-STABLE-200408261030/Zend/zend_execute.c:2822
#8 0x0819af6c in execute (op_array=0x82889f4)
at /root/bunldes/php5-STABLE-200408261030/Zend/zend_execute.c:1400
#9 0x0817d4b5 in zend_execute_scripts (type=8, retval=0x0,
file_count=3)
---Type to continue, or q to quit---
at /root/bunldes/php5-STABLE-200408261030/Zend/zend.c:1061
#10 0x08149e58 in php_execute_script (primary_file=0xbb20)
at /root/bunldes/php5-STABLE-200408261030/main/main.c:1629
#11 0x081c0f60 in main (argc=2, argv=0xbbc4)
at /root/bunldes/php5-STABLE-200408261030/sapi/cli/php_cli.c:943
#12 0x42017589 in __libc_start_main () from /lib/i686/libc.so.6
(gdb) frame 5
#5 0x0819af6c in execute (op_array=0x828f5b4)
at /root/bunldes/php5-STABLE-200408261030/Zend/zend_execute.c:1400
1400/root/bunldes/php5-STABLE-200408261030/Zend/zend_execute.c: No
such file or directory.
in /root/bunldes/php5-STABLE-200408261030/Zend/zend_execute.c
$ valgrind --tool=memcheck php test.php
==13706== Memcheck, a memory error detector for x86-linux.
==13706== Copyright (C) 2002-2004, and GNU GPL'd, by Julian Seward et
al.
==13706== Using valgrind-2.2.0, a program supervision framework for
x86-linux.
==13706== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward et
al.
==13706== For more details, rerun with: -v
==13706==
==13706== Conditional jump or move depends on uninitialised value(s)
==13706==at 0x8179CEF: compare_function
(/root/bunldes/php5-STABLE-200408261030/Zend/zend_operators.c:1247)
==13706==by 0x817A518: is_smaller_function
(/root/bunldes/php5-STABLE-200408261030/Zend/zend_operators.c:1476)
==13706==by 0x819E196: zend_is_smaller_handler
(/root/bunldes/php5-STABLE-200408261030/Zend/zend_execute.c:1547)
==13706==by 0x819AF6B: execute
(/root/bunldes/php5-STABLE-200408261030/Zend/zend_execut
#30058 [Opn->Fbk]: Yet Another Solaris compilation problem :-((
ID: 30058 Updated by: [EMAIL PROTECTED] Reported By: l_faillie at yahoo dot com -Status: Open +Status: Feedback Bug Type: FTP related Operating System: Solaris 8 PHP Version: 4.3.8 New Comment: l_faillie at yahoo dot com: Do you have any additional info about it? Previous Comments: [2004-10-07 20:32:02] l_faillie at yahoo dot com Oups, yes, you're right ! Well, I've added new probe inside PHP_FUNCTION(ftp_put) [the right one ;-D] and it seems the problem come from the call of instream = php_stream_fopen(local, mode == FTPTYPE_ASCII ? "rt" : "rb", NULL); around line 890 that returns a NULL pointer. I continue to track this bug. [2004-10-06 17:16:55] [EMAIL PROTECTED] Why would PHP call ftp_fput() when your script doesn't have any calls to it in it? (you call ftp_put(), notice the missing 'f' in front of put...) [2004-10-05 22:43:32] l_faillie at yahoo dot com > This seems more like feature request (getting more info > as an error message if the ftp_*() functions fail..) > but anyway, It should be better if we have better message in case of failure, but as I said previously, I put some tracing puts() in ext/ftp/php_ftp.c and it seems that PHP_FUNCTION(ftp_fput), line 768 is never called. So for me it's more an issue in the PHP parser than in ftp function themselfs. Unfortunatly, I'm not confident enough w/ PHP parser to trace deeply in the code. > are you sure this isn't some firewall issue..? (like > I've had had to struggle with for last 6 months.. :) Yes, because both machines are on the same networks and I can connect using the normal Solaris FTP client. [2004-10-05 20:14:20] [EMAIL PROTECTED] This seems more like feature request (getting more info as an error message if the ftp_*() functions fail..) but anyway, are you sure this isn't some firewall issue..? (like I've had had to struggle with for last 6 months.. :) [2004-10-02 17:01:21] l_faillie at yahoo dot com Ok, the result is : bool(false) 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/30058 -- Edit this bug report at http://bugs.php.net/?id=30058&edit=1
#30002 [Opn->Asn]: Undefined property notice appear when __get method access $this->OtherProperty
ID: 30002
Updated by: [EMAIL PROTECTED]
Reported By: orlum at mail dot ru
-Status: Open
+Status: Assigned
Bug Type: Zend Engine 2 problem
Operating System: *
PHP Version: 5.0.1
-Assigned To: Andi
+Assigned To: andi
Previous Comments:
[2004-09-06 21:46:32] [EMAIL PROTECTED]
Interesting thing:
1) It should happen at all because using $this->B should result in an
implicitly declared proeprty.
2) It is expected behavior because __get/__set have a simple recursion
protection which disables __get/__set during __get/__set calls.
[2004-09-06 18:51:46] orlum at mail dot ru
Description:
When __get method accesses other property in some class, expected call
to __get method not occurs, undefined property notice appears and null
value of property returns.
Reproduce code:
---
B;
}
}
error_reporting(E_ALL);
$a = new A();
echo "B={$a->B}\n";
echo "C={$a->C}\n";
?>
Expected result:
__get()
B=1
__get()
__get()
C=1
Actual result:
--
__get()
B=1
__get()
Notice: Undefined property: A::$B in PHPDocument1 on line 12
C=
--
Edit this bug report at http://bugs.php.net/?id=30002&edit=1
#30188 [Bgs->Opn]: open_basedir check is badly performed under some circumstances
ID: 30188
User updated by: lists+php at box dot cz
Reported By: lists+php at box dot cz
-Status: Bogus
+Status: Open
Bug Type: Filesystem function related
Operating System: Linux (Gentoo, latest)
PHP Version: 5.0.1
New Comment:
No, you're simply WRONG:
"->All symbolic
links are resolved, so it's not possible to avoid this restriction
with
a symlink.<-"
because my open_basedir is set to:
"/home/wejn/x/docs/html:/home/wejn/x/docs1/html"
therefore the file lies in basedir either way, when I call:
copy("/home/wejn/x/docs/html/x", "/home/wejn/x/docs/html/y");
It's a bug and I would expect someone with email "@php.net" to at least
READ MY BUGREPORT. I feel a bit stupid when I have to repeat myself over
and over again, because you simply assume from beginning that I'm wrong
(and the only action you do is actually telling me bullshit about
RTFM).
I did RTFM, but your implementation simply doesn't correspond with the
things written in TFM.
[offensive]
Anyway, I don't care about PHP anymore - I have better things to do
than pushing you to at least read what you're responding to ... btw,
responding to bugreports after 2 months is really, really wonderful.
Better than never, though.
[/offensive]
Previous Comments:
[2004-11-28 15:16:38] [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
"When a script tries to open a file with, for example, fopen() or
gzopen(), the location of the file is checked. When the file is outside
the specified directory-tree, PHP will refuse to open it. ->All symbolic
links are resolved, so it's not possible to avoid this restriction with
a symlink.<-"
http://www.php.net/manual/en/features.safe-mode.php#ini.open-basedir
You have to copy file to "/home/wejn/x/docs1/html/" instead of it's
symlink if want open_basedir to work properly.
[2004-10-14 12:10:46] lists+php at box dot cz
> > Maybe it would be better to perform open_basedir check
> > just on dirs
> > instead of files (in various filesystem functions)?
> No, because it's sometimes vital to have files in
> open_basedir to allow acces to one specific file without
> the need to put it into a directory for its own.
OK ... but the rest still applies. The code is obviously broken. And
sorry, folks @ php.net ... but if I would ever use PHP in production, I
would expect bugs to be solved in timely fashion, not after 6 months of
waiting as "open" (or even not solved at all).
It imho says all the "right" things about PHP - it's still toy, it has
(almost) no support, nobody really cares about users' aches, ...
It's simply another hack-it-yourself-or-shut-up thingie ... but I'm
probably crying on wrong shoulder here, anyway. :)
[2004-10-14 11:51:28] evp at heise dot de
> Maybe it would be better to perform open_basedir check just
> on dirs
> instead of files (in various filesystem functions)?
No, because it's sometimes vital to have files in open_basedir to allow
acces to one specific file without the need to put it into a directory
for its own.
[2004-09-21 23:50:28] lists+php at box dot cz
Description:
My setup:
document root is: "/home/wejn/x/docs/html/".
While "/home/wejn/x/docs/html/" is symlink to:
"/home/wejn/x/docs1/html/".
I have safe_mode enabled and open_basedir set to
"/home/wejn/x/docs/html:/home/wejn/x/docs1/html".
With this setup I'm unable to perform:
copy("/home/wejn/x/docs/html/x", "/home/wejn/x/docs/html/y");
when "y" doesn't exist. If I touch "y" prior running the
script, everything runs just fine.
IMO, there is problem with symlink resolving code somewhere under
php_check_specific_open_basedir().
It seems to me that more precise location of the bug is somewhere in
virtual_file_ex() regarding the realpath() call.
Maybe it would be better to perform open_basedir check just on dirs
instead of files (in various filesystem functions)?
Btw, this problem exists also in 4.3.8, which makes me think that it's
there for a LONG time ... unnoticed.
W.
Reproduce code:
---
// when all conditions described above are met, this fails:
copy('/home/wejn/x/docs/html/x', '/home/wejn/x/docs/html/y');
Expected result:
no error.
Actual result:
--
Warning: copy() [function.copy]: open_basedir restriction in effect.
File(/home/wejn/x/docs/html/y) is not within the allowed path(s):
(/home/wejn/x/docs/html:/home/wejn/x/docs1/html) in
/home/wejn/x/docs1/html/index.html on line 2
Warning: copy(/home/wejn/x/docs/html/y)
#29975 [Opn->Fbk]: memory leaks
ID: 29975 Updated by: [EMAIL PROTECTED] Reported By: guth at fiifo dot u-psud dot fr -Status: Open +Status: Feedback Bug Type: Performance problem Operating System: Linux (Mandrake 10) PHP Version: 5.0.1 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php5-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.0-win32-latest.zip Works fine here. Previous Comments: [2004-10-12 10:36:00] guth at fiifo dot u-psud dot fr I use a SimpleTest to do unit tests and it seems that it is this library which causes the memory leaks. run(); ?> /usr/src/php5-200410111030/Zend/zend_builtin_functions.c(1058) : Freeing 0x082D0C54 (16 bytes), script=/www/test2.php Last leak repeated times /usr/src/php5-200410111030/Zend/zend_variables.h(45) : Freeing 0x082D0B84 (23 bytes), script=/www/test2.php /usr/src/php5-200410111030/Zend/zend_variables.c(120) : Actual location (location was relayed) Last leak repeated times [2004-09-20 01:00:02] 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". [2004-09-06 08:12:18] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , is max. 10-20 lines long and does not require any external resources such as databases, etc. If possible, make the script source available online and provide an URL to it here. Try avoid embedding huge scripts into the report. [2004-09-03 21:21:15] guth at fiifo dot u-psud dot fr Description: (i'm french, excuse me for my english) I try to develop a CMS and i take more time to debug PHP than code PHP... After 3 segmentation fault, I compiled PHP with --enable-debug, and my tests give the following errors. Reproduce code: --- /usr/src/php-5.0.1/Zend/zend_builtin_functions.c(1023) : Freeing 0x0846F864 (23 bytes), script=/www/haricow/0.4/haricow/test/runTests.php /usr/src/php-5.0.1/Zend/zend_variables.c(137) : Actual location (location was relayed) Last leak repeated 32 times /usr/src/php-5.0.1/Zend/zend_builtin_functions.c(1013) : Freeing 0x084702C4 (16 bytes), script=/www/haricow/0.4/haricow/test/runTests.php Last leak repeated 32 times /usr/src/php-5.0.1/Zend/zend_execute.c(3718) : Freeing 0x0844FA94 (44 bytes), script=/www/haricow/0.4/haricow/test/runTests.php /usr/src/php-5.0.1/Zend/zend_variables.c(149) : Actual location (location was relayed) Last leak repeated 1 time /usr/src/php-5.0.1/Zend/zend_execute.c(3252) : Freeing 0x0844DCCC (16 bytes), script=/www/haricow/0.4/haricow/test/runTests.php Last leak repeated 7 times /usr/src/php-5.0.1/Zend/zend_variables.c(150) : Freeing 0x0843597C (32 bytes), script=/www/haricow/0.4/haricow/test/runTests.php /usr/src/php-5.0.1/Zend/zend_hash.c(169) : Actual location (location was relayed) /usr/src/php-5.0.1/Zend/zend_execute.c(3389) : Freeing 0x084315DC (16 bytes), script=/www/haricow/0.4/haricow/test/runTests.php /usr/src/php-5.0.1/Zend/zend_hash.c(242) : Freeing 0x08233804 (40 bytes), script=/www/haricow/0.4/haricow/test/runTests.php === Total 79 memory leaks detected === Expected result: No memory leaks Actual result: -- About 3 Kb of memory leaks. I tryed to "insulate" them, but i didn't manage, because of the complexity of the script. -- Edit this bug report at http://bugs.php.net/?id=29975&edit=1
#30120 [Fbk->Opn]: imagettftext() and imagettfbbox() has superfluous optional parameter
ID: 30120 User updated by: [EMAIL PROTECTED] -Summary: imagettftext() and imagettf() has superfluous optional parameter Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: GD related Operating System: Irrelevant PHP Version: 5.0.1 New Comment: Before patch, imagettftext() could be called with 4 parameters. Now it's possible to call it with 4 or 5 parameter but the 5th parameter is superfluous. The patch was made to allow 5th parameter of imagefttext() be optional but unnecessary side-effect was that 5th parameter of imagettftext() was allowed. Previous Comments: [2004-11-28 15:32:41] [EMAIL PROTECTED] I'm not quite sure I understand what are you talking about, Jakub. Could you plz explain how Ilia could add parameter while he made it optional? [2004-09-16 17:09:03] [EMAIL PROTECTED] Description: Since PHP 4.3.5 (precisely since patch http://cvs.php.net/diff.php/php-src/ext/gd/gd.c?r1=1.279&r2=1.280&ty=u), these two functions has superfluous optional parameter. -- Edit this bug report at http://bugs.php.net/?id=30120&edit=1
#30188 [Opn->Bgs]: open_basedir check is badly performed under some circumstances
ID: 30188
Updated by: [EMAIL PROTECTED]
Reported By: lists+php at box dot cz
-Status: Open
+Status: Bogus
Bug Type: Filesystem function related
Operating System: Linux (Gentoo, latest)
PHP Version: 5.0.1
New Comment:
Using "/home/wejn/x/docs/html:/home/wejn/x/docs1/html" as value of
open_basedir is senseless, as it's similar to
"/home/wejn/x/docs/html:/home/wejn/x/docs/html", because open_basedir's
values are resolved too.
Obviously PHP cannot resolve "/home/wejn/x/docs1/html/y" as it even
doesn't exist, so it compares non-existing "/home/wejn/x/docs1/html/y"
to "/home/wejn/x/docs/html/" and reports that they aren't the same.
Please, stop reopening this report and begin to respect people that
wasting their own free time to help you.
Previous Comments:
[2004-11-28 16:58:48] lists+php at box dot cz
No, you're simply WRONG:
"->All symbolic
links are resolved, so it's not possible to avoid this restriction
with
a symlink.<-"
because my open_basedir is set to:
"/home/wejn/x/docs/html:/home/wejn/x/docs1/html"
therefore the file lies in basedir either way, when I call:
copy("/home/wejn/x/docs/html/x", "/home/wejn/x/docs/html/y");
It's a bug and I would expect someone with email "@php.net" to at least
READ MY BUGREPORT. I feel a bit stupid when I have to repeat myself over
and over again, because you simply assume from beginning that I'm wrong
(and the only action you do is actually telling me bullshit about
RTFM).
I did RTFM, but your implementation simply doesn't correspond with the
things written in TFM.
[offensive]
Anyway, I don't care about PHP anymore - I have better things to do
than pushing you to at least read what you're responding to ... btw,
responding to bugreports after 2 months is really, really wonderful.
Better than never, though.
[/offensive]
[2004-11-28 15:16:38] [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
"When a script tries to open a file with, for example, fopen() or
gzopen(), the location of the file is checked. When the file is outside
the specified directory-tree, PHP will refuse to open it. ->All symbolic
links are resolved, so it's not possible to avoid this restriction with
a symlink.<-"
http://www.php.net/manual/en/features.safe-mode.php#ini.open-basedir
You have to copy file to "/home/wejn/x/docs1/html/" instead of it's
symlink if want open_basedir to work properly.
[2004-10-14 12:10:46] lists+php at box dot cz
> > Maybe it would be better to perform open_basedir check
> > just on dirs
> > instead of files (in various filesystem functions)?
> No, because it's sometimes vital to have files in
> open_basedir to allow acces to one specific file without
> the need to put it into a directory for its own.
OK ... but the rest still applies. The code is obviously broken. And
sorry, folks @ php.net ... but if I would ever use PHP in production, I
would expect bugs to be solved in timely fashion, not after 6 months of
waiting as "open" (or even not solved at all).
It imho says all the "right" things about PHP - it's still toy, it has
(almost) no support, nobody really cares about users' aches, ...
It's simply another hack-it-yourself-or-shut-up thingie ... but I'm
probably crying on wrong shoulder here, anyway. :)
[2004-10-14 11:51:28] evp at heise dot de
> Maybe it would be better to perform open_basedir check just
> on dirs
> instead of files (in various filesystem functions)?
No, because it's sometimes vital to have files in open_basedir to allow
acces to one specific file without the need to put it into a directory
for its own.
[2004-09-21 23:50:28] lists+php at box dot cz
Description:
My setup:
document root is: "/home/wejn/x/docs/html/".
While "/home/wejn/x/docs/html/" is symlink to:
"/home/wejn/x/docs1/html/".
I have safe_mode enabled and open_basedir set to
"/home/wejn/x/docs/html:/home/wejn/x/docs1/html".
With this setup I'm unable to perform:
copy("/home/wejn/x/docs/html/x", "/home/wejn/x/docs/html/y");
when "y" doesn't exist. If I touch "y" prior running the
script, everything runs just fine.
IMO, there is problem with symlink resolving code somewhere under
php_check_specific_open_basedir().
It seems to me that more precise location of the bug is somewhere in
virtual_file_ex() regarding the realpath() call.
Maybe it would be better to perform open_basedir check just on dirs
instead of files (in vari
#30120 [Opn->Asn]: imagettftext() and imagettfbbox() has superfluous optional parameter
ID: 30120 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Assigned Bug Type: GD related Operating System: Irrelevant PHP Version: 5.0.1 -Assigned To: +Assigned To: pajoye Previous Comments: [2004-11-28 17:01:21] [EMAIL PROTECTED] Before patch, imagettftext() could be called with 4 parameters. Now it's possible to call it with 4 or 5 parameter but the 5th parameter is superfluous. The patch was made to allow 5th parameter of imagefttext() be optional but unnecessary side-effect was that 5th parameter of imagettftext() was allowed. [2004-11-28 15:32:41] [EMAIL PROTECTED] I'm not quite sure I understand what are you talking about, Jakub. Could you plz explain how Ilia could add parameter while he made it optional? [2004-09-16 17:09:03] [EMAIL PROTECTED] Description: Since PHP 4.3.5 (precisely since patch http://cvs.php.net/diff.php/php-src/ext/gd/gd.c?r1=1.279&r2=1.280&ty=u), these two functions has superfluous optional parameter. -- Edit this bug report at http://bugs.php.net/?id=30120&edit=1
#30188 [Bgs->Csd]: open_basedir check is badly performed under some circumstances
ID: 30188
User updated by: lists+php at box dot cz
Reported By: lists+php at box dot cz
-Status: Bogus
+Status: Closed
Bug Type: Filesystem function related
Operating System: Linux (Gentoo, latest)
PHP Version: 5.0.1
New Comment:
My final words would be:
Function, that does basedir check differently based on (non)existence
of the file (which is) being checked, is flawed.
I'm putting my hands off it ... to ensure your precious time won't be
wasted. After all -1 happy_user/advocate means nothing compared to
solving real issues like adding more entropy to PHP sources or changing
parameter passing again ;-)
Btw, this attitude kinda reminds me "don't live with broken windows"
from "The Pragmatic Programmer" (and if you don't know what that means,
all the more reason not to mess with this [in your opinion absolutely
correct] behaviour of basedir check).
Luckily enough there's enough alternatives to this whole PHP thing.
Previous Comments:
[2004-11-28 17:28:15] [EMAIL PROTECTED]
Using "/home/wejn/x/docs/html:/home/wejn/x/docs1/html" as value of
open_basedir is senseless, as it's similar to
"/home/wejn/x/docs/html:/home/wejn/x/docs/html", because open_basedir's
values are resolved too.
Obviously PHP cannot resolve "/home/wejn/x/docs1/html/y" as it even
doesn't exist, so it compares non-existing "/home/wejn/x/docs1/html/y"
to "/home/wejn/x/docs/html/" and reports that they aren't the same.
Please, stop reopening this report and begin to respect people that
wasting their own free time to help you.
[2004-11-28 16:58:48] lists+php at box dot cz
No, you're simply WRONG:
"->All symbolic
links are resolved, so it's not possible to avoid this restriction
with
a symlink.<-"
because my open_basedir is set to:
"/home/wejn/x/docs/html:/home/wejn/x/docs1/html"
therefore the file lies in basedir either way, when I call:
copy("/home/wejn/x/docs/html/x", "/home/wejn/x/docs/html/y");
It's a bug and I would expect someone with email "@php.net" to at least
READ MY BUGREPORT. I feel a bit stupid when I have to repeat myself over
and over again, because you simply assume from beginning that I'm wrong
(and the only action you do is actually telling me bullshit about
RTFM).
I did RTFM, but your implementation simply doesn't correspond with the
things written in TFM.
[offensive]
Anyway, I don't care about PHP anymore - I have better things to do
than pushing you to at least read what you're responding to ... btw,
responding to bugreports after 2 months is really, really wonderful.
Better than never, though.
[/offensive]
[2004-11-28 15:16:38] [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
"When a script tries to open a file with, for example, fopen() or
gzopen(), the location of the file is checked. When the file is outside
the specified directory-tree, PHP will refuse to open it. ->All symbolic
links are resolved, so it's not possible to avoid this restriction with
a symlink.<-"
http://www.php.net/manual/en/features.safe-mode.php#ini.open-basedir
You have to copy file to "/home/wejn/x/docs1/html/" instead of it's
symlink if want open_basedir to work properly.
[2004-10-14 12:10:46] lists+php at box dot cz
> > Maybe it would be better to perform open_basedir check
> > just on dirs
> > instead of files (in various filesystem functions)?
> No, because it's sometimes vital to have files in
> open_basedir to allow acces to one specific file without
> the need to put it into a directory for its own.
OK ... but the rest still applies. The code is obviously broken. And
sorry, folks @ php.net ... but if I would ever use PHP in production, I
would expect bugs to be solved in timely fashion, not after 6 months of
waiting as "open" (or even not solved at all).
It imho says all the "right" things about PHP - it's still toy, it has
(almost) no support, nobody really cares about users' aches, ...
It's simply another hack-it-yourself-or-shut-up thingie ... but I'm
probably crying on wrong shoulder here, anyway. :)
[2004-10-14 11:51:28] evp at heise dot de
> Maybe it would be better to perform open_basedir check just
> on dirs
> instead of files (in various filesystem functions)?
No, because it's sometimes vital to have files in open_basedir to allow
acces to one specific file without the need to put it into a directory
for its own.
#29954 [Opn->Csd]: array_reduce crashes
ID: 29954
Updated by: [EMAIL PROTECTED]
Reported By: tomas_matousek at hotmail dot com
-Status: Open
+Status: Closed
Bug Type: Reproducible crash
Operating System: WinXP
PHP Version: 5.0.1
New Comment:
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2004-09-02 16:56:44] tomas_matousek at hotmail dot com
Errata:
$array1 should be empty when printed out
[2004-09-02 16:24:48] tomas_matousek at hotmail dot com
Description:
array_reduce function crashes PHP in the following case
Reproduce code:
---
function &t(&$a, &$b)
{
static $o = 1;
$a[$b] = $o;
$b = $o;
$o++;
return $a;
}
$array0 = array("a", "b", "c", "d", "e");
$array1 = array();
print_r(array_reduce($array0,"t",$array1));
print_r($array0);
print_r($array1);
Expected result:
Array
(
[a] => 1
[b] => 2
[c] => 3
[d] => 4
[e] => 5
)
Array
(
[0] => 1
[1] => 2
[2] => 3
[3] => 4
[4] => 5
)
Array
(
[a] => 1
[b] => 2
[c] => 3
[d] => 4
[e] => 5
)
Actual result:
--
crash
--
Edit this bug report at http://bugs.php.net/?id=29954&edit=1
#30922 [NEW]: reflective functions crash PHP when interfaces extend themselves
From: Jason at AMP-design dot net Operating system: Windows 2003 PHP version: 5.0.2 PHP Bug Type: Reproducible crash Bug description: reflective functions crash PHP when interfaces extend themselves Description: When a interface extends it's self, it will cause PHP to crash when reflective language features such as instanceOf, is_a are used on objects that implement the recursive interface. Reproduce code: --- Expected result: Something like ... Fatal Error: interface can not extend it's self on line __LINE__ in __FILE__ Actual result: -- PHP Crashes. Apache log shows this activity. [Sun Nov 28 15:47:43 2004] [notice] Parent: child process exited with status 128 -- Restarting. [Sun Nov 28 15:47:43 2004] [notice] Parent: Created child process 3932 [Sun Nov 28 15:47:43 2004] [notice] Child 3932: Child process is running [Sun Nov 28 15:47:43 2004] [notice] Child 3932: Acquired the start mutex. [Sun Nov 28 15:47:43 2004] [notice] Child 3932: Starting 250 worker threads. -- Edit bug report at http://bugs.php.net/?id=30922&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=30922&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=30922&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=30922&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=30922&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=30922&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=30922&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=30922&r=needscript Try newer version: http://bugs.php.net/fix.php?id=30922&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=30922&r=support Expected behavior: http://bugs.php.net/fix.php?id=30922&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=30922&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=30922&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=30922&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=30922&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=30922&r=dst IIS Stability: http://bugs.php.net/fix.php?id=30922&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=30922&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=30922&r=float MySQL Configuration Error: http://bugs.php.net/fix.php?id=30922&r=mysqlcfg
#30922 [Opn->Asn]: reflective functions crash PHP when interfaces extend themselves
ID: 30922 Updated by: [EMAIL PROTECTED] Reported By: Jason at AMP-design dot net -Status: Open +Status: Assigned -Bug Type: Reproducible crash +Bug Type: Zend Engine 2 problem Operating System: Windows 2003 PHP Version: 5.0.2 -Assigned To: +Assigned To: andi Previous Comments: [2004-11-28 18:40:08] Jason at AMP-design dot net Description: When a interface extends it's self, it will cause PHP to crash when reflective language features such as instanceOf, is_a are used on objects that implement the recursive interface. Reproduce code: --- Expected result: Something like ... Fatal Error: interface can not extend it's self on line __LINE__ in __FILE__ Actual result: -- PHP Crashes. Apache log shows this activity. [Sun Nov 28 15:47:43 2004] [notice] Parent: child process exited with status 128 -- Restarting. [Sun Nov 28 15:47:43 2004] [notice] Parent: Created child process 3932 [Sun Nov 28 15:47:43 2004] [notice] Child 3932: Child process is running [Sun Nov 28 15:47:43 2004] [notice] Child 3932: Acquired the start mutex. [Sun Nov 28 15:47:43 2004] [notice] Child 3932: Starting 250 worker threads. -- Edit this bug report at http://bugs.php.net/?id=30922&edit=1
#30922 [Asn]: reflective functions crash PHP when interfaces extend themselves
ID: 30922
Updated by: [EMAIL PROTECTED]
Reported By: Jason at AMP-design dot net
Status: Assigned
Bug Type: Zend Engine 2 problem
Operating System: Windows 2003
PHP Version: 5.0.2
Assigned To: andi
New Comment:
Reproduced with HEAD too.
Please, review the patch below:
Index: zend_compile.c
===
RCS file: /repository/ZendEngine2/zend_compile.c,v
retrieving revision 1.600
diff -u -r1.600 zend_compile.c
--- zend_compile.c 16 Oct 2004 23:17:58 - 1.600
+++ zend_compile.c 28 Nov 2004 17:48:34 -
@@ -1997,6 +1997,10 @@
if (!(ce->ce_flags & ZEND_ACC_INTERFACE) &&
iface->interface_gets_implemented &&
iface->interface_gets_implemented(iface, ce TSRMLS_CC) == FAILURE) {
zend_error(E_CORE_ERROR, "Class %s could not implement
interface %s", ce->name, iface->name);
}
+
+ if (ce == iface) {
+ zend_error(E_CORE_ERROR, "Interface %s cannot not
implement itself", ce->name);
+ }
}
Previous Comments:
[2004-11-28 18:40:08] Jason at AMP-design dot net
Description:
When a interface extends it's self, it will cause PHP to crash when
reflective language features such as instanceOf, is_a are used on
objects that implement the recursive interface.
Reproduce code:
---
Expected result:
Something like ...
Fatal Error: interface can not extend it's self on line __LINE__ in
__FILE__
Actual result:
--
PHP Crashes. Apache log shows this activity.
[Sun Nov 28 15:47:43 2004] [notice] Parent: child process exited with
status 128 -- Restarting.
[Sun Nov 28 15:47:43 2004] [notice] Parent: Created child process 3932
[Sun Nov 28 15:47:43 2004] [notice] Child 3932: Child process is
running
[Sun Nov 28 15:47:43 2004] [notice] Child 3932: Acquired the start
mutex.
[Sun Nov 28 15:47:43 2004] [notice] Child 3932: Starting 250 worker
threads.
--
Edit this bug report at http://bugs.php.net/?id=30922&edit=1
#30333 [Fbk->Opn]: fscanf() and() not working correctly with other then English language
ID: 30333 User updated by: altuhov at nm dot ru Reported By: altuhov at nm dot ru -Status: Feedback +Status: Open Bug Type: Filesystem function related Operating System: WinXP SP2 PHP Version: 5.1.0-dev New Comment: YES! Todays PHP-5.1-dev build Previous Comments: [2004-11-28 13:43:18] [EMAIL PROTECTED] Do you still expirience this problem? [2004-10-23 16:00:46] profic at nospam dot kursknet dot ru Hm, russian letters converts to it's codes. I think this is even better then looking at ugly characters =) [2004-10-23 15:53:35] profic at nospam dot kursknet dot ru E:\>ver Microsoft Windows XP [Version 5.1.2600] E:\>php -v PHP 5.0.2 (cli) (built: Sep 24 2004 01:25:41) Copyright (c) 1997-2004 The PHP Group Zend Engine v2.0.2, Copyright (c) 1998-2004 Zend Technologies with DBG v2.11.30, (C) 2000,2004, by Dmitri Dmitrienko E:\>chcp 866 Active code page: 866 E:\>php ^Z Array ( [0] => проверка [1] => проверка [2] => проверка ) E:\>chcp 1251 Active code page: 1251 E:\>php ^Z Array ( [0] => пр [1] => в [2] => р ) E:\>php ^Z string(19) "Russian_Russia.1251" Array ( [0] => пр [1] => вер [2] => а ) E:\>php test.php string(19) "Russian_Russia.1251" Array ( [0] => пр [1] => в [2] => р ) E:\> Some comments to listing above: All text here is in cp1251 (windows-1251). There are 2 codepages for russian in windows: cp866 (aka OEM/DOS) and cp1251 (aka ANSI/Windows). As Windows' console can change current input/output codepage on fly, it seems to explain this bug, as with cp866 it works well and it is default console (in which php-cli is runing), but with cp1251 does not. But last 2 examples seems strange as locale is setted exactly. The test.php file is copy of the last inline PHP-code [2004-10-12 19:47:32] altuhov at nm dot ru Yes. Windows-1251. Reproduce code was writed and saved in the "Notepad". [2004-10-12 19:40:43] [EMAIL PROTECTED] Is the russian locale used by winxp the same locale as the one used by the document? 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/30333 -- Edit this bug report at http://bugs.php.net/?id=30333&edit=1
#30920 [Bgs]: SimpleXML : tags with "xs:" prefix
ID: 30920
User updated by: hieu at laposte dot net
Reported By: hieu at laposte dot net
Status: Bogus
Bug Type: XML related
Operating System: windows xp
PHP Version: 5.0.2
New Comment:
print_r doesn't work correctly with simplexml, okay... but please read
this new code, it doesn't use print_r and shows the same bug :
bug.xsd =
http://www.w3.org/2001/XMLSchema";>
$xml = simplexml_load_file("bug.xsd");
$elt = $xml->element;
$attr = (string) $elt['name'];
echo $attr;
=> nothing is printed...
if i remove the "xs:" prefix in the xsd file, this same code displays :
"dataset"
Previous Comments:
[2004-11-28 12:07:14] [EMAIL PROTECTED]
print_r and var_dump don't work reliably on simplexml objects... do
*not* use them or even rely on them...
And see http://www.zend.com/php5/articles/php5-simplexml.php for more
info about SimpleXML and Namespaces
[2004-11-27 17:55:59] hieu at laposte dot net
Description:
When the xml file contains this "xs:" prefix, the file is not correctly
parsed.
Reproduce code:
---
The XML file is :
http://www.w3.org/2001/XMLSchema";
xmlns:msdata="urn:schemas-microsoft-com:xml-msdata">
data:IsDataSet="true"; msdata:Locale="fr-FR";>
...
Php 5 code :
$oXml = simplexml_load_file($sFileName);
print_r($oXml->element);
// doesn't work, nothing printed...
PS : this code works correctly :
$oXml = simplexml_load_file($sFileName);
$aXml = get_object_vars($oXml);
print_r($aXml['element']);
// ok i can now access the "element".
Expected result:
SimpleXMLElement Object
(
[complexType] => SimpleXMLElement Object
(
.
)
)
Actual result:
--
SimpleXMLElement Object
(
)
--
Edit this bug report at http://bugs.php.net/?id=30920&edit=1
#30058 [Fbk->Opn]: Yet Another Solaris compilation problem :-((
ID: 30058 User updated by: l_faillie at yahoo dot com Reported By: l_faillie at yahoo dot com -Status: Feedback +Status: Open Bug Type: FTP related Operating System: Solaris 8 PHP Version: 4.3.8 New Comment: No, I haven't time to go deeper yet :( Previous Comments: [2004-11-28 16:42:26] [EMAIL PROTECTED] l_faillie at yahoo dot com: Do you have any additional info about it? [2004-10-07 20:32:02] l_faillie at yahoo dot com Oups, yes, you're right ! Well, I've added new probe inside PHP_FUNCTION(ftp_put) [the right one ;-D] and it seems the problem come from the call of instream = php_stream_fopen(local, mode == FTPTYPE_ASCII ? "rt" : "rb", NULL); around line 890 that returns a NULL pointer. I continue to track this bug. [2004-10-06 17:16:55] [EMAIL PROTECTED] Why would PHP call ftp_fput() when your script doesn't have any calls to it in it? (you call ftp_put(), notice the missing 'f' in front of put...) [2004-10-05 22:43:32] l_faillie at yahoo dot com > This seems more like feature request (getting more info > as an error message if the ftp_*() functions fail..) > but anyway, It should be better if we have better message in case of failure, but as I said previously, I put some tracing puts() in ext/ftp/php_ftp.c and it seems that PHP_FUNCTION(ftp_fput), line 768 is never called. So for me it's more an issue in the PHP parser than in ftp function themselfs. Unfortunatly, I'm not confident enough w/ PHP parser to trace deeply in the code. > are you sure this isn't some firewall issue..? (like > I've had had to struggle with for last 6 months.. :) Yes, because both machines are on the same networks and I can connect using the normal Solaris FTP client. [2004-10-05 20:14:20] [EMAIL PROTECTED] This seems more like feature request (getting more info as an error message if the ftp_*() functions fail..) but anyway, are you sure this isn't some firewall issue..? (like I've had had to struggle with for last 6 months.. :) 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/30058 -- Edit this bug report at http://bugs.php.net/?id=30058&edit=1
#30923 [NEW]: Unicode subject lines getting garbled
From: mfurdyk at takingitglobal dot org Operating system: RH 7.3 PHP version: 4.3.9 PHP Bug Type: MySQL related Bug description: Unicode subject lines getting garbled Description: I'm trying to upgrade the Client API version, and I've upgraded mySQL, deleted the old libraries, and installed the new 4.1.7-Shared and devel packages, but with --with-mysql=user and --with-mysql=/path/to/mysql, the old client API version still sticks around. With a new server I've installed, it pops up to 4.1.7 fine. Reproduce code: --- Here's my build: './configure' '--with-mysql=/usr' '--with-apxs=/usr/local/apache/bin/apxs' '--with-zlib' '--with-gd=/usr/local/lib' '--with-jpeg-dir=/usr/local/bin' '--with-png-dir=/usr/lib' '--enable-inline-optimization' '--with-curl' '--disable-debug' '--with-mcrypt=/usr/local/src/libmcrypt-2.5.7' '--with-mhash' '--enable-ftp' '--enable-mbstring' Expected result: Upgrade to 4.1.7 -- Edit bug report at http://bugs.php.net/?id=30923&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=30923&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=30923&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=30923&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=30923&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=30923&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=30923&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=30923&r=needscript Try newer version: http://bugs.php.net/fix.php?id=30923&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=30923&r=support Expected behavior: http://bugs.php.net/fix.php?id=30923&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=30923&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=30923&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=30923&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=30923&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=30923&r=dst IIS Stability: http://bugs.php.net/fix.php?id=30923&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=30923&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=30923&r=float MySQL Configuration Error: http://bugs.php.net/fix.php?id=30923&r=mysqlcfg
#30923 [Opn]: MySQL Client API version stagnant
ID: 30923 User updated by: mfurdyk at takingitglobal dot org -Summary: Unicode subject lines getting garbled Reported By: mfurdyk at takingitglobal dot org Status: Open Bug Type: MySQL related Operating System: RH 7.3 PHP Version: 4.3.9 New Comment: updated summary...kept old one. Previous Comments: [2004-11-28 23:41:05] mfurdyk at takingitglobal dot org Description: I'm trying to upgrade the Client API version, and I've upgraded mySQL, deleted the old libraries, and installed the new 4.1.7-Shared and devel packages, but with --with-mysql=user and --with-mysql=/path/to/mysql, the old client API version still sticks around. With a new server I've installed, it pops up to 4.1.7 fine. Reproduce code: --- Here's my build: './configure' '--with-mysql=/usr' '--with-apxs=/usr/local/apache/bin/apxs' '--with-zlib' '--with-gd=/usr/local/lib' '--with-jpeg-dir=/usr/local/bin' '--with-png-dir=/usr/lib' '--enable-inline-optimization' '--with-curl' '--disable-debug' '--with-mcrypt=/usr/local/src/libmcrypt-2.5.7' '--with-mhash' '--enable-ftp' '--enable-mbstring' Expected result: Upgrade to 4.1.7 -- Edit this bug report at http://bugs.php.net/?id=30923&edit=1
#30923 [Opn->Bgs]: MySQL Client API version stagnant
ID: 30923 Updated by: [EMAIL PROTECTED] Reported By: mfurdyk at takingitglobal dot org -Status: Open +Status: Bogus Bug Type: MySQL related Operating System: RH 7.3 PHP Version: 4.3.9 New Comment: If you want to use the new features of MySQL 4.1+, like the new binary protocol, you need to use PHP 5 and the MySQLi extension. (MySQLi, not MySQL.) You cannot use the new client protocol with PHP 4. Previous Comments: [2004-11-28 23:43:43] mfurdyk at takingitglobal dot org updated summary...kept old one. [2004-11-28 23:41:05] mfurdyk at takingitglobal dot org Description: I'm trying to upgrade the Client API version, and I've upgraded mySQL, deleted the old libraries, and installed the new 4.1.7-Shared and devel packages, but with --with-mysql=user and --with-mysql=/path/to/mysql, the old client API version still sticks around. With a new server I've installed, it pops up to 4.1.7 fine. Reproduce code: --- Here's my build: './configure' '--with-mysql=/usr' '--with-apxs=/usr/local/apache/bin/apxs' '--with-zlib' '--with-gd=/usr/local/lib' '--with-jpeg-dir=/usr/local/bin' '--with-png-dir=/usr/lib' '--enable-inline-optimization' '--with-curl' '--disable-debug' '--with-mcrypt=/usr/local/src/libmcrypt-2.5.7' '--with-mhash' '--enable-ftp' '--enable-mbstring' Expected result: Upgrade to 4.1.7 -- Edit this bug report at http://bugs.php.net/?id=30923&edit=1
#30923 [Bgs]: MySQL Client API version stagnant
ID: 30923 User updated by: mfurdyk at takingitglobal dot org Reported By: mfurdyk at takingitglobal dot org Status: Bogus Bug Type: MySQL related Operating System: RH 7.3 PHP Version: 4.3.9 New Comment: No, I don't (at this point) care about using those features, I just want to know why the Client API version is setting at 3.X -- does this matter? It just seems weird, and thought it might explain some random mySQL errors (unable to save result set) that someone suggested were due to incorrect Client API. -- In terms of mySQLi, is there a way to have the existing mysql_query / mysql_fetch_assoc use the mysqli variants without doing a huge find/replace on all code? Previous Comments: [2004-11-29 00:10:20] [EMAIL PROTECTED] If you want to use the new features of MySQL 4.1+, like the new binary protocol, you need to use PHP 5 and the MySQLi extension. (MySQLi, not MySQL.) You cannot use the new client protocol with PHP 4. [2004-11-28 23:43:43] mfurdyk at takingitglobal dot org updated summary...kept old one. [2004-11-28 23:41:05] mfurdyk at takingitglobal dot org Description: I'm trying to upgrade the Client API version, and I've upgraded mySQL, deleted the old libraries, and installed the new 4.1.7-Shared and devel packages, but with --with-mysql=user and --with-mysql=/path/to/mysql, the old client API version still sticks around. With a new server I've installed, it pops up to 4.1.7 fine. Reproduce code: --- Here's my build: './configure' '--with-mysql=/usr' '--with-apxs=/usr/local/apache/bin/apxs' '--with-zlib' '--with-gd=/usr/local/lib' '--with-jpeg-dir=/usr/local/bin' '--with-png-dir=/usr/lib' '--enable-inline-optimization' '--with-curl' '--disable-debug' '--with-mcrypt=/usr/local/src/libmcrypt-2.5.7' '--with-mhash' '--enable-ftp' '--enable-mbstring' Expected result: Upgrade to 4.1.7 -- Edit this bug report at http://bugs.php.net/?id=30923&edit=1
#30858 [Fbk->Opn]: Upload permission error
ID: 30858
User updated by: michaelchikit at gmail dot com
Reported By: michaelchikit at gmail dot com
-Status: Feedback
+Status: Open
Bug Type: Filesystem function related
Operating System: Fedora 3
PHP Version: 5.0.2
New Comment:
Because I have tried this script into a older version PHP server, this
is working.
But my new PHP5 + Apache 2 server can't make this script working.
Previous Comments:
[2004-11-27 09:28:49] [EMAIL PROTECTED]
Why do you think it's a bug in PHP and how can we reproduce it?
[2004-11-26 01:11:42] michaelchikit at gmail dot com
I tried to use abd path.
This is not working
[2004-11-25 23:10:27] [EMAIL PROTECTED]
Try it using absolute path for destination file.
[2004-11-22 06:02:13] michaelchikit at gmail dot com
Description:
I have tried this code in my old server that is working very fine. But
after I upgraded my server into Fedora 3 and PHP 5.0.2. that generated
the followings error. The server does not allow me to upload the file
and say permission denied. But I am very very sure, I have set the
correct permission with the dir. The mode of upload_files and its
parenet dir are 0777.
Is it a bug of PHP?
Reproduce code:
---
$temp_name = $_FILES['userfile']['tmp_name'];
$file_name = $_FILES['userfile']['name'];
$file_type = $_FILES['userfile']['type'];
$file_size = $_FILES['userfile']['size'];
$result= $_FILES['userfile']['error'];
$file_url = $upload_url.$file_name;
$file_path = $upload_dir.$file_name;
//File Name Check
if ( $file_name =="") {
$message = "Invalid File Name Specified";
return $message;
}
$result = move_uploaded_file($temp_name, $file_path);
Expected result:
No Error , the file should be appeared in the dir
Actual result:
--
Warning: move_uploaded_file(upload_files/Sunset.jpg)
[function.move-uploaded-file]: failed to open stream: Permission denied
in /var/www/html/simple_upload.php on line 47
Warning: move_uploaded_file() [function.move-uploaded-file]: Unable to
move '/tmp/phpO1zvJO' to 'upload_files/Sunset.jpg' in
/var/www/html/simple_upload.php on line 47
Somthing is wrong with uploading a file.
--
Edit this bug report at http://bugs.php.net/?id=30858&edit=1
#30630 [Fbk->NoF]: Error message: Call to a member function on a non-object
ID: 30630 Updated by: [EMAIL PROTECTED] Reported By: boccara at netvision dot net dot il -Status: Feedback +Status: No Feedback Bug Type: Reproducible crash Operating System: win 2K / apache 2.0.49 PHP Version: 4.3.9 New Comment: 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". Previous Comments: [2004-11-21 18:50:55] boccara at netvision dot net dot il Let me some times to prepare a short script [2004-11-19 01:00:02] 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". [2004-11-11 14:00:16] [EMAIL PROTECTED] Please, simplify your reproduce script as much as possible. I'm unable to get where the bug is and your explanations do not help much. [2004-11-01 22:10:11] boccara at netvision dot net dot il If I could I would be short but this bug is quite strange so I gave you a part of the code and part of the result. The result is explained in a few line, you don't have to read the 300 lines !!. I lost a lot of time because of this possible bug, so please take at less 5 mn to read my explains. thank you. [2004-11-01 21:03:59] [EMAIL PROTECTED] Please make a short reproducing script (max 15 lines if you can). 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/30630 -- Edit this bug report at http://bugs.php.net/?id=30630&edit=1
#30924 [NEW]: HTTP POST file upload problem
From: himself at zhwau dot net Operating system: Windows XP PHP version: 5.0.2 PHP Bug Type: Unknown/Other Function Bug description: HTTP POST file upload problem Description: When trying to POST upload a file with the proper tag, including the proper enctype and all (but without size restriction with MAX_FILE_SIZE as in manual example), the receiving script defined in ACTION results in move_uploaded_file() returning TRUE even though the file wasn't moved at all. Odd things happen when you try reloading the ACTION target page which makes Firefox repost the data - the second time around, the PHP script moves the file, even though it is assigned a different temp file name. Then everything works fine. Could this be the result of a write-behind process for the filesystem which makes move_uploaded_file() return true even if it didn't move the actual file? Reproduce code: --- Expected result: Should execute the 'ELSE' part of the sentence, since the move_upload_file() should return true in the case of a failed file move - unless it only detects whether or not the tmp_name file exists. Actual result: -- First time around, the move_uploaded_file() returns true (meaning the temp file exists) but the file isn't moved to $ime (i.e. the same dir where the script is executed). If you reload the page (and repost the same data), the tmp_name changes while all stays the same and the file is successfully moved. -- Edit bug report at http://bugs.php.net/?id=30924&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=30924&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=30924&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=30924&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=30924&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=30924&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=30924&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=30924&r=needscript Try newer version: http://bugs.php.net/fix.php?id=30924&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=30924&r=support Expected behavior: http://bugs.php.net/fix.php?id=30924&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=30924&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=30924&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=30924&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=30924&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=30924&r=dst IIS Stability: http://bugs.php.net/fix.php?id=30924&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=30924&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=30924&r=float MySQL Configuration Error: http://bugs.php.net/fix.php?id=30924&r=mysqlcfg
#30925 [NEW]: HTTP POST file upload problem
From: himself at zhwau dot net Operating system: Windows XP PHP version: 5.0.2 PHP Bug Type: Unknown/Other Function Bug description: HTTP POST file upload problem Description: When trying to POST upload a file with the proper tag, including the proper enctype and all (but without size restriction with MAX_FILE_SIZE as in manual example), the receiving script defined in ACTION results in move_uploaded_file() returning TRUE even though the file wasn't moved at all. Odd things happen when you try reloading the ACTION target page which makes Firefox repost the data - the second time around, the PHP script moves the file, even though it is assigned a different temp file name. Then everything works fine. Could this be the result of a write-behind process for the filesystem which makes move_uploaded_file() return true even if it didn't move the actual file? Reproduce code: --- Expected result: Should execute the 'ELSE' part of the sentence, since the move_upload_file() should return true in the case of a failed file move - unless it only detects whether or not the tmp_name file exists. Actual result: -- First time around, the move_uploaded_file() returns true (meaning the temp file exists) but the file isn't moved to $ime (i.e. the same dir where the script is executed). If you reload the page (and repost the same data), the tmp_name changes while all stays the same and the file is successfully moved. Apache 2.0.52 / PHP 5.0.2 running on WinXP SP2 -- Edit bug report at http://bugs.php.net/?id=30925&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=30925&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=30925&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=30925&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=30925&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=30925&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=30925&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=30925&r=needscript Try newer version: http://bugs.php.net/fix.php?id=30925&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=30925&r=support Expected behavior: http://bugs.php.net/fix.php?id=30925&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=30925&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=30925&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=30925&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=30925&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=30925&r=dst IIS Stability: http://bugs.php.net/fix.php?id=30925&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=30925&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=30925&r=float MySQL Configuration Error: http://bugs.php.net/fix.php?id=30925&r=mysqlcfg
#30925 [Opn->Bgs]: HTTP POST file upload problem
ID: 30925 Updated by: [EMAIL PROTECTED] Reported By: himself at zhwau dot net -Status: Open +Status: Bogus Bug Type: Unknown/Other Function Operating System: Windows XP PHP Version: 5.0.2 New Comment: Submitted twice. Previous Comments: [2004-11-29 01:30:08] himself at zhwau dot net Description: When trying to POST upload a file with the proper tag, including the proper enctype and all (but without size restriction with MAX_FILE_SIZE as in manual example), the receiving script defined in ACTION results in move_uploaded_file() returning TRUE even though the file wasn't moved at all. Odd things happen when you try reloading the ACTION target page which makes Firefox repost the data - the second time around, the PHP script moves the file, even though it is assigned a different temp file name. Then everything works fine. Could this be the result of a write-behind process for the filesystem which makes move_uploaded_file() return true even if it didn't move the actual file? Reproduce code: --- Expected result: Should execute the 'ELSE' part of the sentence, since the move_upload_file() should return true in the case of a failed file move - unless it only detects whether or not the tmp_name file exists. Actual result: -- First time around, the move_uploaded_file() returns true (meaning the temp file exists) but the file isn't moved to $ime (i.e. the same dir where the script is executed). If you reload the page (and repost the same data), the tmp_name changes while all stays the same and the file is successfully moved. Apache 2.0.52 / PHP 5.0.2 running on WinXP SP2 -- Edit this bug report at http://bugs.php.net/?id=30925&edit=1
#30923 [Bgs]: MySQL Client API version stagnant
ID: 30923 Updated by: [EMAIL PROTECTED] Reported By: mfurdyk at takingitglobal dot org Status: Bogus Bug Type: MySQL related Operating System: RH 7.3 PHP Version: 4.3.9 New Comment: You probably have some rogue mysql headers around. Make sure to get rid of them all before installing new version. --with-mysql=/path/to/mysql should work fine with the new client library. Previous Comments: [2004-11-29 00:13:40] mfurdyk at takingitglobal dot org No, I don't (at this point) care about using those features, I just want to know why the Client API version is setting at 3.X -- does this matter? It just seems weird, and thought it might explain some random mySQL errors (unable to save result set) that someone suggested were due to incorrect Client API. -- In terms of mySQLi, is there a way to have the existing mysql_query / mysql_fetch_assoc use the mysqli variants without doing a huge find/replace on all code? [2004-11-29 00:10:20] [EMAIL PROTECTED] If you want to use the new features of MySQL 4.1+, like the new binary protocol, you need to use PHP 5 and the MySQLi extension. (MySQLi, not MySQL.) You cannot use the new client protocol with PHP 4. [2004-11-28 23:43:43] mfurdyk at takingitglobal dot org updated summary...kept old one. [2004-11-28 23:41:05] mfurdyk at takingitglobal dot org Description: I'm trying to upgrade the Client API version, and I've upgraded mySQL, deleted the old libraries, and installed the new 4.1.7-Shared and devel packages, but with --with-mysql=user and --with-mysql=/path/to/mysql, the old client API version still sticks around. With a new server I've installed, it pops up to 4.1.7 fine. Reproduce code: --- Here's my build: './configure' '--with-mysql=/usr' '--with-apxs=/usr/local/apache/bin/apxs' '--with-zlib' '--with-gd=/usr/local/lib' '--with-jpeg-dir=/usr/local/bin' '--with-png-dir=/usr/lib' '--enable-inline-optimization' '--with-curl' '--disable-debug' '--with-mcrypt=/usr/local/src/libmcrypt-2.5.7' '--with-mhash' '--enable-ftp' '--enable-mbstring' Expected result: Upgrade to 4.1.7 -- Edit this bug report at http://bugs.php.net/?id=30923&edit=1
#30926 [NEW]: change the return value of socket_select() !
From: igor at gameplasma dot com Operating system: Linux PHP version: Irrelevant PHP Bug Type: Feature/Change Request Bug description: change the return value of socket_select() ! Description: Hi, I've noticed that when using socket_select() it will return an integer greater than 0 when something has happened to one of the sockets we are watching. Then, if we are watching, say 100 sockets, we must go through each one of them until we find the one we can now access. Instead, how about returning an array with 2 elements? $array[0] will be a pointer to the socket that was changed $array[1] will be "r" or "w" or "e" to indicate whether it's now avaible for read, write, or there is an error :). Thanks! -- Edit bug report at http://bugs.php.net/?id=30926&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=30926&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=30926&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=30926&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=30926&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=30926&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=30926&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=30926&r=needscript Try newer version: http://bugs.php.net/fix.php?id=30926&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=30926&r=support Expected behavior: http://bugs.php.net/fix.php?id=30926&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=30926&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=30926&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=30926&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=30926&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=30926&r=dst IIS Stability: http://bugs.php.net/fix.php?id=30926&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=30926&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=30926&r=float MySQL Configuration Error: http://bugs.php.net/fix.php?id=30926&r=mysqlcfg
#30927 [NEW]: zend_strtod.c compile failure
From: php_bug at cklowe dot com Operating system: Darwin 10.3.6 PHP version: 4.3.10RC1 PHP Bug Type: Compile Failure Bug description: zend_strtod.c compile failure Description: zend_strtod.c fails to compile, it fails on the #define trap for multiple floating point types, zend_strtod.c:228 This is not dissimilar to bug #30779 fixed on the 5 branch. -- Edit bug report at http://bugs.php.net/?id=30927&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=30927&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=30927&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=30927&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=30927&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=30927&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=30927&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=30927&r=needscript Try newer version: http://bugs.php.net/fix.php?id=30927&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=30927&r=support Expected behavior: http://bugs.php.net/fix.php?id=30927&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=30927&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=30927&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=30927&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=30927&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=30927&r=dst IIS Stability: http://bugs.php.net/fix.php?id=30927&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=30927&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=30927&r=float MySQL Configuration Error: http://bugs.php.net/fix.php?id=30927&r=mysqlcfg
#30923 [Bgs]: MySQL Client API version stagnant
ID: 30923 User updated by: mfurdyk at takingitglobal dot org Reported By: mfurdyk at takingitglobal dot org Status: Bogus Bug Type: MySQL related Operating System: RH 7.3 PHP Version: 4.3.9 New Comment: Which files does it look for specifically? I think I've done a relatively thorough uninstall Previous Comments: [2004-11-29 02:48:04] [EMAIL PROTECTED] You probably have some rogue mysql headers around. Make sure to get rid of them all before installing new version. --with-mysql=/path/to/mysql should work fine with the new client library. [2004-11-29 00:13:40] mfurdyk at takingitglobal dot org No, I don't (at this point) care about using those features, I just want to know why the Client API version is setting at 3.X -- does this matter? It just seems weird, and thought it might explain some random mySQL errors (unable to save result set) that someone suggested were due to incorrect Client API. -- In terms of mySQLi, is there a way to have the existing mysql_query / mysql_fetch_assoc use the mysqli variants without doing a huge find/replace on all code? [2004-11-29 00:10:20] [EMAIL PROTECTED] If you want to use the new features of MySQL 4.1+, like the new binary protocol, you need to use PHP 5 and the MySQLi extension. (MySQLi, not MySQL.) You cannot use the new client protocol with PHP 4. [2004-11-28 23:43:43] mfurdyk at takingitglobal dot org updated summary...kept old one. [2004-11-28 23:41:05] mfurdyk at takingitglobal dot org Description: I'm trying to upgrade the Client API version, and I've upgraded mySQL, deleted the old libraries, and installed the new 4.1.7-Shared and devel packages, but with --with-mysql=user and --with-mysql=/path/to/mysql, the old client API version still sticks around. With a new server I've installed, it pops up to 4.1.7 fine. Reproduce code: --- Here's my build: './configure' '--with-mysql=/usr' '--with-apxs=/usr/local/apache/bin/apxs' '--with-zlib' '--with-gd=/usr/local/lib' '--with-jpeg-dir=/usr/local/bin' '--with-png-dir=/usr/lib' '--enable-inline-optimization' '--with-curl' '--disable-debug' '--with-mcrypt=/usr/local/src/libmcrypt-2.5.7' '--with-mhash' '--enable-ftp' '--enable-mbstring' Expected result: Upgrade to 4.1.7 -- Edit this bug report at http://bugs.php.net/?id=30923&edit=1
#30928 [NEW]: When Using WSDL, SoapServer doesn't handle private or protected properties
From: david at giffin dot org Operating system: Linux PHP version: 5CVS-2004-11-29 (dev) PHP Bug Type: SOAP related Bug description: When Using WSDL, SoapServer doesn't handle private or protected properties Description: When using WSDL with a complex type definition the SoapServer doesn't handle static, private or protected properties correctly. SoapServer returns a SoapFault: "SOAP-ERROR: Encoding: object hasn't '' property." Where '' is the property defined as static, private or protected. FYI: This bug is similar to Bug #30799. Bug #30799 is fixed when returning a user defined object, which is not defined in the WSDL. Reproduce code: --- I can post some code if you need it. It would be too much code for this form. Expected result: The SoapServer would return the data present in the static, private or protected property if it is defined as an element for the complexType defined in the WSDL. Actual result: -- The SoapServer returns a SoapFault: "SOAP-ERROR: Encoding: object hasn't '' property." -- Edit bug report at http://bugs.php.net/?id=30928&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=30928&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=30928&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=30928&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=30928&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=30928&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=30928&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=30928&r=needscript Try newer version: http://bugs.php.net/fix.php?id=30928&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=30928&r=support Expected behavior: http://bugs.php.net/fix.php?id=30928&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=30928&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=30928&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=30928&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=30928&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=30928&r=dst IIS Stability: http://bugs.php.net/fix.php?id=30928&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=30928&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=30928&r=float MySQL Configuration Error: http://bugs.php.net/fix.php?id=30928&r=mysqlcfg
#28610 [Com]: ISAPI MSSQL horribly slow
ID: 28610 Comment by: darpa at yandex dot ru Reported By: michael dot lidgren at cypoint dot se Status: Open Bug Type: Performance problem Operating System: Windows Server 2003 PHP Version: 4.3.6 New Comment: I have the problem with PHP 5.02,Windows 2003, ISAPI module. Previous Comments: [2004-11-28 06:09:28] cabadam at tamu dot edu I've got the same thing here - except still a problem with PHP 5 (Windows 2003, ISAPI module). [2004-11-11 14:51:27] extranet at skoda-auto dot de Same Problem here, php ist extremely slow under Windows 2003 Server running in ISAPI Mode. CGI Speed it up but it doesnt reach Speed like running under Windows 2000. Any Help possible? Output Buffering = On helps a lot but it is still slower than in windows 2000. [2004-11-09 11:49:11] i_know_u21 at yahoo dot com I consider PHP as the best web tool I have experienced, but I have been experiencing the same problem, I have a big PHP application, running on Windows XP/2000/2003, I used to use CGI under IIS but i constantly got the error "CGI scripts doesn't behave"! i tried all that was written in all web sites i searched within but still CGI never behaved! so i had to switch to ISAPI. I noticed how slower ISAPI is compared to CGI, but this never was a problem when few records were retrieved from MS SQL (from 20 to 100) now my application grows into 1500 to 2500 and growing too much more, and this is a great problem now since retrieving 2000 records (Only Retrieving) took me about 3 minutes. while some other page with extensive calculations on the 2000 records took exactly 7:30 minutes. As a test, I have switched to CGI, because I had the feeling that ISAPI has something to do with it, and it took exactly 2 seconds to retrieve 2500 records! so now i am positive that ISAPI has something to do with that draw back! maybe there is some settings between ISAPI - MSSQL - ISS that i should fix! because using CGI is not an option at all because of the frequent (The specified CGI application misbehaved by not returning a complete set of HTTP headers. The headers it did return are:) errors i had, especially in multi-frames pages with MSSQL actions. I have tried versions PHP 4.3.3 until 4.3.6, same trouble. Thanks for listening to our troubles :) [2004-10-08 17:24:24] john at appliedgroup dot com I am having the same issue with W2K3/IIS and mysql. Same problem with php 4.3.7 and 4.3.9 Even weirder is that only some systems on the network were affected Changing to CGI speeded everything up. [2004-06-08 23:35:27] andy at advancethermal dot com Experiencing the same problem with WindowsXP / Apache 2.0 / PHP 4.3.7 / MS SQL Server 2k (Evaluation Version). Queries take about 3-4x longer through mssql_query than odbc_exec. 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/28610 -- Edit this bug report at http://bugs.php.net/?id=28610&edit=1
#30920 [Bgs]: SimpleXML : tags with "xs:" prefix
ID: 30920
Updated by: [EMAIL PROTECTED]
Reported By: hieu at laposte dot net
Status: Bogus
Bug Type: XML related
Operating System: windows xp
PHP Version: 5.0.2
New Comment:
read the article mentioned above at zend, especially the part about
namespaces.. It's not a bug. You have to use the method "children()"
Previous Comments:
[2004-11-28 20:26:04] hieu at laposte dot net
print_r doesn't work correctly with simplexml, okay... but please read
this new code, it doesn't use print_r and shows the same bug :
bug.xsd =
http://www.w3.org/2001/XMLSchema";>
$xml = simplexml_load_file("bug.xsd");
$elt = $xml->element;
$attr = (string) $elt['name'];
echo $attr;
=> nothing is printed...
if i remove the "xs:" prefix in the xsd file, this same code displays :
"dataset"
[2004-11-28 12:07:14] [EMAIL PROTECTED]
print_r and var_dump don't work reliably on simplexml objects... do
*not* use them or even rely on them...
And see http://www.zend.com/php5/articles/php5-simplexml.php for more
info about SimpleXML and Namespaces
[2004-11-27 17:55:59] hieu at laposte dot net
Description:
When the xml file contains this "xs:" prefix, the file is not correctly
parsed.
Reproduce code:
---
The XML file is :
http://www.w3.org/2001/XMLSchema";
xmlns:msdata="urn:schemas-microsoft-com:xml-msdata">
data:IsDataSet="true"; msdata:Locale="fr-FR";>
...
Php 5 code :
$oXml = simplexml_load_file($sFileName);
print_r($oXml->element);
// doesn't work, nothing printed...
PS : this code works correctly :
$oXml = simplexml_load_file($sFileName);
$aXml = get_object_vars($oXml);
print_r($aXml['element']);
// ok i can now access the "element".
Expected result:
SimpleXMLElement Object
(
[complexType] => SimpleXMLElement Object
(
.
)
)
Actual result:
--
SimpleXMLElement Object
(
)
--
Edit this bug report at http://bugs.php.net/?id=30920&edit=1
#30927 [Opn->Ana]: zend_strtod.c compile failure
ID: 30927 Updated by: [EMAIL PROTECTED] Reported By: php_bug at cklowe dot com -Status: Open +Status: Analyzed Bug Type: Compile Failure Operating System: Darwin 10.3.6 PHP Version: 4.3.10RC1 -Assigned To: +Assigned To: derick Previous Comments: [2004-11-29 04:25:53] php_bug at cklowe dot com Description: zend_strtod.c fails to compile, it fails on the #define trap for multiple floating point types, zend_strtod.c:228 This is not dissimilar to bug #30779 fixed on the 5 branch. -- Edit this bug report at http://bugs.php.net/?id=30927&edit=1
#30927 [Opn->Asn]: zend_strtod.c compile failure
ID: 30927 Updated by: [EMAIL PROTECTED] Reported By: php_bug at cklowe dot com -Status: Open +Status: Assigned Bug Type: Compile Failure Operating System: Darwin 10.3.6 PHP Version: 4.3.10RC1 -Assigned To: +Assigned To: derick Previous Comments: [2004-11-29 04:25:53] php_bug at cklowe dot com Description: zend_strtod.c fails to compile, it fails on the #define trap for multiple floating point types, zend_strtod.c:228 This is not dissimilar to bug #30779 fixed on the 5 branch. -- Edit this bug report at http://bugs.php.net/?id=30927&edit=1
#30058 [Opn->Fbk]: Yet Another Solaris compilation problem :-((
ID: 30058 Updated by: [EMAIL PROTECTED] Reported By: l_faillie at yahoo dot com -Status: Open +Status: Feedback Bug Type: FTP related Operating System: Solaris 8 PHP Version: 4.3.8 New Comment: Ok, marking it as awaiting for feedback, until you're able to add more info about it. Previous Comments: [2004-11-28 20:34:39] l_faillie at yahoo dot com No, I haven't time to go deeper yet :( [2004-11-28 16:42:26] [EMAIL PROTECTED] l_faillie at yahoo dot com: Do you have any additional info about it? [2004-10-07 20:32:02] l_faillie at yahoo dot com Oups, yes, you're right ! Well, I've added new probe inside PHP_FUNCTION(ftp_put) [the right one ;-D] and it seems the problem come from the call of instream = php_stream_fopen(local, mode == FTPTYPE_ASCII ? "rt" : "rb", NULL); around line 890 that returns a NULL pointer. I continue to track this bug. [2004-10-06 17:16:55] [EMAIL PROTECTED] Why would PHP call ftp_fput() when your script doesn't have any calls to it in it? (you call ftp_put(), notice the missing 'f' in front of put...) [2004-10-05 22:43:32] l_faillie at yahoo dot com > This seems more like feature request (getting more info > as an error message if the ftp_*() functions fail..) > but anyway, It should be better if we have better message in case of failure, but as I said previously, I put some tracing puts() in ext/ftp/php_ftp.c and it seems that PHP_FUNCTION(ftp_fput), line 768 is never called. So for me it's more an issue in the PHP parser than in ftp function themselfs. Unfortunatly, I'm not confident enough w/ PHP parser to trace deeply in the code. > are you sure this isn't some firewall issue..? (like > I've had had to struggle with for last 6 months.. :) Yes, because both machines are on the same networks and I can connect using the normal Solaris FTP client. 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/30058 -- Edit this bug report at http://bugs.php.net/?id=30058&edit=1
#28610 [Com]: ISAPI MSSQL horribly slow
ID: 28610 Comment by: darpa at yandex dot ru Reported By: michael dot lidgren at cypoint dot se Status: Open Bug Type: Performance problem Operating System: Windows Server 2003 PHP Version: 4.3.6 New Comment: PROBLEM: Very slow ISAPI (MSSQL 2000, Windows 2003, PHP 5.02) SOLVED: In PHp.INI I set: output_buffering = 1500 or output_buffering = on Previous Comments: [2004-11-29 06:38:39] darpa at yandex dot ru I have the problem with PHP 5.02,Windows 2003, ISAPI module. [2004-11-28 06:09:28] cabadam at tamu dot edu I've got the same thing here - except still a problem with PHP 5 (Windows 2003, ISAPI module). [2004-11-11 14:51:27] extranet at skoda-auto dot de Same Problem here, php ist extremely slow under Windows 2003 Server running in ISAPI Mode. CGI Speed it up but it doesnt reach Speed like running under Windows 2000. Any Help possible? Output Buffering = On helps a lot but it is still slower than in windows 2000. [2004-11-09 11:49:11] i_know_u21 at yahoo dot com I consider PHP as the best web tool I have experienced, but I have been experiencing the same problem, I have a big PHP application, running on Windows XP/2000/2003, I used to use CGI under IIS but i constantly got the error "CGI scripts doesn't behave"! i tried all that was written in all web sites i searched within but still CGI never behaved! so i had to switch to ISAPI. I noticed how slower ISAPI is compared to CGI, but this never was a problem when few records were retrieved from MS SQL (from 20 to 100) now my application grows into 1500 to 2500 and growing too much more, and this is a great problem now since retrieving 2000 records (Only Retrieving) took me about 3 minutes. while some other page with extensive calculations on the 2000 records took exactly 7:30 minutes. As a test, I have switched to CGI, because I had the feeling that ISAPI has something to do with it, and it took exactly 2 seconds to retrieve 2500 records! so now i am positive that ISAPI has something to do with that draw back! maybe there is some settings between ISAPI - MSSQL - ISS that i should fix! because using CGI is not an option at all because of the frequent (The specified CGI application misbehaved by not returning a complete set of HTTP headers. The headers it did return are:) errors i had, especially in multi-frames pages with MSSQL actions. I have tried versions PHP 4.3.3 until 4.3.6, same trouble. Thanks for listening to our troubles :) [2004-10-08 17:24:24] john at appliedgroup dot com I am having the same issue with W2K3/IIS and mysql. Same problem with php 4.3.7 and 4.3.9 Even weirder is that only some systems on the network were affected Changing to CGI speeded everything up. 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/28610 -- Edit this bug report at http://bugs.php.net/?id=28610&edit=1
#30772 [Ana]: php_check_syntax collides with require_once
ID: 30772
User updated by: pecoes at web dot de
Reported By: pecoes at web dot de
Status: Analyzed
Bug Type: Zend Engine 2 problem
Operating System: irrelevant
PHP Version: 5.0.2, 5.1
Assigned To: andi
New Comment:
Hi Tony,
You haven't read my entire post. I've given *two* code samples. The
*second* is the reproduce code. Please note, that my reproduce code is
actually simpler, than what you have "reduced" it to.
My laymen's guess is that php_check_syntax doesn't add a script that
has proven to be faulty to the list require_once and include_once
maintain. The reasoning behind that is superficially seen sound. Why
would you want to try again to include code that has already proven to
be bad? Well, that's why I featured the "real life" sample prior to the
actual reproduce code. There's a scenario, where it's impossible to
avoid a new inclusion attempt, since class_exists *will* call
__autoload if the class doesn't exist.
Peter
Previous Comments:
[2004-11-16 09:16:25] [EMAIL PROTECTED]
Reproducible both with 5.0 & 5.1 branches.
Program received signal SIGSEGV, Segmentation fault.
0x0006 in ?? ()
(gdb) bt
#0 0x0006 in ?? ()
#1 0x in ?? ()
#2 0xbfffbf30 in ?? ()
#3 0xbfffbf68 in ?? ()
#4 0xbfffbeec in ?? ()
#5 0x0001 in ?? ()
#6 0x08226ebb in yy_chk ()
#7 0xbfffbf68 in ?? ()
#8 0x08188964 in zif_class_exists (ht=-1073758484, return_value=0x1,
this_ptr=0x8226ebb, return_value_used=-1073758360)
at /home/dev/php-src/Zend/zend_builtin_functions.c:907
Previous frame inner to this frame (corrupt stack?)
Reproduce code could be safely reduced to this:
[2004-11-13 10:24:20] pecoes at web dot de
Description:
The reproduce code is pretty straight-forward, which makes the issue
look easy to avoid. My real problem, however, is more subtle:
I'm writing an extensible library. All my internal classes are
__autoload'ed, but I want to treat all user-defined classes as tainted
and load them manually:
Test.php:
bug.php:
Reproduce code:
---
$file = "Test.php";
if (!php_check_syntax($file)) {
die("$file cannot be included");
}
// the following line should do nothing!
require_once $file;
Expected result:
no crash
Actual result:
--
"Fatal Error: Cannot redeclare class..."
and then php(cli) crashes hard!
--
Edit this bug report at http://bugs.php.net/?id=30772&edit=1
#30858 [Opn->Fbk]: Upload permission error
ID: 30858
Updated by: [EMAIL PROTECTED]
Reported By: michaelchikit at gmail dot com
-Status: Open
+Status: Feedback
Bug Type: Filesystem function related
Operating System: Fedora 3
PHP Version: 5.0.2
New Comment:
But in addition to upgrade of PHP you upgraded the whole server.
Please, add more information on how we can reproduce your problem.
Previous Comments:
[2004-11-29 00:27:31] michaelchikit at gmail dot com
Because I have tried this script into a older version PHP server, this
is working.
But my new PHP5 + Apache 2 server can't make this script working.
[2004-11-27 09:28:49] [EMAIL PROTECTED]
Why do you think it's a bug in PHP and how can we reproduce it?
[2004-11-26 01:11:42] michaelchikit at gmail dot com
I tried to use abd path.
This is not working
[2004-11-25 23:10:27] [EMAIL PROTECTED]
Try it using absolute path for destination file.
[2004-11-22 06:02:13] michaelchikit at gmail dot com
Description:
I have tried this code in my old server that is working very fine. But
after I upgraded my server into Fedora 3 and PHP 5.0.2. that generated
the followings error. The server does not allow me to upload the file
and say permission denied. But I am very very sure, I have set the
correct permission with the dir. The mode of upload_files and its
parenet dir are 0777.
Is it a bug of PHP?
Reproduce code:
---
$temp_name = $_FILES['userfile']['tmp_name'];
$file_name = $_FILES['userfile']['name'];
$file_type = $_FILES['userfile']['type'];
$file_size = $_FILES['userfile']['size'];
$result= $_FILES['userfile']['error'];
$file_url = $upload_url.$file_name;
$file_path = $upload_dir.$file_name;
//File Name Check
if ( $file_name =="") {
$message = "Invalid File Name Specified";
return $message;
}
$result = move_uploaded_file($temp_name, $file_path);
Expected result:
No Error , the file should be appeared in the dir
Actual result:
--
Warning: move_uploaded_file(upload_files/Sunset.jpg)
[function.move-uploaded-file]: failed to open stream: Permission denied
in /var/www/html/simple_upload.php on line 47
Warning: move_uploaded_file() [function.move-uploaded-file]: Unable to
move '/tmp/phpO1zvJO' to 'upload_files/Sunset.jpg' in
/var/www/html/simple_upload.php on line 47
Somthing is wrong with uploading a file.
--
Edit this bug report at http://bugs.php.net/?id=30858&edit=1
#30928 [Opn->Asn]: When Using WSDL, SoapServer doesn't handle private or protected properties
ID: 30928 Updated by: [EMAIL PROTECTED] Reported By: david at giffin dot org -Status: Open +Status: Assigned Bug Type: SOAP related Operating System: Linux PHP Version: 5CVS-2004-11-29 (dev) -Assigned To: +Assigned To: dmitry Previous Comments: [2004-11-29 05:45:50] david at giffin dot org Description: When using WSDL with a complex type definition the SoapServer doesn't handle static, private or protected properties correctly. SoapServer returns a SoapFault: "SOAP-ERROR: Encoding: object hasn't '' property." Where '' is the property defined as static, private or protected. FYI: This bug is similar to Bug #30799. Bug #30799 is fixed when returning a user defined object, which is not defined in the WSDL. Reproduce code: --- I can post some code if you need it. It would be too much code for this form. Expected result: The SoapServer would return the data present in the static, private or protected property if it is defined as an element for the complexType defined in the WSDL. Actual result: -- The SoapServer returns a SoapFault: "SOAP-ERROR: Encoding: object hasn't '' property." -- Edit this bug report at http://bugs.php.net/?id=30928&edit=1
