#26738 [NEW]: PHP-OCI binding error
From: mbaranidharan at yahoo dot com
Operating system: windows/linux
PHP version: 4.3.4
PHP Bug Type: OCI8 related
Bug description: PHP-OCI binding error
Description:
Trying to call a package in oracle which will return a parameter of type
table. When i try calling the procedure from PHP using OCI iam getting
wrong types or parameters.
Reproduce code:
---
$sql="declare var1 xxx.tbl_date;var2 xxx.tbl_varchar;";
$sql=$sql."begin xxx(3,:var1,:var2,:var3);end;";
$conn = OCILogon("usr","pwd","servername");
$stmt = OCIParse($conn,$sql);
OCIBindByname($stmt,'var1',$var1);
OCIBindByname($stmt,'var2',$var2);
OCIBindByname($stmt,'var3',$var3);
$rs = OCIExecute($stmt);
Expected result:
The result should be stored in the recordset which later can be iterated
and get the values from each array variable var1,2 and 3.
--
Edit bug report at http://bugs.php.net/?id=26738&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=26738&r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=26738&r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=26738&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=26738&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=26738&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=26738&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=26738&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=26738&r=support
Expected behavior: http://bugs.php.net/fix.php?id=26738&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=26738&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=26738&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=26738&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=26738&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=26738&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=26738&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=26738&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=26738&r=float
#26736 [Opn->Csd]: __autoload not invoked for parent classes
ID: 26736
Updated by: [EMAIL PROTECTED]
-Summary: __autoload not invoked for missing parent classes
Reported By: jaanus at heeringson dot com
-Status: Open
+Status: Closed
Bug Type: Class/Object related
Operating System: *
PHP Version: 5.0.0b3
Assigned To: helly
New Comment:
This bug has been fixed in CVS.
In case this was a PHP problem, 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/.
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.
In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2003-12-28 21:06:12] jaanus at heeringson dot com
Description:
Autoload is not invoked for missing parent class in object declaration.
This worked with php5-beta2.
Reproduce code:
---
Child_class and Parent_class are in separate documents. Autoload
function is working.
class Child_class extends Parent_class {
}
$class=new Child_class();
Expected result:
No errors, everything loads.
Actual result:
--
Fatal error: Class 'Parent_class' not found in [path to Child_class
document] on line 2
--
Edit this bug report at http://bugs.php.net/?id=26736&edit=1
#26739 [NEW]: __call() doesn't work for class methods
From: demiurg at terra dot es Operating system: Windows XP Pro PHP version: 5CVS-2003-12-29 (dev) PHP Bug Type: Zend Engine 2 problem Bug description: __call() doesn't work for class methods Description: Hello, I'm not sure whether it is a bug or a feature, so I just point this out and you decide. __class() method works like OK for objects, but completely fails when calling a class method (see Reproduce Code). P.S. Before sending this report, I did a search on "__call" and have found 11 bugs, none of which describes the issue. Thanks! Reproduce code: --- test(1, 2, 3); a::test(3, 2, 1); ?> Expected result: Called test(1, 2, 3) Called test(3, 2, 1) Actual result: -- Called test(1, 2, 3) Fatal error: Call to undefined method a::test() in a.php on line 12 -- Edit bug report at http://bugs.php.net/?id=26739&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=26739&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=26739&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=26739&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=26739&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=26739&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=26739&r=needscript Try newer version: http://bugs.php.net/fix.php?id=26739&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=26739&r=support Expected behavior: http://bugs.php.net/fix.php?id=26739&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=26739&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=26739&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=26739&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=26739&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=26739&r=dst IIS Stability: http://bugs.php.net/fix.php?id=26739&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=26739&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=26739&r=float
#26633 [Bgs->Opn]: exec(), system() and backtick give maximum execution time error with Apache
ID: 26633
User updated by: jruffer at hss dot co dot uk
Reported By: jruffer at hss dot co dot uk
-Status: Bogus
+Status: Open
Bug Type: Apache related
Operating System: DG/UX
PHP Version: 4.3.4
New Comment:
I could compile without changing the sources by adding a CFLAG of
-DHAVE_SCANDIR and by creating a library with the extra function.
Don't you support PHP on Unix?
Previous Comments:
[2003-12-16 05:39:54] jruffer at hss dot co dot uk
DG/UX is the OS used by Data General Unix machines. It uses GNU C. I
made the changes because it would not compile without them.
[2003-12-15 17:14:11] [EMAIL PROTECTED]
Dunno what DG/UX even is, apparently not any OS we can support. (and as
you have modified the sources yourself..)
[2003-12-15 12:53:00] jruffer at hss dot co dot uk
set_time_limit(0) makes it work.
[2003-12-15 12:28:32] jruffer at hss dot co dot uk
Description:
These functions work fine using the CLI but when used with Apache give
a spurious execution timeout error. I tried setting the timeout to
3 and it still happened immediately. The problem occurs with any
command that I try to call using system(), exec() or backtick. I do
not have safe-mode enabled.
I did have a couple of porting problems with DG/UX. I had to add
#include to main/php_scandir.h and
double expm1(double x)
{
return(exp(x));
}
before #include "php.h" in ext/standard/math.c
'./configure' '--with-ingres=/OI/ingres' '--without-mysql'
'--enable-ftp' '--enable-cli' '--enable-cgi'
'--with-apache=/usr/opt/apache/apache_1.3.29'
php.ini:
safe_mode_exec_dir = /usr/
log_errors = On
report_memleaks = Off
track_errors = On
error_log = /usr/opt/apache/www/logs/php.log
sendmail_from = [EMAIL PROTECTED]
ingres.allow_persistent = Off
ingres.default_database = divtest
ingres.default_user = devdba
Reproduce code:
---
\n";
print "Attempting to run `ls -l` \n";
$list = `ls -l`;
foreach($list as $value) {
print "$list\n";
print "\n";
?>
Expected result:
Attempting to run `ls -l`
total 97 -rw-r--r-- 1 jeremy general 5520 Dec 12 09:56 build_status.php
-rw-r--r
-- 1 jeremy general 501 Dec 12 10:24 cr.menu -rw-r--r-- 1 jeremy
general 365 Dec
2 08:49 debug.inc lrwxrwxrwx 1 jeremy general 11 Dec 2 09:36 doc ->
/phase3/doc
-rw-r--r-- 1 jeremy general 3868 Dec 10 18:29 image_request.php
-rw-r--r-- 1 je
remy other 2543 Dec 2 17:31 images.php -rw-r--r-- 1 jeremy general 86
Dec 12 11:
00 index.html -rw-r--r-- 1 jeremy general 362 Dec 1 16:12
index.old.html -rw-r--
r-- 1 jeremy general 77 Dec 10 12:08 info.php -rw-r--r-- 1 jeremy
general 105 De
c 12 11:21 ingkey.err -rw-r--r-- 1 jeremy general 386 Dec 12 12:21
init.inc -rw-
r--r-- 1 jeremy general 786 Dec 12 15:17 login.inc -rw-r--r-- 1 jeremy
general 2
05 Dec 12 11:10 login.php -rw-r--r-- 1 jeremy general 863 Dec 12 10:55
menu.php
-rw-r--r-- 1 jeremy general 1899 Dec 3 10:31 release.php -rw-r--r-- 1
jeremy gen
eral 569 Dec 7 10:08 resume.php -rw-r--r-- 1 jeremy general 1041 Dec 11
17:52 ru
n_signoff.php -rw-r--r-- 1 jeremy general 857 Dec 12 15:18 secure.inc
-rw-r--r--
1 jeremy general 6712 Dec 15 09:30 signoff.php -rw-r--r-- 1 jeremy
general 1046
Dec 3 11:37 suspend.php -rw-r--r-- 1 jeremy general 619 Dec 5 16:45
tech.html -
rw-r--r-- 1 jeremy general 155 Dec 15 17:08 test.php -rw-r--r-- 1
jeremy general
2379 Dec 10 16:51 update_queue.php -rw-r--r-- 1 jeremy general 2783
Dec 10 16:4
8 update_queue.v1.php -rw-r--r-- 1 jeremy general 277 Dec 12 12:23
wrap.inc
Actual result:
--
Attempting to run `ls -l`
Fatal error: Maximum execution time of 30 seconds exceeded in
/usr/opt/apache/www/htdocs/image/test.php on line 4
--
Edit this bug report at http://bugs.php.net/?id=26633&edit=1
#16626 [Com]: Only last cookie set
ID: 16626 Comment by: erezoom at netvision dot net dot il Reported By: svein dot olav at bjerkeset dot com Status: Closed Bug Type: Apache2 related Operating System: All PHP Version: 4.2.1 New Comment: I have the same problem I installed the latesed versions but still it's not working !!! What to do? look: www.artic.co.il Previous Comments: [2002-06-20 14:55:19] marcum at austin dot rr dot com I downloaded the latest cvs snapshot (php4.3 on 06/20) from http://snaps.php.net/ and compiled with apache 2.0.39. The setcookie function seems to be working in that release. [2002-06-20 10:03:18] red at tripany dot com Well after extensive testing, I have to conclude it's probably not a php (alone) problem. I have tried: PHP ver. Apache ver.--enable-soworks? error - 4.2.12.0.39 yes no yes 2.1 36 yes yesno 2.0 39 yes no yes 2.0 36 nono yes 2.0 36 yes yesno 4.0.3pl1 1.3.9 ? yes? (4.0.3pl1 is the standard debian package) The rest of the 2.1 installations (with apache 39) don't work and give errors, so there's some problem with the apxs interaction between php and httpd 2.0.39. As php2.1.0 works with httpd 2.0.36 I'm now assuming there was a change in the apxs of apache in the security fix version which renders the multiple cookies unwriteable. I'll send this off to apache as well. Cheers Robin [2002-06-20 07:41:07] [EMAIL PROTECTED] Dup of #17663, please update only that bugreport! Derick [2002-05-17 03:12:48] [EMAIL PROTECTED] This bug has been fixed in CVS. You can grab a snapshot of the CVS version at http://snaps.php.net/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites. Thank you for the report, and for helping us make PHP better. Patch committed. Thanks, regina! [2002-05-03 01:11:05] regina at hitel dot net I did fix this problem by modifing "ext/standard/head.c". The diff is below. 124c124 < return sapi_add_header(cookie, strlen(cookie), 0); --- > return sapi_add_header_ex(cookie, strlen(cookie), 0, 0 TSRMLS_CC); PS) This bug should be killed at next version. May be 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/16626 -- Edit this bug report at http://bugs.php.net/?id=16626&edit=1
#26739 [Opn]: __call() doesn't work for static methods
ID: 26739 Updated by: [EMAIL PROTECTED] -Summary: __call() doesn't work for class methods Reported By: demiurg at terra dot es Status: Open -Bug Type: Zend Engine 2 problem +Bug Type: Feature/Change Request -Operating System: Windows XP Pro +Operating System: * -PHP Version: 5CVS-2003-12-29 (dev) +PHP Version: 5.0.0 New Comment: __call() doesn't offer anything to distinguish between static and dynamic calls. So we'd need a new magic function say __static_call(). For 5.0.0 we have a feature freeze already, so this might take a while. Previous Comments: [2003-12-29 07:50:16] demiurg at terra dot es Description: Hello, I'm not sure whether it is a bug or a feature, so I just point this out and you decide. __class() method works like OK for objects, but completely fails when calling a class method (see Reproduce Code). P.S. Before sending this report, I did a search on "__call" and have found 11 bugs, none of which describes the issue. Thanks! Reproduce code: --- test(1, 2, 3); a::test(3, 2, 1); ?> Expected result: Called test(1, 2, 3) Called test(3, 2, 1) Actual result: -- Called test(1, 2, 3) Fatal error: Call to undefined method a::test() in a.php on line 12 -- Edit this bug report at http://bugs.php.net/?id=26739&edit=1
#26735 [Fbk->Opn]: php.ini not read
ID: 26735
User updated by: cmouse at youzen dot projectb2 dot net
Reported By: cmouse at youzen dot projectb2 dot net
-Status: Feedback
+Status: Open
Bug Type: PHP options/info functions
Operating System: Linux 2.4.23
PHP Version: 4.3.4
New Comment:
The problem was that PHP tells me it is using /etc/php/php.ini as FILE,
when this is PATH. Suprise suprise, it tries to read
/etc/php/php.ini/php.ini, which is not what I expected. A more clearer
configure item would be nice (and output of phpinfo()):
The strace readout:
$ strace -eopen php -r '' 2>&1 | grep ini
open("php/php-cli.ini", O_RDONLY) = -1 ENOENT (No such file or
directory)
open("/etc/php/php.ini/php-cli.ini", O_RDONLY) = -1 ENOTDIR (Not a
directory)
open("php/php.ini", O_RDONLY) = -1 ENOENT (No such file or
directory)
open("/etc/php/php.ini/php.ini", O_RDONLY) = -1 ENOTDIR (Not a
directory)
Previous Comments:
[2003-12-28 22:39:04] [EMAIL PROTECTED]
what does this (with correct path substiitution) return
you:
strace -eopen ./sapi/cli/php -r '' 2>&1 | grep ini
[2003-12-28 19:48:22] cmouse at youzen dot projectb2 dot net
Ah and here are mod_php clips:
Configuration File (php.ini) Path /etc/php/php.ini
cat /etc/php/php.ini | grep upload_tmp_dir
upload_tmp_dir = "/www/tmp"
upload_tmp_dir no value no value
[2003-12-28 19:45:55] cmouse at youzen dot projectb2 dot net
Ok.
Here goes:
php -r 'phpinfo();' | grep php.ini
Configuration File (php.ini) Path => /etc/php/php.ini
cat /etc/php/php.ini | grep upload_tmp_dir
upload_tmp_dir = "/www/tmp"
php -r 'phpinfo();' | grep upload_tmp_dir
upload_tmp_dir => no value => no value
[2003-12-28 19:40:28] [EMAIL PROTECTED]
Works fine for me:
19:49:41([EMAIL PROTECTED])[~/src/php-4.3.4]> ./sapi/cli/php -r
'phpinfo();' | grep php.ini
Configuration File (php.ini) Path => /usr/local/lib/php.ini
19:49:48([EMAIL PROTECTED])[~/src/php-4.3.4]> cat /usr/local/
lib/php.iniupload_tmp_dir = /www/tmp
19:49:57([EMAIL PROTECTED])[~/src/php-4.3.4]> ./sapi/cli/php -r
'phpinfo();' | grep upload_tmp_dir
upload_tmp_dir => /www/tmp => /www/tmp
Again, 10-1 your php.ini is not what you expect it is.
Please repeat the above steps on your system, If you are
running this as mod_php, make steps 1 and 3 be clips from
the html dump.
[2003-12-28 19:15:35] cmouse at youzen dot projectb2 dot net
I'll paste the thing I'm trying to modify:
### php.ini ###
; Temporary directory for HTTP uploaded files (will use system default
if not
; specified).
upload_tmp_dir = /www/tmp
### phpinfo() ###
upload_tmp_dir no value no value
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/26735
--
Edit this bug report at http://bugs.php.net/?id=26735&edit=1
#26740 [NEW]: Object Attribute Unexpectly Overwritten
From: leo at myleo dot info
Operating system: Linux
PHP version: 5.0.0b2 (beta2)
PHP Bug Type: Scripting Engine problem
Bug description: Object Attribute Unexpectly Overwritten
Description:
In the source code, $this->filepath is overwritten unexpectly in the
assignment
$this->$tempFilepath=$this->$filepath.".tmp";
Reproduce code:
---
class Zone{
var $path; // The path to store zone files
var $filepath; // The zone file with absolute filepath
var $tempFilepath; // Temporary file
var $domain; // Domain object
function Zone($domainTemp,$pathTemp){
if(preg_match("/^\//",$pathTemp)){
$this->$path=$pathTemp;
$this->$domain=new Domain($domainTemp.".");
$this->$filepath=$pathTemp."/".$domainTemp.".zone";
print $this->$filepath;
$this->$tempFilepath=$this->$filepath.".tmp";
print $this->$filepath;
...
...
Expected result:
I create the object
$zone=new Zone("mydomain.com","/var/named");
$this->$filepath should be /var/named.mydomain.com.zone
$this->$tempFilepath should be /var/named.mydomain.com.zone.tmp
Actual result:
--
both variable metioned above have the same value
/var/named.mydomain.com.zone.tmp
--
Edit bug report at http://bugs.php.net/?id=26740&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=26740&r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=26740&r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=26740&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=26740&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=26740&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=26740&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=26740&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=26740&r=support
Expected behavior: http://bugs.php.net/fix.php?id=26740&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=26740&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=26740&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=26740&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=26740&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=26740&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=26740&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=26740&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=26740&r=float
#26740 [Opn->Bgs]: Object Attribute Unexpectly Overwritten
ID: 26740
Updated by: [EMAIL PROTECTED]
Reported By: leo at myleo dot info
-Status: Open
+Status: Bogus
Bug Type: Scripting Engine problem
Operating System: Linux
PHP Version: 5.0.0b2 (beta2)
New Comment:
Bogus code, use $this->domain and not $this->$domain.
Previous Comments:
[2003-12-29 08:43:01] leo at myleo dot info
Description:
In the source code, $this->filepath is overwritten unexpectly in the
assignment
$this->$tempFilepath=$this->$filepath.".tmp";
Reproduce code:
---
class Zone{
var $path; // The path to store zone files
var $filepath; // The zone file with absolute filepath
var $tempFilepath; // Temporary file
var $domain; // Domain object
function Zone($domainTemp,$pathTemp){
if(preg_match("/^\//",$pathTemp)){
$this->$path=$pathTemp;
$this->$domain=new Domain($domainTemp.".");
$this->$filepath=$pathTemp."/".$domainTemp.".zone";
print $this->$filepath;
$this->$tempFilepath=$this->$filepath.".tmp";
print $this->$filepath;
...
...
Expected result:
I create the object
$zone=new Zone("mydomain.com","/var/named");
$this->$filepath should be /var/named.mydomain.com.zone
$this->$tempFilepath should be /var/named.mydomain.com.zone.tmp
Actual result:
--
both variable metioned above have the same value
/var/named.mydomain.com.zone.tmp
--
Edit this bug report at http://bugs.php.net/?id=26740&edit=1
#26741 [NEW]: Problem on Get Varchar Colunms from Oracle 9i
From: fernando at napl dot com dot br
Operating system: Linux RedHat 8
PHP version: 4.3.4
PHP Bug Type: OCI8 related
Bug description: Problem on Get Varchar Colunms from Oracle 9i
Description:
I have the Problem on fetch Columns Varchar os Char from oracle..
I Have changed the Group of Apache on httpd.conf to oracle user..
All ENV Variables on oracle user already ok..
On SQlplus this machi I not have problems...
Thanks for any help...
Reproduce code:
---
while ($arr_my_emp = mysql_fetch_row($exec_my_emp)) {
$sql_ora_emp="SELECT CD_EMP,NM_EMP FROM EMPS WHERE CD_EMP
= $arr_my_emp[0]";
$stm_ora_emp=ociparse($conn_oracle,$sql_ora_emp);
$exec_ora_emp=ociexecute($stm_ora_emp);
ocifetchinto($stm_ora_emp,$arr_ora_emp,OCI_NUM);
echo "$arr_ora_emp[0]";
}
?>
Expected result:
One Combo box whit option from table EMPS
Actual result:
--
Warning: ociexecute(): OCIStmtExecute: ORA-03106: fatal two-task
communication protocol error
in /www/htdocs/vw/main.php on line 131
Warning: ocifetchinto(): OCIFetchInto: ORA-24374: define not done
before fetch or execute and fetch
in /www/htdocs/vw/main.php on line 132
--
Edit bug report at http://bugs.php.net/?id=26741&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=26741&r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=26741&r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=26741&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=26741&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=26741&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=26741&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=26741&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=26741&r=support
Expected behavior: http://bugs.php.net/fix.php?id=26741&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=26741&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=26741&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=26741&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=26741&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=26741&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=26741&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=26741&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=26741&r=float
#26742 [NEW]: The base64_encode() function returns an string that cannot decoded by outlook
From: eric dot maman at free dot fr
Operating system: Windows 2000
PHP version: 4.3.4
PHP Bug Type: *URL Functions
Bug description: The base64_encode() function returns an string that cannot decoded
by outlook
Description:
I am using the base64_encode() function to send attachements by email.
When I receive the mail on Outlook, the attachement is visible but
corrupeted.
I have tested the whole process and my conclusion is that the
base64_encode() function does not work correctly.
I have made a workarround with an extrenal program that performs the
base64 encoding and it work correctly.
Reproduce code:
---
function EncodeString ($str, $encoding = "base64") {
$encoded = "";
switch(strtolower($encoding)) {
case "base64":
$encoded = chunk_split(base64_encode($str), 76, $this->LE);
break;
case "7bit":
case "8bit":
$encoded = $this->FixEOL($str);
if (substr($encoded, -(strlen($this->LE))) != $this->LE)
$encoded .= $this->LE;
break;
case "binary":
$encoded = $str;
break;
case "quoted-printable":
$encoded = $this->EncodeQP($str);
break;
default:
$this->SetError($this->Lang("encoding") . $encoding);
break;
}
return $encoded;
}
--
Edit bug report at http://bugs.php.net/?id=26742&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=26742&r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=26742&r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=26742&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=26742&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=26742&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=26742&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=26742&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=26742&r=support
Expected behavior: http://bugs.php.net/fix.php?id=26742&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=26742&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=26742&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=26742&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=26742&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=26742&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=26742&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=26742&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=26742&r=float
#26743 [NEW]: getElementByTagName doesn't work properly
From: olivier dot bichler at laposte dot net
Operating system: Windows XP (with SP1)
PHP version: 5.0.0b2 (beta2)
PHP Bug Type: *XML functions
Bug description: getElementByTagName doesn't work properly
Description:
The DOM function "getElementByTagName" doesn't work properly when it's
call from an element.
The W3C specification say "Returns a NodeList of all DESCENDANT Elements
with a given tag name, in the order in which they are encountered in a
preorder traversal of this Element tree."
But getElementByTagName return ALL elements encountered after the current
element and not only the descendant elements in the tree...
Reproduce code:
---
value1
value2
value3
';
$dom = new DomDocument;
$dom -> loadXML($xml);
$params = $dom -> documentElement -> firstChild ->
getElementsByTagName('param');
foreach ($params as $param) {
echo $param -> getAttribute('name').'';
}
?>
Expected result:
param1
param2
(according with the W3C specifications)
Actual result:
--
param1
param2
param3
--
Edit bug report at http://bugs.php.net/?id=26743&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=26743&r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=26743&r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=26743&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=26743&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=26743&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=26743&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=26743&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=26743&r=support
Expected behavior: http://bugs.php.net/fix.php?id=26743&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=26743&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=26743&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=26743&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=26743&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=26743&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=26743&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=26743&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=26743&r=float
#26742 [Opn->Fbk]: The base64_encode() function returns an string that cannot decoded by outlook
ID: 26742
Updated by: [EMAIL PROTECTED]
Reported By: eric dot maman at free dot fr
-Status: Open
+Status: Feedback
Bug Type: *URL Functions
Operating System: Windows 2000
PHP Version: 4.3.4
New Comment:
What is the value of $this->LE ?
Previous Comments:
[2003-12-29 09:32:14] eric dot maman at free dot fr
Description:
I am using the base64_encode() function to send attachements by email.
When I receive the mail on Outlook, the attachement is visible but
corrupeted.
I have tested the whole process and my conclusion is that the
base64_encode() function does not work correctly.
I have made a workarround with an extrenal program that performs the
base64 encoding and it work correctly.
Reproduce code:
---
function EncodeString ($str, $encoding = "base64") {
$encoded = "";
switch(strtolower($encoding)) {
case "base64":
$encoded = chunk_split(base64_encode($str), 76,
$this->LE);
break;
case "7bit":
case "8bit":
$encoded = $this->FixEOL($str);
if (substr($encoded, -(strlen($this->LE))) != $this->LE)
$encoded .= $this->LE;
break;
case "binary":
$encoded = $str;
break;
case "quoted-printable":
$encoded = $this->EncodeQP($str);
break;
default:
$this->SetError($this->Lang("encoding") . $encoding);
break;
}
return $encoded;
}
--
Edit this bug report at http://bugs.php.net/?id=26742&edit=1
#26743 [Opn]: getElementsByTagName with s !
ID: 26743
User updated by: olivier dot bichler at laposte dot net
-Summary: getElementByTagName doesn't work properly
Reported By: olivier dot bichler at laposte dot net
Status: Open
Bug Type: *XML functions
Operating System: Windows XP (with SP1)
PHP Version: 5.0.0b2 (beta2)
New Comment:
Sorry, the name of the function is getElementsByTagName with "s" at
"Element".
Previous Comments:
[2003-12-29 10:34:18] olivier dot bichler at laposte dot net
Description:
The DOM function "getElementByTagName" doesn't work properly when it's
call from an element.
The W3C specification say "Returns a NodeList of all DESCENDANT
Elements with a given tag name, in the order in which they are
encountered in a preorder traversal of this Element tree."
But getElementByTagName return ALL elements encountered after the
current element and not only the descendant elements in the tree...
Reproduce code:
---
value1
value2
value3
';
$dom = new DomDocument;
$dom -> loadXML($xml);
$params = $dom -> documentElement -> firstChild ->
getElementsByTagName('param');
foreach ($params as $param) {
echo $param -> getAttribute('name').'';
}
?>
Expected result:
param1
param2
(according with the W3C specifications)
Actual result:
--
param1
param2
param3
--
Edit this bug report at http://bugs.php.net/?id=26743&edit=1
#26743 [Opn]: getElementsByTagName doesn't work properly
ID: 26743
User updated by: olivier dot bichler at laposte dot net
-Summary: getElementsByTagName with s !
Reported By: olivier dot bichler at laposte dot net
Status: Open
Bug Type: *XML functions
Operating System: Windows XP (with SP1)
PHP Version: 5.0.0b2 (beta2)
New Comment:
I have modified the title...
Previous Comments:
[2003-12-29 10:42:32] olivier dot bichler at laposte dot net
Sorry, the name of the function is getElementsByTagName with "s" at
"Element".
[2003-12-29 10:34:18] olivier dot bichler at laposte dot net
Description:
The DOM function "getElementByTagName" doesn't work properly when it's
call from an element.
The W3C specification say "Returns a NodeList of all DESCENDANT
Elements with a given tag name, in the order in which they are
encountered in a preorder traversal of this Element tree."
But getElementByTagName return ALL elements encountered after the
current element and not only the descendant elements in the tree...
Reproduce code:
---
value1
value2
value3
';
$dom = new DomDocument;
$dom -> loadXML($xml);
$params = $dom -> documentElement -> firstChild ->
getElementsByTagName('param');
foreach ($params as $param) {
echo $param -> getAttribute('name').'';
}
?>
Expected result:
param1
param2
(according with the W3C specifications)
Actual result:
--
param1
param2
param3
--
Edit this bug report at http://bugs.php.net/?id=26743&edit=1
#26743 [Opn->Csd]: getElementsByTagName doesn't work properly
ID: 26743
Updated by: [EMAIL PROTECTED]
Reported By: olivier dot bichler at laposte dot net
-Status: Open
+Status: Closed
Bug Type: *XML functions
Operating System: Windows XP (with SP1)
PHP Version: 5.0.0b2 (beta2)
New Comment:
This bug has been fixed in CVS.
In case this was a PHP problem, 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/.
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.
In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2003-12-29 10:43:58] olivier dot bichler at laposte dot net
I have modified the title...
[2003-12-29 10:42:32] olivier dot bichler at laposte dot net
Sorry, the name of the function is getElementsByTagName with "s" at
"Element".
[2003-12-29 10:34:18] olivier dot bichler at laposte dot net
Description:
The DOM function "getElementByTagName" doesn't work properly when it's
call from an element.
The W3C specification say "Returns a NodeList of all DESCENDANT
Elements with a given tag name, in the order in which they are
encountered in a preorder traversal of this Element tree."
But getElementByTagName return ALL elements encountered after the
current element and not only the descendant elements in the tree...
Reproduce code:
---
value1
value2
value3
';
$dom = new DomDocument;
$dom -> loadXML($xml);
$params = $dom -> documentElement -> firstChild ->
getElementsByTagName('param');
foreach ($params as $param) {
echo $param -> getAttribute('name').'';
}
?>
Expected result:
param1
param2
(according with the W3C specifications)
Actual result:
--
param1
param2
param3
--
Edit this bug report at http://bugs.php.net/?id=26743&edit=1
#23220 [Com]: fgets() causes warning while reading data via SSL channel (HTTPS)
ID: 23220 Comment by: Roger dot Schweppe at cbsks dot com Reported By: storozhilov at mail dot ru Status: No Feedback Bug Type: Filesystem function related Operating System: FreeBSD 4.8 PHP Version: 4-STABLE-200307070330 Assigned To: wez New Comment: I have been having the same problem with IIS 5. So if you ever find a solution I would be very happy to hear from you. Thanks, Roger Previous Comments: [2003-12-23 14:02:46] pta at interkan dot net Forgot to include this info: PHP 4.3.4 (cli) (built: Dec 4 2003 11:17:45) Copyright (c) 1997-2003 The PHP Group Zend Engine v1.3.0, Copyright (c) 1998-2003 Zend Technologies [2003-12-23 14:01:39] pta at interkan dot net I've been experiencing the same problem with PHP 4.3.4 running on a Linux Slackware/Apache server. The problem did initially crop up inside the PEAR Socket class which I'm trying to use to connect to Authorize.Net's gateway. Here's the exact message returned (with path changes): Warning: fread(): SSL: fatal protocol error in /path/to/Net/Socket.php on line 243 [2003-12-12 20:59:12] tim at timcrider dot com oh by the way. I am trying this with https:// as wez requested and am reproducing the same error: PHP 5.0.0b2 (cli) (built: Dec 7 2003 18:04:51) Copyright (c) 1997-2003 The PHP Group Zend Engine v2.0.0-dev, Copyright (c) 1998-2003 Zend Technologies with Turck MMCache v2.4.6, Copyright (c) 2002-2003 TurckSoft, St. Petersburg, by Dmitry Stogov [2003-12-12 20:54:11] tim at timcrider dot com I am having the same problem on Red Hat 9.0 with PHP 5.0 B2. It's coming from Net/Socket.php [2003-12-04 02:24:40] [EMAIL PROTECTED] No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you. 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/23220 -- Edit this bug report at http://bugs.php.net/?id=23220&edit=1
#26741 [Opn->Csd]: Problem on Get Varchar Colunms from Oracle 9i
ID: 26741
User updated by: fernando at napl dot com dot br
Reported By: fernando at napl dot com dot br
-Status: Open
+Status: Closed
Bug Type: OCI8 related
Operating System: Linux RedHat 8
PHP Version: 4.3.4
New Comment:
I am have Solved the Problem Compiling the php but ALL ORACLE ENV
VARIABLES SETUP TO ROOT!!
thanx for suppport!
Fernando N.
Previous Comments:
[2003-12-29 09:28:35] fernando at napl dot com dot br
Description:
I have the Problem on fetch Columns Varchar os Char from oracle..
I Have changed the Group of Apache on httpd.conf to oracle user..
All ENV Variables on oracle user already ok..
On SQlplus this machi I not have problems...
Thanks for any help...
Reproduce code:
---
while ($arr_my_emp = mysql_fetch_row($exec_my_emp)) {
$sql_ora_emp="SELECT CD_EMP,NM_EMP FROM EMPS WHERE
CD_EMP = $arr_my_emp[0]";
$stm_ora_emp=ociparse($conn_oracle,$sql_ora_emp);
$exec_ora_emp=ociexecute($stm_ora_emp);
ocifetchinto($stm_ora_emp,$arr_ora_emp,OCI_NUM);
echo "$arr_ora_emp[0]";
}
?>
Expected result:
One Combo box whit option from table EMPS
Actual result:
--
Warning: ociexecute(): OCIStmtExecute: ORA-03106: fatal two-task
communication protocol error
in /www/htdocs/vw/main.php on line 131
Warning: ocifetchinto(): OCIFetchInto: ORA-24374: define not
done before fetch or execute and fetch
in /www/htdocs/vw/main.php on line 132
--
Edit this bug report at http://bugs.php.net/?id=26741&edit=1
#26038 [Com]: session_start(): Failed to initialize storage module
ID: 26038 Comment by: der at derdev dot com Reported By: pedro at dehumanizer dot com Status: Bogus Bug Type: Session related Operating System: FreeBSD 4.9 PHP Version: 4CVS-2003-10-30 (stable) New Comment: I confirm problem on RedHat 7.3, source-built apache 1.3.29, php 4.3.4 as module. Mysql 3.23.56, localhost socket connect. Previous Comments: [2003-12-16 17:05:45] darren at cpanel dot net Just FYI, this also happens with apache 1.3.29 and php 4.3.3 and 4.3.4 on RedHat Linux. [2003-11-17 18:08:18] [EMAIL PROTECTED] It's not PHP bug. (Apache2 is really not ready for production) [2003-10-30 07:34:12] pedro at dehumanizer dot com By the way, if I use Apache 1.3.28 instead, configuring the same version of PHP with exactly the same options (except replacing --with-apxs2 with --with-apxs), the problem disappears. [2003-10-30 07:30:51] pedro at dehumanizer dot com Description: I believe this bug had already been reported by someone else (#25876), but it was marked as "bogus". I'm using FreeBSD 4.9 (and 4.8-STABLE before), Apache 2.0.48 from ports (and 2.0.47 before), and tried several PHP versions from 4.3.2 to 4CVS-20031030 (today's). All of them exhibit this problem, with SquirrelMail 1.4.2. I don't think it's a SquirrelMail problem, however, as the line in question is a simple session_start(); The problem is intermitent - when navigating through the webmail, from time to time, when I click on a link, a blank page appears *very quickly*, just in the frame which was supposed to be changed. In the logs, I get this error: [client 62.169.69.5] PHP Fatal error: session_start(): Failed to initialize storage module. in /var/www/htdocs/mail/functions/global.php on line 295, referer: https://www.dehumanizer.com/mail/src/webmail.php If I reload the page, or go back from the blank page and click on the same link again, it usually works then. The error rate is hard to calculate, but it should be less than 1 in 10 times. I've tried changing the sessions handler between files and mm, but it doesn't solve the problem. Neither does activating register_globals, which SquirrelMail doesn't need, anyway. PHP configure options: ./configure --disable-cgi --with-apxs2=/usr/local/sbin/apxs --with-openssl --with-zlib --with-gdbm --with-imap --with-iconv --enable-ftp --with-mysql=/usr/local/mysql --with-curl --disable-debug --enable-exif --enable-sockets --disable-ipv6 --with-gd --with-jpeg-dir --with-png-dir --enable-dio --with-gettext=/usr/local --with-bz2 --enable-mbstring --enable-mbregex --enable-zend-multibyte --with-mysql-sock=/tmp/mysql.sock --with-mm=/usr/local -- Edit this bug report at http://bugs.php.net/?id=26038&edit=1
#26736 [Csd->Opn]: __autoload not invoked for parent classes
ID: 26736
User updated by: jaanus at heeringson dot com
Reported By: jaanus at heeringson dot com
-Status: Closed
+Status: Open
Bug Type: Class/Object related
Operating System: *
PHP Version: 5.0.0b3
Assigned To: helly
New Comment:
This bug was NOT fixed in snap 200312291230, which was created after
your comment.
Previous Comments:
[2003-12-29 07:34:27] [EMAIL PROTECTED]
This bug has been fixed in CVS.
In case this was a PHP problem, 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/.
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.
In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
Thank you for the report, and for helping us make PHP better.
[2003-12-28 21:06:12] jaanus at heeringson dot com
Description:
Autoload is not invoked for missing parent class in object declaration.
This worked with php5-beta2.
Reproduce code:
---
Child_class and Parent_class are in separate documents. Autoload
function is working.
class Child_class extends Parent_class {
}
$class=new Child_class();
Expected result:
No errors, everything loads.
Actual result:
--
Fatal error: Class 'Parent_class' not found in [path to Child_class
document] on line 2
--
Edit this bug report at http://bugs.php.net/?id=26736&edit=1
#26736 [Opn->Csd]: __autoload not invoked for parent classes
ID: 26736
User updated by: jaanus at heeringson dot com
Reported By: jaanus at heeringson dot com
-Status: Open
+Status: Closed
Bug Type: Class/Object related
Operating System: *
PHP Version: 5.0.0b3
Assigned To: helly
New Comment:
Just checked with 200312300030, and bug seems to be fixed.
Thanks, and sorry about the whining...
Previous Comments:
[2003-12-29 19:37:58] jaanus at heeringson dot com
This bug was NOT fixed in snap 200312291230, which was created after
your comment.
[2003-12-29 07:34:27] [EMAIL PROTECTED]
This bug has been fixed in CVS.
In case this was a PHP problem, 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/.
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.
In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
Thank you for the report, and for helping us make PHP better.
[2003-12-28 21:06:12] jaanus at heeringson dot com
Description:
Autoload is not invoked for missing parent class in object declaration.
This worked with php5-beta2.
Reproduce code:
---
Child_class and Parent_class are in separate documents. Autoload
function is working.
class Child_class extends Parent_class {
}
$class=new Child_class();
Expected result:
No errors, everything loads.
Actual result:
--
Fatal error: Class 'Parent_class' not found in [path to Child_class
document] on line 2
--
Edit this bug report at http://bugs.php.net/?id=26736&edit=1
#26735 [Opn->Fbk]: php.ini not read
ID: 26735
Updated by: [EMAIL PROTECTED]
Reported By: cmouse at youzen dot projectb2 dot net
-Status: Open
+Status: Feedback
Bug Type: PHP options/info functions
Operating System: Linux 2.4.23
PHP Version: 4.3.4
New Comment:
That strace doesn't indicate that any of the files were
found. Those locations are typical for many vendor
distributed php's are you sure that the php you are running
is the one you installed and not the vendor-distributed
one?
Previous Comments:
[2003-12-29 08:20:59] cmouse at youzen dot projectb2 dot net
The problem was that PHP tells me it is using /etc/php/php.ini as FILE,
when this is PATH. Suprise suprise, it tries to read
/etc/php/php.ini/php.ini, which is not what I expected. A more clearer
configure item would be nice (and output of phpinfo()):
The strace readout:
$ strace -eopen php -r '' 2>&1 | grep ini
open("php/php-cli.ini", O_RDONLY) = -1 ENOENT (No such file or
directory)
open("/etc/php/php.ini/php-cli.ini", O_RDONLY) = -1 ENOTDIR (Not a
directory)
open("php/php.ini", O_RDONLY) = -1 ENOENT (No such file or
directory)
open("/etc/php/php.ini/php.ini", O_RDONLY) = -1 ENOTDIR (Not a
directory)
[2003-12-28 22:39:04] [EMAIL PROTECTED]
what does this (with correct path substiitution) return
you:
strace -eopen ./sapi/cli/php -r '' 2>&1 | grep ini
[2003-12-28 19:48:22] cmouse at youzen dot projectb2 dot net
Ah and here are mod_php clips:
Configuration File (php.ini) Path /etc/php/php.ini
cat /etc/php/php.ini | grep upload_tmp_dir
upload_tmp_dir = "/www/tmp"
upload_tmp_dir no value no value
[2003-12-28 19:45:55] cmouse at youzen dot projectb2 dot net
Ok.
Here goes:
php -r 'phpinfo();' | grep php.ini
Configuration File (php.ini) Path => /etc/php/php.ini
cat /etc/php/php.ini | grep upload_tmp_dir
upload_tmp_dir = "/www/tmp"
php -r 'phpinfo();' | grep upload_tmp_dir
upload_tmp_dir => no value => no value
[2003-12-28 19:40:28] [EMAIL PROTECTED]
Works fine for me:
19:49:41([EMAIL PROTECTED])[~/src/php-4.3.4]> ./sapi/cli/php -r
'phpinfo();' | grep php.ini
Configuration File (php.ini) Path => /usr/local/lib/php.ini
19:49:48([EMAIL PROTECTED])[~/src/php-4.3.4]> cat /usr/local/
lib/php.iniupload_tmp_dir = /www/tmp
19:49:57([EMAIL PROTECTED])[~/src/php-4.3.4]> ./sapi/cli/php -r
'phpinfo();' | grep upload_tmp_dir
upload_tmp_dir => /www/tmp => /www/tmp
Again, 10-1 your php.ini is not what you expect it is.
Please repeat the above steps on your system, If you are
running this as mod_php, make steps 1 and 3 be clips from
the html dump.
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/26735
--
Edit this bug report at http://bugs.php.net/?id=26735&edit=1
#26724 [Opn]: get_class() and __CLASS__ causing crashes and erratic behaviour
ID: 26724 User updated by: thought at phenomind dot com Reported By: thought at phenomind dot com Status: Open Bug Type: Class/Object related Operating System: Windows XP PHP Version: 5CVS-2003-12-26 (dev) New Comment: Okay. I think I may have some snippets of code to demonstrate this: I have defined a two dimensional array like this: $this->composite_object_names[0]= "piece"; $this->composite_object_names[1]= "pod_log"; Yet when I do a print_r on the object, I am getting this: [composite_object_names:public] => Array ( [0] => Diece [1] => Dod_log ) I have numerous instances of get_class() and __CLASS__ scattered throughout my code. I know that if I remove this, the object will be fine. I am also suspicious of the get_object_vars() function but that it is almost impossible for me to quantify which one of these functions is at the root of the problem. There is a bug here Previous Comments: [2003-12-26 23:48:51] thought at phenomind dot com Sorry, I cannot but I just removed 500+ instances of get_class() and __CLASS__ from many libraries of code and the problem has disappeared. I'll give you an example of the object where the primary_key property was corrupted. It is fine in this instance because I have already done the abovementioned alterations: user_session Object ( [y_resolution] => [x_resolution] => [flash_version] => [session_identifier] => [timestamp_difference] => [cookies_enabled] => [ip_address] => [browser] => [nominated_transport_agent_key] => [nominated_shipper_key] => [nominated_project_key] => [live_key] => 73 [new_on_load] => [table_name] => user_sessions [composite_object_name] => [composite_key] => [primary_key] => user_session_key [database] => mysql_db Object ( [engine] => mysql [username] => [password] => * [service_name] => [live_table] => [commit_query] => 0 [tns_admin] => [vars] => vars Object ( [username] => ** [btn_login] => Login [password] => [encoded_php_self] => ) [database_name] => BKCARGO [host] => localhost [port] => 3306 [host_port] => localhost:3306 [database_handle] => Resource id #80 [query] => UPDATE user_sessions SET user_key = '1', transport_agent_key = '', shipper_key = '', project_key = '', y_resolution = '', x_resolution = '', flash_version = '', session_identifier = '', timestamp_difference = '', cookies_enabled = '', ip_address = '', browser = '', live_user_key = '1' WHERE user_session_key='73' [result_handle] => 1 ) [vars] => vars Object ( [username] => [btn_login] => Login [password] => *** [encoded_php_self] => * ) [user_key] => 1 [user_session_key] => 73 [live_user_key] => 1 ) [2003-12-26 23:41:25] [EMAIL PROTECTED] Can you post an example that actually reproduces? A simple class used with your code runs fine on OS X. [2003-12-26 23:08:41] thought at phenomind dot com Problems also with get_object_vars() If my script has this function anywhere, PHP5 produces erratic results. [2003-12-26 22:34:17] thought at phenomind dot com Description: Apologise for not being able to describe this better or give example code. get_class() and __CLASS__ cause PHP5 to behave erratically. Sometimes changes the data within the [argument] object and often causes Apache to crash. Problems experienced on Windows XP. Same problem also caused a Dual Processor Mac OS-X box to soak up CPU time 1 processor. Script calls get_class() many, many times or complex, composite objects. The erratic behaviour is very hard to pin down but the source is definitely get_class(). PHP5 objects are not very happy with this function. Reproduce code: --- I can say: print_r($object); print get_class($object); print_r($object); Expected result: 1) object dump 2) Name of object 3) same object dump Actual result: -- 1) object dump 2) Name of object 3) object dump with probably one property changed No other code in the middle to cause this behaviour. -- Edit this bug report at http://bugs.php.net/?id=26724&edit=1
#26724 [Opn]: get_class() and __CLASS__ causing crashes and erratic behaviour
ID: 26724 User updated by: thought at phenomind dot com Reported By: thought at phenomind dot com Status: Open Bug Type: Class/Object related Operating System: Windows XP PHP Version: 5CVS-2003-12-26 (dev) New Comment: Apologies. I meant two-element array. Not two-dimensional! Previous Comments: [2003-12-29 22:36:02] thought at phenomind dot com Okay. I think I may have some snippets of code to demonstrate this: I have defined a two dimensional array like this: $this->composite_object_names[0]= "piece"; $this->composite_object_names[1]= "pod_log"; Yet when I do a print_r on the object, I am getting this: [composite_object_names:public] => Array ( [0] => Diece [1] => Dod_log ) I have numerous instances of get_class() and __CLASS__ scattered throughout my code. I know that if I remove this, the object will be fine. I am also suspicious of the get_object_vars() function but that it is almost impossible for me to quantify which one of these functions is at the root of the problem. There is a bug here [2003-12-26 23:48:51] thought at phenomind dot com Sorry, I cannot but I just removed 500+ instances of get_class() and __CLASS__ from many libraries of code and the problem has disappeared. I'll give you an example of the object where the primary_key property was corrupted. It is fine in this instance because I have already done the abovementioned alterations: user_session Object ( [y_resolution] => [x_resolution] => [flash_version] => [session_identifier] => [timestamp_difference] => [cookies_enabled] => [ip_address] => [browser] => [nominated_transport_agent_key] => [nominated_shipper_key] => [nominated_project_key] => [live_key] => 73 [new_on_load] => [table_name] => user_sessions [composite_object_name] => [composite_key] => [primary_key] => user_session_key [database] => mysql_db Object ( [engine] => mysql [username] => [password] => * [service_name] => [live_table] => [commit_query] => 0 [tns_admin] => [vars] => vars Object ( [username] => ** [btn_login] => Login [password] => [encoded_php_self] => ) [database_name] => BKCARGO [host] => localhost [port] => 3306 [host_port] => localhost:3306 [database_handle] => Resource id #80 [query] => UPDATE user_sessions SET user_key = '1', transport_agent_key = '', shipper_key = '', project_key = '', y_resolution = '', x_resolution = '', flash_version = '', session_identifier = '', timestamp_difference = '', cookies_enabled = '', ip_address = '', browser = '', live_user_key = '1' WHERE user_session_key='73' [result_handle] => 1 ) [vars] => vars Object ( [username] => [btn_login] => Login [password] => *** [encoded_php_self] => * ) [user_key] => 1 [user_session_key] => 73 [live_user_key] => 1 ) [2003-12-26 23:41:25] [EMAIL PROTECTED] Can you post an example that actually reproduces? A simple class used with your code runs fine on OS X. [2003-12-26 23:08:41] thought at phenomind dot com Problems also with get_object_vars() If my script has this function anywhere, PHP5 produces erratic results. [2003-12-26 22:34:17] thought at phenomind dot com Description: Apologise for not being able to describe this better or give example code. get_class() and __CLASS__ cause PHP5 to behave erratically. Sometimes changes the data within the [argument] object and often causes Apache to crash. Problems experienced on Windows XP. Same problem also caused a Dual Processor Mac OS-X box to soak up CPU time 1 processor. Script calls get_class() many, many times or complex, composite objects. The erratic behaviour is very hard to pin down but the source is definitely get_class(). PHP5 objects are not very happy with this function. Reproduce code: --- I can say: print_r($object); print get_class($object); print_r($object); Expected result: 1) object dump 2) Name of object 3) same object dump Actual result: -- 1) object dump 2) Name of object 3) object dump with probably one property changed No other code in the middle to ca
#26724 [Opn->Csd]: get_class() and __CLASS__ causing crashes and erratic behaviour
ID: 26724 User updated by: thought at phenomind dot com Reported By: thought at phenomind dot com -Status: Open +Status: Closed Bug Type: Class/Object related Operating System: Windows XP PHP Version: 5CVS-2003-12-26 (dev) New Comment: I will close this bug until I can get more specific, reproducable results. Previous Comments: [2003-12-29 22:37:09] thought at phenomind dot com Apologies. I meant two-element array. Not two-dimensional! [2003-12-29 22:36:02] thought at phenomind dot com Okay. I think I may have some snippets of code to demonstrate this: I have defined a two dimensional array like this: $this->composite_object_names[0]= "piece"; $this->composite_object_names[1]= "pod_log"; Yet when I do a print_r on the object, I am getting this: [composite_object_names:public] => Array ( [0] => Diece [1] => Dod_log ) I have numerous instances of get_class() and __CLASS__ scattered throughout my code. I know that if I remove this, the object will be fine. I am also suspicious of the get_object_vars() function but that it is almost impossible for me to quantify which one of these functions is at the root of the problem. There is a bug here [2003-12-26 23:48:51] thought at phenomind dot com Sorry, I cannot but I just removed 500+ instances of get_class() and __CLASS__ from many libraries of code and the problem has disappeared. I'll give you an example of the object where the primary_key property was corrupted. It is fine in this instance because I have already done the abovementioned alterations: user_session Object ( [y_resolution] => [x_resolution] => [flash_version] => [session_identifier] => [timestamp_difference] => [cookies_enabled] => [ip_address] => [browser] => [nominated_transport_agent_key] => [nominated_shipper_key] => [nominated_project_key] => [live_key] => 73 [new_on_load] => [table_name] => user_sessions [composite_object_name] => [composite_key] => [primary_key] => user_session_key [database] => mysql_db Object ( [engine] => mysql [username] => [password] => * [service_name] => [live_table] => [commit_query] => 0 [tns_admin] => [vars] => vars Object ( [username] => ** [btn_login] => Login [password] => [encoded_php_self] => ) [database_name] => BKCARGO [host] => localhost [port] => 3306 [host_port] => localhost:3306 [database_handle] => Resource id #80 [query] => UPDATE user_sessions SET user_key = '1', transport_agent_key = '', shipper_key = '', project_key = '', y_resolution = '', x_resolution = '', flash_version = '', session_identifier = '', timestamp_difference = '', cookies_enabled = '', ip_address = '', browser = '', live_user_key = '1' WHERE user_session_key='73' [result_handle] => 1 ) [vars] => vars Object ( [username] => [btn_login] => Login [password] => *** [encoded_php_self] => * ) [user_key] => 1 [user_session_key] => 73 [live_user_key] => 1 ) [2003-12-26 23:41:25] [EMAIL PROTECTED] Can you post an example that actually reproduces? A simple class used with your code runs fine on OS X. [2003-12-26 23:08:41] thought at phenomind dot com Problems also with get_object_vars() If my script has this function anywhere, PHP5 produces erratic results. 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/26724 -- Edit this bug report at http://bugs.php.net/?id=26724&edit=1
#26744 [NEW]: php_oci8.dll is missing from prebuilt Windows binaries
From: cjbj at hotmail dot com Operating system: W2K PHP version: 5.0.0b2 (beta2) PHP Bug Type: OCI8 related Bug description: php_oci8.dll is missing from prebuilt Windows binaries Description: Php_oci8.dll is missing from the bundle: http://www.php.net/get/php-5.0.0b3-Win32.zip/from/a/mirror The old php_oracle.dll library exists. The oci8 extension source code exists in the source bundle: http://www.php.net/get/php-5.0.0b3.tar.gz/from/a/mirror There is nothing in the various php5 announcements, or in http://www.php.net/ChangeLog-5.php that mentions the extension. This problem was raised in the php-db mail list: http://news.php.net/article.php?group=php.db&article=32200 The last time I pulled PHP5 (on September 3, 2003) php_oci8.dll was in the pre-built bundle. -- Edit bug report at http://bugs.php.net/?id=26744&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=26744&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=26744&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=26744&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=26744&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=26744&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=26744&r=needscript Try newer version: http://bugs.php.net/fix.php?id=26744&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=26744&r=support Expected behavior: http://bugs.php.net/fix.php?id=26744&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=26744&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=26744&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=26744&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=26744&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=26744&r=dst IIS Stability: http://bugs.php.net/fix.php?id=26744&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=26744&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=26744&r=float
#26623 [Opn->Bgs]: XML Parser ignores UTF-8 input encoding?
ID: 26623
User updated by: steven at acko dot net
Reported By: steven at acko dot net
-Status: Open
+Status: Bogus
Bug Type: XML related
Operating System: Windows 2000
PHP Version: 4CVS-2003-12-14 (stable)
New Comment:
Hmmm I finally figured this out: PHP4 apparently always expects you to
specify the input encoding manually as a parameter to
xml_parser_create(). The manual is a bit unclear about this (it says
"you /can/ specify an input encoding" rather than "you have to").
In PHP5, the parameter to xml_parser_create() is ignored completely,
and the XML parser extract the encoding on its own.
Previous Comments:
[2003-12-15 16:43:10] steven at acko dot net
This bug does not happen with the latest PHP5 by the way. PHP5 will
correctly handle my example.
[2003-12-14 23:13:35] steven at acko dot net
Description:
PHP seems to ignore the encoding when parsing an UTF-8 encoded XML
file, and assumes it is ISO-8859-1 instead.
The code below contains a very short XML file (inline) to parse, with
the character a-with-tilde as value (this is just to show what happens,
there is nothing special about this character). The a-with-tilde takes
2 bytes in UTF-8 encoding, and is represented as such in the XML file
string.
The buggy behaviour is illustrated with the 3 possible PHP output
encodings. Comment/uncomment the correct xml_parser_set_option() call
to see the behaviour in all output encodings.
Note that nothing changes in behaviour if you change the
encoding="utf-8" in the source XML into 'iso-8859-1', or remove it
altogether, which shows that it is being ignored.
Reproduce code:
---
\xC3\xA3";
function handler_data($parser, $data) {
print "Data: $data\n";
print "Length: ". strlen($data) ."\n";
}
$xml_parser = xml_parser_create();
xml_set_character_data_handler($xml_parser, "handler_data");
xml_parser_set_option($xml_parser, XML_OPTION_TARGET_ENCODING,
"utf-8");
// xml_parser_set_option($xml_parser, XML_OPTION_TARGET_ENCODING,
"iso-8859-1");
// xml_parser_set_option($xml_parser, XML_OPTION_TARGET_ENCODING,
"us-ascii");
xml_parse($xml_parser, $xmlfile, 1);
xml_parser_free($xml_parser);
?>
Expected result:
With output encoding set to UTF-8, PHP should leave the data alone and
should print 2 bytes (\xC3 and \xA3) for the a-with-tilde.
With output encoding set to ISO-8859-1, PHP should encode the
a-with-tile as a single byte (\xE3).
With output encoding set to US-ASCII, PHP should output a single '?' to
indicate the a-with-tilde is not available in the output encoding.
Actual result:
--
With output encoding set to UTF-8, PHP re-encodes the input into UTF-8,
resulting in 4 bytes for a-with-tilde.
With output encoding set to ISO-8859-1, PHP leaves the input
untouched.
With output encoding set to US-ASCII, PHP outputs two question marks.
--
Edit this bug report at http://bugs.php.net/?id=26623&edit=1
#26745 [NEW]: "No input file specified." with doc_root set to a path prefix
From: cdragon at draconic dot com Operating system: windows 2000 PHP version: 5.0.0b2 (beta2) PHP Bug Type: IIS related Bug description: "No input file specified." with doc_root set to a path prefix Description: I've been setting up a development server with the exact same configuration as a live server. Instead of using php 4.3.x I decided to try 5b3. I use the same php.ini file. I have IIS set to host two web sites in the following two directories: c:\inetpub\wwwroot\www.draconic.com c:\inetpub\wwwroot\www.draconic.net In php.ini, I have doc_root set to "c:\inetpub\wwwroot" so that files in either of these directories can be loaded. Yet when I load any php page from either site I get the error "No input file specified". I am using IIS 5 under win2k using the ISAPI version of php 5b3. I found that by changing doc_root from "c:\inetpub\wwwroot" to "c:\inetpub\wwwroot\www.draconic.com", I can get the php pages to work reliably for the first web site. However, this means I get the "No input file specified" error when I try to load pages from "c:\inetpub\wwwroot\www.draconic.net". With doc_root set to "c:\inetpub\wwwroot" I get the "No input file specified" most of the time, but I found it would occasionally load the php page correctly (maybe that was a caching thing?), or even give me a memory access violation when I tried to use the "include(...)" statement! I can't figure out what was different when it worked or when it access violationed, but something seems to be seriously broken with doc_root in php 5b3. -- Edit bug report at http://bugs.php.net/?id=26745&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=26745&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=26745&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=26745&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=26745&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=26745&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=26745&r=needscript Try newer version: http://bugs.php.net/fix.php?id=26745&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=26745&r=support Expected behavior: http://bugs.php.net/fix.php?id=26745&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=26745&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=26745&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=26745&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=26745&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=26745&r=dst IIS Stability: http://bugs.php.net/fix.php?id=26745&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=26745&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=26745&r=float
#26746 [NEW]: using unserialize in a class on the object itself
From: ken dot shin at ifrance dot com
Operating system: win2000
PHP version: 5CVS-2003-12-30 (dev)
PHP Bug Type: *General Issues
Bug description: using unserialize in a class on the object itself
Description:
well,
when i try to use unserialize in a class on the object itself,
that's return me an empty object, all property are set to NULL.
the code below work well with php4, but doesn't with php5.
Reproduce code:
---
x = 'blabla';
var_dump($test1);
$serial = serialize ($test1);
var_dump($serial);
$test2 = new a;
$test2->unS($serial);
//$test2 = unserialize($serial);
var_dump($test2);
?>
Expected result:
i expected the same behaviour as in php4. php5 return me the right result
when i use unserialize out of the class but return me an empty object when
i use it in the class.
actual result
-
object(a)#2 (1) {
["x"]=>
NULL
}
expected result
-
object(a)#2 (1) {
["x"]=>
string(7) "blabla"
}
--
Edit bug report at http://bugs.php.net/?id=26746&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=26746&r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=26746&r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=26746&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=26746&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=26746&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=26746&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=26746&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=26746&r=support
Expected behavior: http://bugs.php.net/fix.php?id=26746&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=26746&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=26746&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=26746&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=26746&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=26746&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=26746&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=26746&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=26746&r=float
#23331 [Fbk->NoF]: Memory leak in ISAPI
ID: 23331
Updated by: [EMAIL PROTECTED]
Reported By: jakub at icewarp dot com
-Status: Feedback
+Status: No Feedback
Bug Type: IIS related
Operating System: win32
PHP Version: 4CVS, 5CVS
New Comment:
No feedback was provided for this bug for over 2 weeks, 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:
[2003-12-16 14:31:02] msisolak at yahoo dot com
The recent changes have fixed a big chunk of the leaks, but there are
still a couple of memory types that are not getting freed. I'll have a
couple of more patches to close out this bug soon.
[2003-12-14 20:16:31] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-STABLE-latest.zip
Some fixes have been committed recently which should fix this bug.
Please try the snapshot out.
[2003-10-04 08:40:57] jakub at icewarp dot com
I think I tracked down the leak.
In this function:
TSRM_API void *ts_resource_ex(ts_rsrc_id id, THREAD_T *th_id)
There's at the end this:
TSRM_SAFE_RETURN_RSRC(thread_resources->storage, id,
thread_resources->count);
Now if I uncomment this. It does not leak the memory for the 2 calls
from my last post.
The call translates to
return &thread_resources->storage;
Why should this leak? Please, C++ people help us here.
[2003-10-04 06:17:00] jakub at icewarp dot com
I have been digging more into this issue and I have found this.
1. HttpExtensionProc like this does not leak at all.
DWORD WINAPI HttpExtensionProc(LPEXTENSION_CONTROL_BLOCK lpECB)
{ return 0; }
2. 1. HttpExtensionProc like this does leak.
DWORD WINAPI HttpExtensionProc(LPEXTENSION_CONTROL_BLOCK lpECB)
{
TSRMLS_FETCH();
ts_free_thread();
return 0;
}
It is clear that the ts_free_thread does not free everything. I'm not a
C/C++ guru please people help here. This issue has been here since 2
years ago and nobody fixed it yet. Let me know.
Jakub
[2003-08-18 09:42:43] jakub at icewarp dot com
That's what I thought of too so I removed all extensions and the
results I posted are without any extensions.
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/23331
--
Edit this bug report at http://bugs.php.net/?id=23331&edit=1
