#29951 [Csd->Bgs]: PHP + MySQL (build with Intel Compiler) Compile Failure
ID: 29951 Updated by: [EMAIL PROTECTED] Reported By: v_santhanam at ettimadai dot amrita dot edu -Status: Closed +Status: Bogus Bug Type: Compile Failure Operating System: Redhat Enterprise Linux AS 3 PHP Version: 4.3.8 Previous Comments: [2004-09-02 22:13:07] v_santhanam at ettimadai dot amrita dot edu Dear Friends, I have installed MySQL-devel RPM (Standard - gcc) and used it for compiling PHP. MySQL Server remains the same intel build. It is working perfectly although this may not be the desired solution.. please post if u find any results. With Regards Santhanam [2004-09-02 14:44:21] [EMAIL PROTECTED] Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Thank you for your interest in PHP. . [2004-09-02 14:41:14] v_santhanam at ettimadai dot amrita dot edu Description: Dear Friends, I am trying to compile PHP with MySQL support in an HP DL380 server (Xeon Processors). The MySQL is build with Intel Compiler. I am getting the following problem / error : --- /usr/local/mysql/lib/libmysqlclient.a(libmysql.o)(.text+0x1ade): In function `store_param_time': : undefined reference to `_intel_fast_memcpy' /usr/local/mysql/lib/libmysqlclient.a(libmysql.o)(.text+0x1ba2): In function `net_store_datetime': : undefined reference to `_intel_fast_memcpy' /usr/local/mysql/lib/libmysqlclient.a(libmysql.o)(.text+0x1beb): In function `store_param_str': : undefined reference to `_intel_fast_memcpy' /usr/local/mysql/lib/libmysqlclient.a(libmysql.o)(.text+0x2428): In function `mysql_stmt_bind_param': : undefined reference to `_intel_fast_memcpy' /usr/local/mysql/lib/libmysqlclient.a(libmysql.o)(.text+0x2a01): In function `fetch_result_bin': : undefined reference to `_intel_fast_memcpy' /usr/local/mysql/lib/libmysqlclient.a(libmysql.o)(.text+0x2a36): more undefined references to `_intel_fast_memcpy' follow /usr/local/mysql/lib/libmysqlclient.a(my_vsnprintf.o)(.text+0x22a): In function `my_vsnprintf.': : undefined reference to `_intel_fast_memset' /usr/local/mysql/lib/libmysqlclient.a(ctype.o)(.text+0x1b3): In function `cs_value': : undefined reference to `_intel_fast_memcpy' /usr/local/mysql/lib/libmysqlclient.a(ctype.o)(.text+0x218): In function `cs_value': : undefined reference to `_intel_fast_memcpy' /usr/local/mysql/lib/libmysqlclient.a(ctype.o)(.text+0x714): In function `cs_value': : undefined reference to `_intel_fast_memcpy' /usr/local/mysql/lib/libmysqlclient.a(ctype.o)(.text+0x740): In function `cs_value': : undefined reference to `_intel_fast_memcpy' /usr/local/mysql/lib/libmysqlclient.a(ctype-simple.o)(.text+0xf2b): In function `my_long10_to_str_8bit': : undefined reference to `_intel_fast_memcpy' /usr/local/mysql/lib/libmysqlclient.a(ctype-simple.o)(.text+0x1053): more undefined references to `_intel_fast_memcpy' follow /usr/local/mysql/lib/libmysqlclient.a(ctype-simple.o)(.text+0x1495): In function `my_fill_8bit': : undefined reference to `_intel_fast_memset' /usr/local/mysql/lib/libmysqlclient.a(ctype-bin.o)(.text+0x51b): In function `my_strnxfrm_bin': : undefined reference to `_intel_fast_memcpy' /usr/local/mysql/lib/libmysqlclient.a(ctype-ucs2.o)(.text+0x1eb5): In function `my_strnxfrm_ucs2_bin': : undefined reference to `_intel_fast_memcpy' /usr/local/mysql/lib/libmysqlclient.a(ctype-tis620.o)(.text+0x58): In function `my_strnncoll_tis620': : undefined reference to `_intel_fast_memcpy' /usr/local/mysql/lib/libmysqlclient.a(ctype-tis620.o)(.text+0x6e): In function `my_strnncoll_tis620': : undefined reference to `_intel_fast_memcpy' /usr/local/mysql/lib/libmysqlclient.a(ctype-tis620.o)(.text+0x12e): In function `my_strnncoll_tis620': : undefined reference to `_intel_fast_memcpy' /usr/local/mysql/lib/libmysqlclient.a(ctype-tis620.o)(.text+0x239): more undefined references to `_intel_fast_memcpy' follow collect2: ld returned 1 exit status make: *** [sapi/cli/php] Error 1 I have installed the Intel compiler and added the "/opt/intel_cc_80/lib" to the LD_LIBRARY_PATH environment variable. Please kindly help me. Thanks in Advance With Regards Santhanam -- Edit this bug report at http://bugs.php.net/?id=29951&edit=1
#29962 [Opn->Bgs]: A Sharing violation occured while accessing x:\path\file.php
ID: 29962 Updated by: [EMAIL PROTECTED] Reported By: the_krash at hotmail dot com -Status: Open +Status: Bogus Bug Type: IIS related Operating System: Windows XP pro IIS 5.1 PHP Version: 5.0.1 New Comment: Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Thank you for your interest in PHP. . Previous Comments: [2004-09-03 05:38:43] the_krash at hotmail dot com Description: Here it is.. When I use php5isapi.dll to run php script with IIS 5.1.. I load a web page, everything works fine, but then when I try to modify the loaded page and save it, I get a "A Sharing violation occured while accessing x:\path\file.php".. I switch to php5-cgi.exe and it works fine. Now, I'd like to know if it's a bug, or maybe just why it is acting like that.. thanks. Reproduce code: --- simple code was used... -- Edit this bug report at http://bugs.php.net/?id=29962&edit=1
#29963 [Opn->Bgs]: fileaccess dont work properly
ID: 29963 Updated by: [EMAIL PROTECTED] Reported By: neppis at msn dot com -Status: Open +Status: Bogus Bug Type: Filesystem function related Operating System: Solaris 8 - Sparc PHP Version: 5.0.1 New Comment: Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Thank you for your interest in PHP. . Previous Comments: [2004-09-03 06:51:19] neppis at msn dot com Description: root user start php script. i set posix_setgid -> www and posix_setuid -> wwwuser both work fine, if i touch file, it will be: wwwuser:www however, i have user ftp:ftp created wwwuser is part of ftp-group. file: -rw-rw-r-- 1 ftp ftp 15 Sep 2 16:25 /home/ftp/testing/testfile with vi i can edit or i can do anything to that testfile as wwwuser, but with php i cannot modify it, if i have used posix_setuid to wwwuser. forexample is_writeable function returns false. -- Edit this bug report at http://bugs.php.net/?id=29963&edit=1
#29297 [Csd->Asn]: PDFLib 6 make error
ID: 29297 Updated by: [EMAIL PROTECTED] Reported By: v_santhanam at ettimadai dot amrita dot edu -Status: Closed +Status: Assigned Bug Type: Compile Failure Operating System: Redhat Enterprise Linux AS 3 PHP Version: 4.3.8 -Assigned To: +Assigned To: rjs New Comment: If it's not supported then configure should check for it. Assigning to the maintainer. Previous Comments: [2004-07-22 16:53:56] [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 The pdf wrapper in PHP 4.3.x is not compatible with PDFlib 6. Please try the PECL package for pdflib, this has the new wrappercode that works with PDFlib 6 too and it can be used with PHP 4.3. [2004-07-21 13:51:14] v_santhanam at ettimadai dot amrita dot edu Description: Dear Friends, I am trying to compile php-4.3.8 with pdflib 6(latest version). But i am not able to make with the following error : -- ext/pdf/pdf.lo(.text+0x5fd): In function `zif_pdf_open': /usr/local/src/php-4.3.8/ext/pdf/pdf.c:472: undefined reference to `PDF_open_fp' collect2: ld returned 1 exit status make: *** [sapi/cli/php] Error 1 -- My php configure command is : --- ./configure --with-apxs2=/usr/local/apache2/bin/apxs --with-mysql=/usr --with-pdflib=/usr/local Please kindly help me. Thanks in advance With Regards Santhanam -- Edit this bug report at http://bugs.php.net/?id=29297&edit=1
#29965 [NEW]: file transfer problem
From: praveen_m_r at yahoo dot com
Operating system: windows XP
PHP version: 4.3.8
PHP Bug Type: *Directory/Filesystem functions
Bug description: file transfer problem
Description:
Iam writing a code for transfering(uploading) file from one server to
another server from the client system. Iam using FTP functions for
that.Iam also giving the code below
Function
uploadTemplate($hostname,$FTPUserName,$FTPPassword,$remotelocation){
[EMAIL PROTECTED]("$hostname");
[EMAIL PROTECTED]($handle,$FTPUserName,$FTPPassword) ;
[EMAIL PROTECTED]($handle);
$workingDirectory=str_replace( "/home","",$workingDirectory);
$workingDirectory=str_replace("ftp","",$workingDirectory);
$local="$local";
//$remote=$remotelocation."index.php";
$remote="/www/htdocs";
$remote=$remote.$workingDirectory."sample.php";
directory=".$workingDirectory."remote=$remote");
[EMAIL PROTECTED]($handle,$remote,$local,FTP_BINARY) ;
echo($upload_success);
@ftp_quit($handle);
return $upload_success;
}
?>
When i used IP address of the host instad of host name only ftp_put shows
FALSE. Otherwise entare code is not working.
Please replay me.
--
Edit bug report at http://bugs.php.net/?id=29965&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=29965&r=trysnapshot4
Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=29965&r=trysnapshot50
Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=29965&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=29965&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=29965&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=29965&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=29965&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=29965&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=29965&r=support
Expected behavior: http://bugs.php.net/fix.php?id=29965&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=29965&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=29965&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=29965&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=29965&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=29965&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=29965&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=29965&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=29965&r=float
#29966 [NEW]: __destruct causes segmentation fault
From: grnick at mail dot ru
Operating system: Redhat Linux 9.0
PHP version: 5.0.1
PHP Bug Type: Zend Engine 2 problem
Bug description: __destruct causes segmentation fault
Description:
If class includes function __destruct() any error of script makes
segmentation fault.
Configure Command: './configure' '--with-pgsql' '--with-mysql'
'--with-apxs' '--with-apxs=/usr/local/apache/bin/apxs' '--enable-sysvsem'
'--enable-sockets'
Apache/1.3.24
Loaded Modules mod_php5, mod_setenvif, mod_so, mod_auth, mod_access,
mod_rewrite, mod_alias, mod_userdir, mod_actions, mod_imap, mod_asis,
mod_cgi, mod_dir, mod_autoindex, mod_include, mod_status, mod_negotiation,
mod_mime, mod_log_config, mod_env, http_core
Reproduce code:
---
class C1 {}
class C2 {
public function __construct() {
$v = new C();
// throw new Exception("");
}
public function __destruct() {$id=0;}
}
$obj = new C2();
Expected result:
Fatal error: Class 'C' not found in test.php on line 7
Actual result:
--
Apache error_log
[notice] child pid 11402 exit signal Segmentation fault (11)
--
Edit bug report at http://bugs.php.net/?id=29966&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=29966&r=trysnapshot4
Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=29966&r=trysnapshot50
Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=29966&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=29966&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=29966&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=29966&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=29966&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=29966&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=29966&r=support
Expected behavior: http://bugs.php.net/fix.php?id=29966&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=29966&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=29966&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=29966&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=29966&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=29966&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=29966&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=29966&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=29966&r=float
#29966 [Opn->Fbk]: __destruct causes segmentation fault
ID: 29966
Updated by: [EMAIL PROTECTED]
Reported By: grnick at mail dot ru
-Status: Open
+Status: Feedback
Bug Type: Zend Engine 2 problem
Operating System: Redhat Linux 9.0
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
Previous Comments:
[2004-09-03 09:36:29] grnick at mail dot ru
Description:
If class includes function __destruct() any error of script makes
segmentation fault.
Configure Command: './configure' '--with-pgsql' '--with-mysql'
'--with-apxs' '--with-apxs=/usr/local/apache/bin/apxs'
'--enable-sysvsem' '--enable-sockets'
Apache/1.3.24
Loaded Modules mod_php5, mod_setenvif, mod_so, mod_auth, mod_access,
mod_rewrite, mod_alias, mod_userdir, mod_actions, mod_imap, mod_asis,
mod_cgi, mod_dir, mod_autoindex, mod_include, mod_status,
mod_negotiation, mod_mime, mod_log_config, mod_env, http_core
Reproduce code:
---
class C1 {}
class C2 {
public function __construct() {
$v = new C();
// throw new Exception("");
}
public function __destruct() {$id=0;}
}
$obj = new C2();
Expected result:
Fatal error: Class 'C' not found in test.php on line 7
Actual result:
--
Apache error_log
[notice] child pid 11402 exit signal Segmentation fault (11)
--
Edit this bug report at http://bugs.php.net/?id=29966&edit=1
#29966 [Fbk->Bgs]: __destruct causes segmentation fault
ID: 29966
Updated by: [EMAIL PROTECTED]
Reported By: grnick at mail dot ru
-Status: Feedback
+Status: Bogus
Bug Type: Zend Engine 2 problem
Operating System: Redhat Linux 9.0
PHP Version: 5.0.1
New Comment:
Reproduce code isn't working, but changing "new C()" to "new C2()"
leads to endless loop and quite expected segfault.
So, it's expected behaviour imo.
Previous Comments:
[2004-09-03 10:26:56] [EMAIL PROTECTED]
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
[2004-09-03 09:36:29] grnick at mail dot ru
Description:
If class includes function __destruct() any error of script makes
segmentation fault.
Configure Command: './configure' '--with-pgsql' '--with-mysql'
'--with-apxs' '--with-apxs=/usr/local/apache/bin/apxs'
'--enable-sysvsem' '--enable-sockets'
Apache/1.3.24
Loaded Modules mod_php5, mod_setenvif, mod_so, mod_auth, mod_access,
mod_rewrite, mod_alias, mod_userdir, mod_actions, mod_imap, mod_asis,
mod_cgi, mod_dir, mod_autoindex, mod_include, mod_status,
mod_negotiation, mod_mime, mod_log_config, mod_env, http_core
Reproduce code:
---
class C1 {}
class C2 {
public function __construct() {
$v = new C();
// throw new Exception("");
}
public function __destruct() {$id=0;}
}
$obj = new C2();
Expected result:
Fatal error: Class 'C' not found in test.php on line 7
Actual result:
--
Apache error_log
[notice] child pid 11402 exit signal Segmentation fault (11)
--
Edit this bug report at http://bugs.php.net/?id=29966&edit=1
#29950 [Opn]: Nondeterministic behavior of array inner pointer
ID: 29950
Updated by: [EMAIL PROTECTED]
Reported By: tomas_matousek at hotmail dot com
Status: Open
Bug Type: Arrays related
Operating System: WinXP
PHP Version: 5.0.1
New Comment:
I think it is mentioned in the manual that PHP uses copy-on-write
technique. This means that if
$a = array(1,2,3);
and
$b = $a;
there is _only_ 1 array and $b reference this array. When change has
been made the copy-on-write starts to work. AFAIK it is not only for
arrays...
Simple example :
php -r '$a=str_repeat("a", 1000);while ($i++<2000) ${"a".$i} = $a;
This thing creates a very long string ~ 10MB, and then reference it
2000 times. If there was no copy-on-write then I will need 2*10^10
memory, which is more than a process on 32bit architecture can
address.
Previous Comments:
[2004-09-02 14:22:19] tomas_matousek at hotmail dot com
Description:
In the manual page describing each() function is the following
caution:
"Because assigning an array to another variable resets the original
arrays pointer, ..."
I think that this is a bug, although it is documented and treated as
feature.
I realized that the pointer is reset when a copy of an array is made.
However, PHP makes some optimizations which prevents unnecessary array
copying (which is good feature).
Since these optimizations are not known for users (and shouldn't be)
the behavior of inner pointer is thus non-deterministic from user's
point of view.
See the follwoing code.
Its output depends on whether the statement $b[] = 1; is commented or
not.
Reproduce code:
---
function f($a) { $b = $a; /*$b[] = 1;*/ return $b; }
$arrayOuter = array("key1","key2");
$arrayInner = array("0","1");
while(list(,$o) = each($arrayOuter))
{
$q = f($arrayInner);
while(list(,$i) = each($arrayInner))
{
print "inloop $i for $o\n";
}
}
Expected result:
inloop 0 for key1
inloop 1 for key1
Actual result:
--
inloop 0 for key1
inloop 1 for key1
inloop 0 for key2
inloop 1 for key2
--
Edit this bug report at http://bugs.php.net/?id=29950&edit=1
#29654 [Bgs]: Different timezone's time is stored in Apache process for other requests
ID: 29654
User updated by: kulakov74 at yandex dot ru
Reported By: kulakov74 at yandex dot ru
Status: Bogus
Bug Type: Date/time related
Operating System: Linux
PHP Version: 4.3.7
New Comment:
Thanks for the answer, there's certainly no bug here, but I want to
make it a feature request this way: the fact that there's no way to
unset an environment variable makes it impossible to recover the
initial state when there's no timezone set. Note that when TZ is not
set and when it is set to an empty string are two different things -
the first uses the locale of the server, while the second uses GMT. In
this situation the only way to leave the process with the correct
timezone is to set it directly, but then one has to know it, and this
is not very convenient. First of all, you can't just have a piece of
code that does all the task - whenever you deploy it to another server
you have to somehow tell it the server's timezone - either via config
files or by hardcoding; after all, one may just forget it. What I mean
is that PHP badly lacks a function for unsetting environment variables.
Previous Comments:
[2004-08-16 08:37:44] [EMAIL PROTECTED]
But you DO need to set it back immediately as the function modifies the
environment which is also used by requests to the same apache child. No
bug here.
[2004-08-13 16:51:49] kulakov74 at yandex dot ru
Description:
I tried putenv('TZ=...') to get local time for any timezone. After
that, if I don't call putenv('TZ=...') using date/time functions
(date()) in consequent requests randomly return either local time or
the time for the zone last set with TZ. In Apache access_log's time
offsets also vary. It seems that Apache proccesses remember the time
for the timezone set with TZ and use it for consequent requests.
Unfortunately, there's no function for deleting an environment
variable. Even though with consequent requests TZ seems to be
undefined, date functions work as if it were set for the last value.
For a reason, calling mktime(0,0,0,1,1,1970) clears Apache's processes
internal time, but that happens only on subsequent requests, not within
the same one.
Of course, one can use putenv('TZ=...') for setting local timezone back
after working with a different timezone, but anyway I guess that
shouldn't be the way it is.
We use Apache 2.
Reproduce code:
---
//first request:
echo(date('H:i:s').''); //localtime
putenv('TZ=Europe/Moscow');
echo(date('H:i:s').''); //Moscow time - works okay
//at consequent requests:
echo(date('H:i:s').''); //may produce local or Moscow time,
depending on which Apache process handles the request
Expected result:
see above
Actual result:
--
see above
--
Edit this bug report at http://bugs.php.net/?id=29654&edit=1
#29950 [Opn]: Nondeterministic behavior of array inner pointer
ID: 29950
Updated by: [EMAIL PROTECTED]
Reported By: tomas_matousek at hotmail dot com
Status: Open
Bug Type: Arrays related
-Operating System: WinXP
+Operating System: all
PHP Version: 5.0.1
New Comment:
http://www.zend.com/zend/art/ref-count.php
Previous Comments:
[2004-09-03 10:53:26] [EMAIL PROTECTED]
I think it is mentioned in the manual that PHP uses copy-on-write
technique. This means that if
$a = array(1,2,3);
and
$b = $a;
there is _only_ 1 array and $b reference this array. When change has
been made the copy-on-write starts to work. AFAIK it is not only for
arrays...
Simple example :
php -r '$a=str_repeat("a", 1000);while ($i++<2000) ${"a".$i} = $a;
This thing creates a very long string ~ 10MB, and then reference it
2000 times. If there was no copy-on-write then I will need 2*10^10
memory, which is more than a process on 32bit architecture can
address.
[2004-09-02 14:22:19] tomas_matousek at hotmail dot com
Description:
In the manual page describing each() function is the following
caution:
"Because assigning an array to another variable resets the original
arrays pointer, ..."
I think that this is a bug, although it is documented and treated as
feature.
I realized that the pointer is reset when a copy of an array is made.
However, PHP makes some optimizations which prevents unnecessary array
copying (which is good feature).
Since these optimizations are not known for users (and shouldn't be)
the behavior of inner pointer is thus non-deterministic from user's
point of view.
See the follwoing code.
Its output depends on whether the statement $b[] = 1; is commented or
not.
Reproduce code:
---
function f($a) { $b = $a; /*$b[] = 1;*/ return $b; }
$arrayOuter = array("key1","key2");
$arrayInner = array("0","1");
while(list(,$o) = each($arrayOuter))
{
$q = f($arrayInner);
while(list(,$i) = each($arrayInner))
{
print "inloop $i for $o\n";
}
}
Expected result:
inloop 0 for key1
inloop 1 for key1
Actual result:
--
inloop 0 for key1
inloop 1 for key1
inloop 0 for key2
inloop 1 for key2
--
Edit this bug report at http://bugs.php.net/?id=29950&edit=1
#29297 [Asn]: PDFLib 6 make error
ID: 29297 Updated by: [EMAIL PROTECTED] Reported By: v_santhanam at ettimadai dot amrita dot edu Status: Assigned Bug Type: Compile Failure Operating System: Redhat Enterprise Linux AS 3 PHP Version: 4.3.8 Assigned To: rjs New Comment: I think the changes in the PECL version which was a repo copy of ext/pdflib should have the PHP 4 changes MFH so that php 4.3.9 compiles cleanly with pdflib 6 support. Previous Comments: [2004-09-03 08:39:23] [EMAIL PROTECTED] If it's not supported then configure should check for it. Assigning to the maintainer. [2004-07-22 16:53:56] [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 The pdf wrapper in PHP 4.3.x is not compatible with PDFlib 6. Please try the PECL package for pdflib, this has the new wrappercode that works with PDFlib 6 too and it can be used with PHP 4.3. [2004-07-21 13:51:14] v_santhanam at ettimadai dot amrita dot edu Description: Dear Friends, I am trying to compile php-4.3.8 with pdflib 6(latest version). But i am not able to make with the following error : -- ext/pdf/pdf.lo(.text+0x5fd): In function `zif_pdf_open': /usr/local/src/php-4.3.8/ext/pdf/pdf.c:472: undefined reference to `PDF_open_fp' collect2: ld returned 1 exit status make: *** [sapi/cli/php] Error 1 -- My php configure command is : --- ./configure --with-apxs2=/usr/local/apache2/bin/apxs --with-mysql=/usr --with-pdflib=/usr/local Please kindly help me. Thanks in advance With Regards Santhanam -- Edit this bug report at http://bugs.php.net/?id=29297&edit=1
#29654 [Bgs->Asn]: Different timezone's time is stored in Apache process for other requests
ID: 29654
Updated by: [EMAIL PROTECTED]
Reported By: kulakov74 at yandex dot ru
-Status: Bogus
+Status: Assigned
Bug Type: Date/time related
Operating System: Linux
PHP Version: 4.3.7
-Assigned To:
+Assigned To: derick
New Comment:
The feature request is already on my todo, should be in 5.1.
Previous Comments:
[2004-09-03 10:58:20] kulakov74 at yandex dot ru
Thanks for the answer, there's certainly no bug here, but I want to
make it a feature request this way: the fact that there's no way to
unset an environment variable makes it impossible to recover the
initial state when there's no timezone set. Note that when TZ is not
set and when it is set to an empty string are two different things -
the first uses the locale of the server, while the second uses GMT. In
this situation the only way to leave the process with the correct
timezone is to set it directly, but then one has to know it, and this
is not very convenient. First of all, you can't just have a piece of
code that does all the task - whenever you deploy it to another server
you have to somehow tell it the server's timezone - either via config
files or by hardcoding; after all, one may just forget it. What I mean
is that PHP badly lacks a function for unsetting environment variables.
[2004-08-16 08:37:44] [EMAIL PROTECTED]
But you DO need to set it back immediately as the function modifies the
environment which is also used by requests to the same apache child. No
bug here.
[2004-08-13 16:51:49] kulakov74 at yandex dot ru
Description:
I tried putenv('TZ=...') to get local time for any timezone. After
that, if I don't call putenv('TZ=...') using date/time functions
(date()) in consequent requests randomly return either local time or
the time for the zone last set with TZ. In Apache access_log's time
offsets also vary. It seems that Apache proccesses remember the time
for the timezone set with TZ and use it for consequent requests.
Unfortunately, there's no function for deleting an environment
variable. Even though with consequent requests TZ seems to be
undefined, date functions work as if it were set for the last value.
For a reason, calling mktime(0,0,0,1,1,1970) clears Apache's processes
internal time, but that happens only on subsequent requests, not within
the same one.
Of course, one can use putenv('TZ=...') for setting local timezone back
after working with a different timezone, but anyway I guess that
shouldn't be the way it is.
We use Apache 2.
Reproduce code:
---
//first request:
echo(date('H:i:s').''); //localtime
putenv('TZ=Europe/Moscow');
echo(date('H:i:s').''); //Moscow time - works okay
//at consequent requests:
echo(date('H:i:s').''); //may produce local or Moscow time,
depending on which Apache process handles the request
Expected result:
see above
Actual result:
--
see above
--
Edit this bug report at http://bugs.php.net/?id=29654&edit=1
#29968 [NEW]: __destruct and calling non-existent function
From: grnick at mail dot ru
Operating system: Linux
PHP version: 5CVS-2004-09-03 (dev)
PHP Bug Type: Zend Engine 2 problem
Bug description: __destruct and calling non-existent function
Description:
Configure Command: './configure' '--with-pgsql' '--with-mysql'
'--with-apxs' '--with-apxs=/usr/local/apache/bin/apxs'
'--enable-sysvsem' '--enable-sockets'
Apache/1.3.24
Loaded Modules mod_php5, mod_setenvif, mod_so, mod_auth, mod_access,
mod_rewrite, mod_alias, mod_userdir, mod_actions, mod_imap, mod_asis,
mod_cgi, mod_dir, mod_autoindex, mod_include, mod_status,
mod_negotiation, mod_mime, mod_log_config, mod_env, http_core
Reproduce code:
---
Test();
}
public function __destruct() {}
}
$obj = new C2();
?>
Expected result:
Fatal error: Call to undefined method C1::Test() in test.php on line 8
Actual result:
--
Apache error_log
[notice] child pid 11402 exit signal Segmentation fault (11)
And without destructor that code works right.
--
Edit bug report at http://bugs.php.net/?id=29968&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=29968&r=trysnapshot4
Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=29968&r=trysnapshot50
Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=29968&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=29968&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=29968&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=29968&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=29968&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=29968&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=29968&r=support
Expected behavior: http://bugs.php.net/fix.php?id=29968&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=29968&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=29968&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=29968&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=29968&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=29968&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=29968&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=29968&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=29968&r=float
#29939 [Opn->Bgs]: HTTP streams not functioning as expected running through web server.
ID: 29939
Updated by: [EMAIL PROTECTED]
Reported By: testwicks17543 at yahoo dot com
-Status: Open
+Status: Bogus
Bug Type: HTTP related
Operating System: RedHat ES 3
PHP Version: 4.3.8
New Comment:
Please file bugs in the RHEL php package at
https://bugzilla.redhat.com/bugzilla/.
PHP socket handling is not reliable and may cause segfaults or hangs if
you push the fd numbers over 1024. This is a duplicate of #24189.
Previous Comments:
[2004-09-01 23:43:29] testwicks17543 at yahoo dot com
Description:
We are currently experiencing issues with HTTP streams within PHP
scripts being run through Apache (using the php4_module). We are not
experiencing the issues if we run the php script from the command
line.
System info:
System is running RedHat ES 3 with all the latest patches applied. The
system has approx 512 virtual web sites configured in Apache. The
Apache startup script changes the max file descriptors to a number
higher than the RedHat default of 1024 (the number is currently set too
409600; we have also tried lower numbers such as 8192; please, note that
Apache opens more than 1024 files upon startup and that the default
setting is no longer an option; each virtual site has its own access
log and error log).
RPM list:
kernel-smp-2.4.21-15.0.4.EL
httpd-2.0.46-32.ent.3
php-4.3.2-11.1.ent
php-mysql-4.3.2-11.1.ent
PHP specifics:
'./configure' '--host=i386-redhat-linux' '--build=i386-redhat-linux'
'--target=i386-redhat-linux-gnu' '--program-prefix=' '--prefix=/usr'
'--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin'
'--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include'
'--libdir=/usr/lib' '--libexecdir=/usr/libexec' '--localstatedir=/var'
'--sharedstatedir=/usr/com' '--mandir=/usr/share/man'
'--infodir=/usr/share/info' '--cache-file=../config.cache'
'--with-config-file-path=/etc' '--with-config-file-scan-dir=/etc/php.d'
'--enable-force-cgi-redirect' '--disable-debug' '--enable-pic'
'--disable-rpath' '--enable-inline-optimization' '--with-bz2'
'--with-db4=/usr' '--with-curl' '--with-dom=/usr'
'--with-exec-dir=/usr/bin' '--with-freetype-dir=/usr'
'--with-png-dir=/usr' '--with-gd' '--enable-gd-native-ttf' '--with-ttf'
'--with-gettext' '--with-ncurses' '--with-gmp' '--with-iconv'
'--with-jpeg-dir=/usr' '--with-openssl' '--with-png' '--with-pspell'
'--with-regex=system' '--with-xml' '--with-expat-dir=/usr'
'--with-pcre-regex=/usr' '--with-zlib' '--with-layout=GNU'
'--enable-bcmath' '--enable-exif' '--enable-ftp'
'--enable-magic-quotes' '--enable-safe-mode' '--enable-sockets'
'--enable-sysvsem' '--enable-sysvshm' '--enable-discard-path'
'--enable-track-vars' '--enable-trans-sid' '--enable-yp'
'--enable-wddx' '--enable-mbstring' '--enable-mbstr-enc-trans'
'--enable-mbregex' '--without-oci8' '--with-pear=/usr/share/pear'
'--with-imap=shared' '--with-imap-ssl' '--with-kerberos=/usr/kerberos'
'--with-ldap=shared' '--with-mysql=shared,/usr' '--with-pgsql=shared'
'--with-unixODBC=shared' '--enable-memory-limit' '--enable-bcmath'
'--enable-shmop' '--enable-versioning' '--enable-calendar'
'--enable-dbx' '--enable-dio' '--enable-mcal'
'--with-apxs2filter=/usr/sbin/apxs'
We would like to know how to further troubleshoot this error to
determine the reason why this error message started happening. We have
other web servers configured identically (same version of RedHat
distribution, same version of Apache, PHP etc.), with fewer web sites
that are not experiencing this issue.
Please, let us know if there is any additional information needed.
Thank you,
Reproduce code:
---
Code that produces errors:
http://somewebhost.domain.gTLD/index.html";, "r");
$httpfile =
file_get_contents("http://somewebhost.domain.gTLD/index.html";);
include 'http://somewebhost.domain.gTLD/index.html';
?>
Expected result:
The contents of index.html.
Actual result:
--
Errors:
Warning: fopen(http://somewebhost.domain.gTLD): failed to open stream:
HTTP request failed! in /www/localwebhost.domain.gTLD/htdocs/test.php
on line 2
Warning: file_get_contents(http://somewebhost.domain.gTLD/index.html):
failed to open stream: HTTP request failed! Ø ` in
/www/localwebhost.domain.gTLD/htdocs/test.php on line 3
Warning: main(http://somewebhost.domain.gTLD/index.html): failed to
open stream: HTTP request failed! 0vÿ¿Øc xÀN1a1þ: in
/www/localwebhost.domain.gTLD/htdocs/test.php on line 4
Warning: main(): Failed opening
'http://somewebhost.domain.gTLD/index.html' for inclusion
(include_path='.') in /www/localwebhost.domain.gTLD/htdocs/test.php on
line 4
--
Edit this bug report at http://bugs.php.net/?id=29939&edit=1
#29917 [Com]: isset() always return
ID: 29917
Comment by: fch at hexanet dot fr
Reported By: dasch at ulmail dot net
Status: Bogus
Bug Type: Class/Object related
Operating System: Linux
PHP Version: 5.0.1
New Comment:
offsetGet($key);
}
function __set($key, $value)
{
$this->offsetSet($key, $value);
}
function offsetExists($key)
{
return isset($this->array[$key]);
}
function offsetGet($key)
{
return $this->array[$key];
}
function offsetSet($key, $value)
{
$this->array[$key] = $value;
}
function offsetUnset($key)
{
unset($this->array[$key];
}
}
$foo = new foo();
echo (isset($foo['bar']) == true ? 'set' : 'not set');
$foo['bar'] = 'bar';
echo (isset($foo['bar']) == true ? 'set' : 'not set');
echo $foo['bar'];
#Expected result :
# not set
# set
# bar
#Real result
# not set
# set
# bar
# !! GREAT !!
#Now, the same thing with __get() and __set()
unset($foo);
$foo = new foo();
echo (isset($foo->array) == true ? 'array is set' : 'array is not
set');
echo (isset($foo->bar) == true ? 'bar is set' : 'bar is not set');
$foo->bar = 'bar';
echo (isset($foo['bar']) == true ? 'bar is set' : 'bar is not set');
echo $foo->bar;
#Expected result :
# array is set
# bar is not set
# bar is set
# bar
#Real result
# array is set # Ok !
# bar is not set # Ok !
# bar is not set # PROBLEM PROBLEM
# bar
# !! NOT GREAT !!
?>
It is abnormal !
isset() does not return the good value on property wich was set with
__set() it is return the good value on property wich was set in the
class,and isset() return the good value on value wich was set with
offsetSet() method !!
It is a paradox !
I think that isset MUST return the same value in all case.
Previous Comments:
[2004-09-01 13:51:05] dasch at ulmail dot net
If the isset() function aren't going to work with properties accessed
with a __get() call, then there should at least be a __isset() method
that allows for custom isset()-handling. eg:
$prop)) {
return TRUE;
} else {
return FALSE;
}
}
}
$foo = new Foo();
echo isset($foo->bar) ? "yes\n" : "no\n";
// Should be the same as
echo $foo->__isset('bar') ? "yes\n" : "no\n";
?>
[2004-09-01 10:24:01] fch at hexanet dot fr
Can you explain where are wrong ???
A call to __set() create a property in the object (see documentation).
Event if this property is not a real member property for PHP language
point of view, for the programers point of view, it is a property !
So, isset() MUST return true in my example.
What are difference between your example :
$o->a = 'bar';
echo isset($o->a) ? "yes\n" : "no\n";
And my example :
$o->foo = 'bar';
echo (isset($o->foo) == true ? 'foo is set' : 'foo is not set');
There is no difference ! Except that my foo property was created with a
__set() call.
[2004-09-01 10:14:10] [EMAIL PROTECTED]
No, you're wrong. The behavior you see is the correct behavior.
[2004-09-01 09:59:01] fch at hexanet dot fr
array[$name] = $value;
}
function __get($name)
{
if (isset($this->array[$name]) == true)
return null;
else
return $this->array[$name];
}
}
$o = new oo();
$o->foo = 'bar';
echo (isset($o->foo) == true ? 'foo is set' : 'foo is not set');
#Expecting result
# => foo is set
#Real result
# => foo is not set
?>
If PHP provide __set() and __get() function in order to create property
dynamicaly, PHP function like isset() MUST BE USED with these "dynamic"
properties as usual.
So, in my example, isset() MUST return TRUE !! and not FALSE !!
[2004-09-01 08:41:52] [EMAIL PROTECTED]
This works fine for me:
[EMAIL PROTECTED]:~$ cat bug29917.php
a) ? "yes\n" : "no\n";
$o->a = 'bar';
echo isset($o->a) ? "yes\n" : "no\n";
?>
[EMAIL PROTECTED]:~$ php bug29917.php
no
yes
Come up with a short example like mine that shows that it doesn't work.
Just saying $o->a won't work doesn't help.
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/29917
--
Edit this bug report at http://bugs.php.net/?id=29917&edit=1
#29665 [Com]: PHP Fails to compile when soap is enabled
ID: 29665 Comment by: amit dot gupta at prudence-india dot com Reported By: moontumbo at hotmail dot com Status: Open Bug Type: Compile Failure Operating System: Red Hat Enterprise Linux WS 3.0 PHP Version: 5.0.1 New Comment: Yes upgrading to libxml2-2.6* solves this problem Previous Comments: [2004-08-31 01:30:36] clewis at myfonts dot com I too saw this problem on RedHat Enterprise 3 using libxml2 2.5.10. Upgrading to 2.6.12 solved the problem. [2004-08-28 16:52:52] michiel at dotgeek dot org same problem, slack 9.0 $ xml2-config --version 2.6.12 [2004-08-25 01:00:11] 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-08-17 23:17:13] ibrash at gaernin dot aswwc dot net Issue reproduced on Slackware 9.1 with libxml2 2.5.11. [2004-08-17 08:06:37] [EMAIL PROTECTED] Which libxml2 did you have installed before? 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/29665 -- Edit this bug report at http://bugs.php.net/?id=29665&edit=1
#29958 [Com]: cURL https request fails when connecting to IP (not domain)
ID: 29958
Comment by: daniel at haxx dot se
Reported By: ryan dot hansen at usa dot net
Status: Open
Bug Type: cURL related
Operating System: Debian
PHP Version: 4.3.8
New Comment:
curl 7.9.5 was released some 30 months ago. Do I need to say more?
Previous Comments:
[2004-09-02 21:28:29] ryan dot hansen at usa dot net
I should mention that this same code DOES work on a different
requesting server (FreeBSD 4.4; PHP 4.2.3)
[2004-09-02 21:21:42] ryan dot hansen at usa dot net
Description:
When attempting to connect to an IP address (not a domain) over SSL
using cURL (7.9.5), there is no response, no errors, etc. I get
nothing. When I test the same script with a domain (a different
server), I get a response as expected. When I test it with the correct
IP address over HTTP (non-secure), I also get a response as expected.
The problem, however, is that the server that I have to connect to for
the app I'm building does not have a domain, only an IP address and it
must be a secure connection.
I admit that I could be missing something, but I can't figure out what
it is and I've tested it pretty thoroughly under multiple scenarios.
Reproduce code:
---
$postdata = "POST DATA TO POST TO SERVER";
// use appropriate IP, of course
$ch = curl_init("https://xxx.xxx.xxx.xxx";);
curl_setopt($ch, CURL_POST, 1);
curl_setopt($ch, CURL_POSTFIELDS, $postdata);
curl_setopt($ch, CURL_ERROR, 1);
curl_setopt($ch, CURL_RETURNTRANSFER, 1);
$retval = curl_exec($ch);
curl_close($ch);
// print result for testing
echo $retval;
exit;
Expected result:
The echo statement should print the web page data from the IP to the
screen, and it does when I test with non-secure IP or domain.
Actual result:
--
Nothing. The echo statement doesn't seem to print anything. No cURL
errors, no results, no PHP warnings or errors.
--
Edit this bug report at http://bugs.php.net/?id=29958&edit=1
#29937 [Com]: $_FILES['name'] no longer has full path (from 4.3.4 to 4.3.8)
ID: 29937 Comment by: brad at timelesstech dot com Reported By: justin at timelesstech dot com Status: Open Bug Type: *Directory/Filesystem functions Operating System: FreeBSD 4.8 stable PHP Version: 4.3.8 New Comment: It might have something to do with this bug fix: http://bugs.php.net/bug.php?id=28456 Previous Comments: [2004-09-02 08:40:25] justin at timelesstech dot com Our web host, pair Networks, installed the PHP version to the server. I believe they compiled from source, and I know they are experts at installing and configuring PHP as they manage hundreds of servers. >From a phpinfo() command here are the configure command options they used on Aug 18/04: './configure' '--with-apache=/usr/pair/sw/apache_1.3.29' '--with-config-file-path=/usr/local/etc' '--enable-magic-quotes' '--enable-bcmath' '--without-cdb' '--with-zlib-dir=/usr/local' '--with-gd' '--with-ttf' '--without-msql' '--with-mysql=/usr/local' '--with-iodbc' '--with-pdflib' '--enable-inline-optimization' '--disable-memory-limit' '--with-db' '--without-gdbm' '--with-ndbm' '--without-db2' '--without-dbm' '--with-gettext' '--without-readline' '--with-recode' '--without-openssl' '--with-mcrypt' '--without-db3' '--enable-dba' '--with-curl' '--with-png-dir=/usr/local/lib' '--with-jpeg-dir=/usr/local/lib' '--enable-calendar' '--with-mhash' '--enable-xslt' '--with-xslt-sablot' '--with-expat-dir=/usr/local' '--enable-gd-lzw-gif' '--enable-mstring' [2004-09-02 08:20:28] [EMAIL PROTECTED] Did you compile PHP from source or did you use the ports? If you used the ports, can you check what patches were applied to the clean php source? [2004-09-01 22:40:40] justin at timelesstech dot com Description: We have had scripts running for a while now fine on PHP 4.3.4 that assume that the $_FILES['name'] value on file uploads contains the full /path/to/the/filename.txt However after our server admins upgraded to PHP 4.3.8 the $FILES['name'] now only contains the filename, with no path. This makes it impossible for our recursive file uploader script to work, since it NEEDS the pathname of those files to know what directory/subdir on the server to upload the file(s) to! The changelog does not mention this, but does anybody have any ideas? -- Edit this bug report at http://bugs.php.net/?id=29937&edit=1
#29958 [Opn->Bgs]: cURL https request fails when connecting to IP (not domain)
ID: 29958
Updated by: [EMAIL PROTECTED]
Reported By: ryan dot hansen at usa dot net
-Status: Open
+Status: Bogus
Bug Type: cURL related
Operating System: Debian
PHP Version: 4.3.8
New Comment:
Good point Daniel, marking this as bogus. Upgrade first!
Previous Comments:
[2004-09-03 14:38:42] daniel at haxx dot se
curl 7.9.5 was released some 30 months ago. Do I need to say more?
[2004-09-02 21:28:29] ryan dot hansen at usa dot net
I should mention that this same code DOES work on a different
requesting server (FreeBSD 4.4; PHP 4.2.3)
[2004-09-02 21:21:42] ryan dot hansen at usa dot net
Description:
When attempting to connect to an IP address (not a domain) over SSL
using cURL (7.9.5), there is no response, no errors, etc. I get
nothing. When I test the same script with a domain (a different
server), I get a response as expected. When I test it with the correct
IP address over HTTP (non-secure), I also get a response as expected.
The problem, however, is that the server that I have to connect to for
the app I'm building does not have a domain, only an IP address and it
must be a secure connection.
I admit that I could be missing something, but I can't figure out what
it is and I've tested it pretty thoroughly under multiple scenarios.
Reproduce code:
---
$postdata = "POST DATA TO POST TO SERVER";
// use appropriate IP, of course
$ch = curl_init("https://xxx.xxx.xxx.xxx";);
curl_setopt($ch, CURL_POST, 1);
curl_setopt($ch, CURL_POSTFIELDS, $postdata);
curl_setopt($ch, CURL_ERROR, 1);
curl_setopt($ch, CURL_RETURNTRANSFER, 1);
$retval = curl_exec($ch);
curl_close($ch);
// print result for testing
echo $retval;
exit;
Expected result:
The echo statement should print the web page data from the IP to the
screen, and it does when I test with non-secure IP or domain.
Actual result:
--
Nothing. The echo statement doesn't seem to print anything. No cURL
errors, no results, no PHP warnings or errors.
--
Edit this bug report at http://bugs.php.net/?id=29958&edit=1
#29970 [NEW]: DOM/EXSLT refuses to load
From: cristi_2112 at yahoo dot com Operating system: Windows XP PHP version: 4.3.8 PHP Bug Type: XSLT related Bug description: DOM/EXSLT refuses to load Description: I need to work in PHP with EXSL. I downloaded the latest version from snaps.php, I also downloaded the libxslt.dll, libxml2.dll, libexslt.dll latest version from your link on the site and put them in c:/php, c:/windows/system32 (like the other extensions I use). xsltproc.exe is working fine: I called xsltproc.exe -V : Using libxml 20612, libxslt 10109 and libexslt 807 xsltproc was compiled against libxml 20612, libxslt 10109 and libexslt 807 libxslt 10109 was compiled against libxml 20612 libexslt 807 was compiled against libxml 20612 I edited my php.ini: extension=php_xslt.dll extension=libxslt.dll extension=libxml2.dll extension=libexslt.dll (tryed in more ways). When I restart Apache, I get (one at a time): Invalid library (maybe not a PHP library) 'libxslt.dll' Invalid library (maybe not a PHP library) 'libxml2.dll' Unable to load dynamic library: 'c:\php\libexslt.dll' - The specified module could not be found. (although it's right there). So php still won't recognize EXSLT. On Linux it's working fine (giving to the compile option --with-dom-exslt). Please, help me out if you can. -- Edit bug report at http://bugs.php.net/?id=29970&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=29970&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=29970&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=29970&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=29970&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=29970&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=29970&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=29970&r=needscript Try newer version: http://bugs.php.net/fix.php?id=29970&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=29970&r=support Expected behavior: http://bugs.php.net/fix.php?id=29970&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=29970&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=29970&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=29970&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=29970&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=29970&r=dst IIS Stability: http://bugs.php.net/fix.php?id=29970&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=29970&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=29970&r=float
#29971 [NEW]: variables_order behaviour
From: [EMAIL PROTECTED]
Operating system: Linux 2.6.7
PHP version: 5.0.1
PHP Bug Type: *Configuration Issues
Bug description: variables_order behaviour
Description:
Hi,
regardless of the setting for variables_order, all types of variables
(EGPCS) are registered by php. This is true for the apache, cli and cgi
SAPI.
For sure I doublechecked using the right ini-file.
If this is desired behaviour at least the docs are confusing:
http://www.php.net/manual/en/ini.sect.data-handling.php#ini.variables-order
as they imply, that variables which are not set in variables_order are
ignored by php.
Reproduce code:
---
Short repro-skript for cli:
./php -n -d variables_order="GPC" -r 'var_dump($_ENV,
$_SERVER);var_dump(ini_get("variables_order"));'
./php -v:
PHP 5.0.1 (cli) (built: Aug 31 2004 00:23:09)
Copyright (c) 1997-2004 The PHP Group
Zend Engine v2.0.1, Copyright (c) 1998-2004 Zend Technologies
Expected result:
array(0) {
}
array(0) {
}
string(3) "GPC"
Actual result:
--
$_ENV and $_SERVER are filled
--
Edit bug report at http://bugs.php.net/?id=29971&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=29971&r=trysnapshot4
Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=29971&r=trysnapshot50
Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=29971&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=29971&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=29971&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=29971&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=29971&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=29971&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=29971&r=support
Expected behavior: http://bugs.php.net/fix.php?id=29971&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=29971&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=29971&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=29971&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=29971&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=29971&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=29971&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=29971&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=29971&r=float
#29970 [Opn->Bgs]: DOM/EXSLT refuses to load
ID: 29970 Updated by: [EMAIL PROTECTED] Reported By: cristi_2112 at yahoo dot com -Status: Open +Status: Bogus Bug Type: XSLT related Operating System: Windows XP PHP Version: 4.3.8 New Comment: Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Thank you for your interest in PHP. . Previous Comments: [2004-09-03 15:51:10] cristi_2112 at yahoo dot com Description: I need to work in PHP with EXSL. I downloaded the latest version from snaps.php, I also downloaded the libxslt.dll, libxml2.dll, libexslt.dll latest version from your link on the site and put them in c:/php, c:/windows/system32 (like the other extensions I use). xsltproc.exe is working fine: I called xsltproc.exe -V : Using libxml 20612, libxslt 10109 and libexslt 807 xsltproc was compiled against libxml 20612, libxslt 10109 and libexslt 807 libxslt 10109 was compiled against libxml 20612 libexslt 807 was compiled against libxml 20612 I edited my php.ini: extension=php_xslt.dll extension=libxslt.dll extension=libxml2.dll extension=libexslt.dll (tryed in more ways). When I restart Apache, I get (one at a time): Invalid library (maybe not a PHP library) 'libxslt.dll' Invalid library (maybe not a PHP library) 'libxml2.dll' Unable to load dynamic library: 'c:\php\libexslt.dll' - The specified module could not be found. (although it's right there). So php still won't recognize EXSLT. On Linux it's working fine (giving to the compile option --with-dom-exslt). Please, help me out if you can. -- Edit this bug report at http://bugs.php.net/?id=29970&edit=1
#29937 [Opn]: $_FILES['name'] no longer has full path (from 4.3.4 to 4.3.8)
ID: 29937 User updated by: justin at timelesstech dot com Reported By: justin at timelesstech dot com Status: Open Bug Type: *Directory/Filesystem functions Operating System: FreeBSD 4.8 stable PHP Version: 4.3.8 New Comment: Yes it probably is related to that "fix" BUT this "fix" breaks a ton of code and changes the behavior. Can the "fix" be done in such a way that it prevents the security vulnerability, but doesn't break all the existing code out there that needs the client path of file(s) being uploaded? Also before this new fix is fixed, is there any workaround? Previous Comments: [2004-09-03 14:56:06] brad at timelesstech dot com It might have something to do with this bug fix: http://bugs.php.net/bug.php?id=28456 [2004-09-02 08:40:25] justin at timelesstech dot com Our web host, pair Networks, installed the PHP version to the server. I believe they compiled from source, and I know they are experts at installing and configuring PHP as they manage hundreds of servers. >From a phpinfo() command here are the configure command options they used on Aug 18/04: './configure' '--with-apache=/usr/pair/sw/apache_1.3.29' '--with-config-file-path=/usr/local/etc' '--enable-magic-quotes' '--enable-bcmath' '--without-cdb' '--with-zlib-dir=/usr/local' '--with-gd' '--with-ttf' '--without-msql' '--with-mysql=/usr/local' '--with-iodbc' '--with-pdflib' '--enable-inline-optimization' '--disable-memory-limit' '--with-db' '--without-gdbm' '--with-ndbm' '--without-db2' '--without-dbm' '--with-gettext' '--without-readline' '--with-recode' '--without-openssl' '--with-mcrypt' '--without-db3' '--enable-dba' '--with-curl' '--with-png-dir=/usr/local/lib' '--with-jpeg-dir=/usr/local/lib' '--enable-calendar' '--with-mhash' '--enable-xslt' '--with-xslt-sablot' '--with-expat-dir=/usr/local' '--enable-gd-lzw-gif' '--enable-mstring' [2004-09-02 08:20:28] [EMAIL PROTECTED] Did you compile PHP from source or did you use the ports? If you used the ports, can you check what patches were applied to the clean php source? [2004-09-01 22:40:40] justin at timelesstech dot com Description: We have had scripts running for a while now fine on PHP 4.3.4 that assume that the $_FILES['name'] value on file uploads contains the full /path/to/the/filename.txt However after our server admins upgraded to PHP 4.3.8 the $FILES['name'] now only contains the filename, with no path. This makes it impossible for our recursive file uploader script to work, since it NEEDS the pathname of those files to know what directory/subdir on the server to upload the file(s) to! The changelog does not mention this, but does anybody have any ideas? -- Edit this bug report at http://bugs.php.net/?id=29937&edit=1
#29937 [Opn->Fbk]: $_FILES['name'] no longer has full path (from 4.3.4 to 4.3.8)
ID: 29937 Updated by: [EMAIL PROTECTED] Reported By: justin at timelesstech dot com -Status: Open +Status: Feedback Bug Type: *Directory/Filesystem functions Operating System: FreeBSD 4.8 stable PHP Version: 4.3.8 New Comment: Which path is this, of the original uploaded file name or the one on the server (in /tmp...)? Previous Comments: [2004-09-03 16:24:50] justin at timelesstech dot com Yes it probably is related to that "fix" BUT this "fix" breaks a ton of code and changes the behavior. Can the "fix" be done in such a way that it prevents the security vulnerability, but doesn't break all the existing code out there that needs the client path of file(s) being uploaded? Also before this new fix is fixed, is there any workaround? [2004-09-03 14:56:06] brad at timelesstech dot com It might have something to do with this bug fix: http://bugs.php.net/bug.php?id=28456 [2004-09-02 08:40:25] justin at timelesstech dot com Our web host, pair Networks, installed the PHP version to the server. I believe they compiled from source, and I know they are experts at installing and configuring PHP as they manage hundreds of servers. >From a phpinfo() command here are the configure command options they used on Aug 18/04: './configure' '--with-apache=/usr/pair/sw/apache_1.3.29' '--with-config-file-path=/usr/local/etc' '--enable-magic-quotes' '--enable-bcmath' '--without-cdb' '--with-zlib-dir=/usr/local' '--with-gd' '--with-ttf' '--without-msql' '--with-mysql=/usr/local' '--with-iodbc' '--with-pdflib' '--enable-inline-optimization' '--disable-memory-limit' '--with-db' '--without-gdbm' '--with-ndbm' '--without-db2' '--without-dbm' '--with-gettext' '--without-readline' '--with-recode' '--without-openssl' '--with-mcrypt' '--without-db3' '--enable-dba' '--with-curl' '--with-png-dir=/usr/local/lib' '--with-jpeg-dir=/usr/local/lib' '--enable-calendar' '--with-mhash' '--enable-xslt' '--with-xslt-sablot' '--with-expat-dir=/usr/local' '--enable-gd-lzw-gif' '--enable-mstring' [2004-09-02 08:20:28] [EMAIL PROTECTED] Did you compile PHP from source or did you use the ports? If you used the ports, can you check what patches were applied to the clean php source? [2004-09-01 22:40:40] justin at timelesstech dot com Description: We have had scripts running for a while now fine on PHP 4.3.4 that assume that the $_FILES['name'] value on file uploads contains the full /path/to/the/filename.txt However after our server admins upgraded to PHP 4.3.8 the $FILES['name'] now only contains the filename, with no path. This makes it impossible for our recursive file uploader script to work, since it NEEDS the pathname of those files to know what directory/subdir on the server to upload the file(s) to! The changelog does not mention this, but does anybody have any ideas? -- Edit this bug report at http://bugs.php.net/?id=29937&edit=1
#29937 [Fbk->Opn]: $_FILES['name'] no longer has full path (from 4.3.4 to 4.3.8)
ID: 29937 User updated by: justin at timelesstech dot com Reported By: justin at timelesstech dot com -Status: Feedback +Status: Open Bug Type: *Directory/Filesystem functions Operating System: FreeBSD 4.8 stable PHP Version: 4.3.8 New Comment: It is the path of the original uploaded file name. The reason this info is needed, is when a bunch of files are uploaded via a web file manager application, it needs to know the path of each file, so when it re-creates the path/file structure on the server, it is able to put all the files in the right places, rather than everything going in "one directory". Previous Comments: [2004-09-03 16:55:42] [EMAIL PROTECTED] Which path is this, of the original uploaded file name or the one on the server (in /tmp...)? [2004-09-03 16:24:50] justin at timelesstech dot com Yes it probably is related to that "fix" BUT this "fix" breaks a ton of code and changes the behavior. Can the "fix" be done in such a way that it prevents the security vulnerability, but doesn't break all the existing code out there that needs the client path of file(s) being uploaded? Also before this new fix is fixed, is there any workaround? [2004-09-03 14:56:06] brad at timelesstech dot com It might have something to do with this bug fix: http://bugs.php.net/bug.php?id=28456 [2004-09-02 08:40:25] justin at timelesstech dot com Our web host, pair Networks, installed the PHP version to the server. I believe they compiled from source, and I know they are experts at installing and configuring PHP as they manage hundreds of servers. >From a phpinfo() command here are the configure command options they used on Aug 18/04: './configure' '--with-apache=/usr/pair/sw/apache_1.3.29' '--with-config-file-path=/usr/local/etc' '--enable-magic-quotes' '--enable-bcmath' '--without-cdb' '--with-zlib-dir=/usr/local' '--with-gd' '--with-ttf' '--without-msql' '--with-mysql=/usr/local' '--with-iodbc' '--with-pdflib' '--enable-inline-optimization' '--disable-memory-limit' '--with-db' '--without-gdbm' '--with-ndbm' '--without-db2' '--without-dbm' '--with-gettext' '--without-readline' '--with-recode' '--without-openssl' '--with-mcrypt' '--without-db3' '--enable-dba' '--with-curl' '--with-png-dir=/usr/local/lib' '--with-jpeg-dir=/usr/local/lib' '--enable-calendar' '--with-mhash' '--enable-xslt' '--with-xslt-sablot' '--with-expat-dir=/usr/local' '--enable-gd-lzw-gif' '--enable-mstring' [2004-09-02 08:20:28] [EMAIL PROTECTED] Did you compile PHP from source or did you use the ports? If you used the ports, can you check what patches were applied to the clean php source? 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/29937 -- Edit this bug report at http://bugs.php.net/?id=29937&edit=1
#29959 [Bgs->Opn]: Resource returned by fopen has type 'stream'
ID: 29959 User updated by: mccarthy36 at earthlink dot net Reported By: mccarthy36 at earthlink dot net -Status: Bogus +Status: Open Bug Type: Filesystem function related Operating System: Linux PHP Version: 4.3.8 New Comment: Not to be combative, but it's not _expected_ based on what the manual says. * fopen() returns a resource * get_resource_type() returns a string representing the type of the resource * Appendix K gives 'file' as the resource type name created by fopen() Would you please say specifically which part of the manual I should double-check to better understand the situation? Thank you Previous Comments: [2004-09-03 04:39:04] [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 This is expected. [2004-09-03 00:03:46] mccarthy36 at earthlink dot net Description: The resource returned by fopen() (when used to open a file) is reported as type 'stream', not 'file'. I'm not sure if this is a documentation problem or an fopen() problem. Appendix K doesn't list any functions as returning resources of type 'stream'. But, as 'stream' seems more generic, from my perspective it seems desirable to have the resource returned by fopen() identified as 'file' as described in the documentation. Reproduce code: --- $file = fopen( 'file.txt', 'r' ); var_dump( get_resource_type( $file ) ); Expected result: Appendix K. List of Resource Types states that 'file' is the type of resource returned by fopen(). Actual result: -- 'stream' is reported as the type of the resourced returned by fopen(). -- Edit this bug report at http://bugs.php.net/?id=29959&edit=1
#29968 [Opn->Fbk]: __destruct and calling non-existent function
ID: 29968
Updated by: [EMAIL PROTECTED]
Reported By: grnick at mail dot ru
-Status: Open
+Status: Feedback
Bug Type: Zend Engine 2 problem
Operating System: Linux
PHP Version: 5CVS-2004-09-03 (dev)
New Comment:
Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php
Once you have generated a backtrace, please submit it to this bug
report and change the status back to "Open". Thank you for helping
us make PHP better.
Tested and not reproduced. Please, provide a backtrace.
Previous Comments:
[2004-09-03 12:05:17] grnick at mail dot ru
Description:
Configure Command: './configure' '--with-pgsql' '--with-mysql'
'--with-apxs' '--with-apxs=/usr/local/apache/bin/apxs'
'--enable-sysvsem' '--enable-sockets'
Apache/1.3.24
Loaded Modules mod_php5, mod_setenvif, mod_so, mod_auth, mod_access,
mod_rewrite, mod_alias, mod_userdir, mod_actions, mod_imap, mod_asis,
mod_cgi, mod_dir, mod_autoindex, mod_include, mod_status,
mod_negotiation, mod_mime, mod_log_config, mod_env, http_core
Reproduce code:
---
Test();
}
public function __destruct() {}
}
$obj = new C2();
?>
Expected result:
Fatal error: Call to undefined method C1::Test() in test.php on line 8
Actual result:
--
Apache error_log
[notice] child pid 11402 exit signal Segmentation fault (11)
And without destructor that code works right.
--
Edit this bug report at http://bugs.php.net/?id=29968&edit=1
#29937 [Opn->Asn]: $_FILES['name'] no longer has full path (from 4.3.4 to 4.3.8)
ID: 29937 Updated by: [EMAIL PROTECTED] Reported By: justin at timelesstech dot com -Status: Open +Status: Assigned Bug Type: *Directory/Filesystem functions Operating System: FreeBSD 4.8 stable PHP Version: 4.3.8 -Assigned To: +Assigned To: derick New Comment: I don't think the RFC actually allows that, nor was this ever documented. I will check the RFC later. Previous Comments: [2004-09-03 16:58:31] justin at timelesstech dot com It is the path of the original uploaded file name. The reason this info is needed, is when a bunch of files are uploaded via a web file manager application, it needs to know the path of each file, so when it re-creates the path/file structure on the server, it is able to put all the files in the right places, rather than everything going in "one directory". [2004-09-03 16:55:42] [EMAIL PROTECTED] Which path is this, of the original uploaded file name or the one on the server (in /tmp...)? [2004-09-03 16:24:50] justin at timelesstech dot com Yes it probably is related to that "fix" BUT this "fix" breaks a ton of code and changes the behavior. Can the "fix" be done in such a way that it prevents the security vulnerability, but doesn't break all the existing code out there that needs the client path of file(s) being uploaded? Also before this new fix is fixed, is there any workaround? [2004-09-03 14:56:06] brad at timelesstech dot com It might have something to do with this bug fix: http://bugs.php.net/bug.php?id=28456 [2004-09-02 08:40:25] justin at timelesstech dot com Our web host, pair Networks, installed the PHP version to the server. I believe they compiled from source, and I know they are experts at installing and configuring PHP as they manage hundreds of servers. >From a phpinfo() command here are the configure command options they used on Aug 18/04: './configure' '--with-apache=/usr/pair/sw/apache_1.3.29' '--with-config-file-path=/usr/local/etc' '--enable-magic-quotes' '--enable-bcmath' '--without-cdb' '--with-zlib-dir=/usr/local' '--with-gd' '--with-ttf' '--without-msql' '--with-mysql=/usr/local' '--with-iodbc' '--with-pdflib' '--enable-inline-optimization' '--disable-memory-limit' '--with-db' '--without-gdbm' '--with-ndbm' '--without-db2' '--without-dbm' '--with-gettext' '--without-readline' '--with-recode' '--without-openssl' '--with-mcrypt' '--without-db3' '--enable-dba' '--with-curl' '--with-png-dir=/usr/local/lib' '--with-jpeg-dir=/usr/local/lib' '--enable-calendar' '--with-mhash' '--enable-xslt' '--with-xslt-sablot' '--with-expat-dir=/usr/local' '--enable-gd-lzw-gif' '--enable-mstring' 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/29937 -- Edit this bug report at http://bugs.php.net/?id=29937&edit=1
#4925 [Csd]: .htaccess problem with custom 401 ErrorDocument (Apache 1.3.12, PHP 4.0.0)
ID: 4925 Updated by: [EMAIL PROTECTED] Reported By: tapio dot ryhanen at oulu dot fi Status: Closed Bug Type: *General Issues Operating System: Redhat 6.0 with kernel 2.2.16 PHP Version: 4.0.0 Release Assigned To: zak New Comment: This bug has been fixed in 4.0.2 Previous Comments: [2000-12-07 11:15:01] [EMAIL PROTECTED] No feedback. [2000-11-08 18:48:02] [EMAIL PROTECTED] Does this still happen with latest snapshot from http://snaps.php.net ?? --Jani [2000-08-23 18:26:55] [EMAIL PROTECTED] Henryk Plötz ([EMAIL PROTECTED]) was kind enough to confirm this bug for me. Here is his message --- I've encountered this same problem myself and it seems to be a general issue with PHP4 and ErrorDocuments. I've tried it under Linux kernel 2.2.14 with Apache 1.3.12 and PHP 4.0.1pl2 as well as with SunOS 5.7, Apache 1.3.12 and PHP 4.0.0. When specifying an ErrorDocument to be parsed by PHP the returned HTTP-Status-Code is changed to 200 OK regardless of its previous value. This causes the browser to not display any password dialogue. The same happens with every other Status-Code (I've tried 401, 404 and 500) which all end up to be sent and logged as 200 OK. [2000-07-26 20:20:32] [EMAIL PROTECTED] I will try to confirm this bug. [2000-06-09 09:34:19] tapio dot ryhanen at oulu dot fi As soon as I specify ErrorDocument 401 /error.html for my virtual server, I can't log into a secured directory under it using .htaccess/htpasswd, I get an error page instead. I've specified other Errodocs for 403/404/500, etc. and I can log in fine with the username/password prompt for http://www.virtualhost.com/foo/ but as soon as I add the ErrorDocument 401 /error.html for virtualhost.com in httpd.conf I get an error message when I goto http://www.virtualhost.com/foo/ instead of the user/pass box. I'm using Apache 1.3.12 with PHP 4.0.0 on Linux 2.2.16. Specifying custom errordocs worked just fine with php version 3.0.15 and Apache 1.3.12. After upgrading to PHP v. 4.0.0 custom errordocs no longer work. Any ideas? -- Edit this bug report at http://bugs.php.net/?id=4925&edit=1
#27795 [Com]: make install fails (PHP5 RC1, PHP5 latest)
ID: 27795
Comment by: tuldavid at hotmail dot com
Reported By: peoyli at bredband dot net
Status: Bogus
Bug Type: Compile Failure
Operating System: OpenBSD 3.4
PHP Version: 5CVS-2004-04-07
New Comment:
I had the same problem => libphp5.so not found.
Just tried the bunzip2 file instead of the gunzipped tarball and hey
presto it works! Well for me anyway ;) Hope that it works for someone
else.
gentoo x86 kernel 2.4.26
apxs2.0.50
php5.0.1
Previous Comments:
[2004-08-01 02:09:02] my-junkmail at earthlink dot net
For x86_64 users, many linux distributions are using a lib64 directory
as well as the standard lib directory so both 32 and 64 bit versions
are available to your system. If your libtool doesn't know about this,
which the one shipped with php doesn't, you will get this error. A
lot.
The solution is *in this order*:
-run ./configure with your favorite options
-edit ./libtool: add /usr/lib64 (or wherever yours is) to
sys_lib_search_path_spec AND sys_lib_dlsearch_path_spec
then make and make install will run. (although I'm still having issues
with mysql's prebuilt binary dist. of libmysqlclient for the x86_64)
[2004-05-13 20:36:49] dparisek at hotmail dot com
I got around this same problem while installing php-4.3.6 by copying
the libphp4.so file from the source location -
/.libs/libphp4.so to the modules directory.
Actually I placed the copy (cp) command in the instdso.sh script
(called by Makefile) but I assume I could have just as easily copied it
manually prior to doing the 'make install'.
[2004-05-09 14:13:05] jelly_bean_junky at hotmail dot com
Okay, I worked it out...
While compiling, do you get an error like this:
*** Warning: linker path does not have real file for library
-lc-client.
*** I have the capability to make that library automatically link in
when
*** you link to this library. But I can only do this if you have a
*** shared version of the library, which you do not appear to have
*** because I did check the linker path looking for a file starting
*** with libc-client and none of the candidates passed a file format
test
*** using a file magic. Last file checked: /usr/lib/c-client.a
*** Warning: linker path does not have real file for library -lbz2.
*** ... [blah blah blah] ...
*** ... ... passed a file format test
*** using a file magic. Last file checked: /usr/lib/libbz2.a
*** Warning: libtool could not satisfy all declared inter-library
*** ... [blah blah blah] ...
*** application is linked with the -dlopen flag.
Okay here I have two libraries it can't link properly, so what you need
to do is that the compile output just before, it should end with -o
libphp4.la and start something like this /bin/sh
/home/kibble/packages/php-4.3.6/libtool --silent --preserve-dup-deps
Its a long string compiling options for the libtool, then all you need
to do is remove the references to the lib-c-client and lib-bzip2, so if
you have this on the line somewhere, blah.lo -lc-client -lssl -lcrypto
-lmysqlclient -lintl -lfreetype -lX11 -lXpm -lpng -lz -ljpeg -lexslt
-lxml2 -lxslt -lz -ldb-4.2 -lgdbm -lbz2 -lz -lssl -lcrypto -lm -lxml2
-lz -liconv -lm -o libphp4.la
You would now have this instead:
blah.lo -lssl -lcrypto -lmysqlclient -lintl -lfreetype -lX11 -lXpm
-lpng -lz -ljpeg -lexslt -lxml2 -lxslt -lz -ldb-4.2 -lgdbm -lz -lssl
-lcrypto -lm -lxml2 -lz -liconv -lm -o libphp4.la
Can you see Ive removed the problem libraries -lbz2 and
-lc-client. Now recompile that with your new string of options and
the try make install
p.s. Sorry about the spelling mistake in my first post./comment, that
Hvae is meant to say Have **
p.p.s If you get your PHP library working because of this post, please
let me know, itd be great to have some feedback.
[2004-05-09 13:40:11] jelly_bean_junky at hotmail dot com
Nope didn't work, damn it. :(
[2004-05-09 13:28:12] jelly_bean_junky at hotmail dot com
Hvae you tried adding the '--enable-so=shared' and double checking your
'--with-apxs2' flag?
I'm just trying it out own my system:
$ automake --version
automake (GNU automake) 1.8.3
$ autoconf --version
autoconf (GNU Autoconf) 2.59
$ libtool --version
ltmain.sh (GNU libtool) 1.5.6 (1.1220.2.94 2004/04/10 16:27:27)
$ make --version
GNU Make 3.80
$ gcc --version
2.95.3
$ uname -mprsv
OpenBSD 3.5 GENERIC#34 i386 AMD-K6(tm) 3D processor ("AuthenticAMD"
586-class)
With PHP 4.3.6, althou I'm sure it will work just as well on PHP5 too.
:)
I'll let you know if it works, trying it now...
--
#29694 [Com]: SetEnv PHPRC in httpd.conf has no effect
ID: 29694 Comment by: ipa at beta dot lt Reported By: mvl22 at mailinator dot com Status: Open Bug Type: Apache related Operating System: Windows XP PHP Version: 5.0.1 New Comment: I have same problem in same configuration, and can add that it doesn't see php.ini file in apache directory. Only "C:/windows" (default), or path set in registry key "HKLM\Software\PHP\IniFilePath" works for me. Previous Comments: [2004-08-16 04:44:22] mvl22 at mailinator dot com Description: http://www.php.net/manual/en/install.windows.apache1.php states " # specify the directory where php.ini is SetEnv PHPRC C:/php " My httpd.conf has SetEnv PHPRC "C:/program files/php" in it and, after reboot, phpinfo () gives: Configuration File (php.ini) Path C:\WINDOWS but PHPRC C:/program files/php is shown (which is correct). php.ini does exist at C:/program files/php/php.ini Using c:/progra~1/php with or without a trailing slash does not change the situation. PHP5.0.1 is otherwise working fine. -- Edit this bug report at http://bugs.php.net/?id=29694&edit=1
#29937 [Asn]: $_FILES['name'] no longer has full path (from 4.3.4 to 4.3.8)
ID: 29937 User updated by: justin at timelesstech dot com Reported By: justin at timelesstech dot com Status: Assigned Bug Type: *Directory/Filesystem functions Operating System: FreeBSD 4.8 stable PHP Version: 4.3.8 Assigned To: derick New Comment: It was not documented, but this has been the well-known behavior for quite some time, and the browsers do send the path information. Any code written to deal the the 'name' value has always had to deal with the path information, so changing it now breaks all code from previous versions. Perhaps the new behaviour default could be to only get the filename, but an override would allow us to get the path too? Just some way so that old written systems will still be able to work =) Previous Comments: [2004-09-03 17:49:08] [EMAIL PROTECTED] I don't think the RFC actually allows that, nor was this ever documented. I will check the RFC later. [2004-09-03 16:58:31] justin at timelesstech dot com It is the path of the original uploaded file name. The reason this info is needed, is when a bunch of files are uploaded via a web file manager application, it needs to know the path of each file, so when it re-creates the path/file structure on the server, it is able to put all the files in the right places, rather than everything going in "one directory". [2004-09-03 16:55:42] [EMAIL PROTECTED] Which path is this, of the original uploaded file name or the one on the server (in /tmp...)? [2004-09-03 16:24:50] justin at timelesstech dot com Yes it probably is related to that "fix" BUT this "fix" breaks a ton of code and changes the behavior. Can the "fix" be done in such a way that it prevents the security vulnerability, but doesn't break all the existing code out there that needs the client path of file(s) being uploaded? Also before this new fix is fixed, is there any workaround? [2004-09-03 14:56:06] brad at timelesstech dot com It might have something to do with this bug fix: http://bugs.php.net/bug.php?id=28456 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/29937 -- Edit this bug report at http://bugs.php.net/?id=29937&edit=1
#29972 [NEW]: array_combine issues warning on empty arrays
From: sean at acidreign dot net
Operating system: all
PHP version: 5.0.1
PHP Bug Type: Feature/Change Request
Bug description: array_combine issues warning on empty arrays
Description:
array_combine issues a warning when empty arrays are passed as arguments,
I submit that empty arrays should be valid input for this function, and
the result should also be an empty array (rather than FALSE and a
warning).
On top of that, the warning is non-sensical, as it states that "Both
parameters should have number of elements at least 0"
Reproduce code:
---
$a = array();
$b = array();
$c = array_combine( $a, $b );
var_dump( $c );
Expected result:
array(0) { }
Actual result:
--
Warning: array_combine() [function.array-combine]: Both parameters should
have number of elements at least 0 in /var/www/vhosts/.../test.php on line
4
bool(false)
--
Edit bug report at http://bugs.php.net/?id=29972&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=29972&r=trysnapshot4
Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=29972&r=trysnapshot50
Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=29972&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=29972&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=29972&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=29972&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=29972&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=29972&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=29972&r=support
Expected behavior: http://bugs.php.net/fix.php?id=29972&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=29972&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=29972&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=29972&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=29972&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=29972&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=29972&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=29972&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=29972&r=float
#29937 [Com]: $_FILES['name'] no longer has full path (from 4.3.4 to 4.3.8)
ID: 29937 Comment by: brad at timelesstech dot com Reported By: justin at timelesstech dot com Status: Assigned Bug Type: *Directory/Filesystem functions Operating System: FreeBSD 4.8 stable PHP Version: 4.3.8 Assigned To: derick New Comment: Let me clarify a bit... we use a tool from Radinks, and in this tool there is a "FULL_PATH" option that will pass along the full path and filename in the $_FILES['..']['name'] variable. By default, it's just the filename in this ['name'] variable, but Radinks did something (possibly in headers?) to allow the fullpath to come through. It looks as though the security "fix" broke this desired behavoiur. Previous Comments: [2004-09-03 18:46:33] justin at timelesstech dot com It was not documented, but this has been the well-known behavior for quite some time, and the browsers do send the path information. Any code written to deal the the 'name' value has always had to deal with the path information, so changing it now breaks all code from previous versions. Perhaps the new behaviour default could be to only get the filename, but an override would allow us to get the path too? Just some way so that old written systems will still be able to work =) [2004-09-03 17:49:08] [EMAIL PROTECTED] I don't think the RFC actually allows that, nor was this ever documented. I will check the RFC later. [2004-09-03 16:58:31] justin at timelesstech dot com It is the path of the original uploaded file name. The reason this info is needed, is when a bunch of files are uploaded via a web file manager application, it needs to know the path of each file, so when it re-creates the path/file structure on the server, it is able to put all the files in the right places, rather than everything going in "one directory". [2004-09-03 16:55:42] [EMAIL PROTECTED] Which path is this, of the original uploaded file name or the one on the server (in /tmp...)? [2004-09-03 16:24:50] justin at timelesstech dot com Yes it probably is related to that "fix" BUT this "fix" breaks a ton of code and changes the behavior. Can the "fix" be done in such a way that it prevents the security vulnerability, but doesn't break all the existing code out there that needs the client path of file(s) being uploaded? Also before this new fix is fixed, is there any workaround? 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/29937 -- Edit this bug report at http://bugs.php.net/?id=29937&edit=1
#29973 [NEW]: Comparing COM object variable with NULL throws an exception
From: tetikr at spytech dot cz
Operating system: Win2000
PHP version: 5.0.1
PHP Bug Type: COM related
Bug description: Comparing COM object variable with NULL throws an exception
Description:
Comparing COM object variable with NULL throws an exception
Reproduce code:
---
$a = new COM(.);
if (!$a)
{
..
}
else
{
.
}
Expected result:
If $a is non null, I expect the ELSE block to be performed.
Actual result:
--
PHP throws an exception when trying to evaluate !$a. I think it tries to
access the default COM object's property.
If this is a valid behavior, how should I test for null?
--
Edit bug report at http://bugs.php.net/?id=29973&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=29973&r=trysnapshot4
Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=29973&r=trysnapshot50
Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=29973&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=29973&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=29973&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=29973&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=29973&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=29973&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=29973&r=support
Expected behavior: http://bugs.php.net/fix.php?id=29973&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=29973&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=29973&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=29973&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=29973&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=29973&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=29973&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=29973&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=29973&r=float
#27290 [Com]: warning msg on missing function argument should mention file/line of caller too
ID: 27290 Comment by: sean at acidreign dot net Reported By: [EMAIL PROTECTED] Status: Open Bug Type:Feature/Change Request PHP Version: 5CVS-2004-02-17 (dev) New Comment: over the last few days, I've had to tack down dozens of errors, with out knowing the file/line they actually occur in. reporting the line of the function declaration rather then the line of the offending expression is completely useless. It makes tracking bugs extremely difficult, because it has to be done on a trial and error basis, looking for and testing every place a function is called. Previous Comments: [2004-02-17 11:11:08] [EMAIL PROTECTED] Description: usually the location of the caller what you really want to know here, especially if you are trying to track this down from not-so-recent messages in your error_log ... Reproduce code: --- Expected result: Warning: Missing argument 1 for foo() in foo.php on line 2, called in foo.php on line 4 Actual result: -- Warning: Missing argument 1 for foo() in - on line 2 -- Edit this bug report at http://bugs.php.net/?id=27290&edit=1
#28714 [Com]: Type hint error completely useless
ID: 28714 Comment by: sean at acidreign dot net Reported By: nlhowell at cableone dot net Status: Open Bug Type: Feature/Change Request Operating System: WinXP Pro 2600 SP1 PHP Version: 5CVS-2004-06-09 (dev) New Comment: This bug is related to the one posted here: http://bugs.php.net/bug.php?id=27290 Previous Comments: [2004-06-09 20:53:43] nlhowell at cableone dot net Description: When you have a type-hint error (ie: you pass an incompatible object to a function with a type hint), the error message is completely useless. It tells you where the function with the type hint is defined; it *should* tell you where you tried to pass the invalid object. Logically, this makes sense. If I pass an object that doesn't fit the type hint, it's not the function that's at fault; it's mine. Reproduce code: --- Expected result: Fatal error: Argument 1 must be an instance of x in c:\Inetpub\wwwroot\test.php5 on line 12 Actual result: -- Fatal error: Argument 1 must be an instance of x in c:\Inetpub\wwwroot\test.php5 on line 8 -- Edit this bug report at http://bugs.php.net/?id=28714&edit=1
#29974 [NEW]: num_rows crashes Apache (recurrence)
From: david dot powers at dial dot pipex dot com
Operating system: Windows XP
PHP version: 5.0.1
PHP Bug Type: MySQLi related
Bug description: num_rows crashes Apache (recurrence)
Description:
Bug #28205 reported fixed in PHP 5.RC-3 appears to have resurfaced.
Use of $result->num_rows causes Apache to crash. Use of mysqli_num_rows()
works without problem.
Environment:
Windows XP Pro
Apache 1.3.31
PHP 5.0.1
MySQL 4.1.4-gamma
extension=php_mbstring.dll
extension=php_mysqli.dll
extension=php_mysql.dll
Reproduce code:
---
$db = new mysqli($hostname, $username, $password, 'db_name');
$sql = 'SELECT * FROM wordlist';
$result = $db->query($sql);
$total = $result->num_rows;
echo "Total words: $total";
while ($row = $result->fetch_assoc()) {
echo $row['word'].'';
}
Expected result:
I expect it not to crash.
Actual result:
--
Error report:
szAppName: Apache.exe szAppVer: 0.0.0.0
szModName: php_mysql.dll szModVer: 5.0.1.1
offset: 11fe
Code works perfectly if $total = $result->num_rows; is commented out.
--
Edit bug report at http://bugs.php.net/?id=29974&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=29974&r=trysnapshot4
Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=29974&r=trysnapshot50
Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=29974&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=29974&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=29974&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=29974&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=29974&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=29974&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=29974&r=support
Expected behavior: http://bugs.php.net/fix.php?id=29974&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=29974&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=29974&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=29974&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=29974&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=29974&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=29974&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=29974&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=29974&r=float
#29958 [Bgs]: cURL https request fails when connecting to IP (not domain)
ID: 29958
User updated by: ryan dot hansen at usa dot net
Reported By: ryan dot hansen at usa dot net
Status: Bogus
Bug Type: cURL related
Operating System: Debian
PHP Version: 4.3.8
New Comment:
Nope, it's not a problem with the curl version (as I knew it wouldn't
be). I upgraded to 7.12 and still had the problem. Turns out I had to
set the CURLOPT_VERIFYHOST to false so it wouldn't try to resolve the
domain name with the SSL certificate.
I don't know if you'd still call it a bug, but this would have been
much easier to solve if I had received some kind of error message to
that effect. I had PHP error messages turned on and the CURLOPT_ERROR
option turned on, so I should have gotten something, but I didn't.
Anyway, it's fixed now.
Previous Comments:
[2004-09-03 15:01:39] [EMAIL PROTECTED]
Good point Daniel, marking this as bogus. Upgrade first!
[2004-09-03 14:38:42] daniel at haxx dot se
curl 7.9.5 was released some 30 months ago. Do I need to say more?
[2004-09-02 21:28:29] ryan dot hansen at usa dot net
I should mention that this same code DOES work on a different
requesting server (FreeBSD 4.4; PHP 4.2.3)
[2004-09-02 21:21:42] ryan dot hansen at usa dot net
Description:
When attempting to connect to an IP address (not a domain) over SSL
using cURL (7.9.5), there is no response, no errors, etc. I get
nothing. When I test the same script with a domain (a different
server), I get a response as expected. When I test it with the correct
IP address over HTTP (non-secure), I also get a response as expected.
The problem, however, is that the server that I have to connect to for
the app I'm building does not have a domain, only an IP address and it
must be a secure connection.
I admit that I could be missing something, but I can't figure out what
it is and I've tested it pretty thoroughly under multiple scenarios.
Reproduce code:
---
$postdata = "POST DATA TO POST TO SERVER";
// use appropriate IP, of course
$ch = curl_init("https://xxx.xxx.xxx.xxx";);
curl_setopt($ch, CURL_POST, 1);
curl_setopt($ch, CURL_POSTFIELDS, $postdata);
curl_setopt($ch, CURL_ERROR, 1);
curl_setopt($ch, CURL_RETURNTRANSFER, 1);
$retval = curl_exec($ch);
curl_close($ch);
// print result for testing
echo $retval;
exit;
Expected result:
The echo statement should print the web page data from the IP to the
screen, and it does when I test with non-secure IP or domain.
Actual result:
--
Nothing. The echo statement doesn't seem to print anything. No cURL
errors, no results, no PHP warnings or errors.
--
Edit this bug report at http://bugs.php.net/?id=29958&edit=1
#29917 [Bgs->WFx]: isset() always return
ID: 29917
Updated by: [EMAIL PROTECTED]
Reported By: dasch at ulmail dot net
-Status: Bogus
+Status: Wont fix
-Bug Type: Class/Object related
+Bug Type: Feature/Change Request
-Operating System: Linux
+Operating System: *
-PHP Version: 5.0.1
+PHP Version: 5.*
-Assigned To:
+Assigned To: Andi
New Comment:
We'd need to all __get() for every non existing property then which
would be worse than only a mahor slowdown.
Een a __exists() would'n help much because that, too. Would be very
slow. The only way out would be to declare abstract properties as
allowed by this patch:
http://marcus-boerger.de/php/ext/ze2/ze2-abstract-properties-20040803.diff.txt
Previous Comments:
[2004-09-03 13:48:23] fch at hexanet dot fr
offsetGet($key);
}
function __set($key, $value)
{
$this->offsetSet($key, $value);
}
function offsetExists($key)
{
return isset($this->array[$key]);
}
function offsetGet($key)
{
return $this->array[$key];
}
function offsetSet($key, $value)
{
$this->array[$key] = $value;
}
function offsetUnset($key)
{
unset($this->array[$key];
}
}
$foo = new foo();
echo (isset($foo['bar']) == true ? 'set' : 'not set');
$foo['bar'] = 'bar';
echo (isset($foo['bar']) == true ? 'set' : 'not set');
echo $foo['bar'];
#Expected result :
# not set
# set
# bar
#Real result
# not set
# set
# bar
# !! GREAT !!
#Now, the same thing with __get() and __set()
unset($foo);
$foo = new foo();
echo (isset($foo->array) == true ? 'array is set' : 'array is not
set');
echo (isset($foo->bar) == true ? 'bar is set' : 'bar is not set');
$foo->bar = 'bar';
echo (isset($foo['bar']) == true ? 'bar is set' : 'bar is not set');
echo $foo->bar;
#Expected result :
# array is set
# bar is not set
# bar is set
# bar
#Real result
# array is set # Ok !
# bar is not set # Ok !
# bar is not set # PROBLEM PROBLEM
# bar
# !! NOT GREAT !!
?>
It is abnormal !
isset() does not return the good value on property wich was set with
__set() it is return the good value on property wich was set in the
class,and isset() return the good value on value wich was set with
offsetSet() method !!
It is a paradox !
I think that isset MUST return the same value in all case.
[2004-09-01 13:51:05] dasch at ulmail dot net
If the isset() function aren't going to work with properties accessed
with a __get() call, then there should at least be a __isset() method
that allows for custom isset()-handling. eg:
$prop)) {
return TRUE;
} else {
return FALSE;
}
}
}
$foo = new Foo();
echo isset($foo->bar) ? "yes\n" : "no\n";
// Should be the same as
echo $foo->__isset('bar') ? "yes\n" : "no\n";
?>
[2004-09-01 10:24:01] fch at hexanet dot fr
Can you explain where are wrong ???
A call to __set() create a property in the object (see documentation).
Event if this property is not a real member property for PHP language
point of view, for the programers point of view, it is a property !
So, isset() MUST return true in my example.
What are difference between your example :
$o->a = 'bar';
echo isset($o->a) ? "yes\n" : "no\n";
And my example :
$o->foo = 'bar';
echo (isset($o->foo) == true ? 'foo is set' : 'foo is not set');
There is no difference ! Except that my foo property was created with a
__set() call.
[2004-09-01 10:14:10] [EMAIL PROTECTED]
No, you're wrong. The behavior you see is the correct behavior.
[2004-09-01 09:59:01] fch at hexanet dot fr
array[$name] = $value;
}
function __get($name)
{
if (isset($this->array[$name]) == true)
return null;
else
return $this->array[$name];
}
}
$o = new oo();
$o->foo = 'bar';
echo (isset($o->foo) == true ? 'foo is set' : 'foo is not set');
#Expecting result
# => foo is set
#Real result
# => foo is not set
?>
If PHP provide __set() and __get() function in order to create property
dynamicaly, PHP function like isset() MUST BE USED with these "dynamic"
properties as usual.
So, in my example, isset() MUST return TRUE !! and not 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/29917
--
Edit this bug report at http://bugs.php.net/?id=29917&edit=1
#29975 [NEW]: memory leaks
From: guth at fiifo dot u-psud dot fr Operating system: Linux (Mandrake 10) PHP version: 5.0.1 PHP Bug Type: Performance problem Bug description: memory leaks 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 bug report at http://bugs.php.net/?id=29975&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=29975&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=29975&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=29975&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=29975&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=29975&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=29975&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=29975&r=needscript Try newer version: http://bugs.php.net/fix.php?id=29975&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=29975&r=support Expected behavior: http://bugs.php.net/fix.php?id=29975&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=29975&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=29975&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=29975&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=29975&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=29975&r=dst IIS Stability: http://bugs.php.net/fix.php?id=29975&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=29975&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=29975&r=float
#29976 [NEW]: PHP script stops parsing prematurely
From: stantoney at firmfoundationtechnology dot com
Operating system: linux 2.4
PHP version: 4.3.8
PHP Bug Type: Scripting Engine problem
Bug description: PHP script stops parsing prematurely
Description:
I'm uploading web pages to a new server and a PHP script is not parsing
fully. It reaches a line that has a > in the line and stops.
Here is part of the relevant code
');
CarpCacheShow("http://news.com.com/2547-1_3-0-5.xml";);
?>
The error occurs at the end of the bilink config line. Once the script
hits the > near the end of the line it exits the script. It works fine
under PHP 2.3.4.
CarpConf refers to a function provided by CaRP, a RSS feed converter at
http://www.geckotribe.com/rss/carp/
Reproduce code:
---
http://s108329740.onlinehome.us/
Expected result:
Correct (current Site)
http://www.firmfoundationtechnology.com/
Here are links to PHPinfo scripts for reference.
GOOD Site - http://www.firmfoundationtechnology.com/scripts/phpinfo.php
BAD Site - http://s108329740.onlinehome.us/scripts/phpinfo.php
--
Edit bug report at http://bugs.php.net/?id=29976&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=29976&r=trysnapshot4
Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=29976&r=trysnapshot50
Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=29976&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=29976&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=29976&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=29976&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=29976&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=29976&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=29976&r=support
Expected behavior: http://bugs.php.net/fix.php?id=29976&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=29976&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=29976&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=29976&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=29976&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=29976&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=29976&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=29976&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=29976&r=float
#29184 [Com]: Fatal error when trying to set an object property an array
ID: 29184
Comment by: jcrawford at codebowl dot com
Reported By: jbeall at heraldic dot us
Status: Open
Bug Type: Zend Engine 2 problem
Operating System: Linux
PHP Version: 5.0.0
New Comment:
I am using the latest version of PHP and i have the same results when i
try to do this.
array_push($object->property, $myarray);
this is not my expected results
Previous Comments:
[2004-07-15 14:52:56] jbeall at heraldic dot us
Description:
Trying to assigned a specific array index of an object property, when
__set() been defined and will catch the __set() call, causes a fatal
error.
This is similar to bug 28444. That bug has the same error, but the
code that produces it is different.
Reproduce code:
---
class Sub
{
function __get($prop)
{
echo "Property $prop called\n";
}
function __set($prop, $val)
{
echo "Property $prop set to $val\n";
}
}
$foo = new Sub();
$foo->someProp[0] = 'apple';
echo $foo->someProp[0];
Expected result:
apple
Actual result:
--
Fatal error: Cannot access undefined property for object with
overloaded property access in test.php on line 18
--
Edit this bug report at http://bugs.php.net/?id=29184&edit=1
#29724 [Fbk->NoF]: PHP Encountered an Access Violation
ID: 29724 Updated by: [EMAIL PROTECTED] Reported By: bojo at gvea dot com -Status: Feedback +Status: No Feedback Bug Type: Reproducible crash Operating System: Windows 2003 Server PHP Version: 5.0.1 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-08-18 02:29:50] [EMAIL PROTECTED] Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to "Open". Thank you for your interest in PHP. [2004-08-18 00:44:45] bojo at gvea dot com Description: The original bug found in PHP 5.0.0, referenced here: http://bugs.php.net/bug.php?id=29127 was never actually resolved. PHP 5.0.1 continues to give the following error under IIS 6.0 on Windows 2003 Server: PHP has encountered an Access Violation at [random memory address]. Expected result: Page processes completely. Actual result: -- Program bails with the following error: PHP has encountered an Access Violation at [random memory address] -- Edit this bug report at http://bugs.php.net/?id=29724&edit=1
#29977 [NEW]: bool cast of "0000000000000"
From: hd dot php at aimail dot de Operating system: linux PHP version: 4.3.7 PHP Bug Type: Feature/Change Request Bug description: bool cast of "0" Description: * PHP Version 4.3.4 * bool cast of "0" should be false, not true. A "0" is returned from mysql timestamp fields. (bool)"0" should be consistent with (bool)(int)"0" At this point it is not. Reproduce code: --- Expected result: false Actual result: -- true -- Edit bug report at http://bugs.php.net/?id=29977&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=29977&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=29977&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=29977&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=29977&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=29977&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=29977&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=29977&r=needscript Try newer version: http://bugs.php.net/fix.php?id=29977&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=29977&r=support Expected behavior: http://bugs.php.net/fix.php?id=29977&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=29977&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=29977&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=29977&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=29977&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=29977&r=dst IIS Stability: http://bugs.php.net/fix.php?id=29977&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=29977&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=29977&r=float
#17576 [Com]: configure bug
ID: 17576 Comment by: johnnymar at hotmail dot com Reported By: blakforge at hotmail dot com Status: Bogus Bug Type: Compile Failure Operating System: win2k / cygwin PHP Version: 4.2.3 New Comment: this sucks Previous Comments: [2003-11-11 01:28:50] jzhigao at sohu dot com cvs -z3 update -d -P checkout -P diff -u [2002-10-25 10:25:51] [EMAIL PROTECTED] After additional testing and to-ing/fro-ing, it seems that the problem might well be down to cc not being available. I fixed the problem on my test machine with: ln --symbolic /usr/bin/gcc /usr/bin/cc configure then properly detects Cygwin. YMMV ;) [2002-10-22 12:38:08] [EMAIL PROTECTED] check config.log for the real reason WHY the check fails. Further discussion about this should happen on [EMAIL PROTECTED] so stop posting your comments here. [2002-10-22 12:33:12] [EMAIL PROTECTED] Sniper, > Use autoconf 2.13 ...seems to contradict with... << [18 Jun 4:59am] [EMAIL PROTECTED] It a bug in autoconf 2.13. If you have autoconf 2.5x installed on your system you shoud be able to compile php >> Anyhow, using autoconf 2.13... ./cvsclean ./buildconf ./configure --without-xml --prefix=/usr creating cache ./config.cache checking for Cygwin environment... no checking for mingw32 environment... no checking host system type... i686-pc-cygwin checking for gcc... gcc checking whether the C compiler (gcc ) works... yes checking whether the C compiler (gcc ) is a cross-compiler... no checking whether we are using GNU C... yes checking whether gcc accepts -g... yes Seems the same...? --Paul [2002-10-22 12:22:22] [EMAIL PROTECTED] Use autoconf 2.13 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/17576 -- Edit this bug report at http://bugs.php.net/?id=17576&edit=1
