#30619 [Opn-Bgs]: class constants cannot be accessed from withing class static method
ID: 30619
Updated by: [EMAIL PROTECTED]
Reported By: junk at pneyman dot com
-Status: Open
+Status: Bogus
Bug Type: Scripting Engine problem
Operating System: Fedora Core 2, kernel 2.6.5
PHP Version: 5.0.2
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.
change
.. private static $currentDb = PostgresDb; ...
to
.. private static $currentDb = 'PostgresDb'; ...
Previous Comments:
[2004-10-30 07:00:33] junk at pneyman dot com
Description:
Seems that there's no way to address the class constant from within a
static method declared in the same class. Script is parsed by the
engine, but I get a warning notice: Use of undefined constant 'xxx',
assuming 'xxx'. The name of the constant assumed is identical to the
one I want to address.
The substitution then occurs correctly, and script works. However, I
couldn't find a way to call cosntant correctly to avoid warning message
and guesswork from the engine.
self:: resolution operator doesn't help either.
Reproduce code:
---
include_once(db/PostGreSqlDbProfile.php);
include_once(db/MySqlDbProfile.php);
class InitStingray {
// constants
const PostgresDb = 'PostGreSQL';
const MysqlDb = 'MySQL';
// private variables
private static $currentDb = PostgresDb;
private static $db = NULL;
// public methods
private static function initDb () {
// xxx: problem addressing constant PostgresDb
if (self::$currentDb == self::PostgresDb) {
self::$db = new PostGreSqlDbProfile();
}
// xxx: problem addressing constant MySqlDb
else if (self::$currentDb = self::MysqlDb) {
self::$db = new MySqlDbProfile();
}
}
public static function getDb () {
if (self::$db == NULL) {
self::initDb();
return self::$db;
}
else {
return self::$db;
}
}
}
Expected result:
Substitution of the name of the constant for its value should occur,
and comparisons between variable $currentDb and predefined values
Postgres and Mysql should take place. No warnings should be issued.
Actual result:
--
Warning is issued that the script cannot locate the constant I'm
addressing, however guesses that I'm trying to call a cosntant with the
same name and correctly does the substitution issuing a warning notice.
--
Edit this bug report at http://bugs.php.net/?id=30619edit=1
#17445 [Com]: open_basedir warning when including file in same dir
ID: 17445
Comment by: stv at seznam dot cz
Reported By: mitch at webcob dot com
Status: No Feedback
Bug Type: Scripting Engine problem
Operating System: FreeB SD 4.4
PHP Version: 4.2.1
New Comment:
Same problem.
Why it haven't been solved yet in core?
Just only first check if file exists before check for permissions.
Why none feedback from here from some developers?
I can describe this problem detaily:
On server php5.cz with this configuration of php
http://slapstick.php5.cz/info.php
include_path is set: /www/7/site2017/:.:/usr/lib/php
open_basedir is set: /www/7/site2017/
Reproduce code:
In file /www/7/site2017/wwwroot/index.php :
require_once('../controller/inc.controller.php');
In file /www/7/site2017/controller/inc.controller.php :
error_reporting(E_ALL | E_STRICT);
if (!include_once('inc.config.php')) die('Application error0');
Require works as expected. Include not.
Because php is first searching in paths related to directory
/www/7/site2017/wwwroot/ and after trying to include file
/usr/lib/php/inc.config.php raises warning permission denied for this
include (due open_basedir) and ends proccessing of script even if the
file /usr/lib/php/inc.config.php doesn't exist.
Why rising permission warning even if file doesn't exist?
Expected result:
Including file /www/7/site2017/controller/inc.config.php
Actual result:
Warning: main() [function.main]: open_basedir restriction in effect.
File(/usr/lib/php/inc.config.php) is not within the allowed path(s):
(/www/7/site2017/) in /www/7/site2017/controller/inc.controller.php on
line 6
Warning: main(inc.config.php) [function.main]: failed to open stream:
Operation not permitted in
/www/7/site2017/controller/inc.controller.php on line 6
Warning: main() [function.include]: Failed opening 'inc.config.php' for
inclusion (include_path='/www/7/site2017/:.:/usr/lib/php') in
/www/7/site2017/controller/inc.controller.php on line 6
Application error0
Previous Comments:
[2002-10-24 01:00:03] php-bugs at lists dot php dot net
No feedback was provided for this bug for over 2 weeks, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to Open.
[2002-10-08 22:51:06] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-latest.zip
[2002-05-27 01:16:34] mitch at webcob dot com
I have set open_basedir =
/home/user
I have set include_path =
.:/home/user/lib:/home/user/site/lib
I have a file located in:
/home/user/site/htdocs/
which requires another file in the same directory.
?php require_once('file2.php'); ?
The include WORKS.
BUT IT PRODUCED A WARNING:
Warning: open_basedir restriction in effect. File is in wrong directory
in /home/user/site/htdocs/file1.php on line 3 File2 is here.
The File2 is here is produced by the included file.
I've seen others comment on this problem, but could find no solution or
open occurance of it in the bug list.
Thanks.
Mitch.
--
Edit this bug report at http://bugs.php.net/?id=17445edit=1
#30587 [Opn-Bgs]: Array assignment with array_multisort
ID: 30587 Updated by: [EMAIL PROTECTED] Reported By: ian_mclaughlin at blueyonder dot co dot uk -Status: Open +Status: Bogus Bug Type: Scripting Engine problem Operating System: Win32 PHP Version: 4.3.9 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-10-27 20:09:56] ian_mclaughlin at blueyonder dot co dot uk Description: this code gives the impression that array assignment is actually done by pointer sharing, when it should be done by copying. Reproduce code: --- ?php // $master_A=array(1,2,4,3); $master_B=array(1,3,2,4); $A = $master_A; $B = $master_B; echobr/BEFORE MULTISORT; echobr/master_Abr/; print_r($master_A); echobr/master_Bbr/; print_r($master_B); array_multisort($A, $B); echobr/AFTER MULTISORT; echobr/master_Abr/; print_r($master_A); echobr/master_Bbr/; print_r($master_B); ? Expected result: BEFORE MULTISORT master_A Array ( [0] = 1 [1] = 2 [2] = 4 [3] = 3 ) master_B Array ( [0] = 1 [1] = 3 [2] = 2 [3] = 4 ) AFTER MULTISORT master_A Array ( [0] = 1 [1] = 2 [2] = 4 [3] = 3 ) master_B Array ( [0] = 1 [1] = 3 [2] = 2 [3] = 4 ) Actual result: -- BEFORE MULTISORT master_A Array ( [0] = 1 [1] = 2 [2] = 4 [3] = 3 ) master_B Array ( [0] = 1 [1] = 3 [2] = 2 [3] = 4 ) AFTER MULTISORT master_A Array ( [0] = 1 [1] = 2 [2] = 3 [3] = 4 ) master_B Array ( [0] = 1 [1] = 3 [2] = 4 [3] = 2 ) -- Edit this bug report at http://bugs.php.net/?id=30587edit=1
#30582 [Opn-Fbk]: Accessing a static method from a static method in class doesn't work
ID: 30582
Updated by: [EMAIL PROTECTED]
Reported By: jj at archit dot uni-karlsruhe dot de
-Status: Open
+Status: Feedback
Bug Type: Class/Object related
Operating System: Debian Woody R3
PHP Version: 4.3.9
New Comment:
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ?php and ends with ?,
is max. 10-20 lines long and does not require any external
resources such as databases, etc.
If possible, make the script source available online and provide
an URL to it here. Try avoid embedding huge scripts into the report.
Previous Comments:
[2004-10-27 14:19:27] jj at archit dot uni-karlsruhe dot de
Description:
When trying to call a static method from within another
static method in the same class, PHP fails and prints
Problem with method call - please report this bug.
However, in a couple of other methods, this does work. I
have no clue, why it doesn't work in this particular
function, though.
Reproduce code:
---
function _getAuthType( ) {
if ( strstr( $_POST[username], tmp_ ) ||
(isset( $_SESSION[wahl] ) strstr( $_SESSION[wahl] - username,
tmp_ ) ) ) {
return DB;
} else {
return LDAP;
}
} /* end of getAuthType */
function getAuthOpts( ) {
$this - authOpts = array( DB = array(dsn =
DB_DRIVER.://.STUD_DB_USER.:.STUD_DB_PASS.@.STUD_DB_HOST./.STUD_DB_NAME,
cryptType= none,
table = studis,
usernamecol = login,
passwordcol = matrikelnr ),
LDAP = array(
host= ldaps://host,
port= 636,
basedn= dn,
userattr= uid )
);
$authType = WahlApplication::_getAuthType( );
return $this - authOpts[ $authType ];
}
Expected result:
$authType should contain a string - either DB or LDAP
Actual result:
--
Warning: Problem with method call - please report this bug
in /home/www/arch/studwahl-test/inc/base_classes.php on
line 76
Fatal error: Call to a member function on a non-object
in /home/www/arch/studwahl-test/inc/base_classes.php on
line 88
--
Edit this bug report at http://bugs.php.net/?id=30582edit=1
#30586 [Opn-Bgs]: Connection problems with MySQL 4.1.5 or later
ID: 30586 Updated by: [EMAIL PROTECTED] Reported By: olger901 at gmail dot com -Status: Open +Status: Bogus Bug Type: MySQL related Operating System: Windows 2000 Server PHP Version: Irrelevant New Comment: This problem (and it's solution) is described here: http://dev.mysql.com/doc/mysql/en/Old_client.html Previous Comments: [2004-10-29 04:16:28] zerr11ty at uregina dot ca I have this exact same problem. I believe the problem is with the mysql client that is bundled internally with php 4. It is used instead of the client that comes with the mysql installation. I have heard of a solution that involves building php with the --with-mysql=[DIR] option, where DIR points to the mysql install path. Then PHP will use mysql's clients instead of the bundled ones [2004-10-27 18:36:54] olger901 at gmail dot com I recently upgraded to MySQL 4.1.7 However after the upgrade PHP wasn't connecting to MySQL anymore and I can't seem to find the problem. This is the error phpmyadmin gives me: #1251 - Client does not support authentication protocol requested by server; consider upgrading MySQL client MySQL Administrator connects fine, I turned on old password compatability with it restarted my server and it didn't help a thing. I both tried using PHP 5.0.2 and PHP 4.3.9 but that didn't work either, I also tried replacing the PHP libmysql.dl with the DLL libmysql.dll that came shipped with MySQL 4.1.7 but then php complains that feature drop table isn't supported and that the MySQL extension won't be loaded. With PHP 5.0.2 I also tried using the MySQLi extension but that doesn't seem to work either. Simply said: The problem is in libmysql.dll in combination with php, because as soon as I upgrade libmysql.dll in C:\WINNT and I restart Apache with php it gives an error about not supporting certain features, while it does, so please upgrade PHP to support MySQL 4.1 versions [2004-10-27 17:01:10] olger901 at gmail dot com Description: Hello all, I am using: Windows 2000 Server Apache 2 PHP 4.3.9 MySQL 4.0.21 (upgraded today to 4.1.7) I recently upgraded to MySQL 4.1.7 However after the upgrade PHP wasn't connecting to MySQL anymore and I can't seem to find the problem. This is the error phpmyadmin gives me: #1251 - Client does not support authentication protocol requested by server; consider upgrading MySQL client MySQL Administrator connects fine, I turned on old password compatability with it restarted my server and it didn't help a thing. I both tried using PHP 5.0.2 and PHP 4.3.9 but that didn't work either, I also tried replacing the PHP libmysql.dl with the DLL libmysql.dll that came shipped with MySQL 4.1.7 but then php complains that feature drop table isn't supported and that the MySQL extension won't be loaded. With PHP 5.0.2 I also tried using the MySQLi extension but that doesn't seem to work either. -- Edit this bug report at http://bugs.php.net/?id=30586edit=1
#30573 [Opn-Asn]: Compiler Warning Due to Invalid Incorrect Type Cast
ID: 30573 Updated by: [EMAIL PROTECTED] Reported By: jbarwick at sentienthealth dot com -Status: Open +Status: Assigned Bug Type: Compile Warning Operating System: SuSE9.1 (amd64) PHP Version: 4.3.8 -Assigned To: +Assigned To: moriyoshi Previous Comments: [2004-10-27 04:10:16] jbarwick at sentienthealth dot com Description: file in consideration: ext/mbstring/libmbfl/filters/mbfilter_htmlent.c line 156 The line in question is written as: filter-cache = (int)mbfl_malloc(html_enc_buffer_size+1); This line is invalid on 64 bit systems as mbfl_malloc should be returning a pointer (64 bit) and int is not... filter-cache is defined as a long ... questions, should it be ulong? don't wanna change it cuz I don't know if there is any negative math used here Anyway, if we rewrite the line to: filter-cache = (long)mbfl_malloc(html_enc_buffer_size+1); we fix the invalid data type size, and this WILL work on both 32 bit and 64 bit systems. Throwing away the top 32 bits of a 64 bit pointer is extremely dangerous...don't you think? Reproduce code: --- compile the source Expected result: no compiler warnings Actual result: -- compiler warnings: cast from pointer ot integer of different size.. -- Edit this bug report at http://bugs.php.net/?id=30573edit=1
#30560 [Opn-Fbk]: Incompatible pointer type in standard/exec.c
ID: 30560 Updated by: [EMAIL PROTECTED] Reported By: jbarwick at sentienthealth dot com -Status: Open +Status: Feedback Bug Type: Compile Failure Operating System: SuSE 9.1 (amd64) PHP Version: 4.3.8 New Comment: Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to Open. Thank you for your interest in PHP. If you get an error in compile time, then where is the error message? Previous Comments: [2004-10-26 11:01:25] jbarwick at sentienthealth dot com Description: OUCH! Now I'm concernedVERY concerned...how many changes will we have to do...really getting difficult! zend_rsrc_list_entry is defined in zend_globals.h as a structure where zend_rsrc_list_entry-ptr is defined of course as a pointer ...in the 64 bit world, let's call that 64 bits... in exec.c, we refer to a HANDLE (for win32..ok 32 bit) or for UNIX a (pid_t)...which is, I suspec, an OS specific integer (process id)... now, zend objects...do we just need to store 32 bits in zend_rsrc_list_entry-ptr? Or do we need to store a memory address pointer? If so, is this going to be compatible with a 32 bit process identifier...or, is there just something wrong with my configure script and pid_t is suppose to be 64 bit! Didn't remember getting all these errors with 5.0 compile...any chance 5.0 compile will be able to use sablotron? (Yes, the readme file says it's in the external functions library...but when I checked, wasn't on the web site for download...no trace of it...)... I guess there's no 64 bit environment for me!!! On line 610 and line 1029 of ext/standard/exec.chow to we get around this 32 bit/64 bit problem? Reproduce code: --- compile exec.c Expected result: no problem with 64 bit environments Actual result: -- serious problem with 64 bit environments -- Edit this bug report at http://bugs.php.net/?id=30560edit=1
#30558 [Opn-Fbk]: mbstring mbregex failure to compile pointer cast problems
ID: 30558 Updated by: [EMAIL PROTECTED] Reported By: jbarwick at sentienthealth dot com -Status: Open +Status: Feedback Bug Type: Compile Failure Operating System: SuSE 9.1 (amd64) PHP Version: 4.3.8 New Comment: Please, provide all warnings and/or errors you get. Previous Comments: [2004-10-26 09:41:03] jbarwick at sentienthealth dot com Description: The entire MBREGEX.C object appears to be written with pointer address math using int variables. Whereas we all know that with the invent of i586/i686 systems the int veriable is nicely 32 bit, in a 64 bit environment, the pointers and the uint/int objects become completely incompatible. (Am I crazy here?)...or completely stupid? Anyway...lot's of pointer errors in mbstring/mbregex. It appears that this module is totally unusable in a 64-bit environment. To FIX, I did the following mbstring/mbregex/mbregex.h #define MINT long #define MLONG long The changed all int's to MINT and changed all long's to MLONG with a nice search and replace. Compiled with no compiler warnings (retesting make clean/make as we speak). It actually appears that the entire mbstring object must be completely re-written. S much pointer math using int's and so many cast from pointer to integer of different size errors. any chance of getting 4.3.9 or 4.3.10 compilable for 64-bit? I have a lot of work left to fix all the mbstring files that wont compile correctly...eg!!! PLEASE someone tell me I can ignore these because the pointer math works even when the compiler complains!! Reproduce code: --- compile mbstring/mbregex.c Expected result: no compiler warnings about bad pointers Actual result: -- compiler warnings about bad pointers -- Edit this bug report at http://bugs.php.net/?id=30558edit=1
#29698 [Com]: include suite does not traverse include_path subdirectories
ID: 29698 Comment by: hawk at air dot linkclub dot or dot jp Reported By: mills at sinetechnologies dot com Status: Open Bug Type: Zend Engine 2 problem Operating System: Win XP PHP Version: 5.0.1 New Comment: Resolved. Check you don't have php4ts.dll when you have PHP5 running. Previous Comments: [2004-11-02 15:49:06] hawk at air dot linkclub dot or dot jp I encountered the behavior of PHP 5.0.2 like your report. I could resolve on PHP 5.0.2 / WindowsXP with rotating the order of include_path elements. try: include_path = C:\Program Files\Apache Group\Apache\php\include;. instead of: include_path = .;C:\Program Files\Apache Group\Apache\php\include I guess this is a bug, anyway. Any suggestions? [2004-08-19 04:51:42] mills at sinetechnologies dot com Changing the '.' to './' had no success on the problem. Also, I cannot directly call C:\Program Files\Apache Group\Apache\php\include\phrame\util\HashMap.php (it is two directories below the include directory). But I can directly call C:\Program Files\Apache Group\Apache\php\include\include.php Permissions on the files are the same. [2004-08-18 12:25:46] scooter at butterball dot demon dot co dot uk Hi, We have resolved this bug on our Solaris box. The php.ini file was still the old php4 version, we installed the php5 version of the php.ini file and now recursive includes work fine on the Solaris box. They always worked on the Fedora box, but it had the php5 .ini file installed from the start. Not sure if this is a solution to the apparent bug on Win XP, but it worked for us. One last point the include_path on the php.ini file was the only element changed from the default, the '.' was changed to './' - this may also be important. Scooter [2004-08-18 10:21:04] scooter at butterball dot demon dot co dot uk Hi, I have seen the same problem on SunOS 5.8 Our code works fine on Linux Fedora Core 2. PHP version 5.0.1 is being used on both platforms. Scooter [2004-08-16 17:00:07] mills at sinetechnologies dot com This is not a duplication of 27891, or any other bug I have seen. 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/29698 -- Edit this bug report at http://bugs.php.net/?id=29698edit=1
#30541 [Opn-Bgs]: $php_errormsg isn't set when an error occured in a function called by eval()
ID: 30541
Updated by: [EMAIL PROTECTED]
Reported By: php at dush dot student dot utwente dot nl
-Status: Open
+Status: Bogus
Bug Type: Unknown/Other Function
Operating System: linux 2.6
PHP Version: 5.0.2
New Comment:
Can't find any errors here:
?
eval('echo $blah;');
var_dump($php_errormsg);
echo $bla;
var_dump($php_errormsg);
?
outputs:
---
Notice: Undefined variable: blah in /www/index.php(3) : eval()'d code
on line 1
string(24) Undefined variable: blah
Notice: Undefined variable: bla in /www/index.php on line 7
string(23) Undefined variable: bla
---
Check your code.
Previous Comments:
[2004-10-23 16:49:20] php at dush dot student dot utwente dot nl
Description:
in debug mode, my script stores every error that occured in the script.
when an error occurs in eval(), the error is stored correctly in
$php_errormsg. however when the error occured in a function called by
eval() the error isn't stored anymore.
Reproduce code:
---
register_tick_function(store_errors, true);
function store_errors($do_tick = true) {
GLOBAL $php_errormsg;
static $errors = array();
if ($do_tick) {
if (isset($php_errormsg) $php_errormsg != ) {
if ($trace = debug_backtrace()) {
$func = $trace[1]['function'];
if (isset($trace[1]['class']))
$func =
$trace[1]['class'].$trace[1]['type'].$func;
}else {
$func = 'unknown';
}
$errors[] = array(
0 = $php_errormsg,
1 = $func
);
$php_errormsg = ;
}
}else {
return $errors;
}
}
/* stupid test function */
function blah() { echo $blah2; echo error is set here:
$php_errormsgbr; }
eval ('echo $blah1; blah();');
$ar = store_errors(false);
while(list($key,$val) = each($ar)) {
echo {$key} = {$val[0]} in {$val[1]}br\n;
}
Expected result:
Notice: Undefined variable: blah1 in
/home/dush/public_html/core/loader.inc.php(28) : eval()'d code on line
1
Notice: Undefined variable: blah2 in
/home/dush/public_html/core/loader.inc.php on line 27
error is set here: Undefined variable: blah2
0 = Undefined variable: blah1 in unknown
1 = Undefined variable: blah2 in blah
Actual result:
--
Notice: Undefined variable: blah1 in
/home/dush/public_html/core/loader.inc.php(28) : eval()'d code on line
1
Notice: Undefined variable: blah2 in
/home/dush/public_html/core/loader.inc.php on line 27
error is set here: Undefined variable: blah2
0 = Undefined variable: blah1 in unknown
--
Edit this bug report at http://bugs.php.net/?id=30541edit=1
#30564 [Opn-Fbk]: existing files not seen (not existant)
ID: 30564
Updated by: [EMAIL PROTECTED]
Reported By: cherub at dagservice dot nl
-Status: Open
+Status: Feedback
Bug Type: Filesystem function related
Operating System: Windows XP SP2
PHP Version: 5.0.1
New Comment:
Please provide a complete example script, so we can just run it and see
the problem.
Previous Comments:
[2004-10-26 16:40:48] cherub at dagservice dot nl
Description:
I used the script below to generate a filename, and check if it already
exists useing file_exists (block 1). It generates the following output:
File 'C:\Program Files\Apache
Group\Apache2\htdocs\aanleverwizard/temppics/e88d28551c277889a0b34b4b2135d348/pic0.png'
does not exist!. However, when I copy/paste this to the windows run
dialog, it actually is executed, so the file does exist!
I also tried replacing the file_exists function with a replacement
function (block 2), but that also doesn't work...
Reproduce code:
---
//BLOCK 1: REPRODUCE FILE_EXISTS BUG
$Teller = 0;
$TestFile = getcwd(). '/temppics/'. session_id(). '/pic'. $Teller.
'.png';
if (file_exists($TestFile)){
echo('File \''. $TestFile. '\' exists!BR');
} else {
echo('File \''. $TestFile. '\' does not exist!BR');
}
// BLOCK2: ALTERNATIVE TO FILE_EXISTS FUNCTION
if (!function_exists('file_does_exist')){
function file_does_exist($FileName){
if (glob($FileName)){
return true;
} else return false;
}
}
Expected result:
I expect file_exists to return true, but it does not. I did verify that
the file does actually exist.
Actual result:
--
// see description.
--
Edit this bug report at http://bugs.php.net/?id=30564edit=1
#30112 [Ver-Csd]: Crash when __ToString() called from object with undefined property
ID: 30112
Updated by: [EMAIL PROTECTED]
Reported By: jw at jwscripts dot com
-Status: Verified
+Status: Closed
Bug Type: Reproducible crash
Operating System: *
PHP Version: 5.0.2
New Comment:
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
Now prints out:
Fatal error: Method Foo::__toString() must return a string value in
/usr/home/thekid/test.php on line 14
Previous Comments:
[2004-09-27 14:08:19] ante dot dfg at moj dot net
I can confirm this on Win XP sp1 using Apache 1.3.31 and php 5.0.2
szAppName : Apache.exe szAppVer : 0.0.0.0 szModName :
php5ts.dll
szModVer : 5.0.2.2 offset : 0004e27f
[2004-09-25 14:40:42] [EMAIL PROTECTED]
#0 0x08136dc9 in zend_get_class_entry (zobject=0x81f735c)
at /home/johannes/src/php/php-5.0.2/Zend/zend_API.c:204
#1 0x0814d413 in zend_std_cast_object_tostring
(readobj=0x81f735c,
writeobj=0xbfffca40, type=3, should_free=0)
at /home/johannes/src/php/php-5.0.2/Zend/zend_object_handlers.c:938
#2 0x0815bd96 in zend_echo_handler
(execute_data=0xbfffcbb0,
opline=0x81f57a0, op_array=0x81f124c)
at /home/johannes/src/php/php-5.0.2/Zend/zend_execute.c:1984
#3 0x0815be3c in zend_print_handler
(execute_data=0xbfffcbb0,
opline=0x81f57a0, op_array=0x81f124c)
at /home/johannes/src/php/php-5.0.2/Zend/zend_execute.c:2002
#4 0x0815ab28 in execute (op_array=0x81f124c)
at /home/johannes/src/php/php-5.0.2/Zend/zend_execute.c:1400
#5 0x081365bf in zend_execute_scripts (type=8,
retval=0x0, file_count=3)
at /home/johannes/src/php/php-5.0.2/Zend/zend.c:1060
#6 0x080f0edc in php_execute_script
(primary_file=0xbfffeff0)
at /home/johannes/src/php/php-5.0.2/main/main.c:1629
#7 0x0816775a in main (argc=1, argv=0xb094)
at /home/johannes/src/php/php-5.0.2/sapi/cli/php_cli.c:943
[2004-09-25 13:33:35] jw at jwscripts dot com
Bug persists in version 5.0.2, the notice and fatal error are not
displayed (crash is more severe).
[2004-09-16 13:39:45] jw at jwscripts dot com
Description:
When the __toString() method is called from a returned object to return
an undefined property, Apache 2.0.48 crashes.
Reproduce code:
---
?
class Foo {
public function doSomething() {
return new Foo;
}
public function __toString () {
return $this-undefined;
}
}
$foo = new Foo;
print $foo-doSomething();
?
Expected result:
Notice: Undefined property: Foo::$undefined
Fatal error: Method Foo::__toString() must return a string value
Actual result:
--
Apache Crash:
=
szAppName : Apache.exe szAppVer : 2.0.48.0
szModName : php5ts.dll
szModVer : 5.0.1.1 offset : 0004dd7f
+ the above messages
--
Edit this bug report at http://bugs.php.net/?id=30112edit=1
#30558 [Com]: mbstring mbregex failure to compile pointer cast problems
ID: 30558 Comment by: jorton at redhat dot com Reported By: jbarwick at sentienthealth dot com Status: Feedback Bug Type: Compile Failure Operating System: SuSE 9.1 (amd64) PHP Version: 4.3.8 New Comment: gcc -Wall output for ext/mbstring from amd64 build of HEAD: ext/mbstring/oniguruma/regexec.c: In function `match_at': ext/mbstring/oniguruma/regexec.c:1106: warning: cast to pointer from integer of different size ext/mbstring/oniguruma/regexec.c:1110: warning: cast to pointer from integer of different size ext/mbstring/oniguruma/regexec.c:1126: warning: cast to pointer from integer of different size ext/mbstring/oniguruma/regexec.c:1130: warning: cast to pointer from integer of different size ext/mbstring/oniguruma/regexec.c:1763: warning: cast from pointer to integer of different size ext/mbstring/oniguruma/regexec.c:1777: warning: cast from pointer to integer of different size ext/mbstring/oniguruma/regexec.c:1794: warning: cast from pointer to integer of different size ext/mbstring/oniguruma/regexec.c:1800: warning: cast from pointer to integer of different size ext/mbstring/oniguruma/regexec.c:1839: warning: cast to pointer from integer of different size ext/mbstring/oniguruma/regexec.c:1843: warning: cast to pointer from integer of different size ext/mbstring/oniguruma/regexec.c:1871: warning: cast to pointer from integer of different size ext/mbstring/oniguruma/regexec.c:1875: warning: cast to pointer from integer of different size ext/mbstring/oniguruma/regexec.c:1903: warning: cast to pointer from integer of different size ext/mbstring/oniguruma/regexec.c:1907: warning: cast to pointer from integer of different size ext/mbstring/oniguruma/regexec.c:1942: warning: cast to pointer from integer of different size ext/mbstring/oniguruma/regexec.c:1946: warning: cast to pointer from integer of different size ext/mbstring/oniguruma/regexec.c:2027: warning: cast to pointer from integer of different size ext/mbstring/oniguruma/regexec.c:2050: warning: cast to pointer from integer of different size ext/mbstring/oniguruma/regexec.c:1138: warning: `pstart' might be used uninitialized in this function ext/mbstring/oniguruma/regparse.c: In function `not_code_range_buf': ext/mbstring/oniguruma/regparse.c:1628: warning: `to' might be used uninitialized in this function ext/mbstring/libmbfl/filters/mbfilter_htmlent.c: In function `mbfl_filt_conv_html_dec_ctor': ext/mbstring/libmbfl/filters/mbfilter_htmlent.c:161: warning: cast from pointer to integer of different size ext/mbstring/libmbfl/filters/mbfilter_htmlent.c: In function `mbfl_filt_conv_html_dec_dtor': ext/mbstring/libmbfl/filters/mbfilter_htmlent.c:169: warning: cast to pointer from integer of different size ext/mbstring/libmbfl/filters/mbfilter_htmlent.c: In function `mbfl_filt_conv_html_dec': ext/mbstring/libmbfl/filters/mbfilter_htmlent.c:178: warning: cast to pointer from integer of different size ext/mbstring/libmbfl/filters/mbfilter_htmlent.c: In function `mbfl_filt_conv_html_dec_flush': ext/mbstring/libmbfl/filters/mbfilter_htmlent.c:249: warning: cast to pointer from integer of different size Previous Comments: [2004-11-04 13:09:36] [EMAIL PROTECTED] Please, provide all warnings and/or errors you get. [2004-10-26 09:41:03] jbarwick at sentienthealth dot com Description: The entire MBREGEX.C object appears to be written with pointer address math using int variables. Whereas we all know that with the invent of i586/i686 systems the int veriable is nicely 32 bit, in a 64 bit environment, the pointers and the uint/int objects become completely incompatible. (Am I crazy here?)...or completely stupid? Anyway...lot's of pointer errors in mbstring/mbregex. It appears that this module is totally unusable in a 64-bit environment. To FIX, I did the following mbstring/mbregex/mbregex.h #define MINT long #define MLONG long The changed all int's to MINT and changed all long's to MLONG with a nice search and replace. Compiled with no compiler warnings (retesting make clean/make as we speak). It actually appears that the entire mbstring object must be completely re-written. S much pointer math using int's and so many cast from pointer to integer of different size errors. any chance of getting 4.3.9 or 4.3.10 compilable for 64-bit? I have a lot of work left to fix all the mbstring files that wont compile correctly...eg!!! PLEASE someone tell me I can ignore these because the pointer math works even when the compiler complains!! Reproduce code: --- compile mbstring/mbregex.c Expected result: no compiler warnings about bad pointers Actual result: -- compiler warnings about bad pointers -- Edit this bug
#30558 [Fbk-Asn]: Interpreter crashes reproducibly (2)
ID: 30558 Updated by: [EMAIL PROTECTED] -Summary: mbstring mbregex failure to compile pointer cast problems Reported By: jbarwick at sentienthealth dot com -Status: Feedback +Status: Assigned Bug Type: Compile Failure -Operating System: SuSE 9.1 (amd64) +Operating System: WinXP SP1 -PHP Version: 4.3.8 +PHP Version: 5CVS-2004-04-22 (dev) -Assigned To: +Assigned To: moriyoshi New Comment: I'm not sure if jbarwick's suggested fix: The changed all int's to MINT and changed all long's to MLONG is really advisable; Moriyoshi, have you looked at this? ISTR it being mentioned before on php-dev. Previous Comments: [2004-11-04 14:27:17] jorton at redhat dot com gcc -Wall output for ext/mbstring from amd64 build of HEAD: ext/mbstring/oniguruma/regexec.c: In function `match_at': ext/mbstring/oniguruma/regexec.c:1106: warning: cast to pointer from integer of different size ext/mbstring/oniguruma/regexec.c:1110: warning: cast to pointer from integer of different size ext/mbstring/oniguruma/regexec.c:1126: warning: cast to pointer from integer of different size ext/mbstring/oniguruma/regexec.c:1130: warning: cast to pointer from integer of different size ext/mbstring/oniguruma/regexec.c:1763: warning: cast from pointer to integer of different size ext/mbstring/oniguruma/regexec.c:1777: warning: cast from pointer to integer of different size ext/mbstring/oniguruma/regexec.c:1794: warning: cast from pointer to integer of different size ext/mbstring/oniguruma/regexec.c:1800: warning: cast from pointer to integer of different size ext/mbstring/oniguruma/regexec.c:1839: warning: cast to pointer from integer of different size ext/mbstring/oniguruma/regexec.c:1843: warning: cast to pointer from integer of different size ext/mbstring/oniguruma/regexec.c:1871: warning: cast to pointer from integer of different size ext/mbstring/oniguruma/regexec.c:1875: warning: cast to pointer from integer of different size ext/mbstring/oniguruma/regexec.c:1903: warning: cast to pointer from integer of different size ext/mbstring/oniguruma/regexec.c:1907: warning: cast to pointer from integer of different size ext/mbstring/oniguruma/regexec.c:1942: warning: cast to pointer from integer of different size ext/mbstring/oniguruma/regexec.c:1946: warning: cast to pointer from integer of different size ext/mbstring/oniguruma/regexec.c:2027: warning: cast to pointer from integer of different size ext/mbstring/oniguruma/regexec.c:2050: warning: cast to pointer from integer of different size ext/mbstring/oniguruma/regexec.c:1138: warning: `pstart' might be used uninitialized in this function ext/mbstring/oniguruma/regparse.c: In function `not_code_range_buf': ext/mbstring/oniguruma/regparse.c:1628: warning: `to' might be used uninitialized in this function ext/mbstring/libmbfl/filters/mbfilter_htmlent.c: In function `mbfl_filt_conv_html_dec_ctor': ext/mbstring/libmbfl/filters/mbfilter_htmlent.c:161: warning: cast from pointer to integer of different size ext/mbstring/libmbfl/filters/mbfilter_htmlent.c: In function `mbfl_filt_conv_html_dec_dtor': ext/mbstring/libmbfl/filters/mbfilter_htmlent.c:169: warning: cast to pointer from integer of different size ext/mbstring/libmbfl/filters/mbfilter_htmlent.c: In function `mbfl_filt_conv_html_dec': ext/mbstring/libmbfl/filters/mbfilter_htmlent.c:178: warning: cast to pointer from integer of different size ext/mbstring/libmbfl/filters/mbfilter_htmlent.c: In function `mbfl_filt_conv_html_dec_flush': ext/mbstring/libmbfl/filters/mbfilter_htmlent.c:249: warning: cast to pointer from integer of different size [2004-11-04 13:09:36] [EMAIL PROTECTED] Please, provide all warnings and/or errors you get. [2004-10-26 09:41:03] jbarwick at sentienthealth dot com Description: The entire MBREGEX.C object appears to be written with pointer address math using int variables. Whereas we all know that with the invent of i586/i686 systems the int veriable is nicely 32 bit, in a 64 bit environment, the pointers and the uint/int objects become completely incompatible. (Am I crazy here?)...or completely stupid? Anyway...lot's of pointer errors in mbstring/mbregex. It appears that this module is totally unusable in a 64-bit environment. To FIX, I did the following mbstring/mbregex/mbregex.h #define MINT long #define MLONG long The changed all int's to MINT and changed all long's to MLONG with a nice search and replace. Compiled with no compiler warnings (retesting make clean/make as we speak). It actually appears that the entire mbstring object must be completely re-written. S much pointer math using int's and so many cast from pointer to integer of different size
#30558 [Asn]: mbstring mbregex failure to compile pointer cast problems
ID: 30558 Updated by: [EMAIL PROTECTED] -Summary: Interpreter crashes reproducibly (2) Reported By: jbarwick at sentienthealth dot com Status: Assigned Bug Type: Compile Failure -Operating System: WinXP SP1 +Operating System: SuSE 9.1 (amd64) -PHP Version: 5CVS-2004-04-22 (dev) +PHP Version: 4.3.8 Assigned To: moriyoshi New Comment: Grrr, fixing version/OS again. Previous Comments: [2004-11-04 14:37:07] [EMAIL PROTECTED] I'm not sure if jbarwick's suggested fix: The changed all int's to MINT and changed all long's to MLONG is really advisable; Moriyoshi, have you looked at this? ISTR it being mentioned before on php-dev. [2004-11-04 14:27:17] jorton at redhat dot com gcc -Wall output for ext/mbstring from amd64 build of HEAD: ext/mbstring/oniguruma/regexec.c: In function `match_at': ext/mbstring/oniguruma/regexec.c:1106: warning: cast to pointer from integer of different size ext/mbstring/oniguruma/regexec.c:1110: warning: cast to pointer from integer of different size ext/mbstring/oniguruma/regexec.c:1126: warning: cast to pointer from integer of different size ext/mbstring/oniguruma/regexec.c:1130: warning: cast to pointer from integer of different size ext/mbstring/oniguruma/regexec.c:1763: warning: cast from pointer to integer of different size ext/mbstring/oniguruma/regexec.c:1777: warning: cast from pointer to integer of different size ext/mbstring/oniguruma/regexec.c:1794: warning: cast from pointer to integer of different size ext/mbstring/oniguruma/regexec.c:1800: warning: cast from pointer to integer of different size ext/mbstring/oniguruma/regexec.c:1839: warning: cast to pointer from integer of different size ext/mbstring/oniguruma/regexec.c:1843: warning: cast to pointer from integer of different size ext/mbstring/oniguruma/regexec.c:1871: warning: cast to pointer from integer of different size ext/mbstring/oniguruma/regexec.c:1875: warning: cast to pointer from integer of different size ext/mbstring/oniguruma/regexec.c:1903: warning: cast to pointer from integer of different size ext/mbstring/oniguruma/regexec.c:1907: warning: cast to pointer from integer of different size ext/mbstring/oniguruma/regexec.c:1942: warning: cast to pointer from integer of different size ext/mbstring/oniguruma/regexec.c:1946: warning: cast to pointer from integer of different size ext/mbstring/oniguruma/regexec.c:2027: warning: cast to pointer from integer of different size ext/mbstring/oniguruma/regexec.c:2050: warning: cast to pointer from integer of different size ext/mbstring/oniguruma/regexec.c:1138: warning: `pstart' might be used uninitialized in this function ext/mbstring/oniguruma/regparse.c: In function `not_code_range_buf': ext/mbstring/oniguruma/regparse.c:1628: warning: `to' might be used uninitialized in this function ext/mbstring/libmbfl/filters/mbfilter_htmlent.c: In function `mbfl_filt_conv_html_dec_ctor': ext/mbstring/libmbfl/filters/mbfilter_htmlent.c:161: warning: cast from pointer to integer of different size ext/mbstring/libmbfl/filters/mbfilter_htmlent.c: In function `mbfl_filt_conv_html_dec_dtor': ext/mbstring/libmbfl/filters/mbfilter_htmlent.c:169: warning: cast to pointer from integer of different size ext/mbstring/libmbfl/filters/mbfilter_htmlent.c: In function `mbfl_filt_conv_html_dec': ext/mbstring/libmbfl/filters/mbfilter_htmlent.c:178: warning: cast to pointer from integer of different size ext/mbstring/libmbfl/filters/mbfilter_htmlent.c: In function `mbfl_filt_conv_html_dec_flush': ext/mbstring/libmbfl/filters/mbfilter_htmlent.c:249: warning: cast to pointer from integer of different size [2004-11-04 13:09:36] [EMAIL PROTECTED] Please, provide all warnings and/or errors you get. [2004-10-26 09:41:03] jbarwick at sentienthealth dot com Description: The entire MBREGEX.C object appears to be written with pointer address math using int variables. Whereas we all know that with the invent of i586/i686 systems the int veriable is nicely 32 bit, in a 64 bit environment, the pointers and the uint/int objects become completely incompatible. (Am I crazy here?)...or completely stupid? Anyway...lot's of pointer errors in mbstring/mbregex. It appears that this module is totally unusable in a 64-bit environment. To FIX, I did the following mbstring/mbregex/mbregex.h #define MINT long #define MLONG long The changed all int's to MINT and changed all long's to MLONG with a nice search and replace. Compiled with no compiler warnings (retesting make clean/make as we speak). It actually appears that the entire mbstring object must be completely re-written. S much pointer math using int's and so
#30328 [Opn]: Crash when passing undefned variable to __get() and return its name
ID: 30328
Updated by: [EMAIL PROTECTED]
Reported By: flying at dom dot natm dot ru
Status: Open
Bug Type: Reproducible crash
Operating System: windows 2000
PHP Version: 5.0.2
New Comment:
This actually happens with $testvar defined to anything that will
evaluate to for the member (including being undefined).
So:
$testvar= ''; // or NULL, or FALSE, or omitted altogether
$test = new Test();
echo $test-$testvar;
The zend_std_read_property() object handler converts the member to a
string before trying to read it, so in each of the above cases (whether
not defined at all, being defined to an empty string, NULL, or FALSE),
the __get argument $name is an empty string (created with
STR_EMPTY_ALLOC() in convert_to_string()) and makes PHP crash at
shutdown.
Now a crash *only* happens if the argument $name is an empty string
*and* left unmodified (e.g. having $name.= '' in the __get method will
not cause the problem).
Maybe this gives a hint at how to solve the problem.
Previous Comments:
[2004-10-05 15:27:51] [EMAIL PROTECTED]
Seems to be 5.0.x specific - I can't reproduce it with 5.1-dev.
Notice: Undefined variable: testvar in /www/index.php on line 13
__get() called:
Program received signal SIGSEGV, Segmentation fault.
0x4207c0dc in mempcpy () from /lib/tls/libc.so.6
(gdb) bt
#0 0x4207c0dc in mempcpy () from /lib/tls/libc.so.6
#1 0x4206e660 in _IO_file_xsputn () from /lib/tls/libc.so.6
#2 0x42062e32 in fwrite () from /lib/tls/libc.so.6
#3 0x081c601a in sapi_cli_single_write (str=0x0, str_length=136509472)
at /home/dev/php-src_PHP_5_0/sapi/cli/php_cli.c:192
#4 0x081c4692 in sapi_cli_ub_write (str=0x0, str_length=136509472) at
/home/dev/php-src_PHP_5_0/sapi/cli/php_cli.c:205
#5 0x0815d563 in php_ub_body_write_no_header (str=0x0,
str_length=136509472) at /home/dev/php-src_PHP_5_0/main/output.c:684
#6 0x0815c1aa in php_body_write (str=0x0, str_length=136509472) at
/home/dev/php-src_PHP_5_0/main/output.c:119
#7 0x0814da36 in php_body_write_wrapper (str=0x0,
str_length=136509472) at /home/dev/php-src_PHP_5_0/main/main.c:1242
#8 0x0819251c in zend_print_zval_ex (write_func=0x814da15
php_body_write_wrapper, expr=0xbfffd2b0, indent=0)
at /home/dev/php-src_PHP_5_0/Zend/zend.c:288
#9 0x0819249a in zend_print_zval (expr=0xbfffd300, indent=0) at
/home/dev/php-src_PHP_5_0/Zend/zend.c:269
#10 0x08191c2f in zend_print_variable (var=0xbfffd300) at
/home/dev/php-src_PHP_5_0/Zend/zend_variables.c:168
#11 0x081b9d2d in zend_echo_handler (execute_data=0xffd45008,
opline=0x2ca910bf, op_array=0x2c641c08) at
/home/dev/php-src_PHP_5_0/Zend/zend_execute.c:1989
[2004-10-05 12:37:01] flying at dom dot natm dot ru
Description:
PHP 5.0.2 on Windows 2000 SP4.
There is reproducible crash happens when one tries to pass undefined
variable to a class with defined __get() function.
Example code:
?php
class Test {
function __construct() {}
public function __get($name)
{
echo '__get() called: '.$name;
return($name);
}
};
$test = new Test();
echo $test-$testvar;
?
Running this code from under Apache results in HTTP 500 error, running
it from shell results to some garbage to be shown on screen and program
exit. However running it as:
php.exe test.php log
results in following text appearing in log:
Notice: Undefined variable: testvar in C:\web\test.php on line 13
__get() called:
Moreover changing return($name); inside __get() to returning anything
else (either static value or some other variable) results in crash
disappearing.
--
Edit this bug report at http://bugs.php.net/?id=30328edit=1
#29035 [Asn-Csd]: using isset() crashes PHP5TS.DLL within Apache
ID: 29035
Updated by: [EMAIL PROTECTED]
Reported By: steven at omicron-software dot co dot uk
-Status: Assigned
+Status: Closed
Bug Type: Reproducible crash
Operating System: *
PHP Version: 5.0.0RC3
Assigned To: andi
New Comment:
Now outputs:
Fatal error: Cannot use [] for reading in /usr/home/thekid/test.php on
line 3
The crash has gone, this is expected functionality, I assume this can
be closed.
Previous Comments:
[2004-08-13 03:02:56] jsgoupil at lookstrike dot com
Same with empty()
[2004-07-07 09:11:16] [EMAIL PROTECTED]
Your expected result is wrong, you can not isset on an addition to an
array.
Besides that, i could reproduce this on Linux too.
backtrace:
0x08316ef5 in zend_isset_isempty_dim_prop_obj_handler (prop_dim=0,
execute_data=0xbfffd540, opline=0x404e63e0, op_array=0x404e60c4)
at /dat/dev/php/php-5.0dev/Zend/zend_execute.c:3969
warning: Source file is more recent than executable.
3969
(gdb) bt
#0 0x08316ef5 in zend_isset_isempty_dim_prop_obj_handler (prop_dim=0,
execute_data=0xbfffd540, opline=0x404e63e0, op_array=0x404e60c4)
at /dat/dev/php/php-5.0dev/Zend/zend_execute.c:3969
#1 0x083171c3 in zend_isset_isempty_dim_obj_handler
(execute_data=0xbfffd540,
opline=0x404e63e0, op_array=0x404e60c4)
at /dat/dev/php/php-5.0dev/Zend/zend_execute.c:4056
#2 0x0831029f in execute (op_array=0x404e60c4)
at /dat/dev/php/php-5.0dev/Zend/zend_execute.c:1391
#3 0x082ec861 in zend_execute_scripts (type=8, retval=0x0,
file_count=3)
at /dat/dev/php/php-5.0dev/Zend/zend.c:1058
#4 0x082a6b83 in php_execute_script (primary_file=0xb980)
at /dat/dev/php/php-5.0dev/main/main.c:1630
#5 0x0831cd96 in main (argc=1, argv=0xba24)
at /dat/dev/php/php-5.0dev/sapi/cli/php_cli.c:943
valgrind says:
==21034==
==21034== Invalid read of size 1
==21034==at 0x8316EF5: zend_isset_isempty_dim_prop_obj_handler
(zend_execute.c:3969)
==21034==by 0x83171C2: zend_isset_isempty_dim_obj_handler
(zend_execute.c:4056)
==21034==by 0x831029E: execute (zend_execute.c:1391)
==21034==by 0x82EC860: zend_execute_scripts (zend.c:1058)
==21034== Address 0xC is not stack'd, malloc'd or free'd
==21034==
==21034== Process terminating with default action of signal 11
(SIGSEGV): dumping core
==21034== Access not within mapped region at address 0xC
==21034==at 0x8316EF5: zend_isset_isempty_dim_prop_obj_handler
(zend_execute.c:3969)
==21034==by 0x83171C2: zend_isset_isempty_dim_obj_handler
(zend_execute.c:4056)
==21034==by 0x831029E: execute (zend_execute.c:1391)
==21034==by 0x82EC860: zend_execute_scripts (zend.c:1058)
==21034==
[2004-07-06 19:19:43] steven at omicron-software dot co dot uk
Description:
When using a simple isset() script crashes PHP5.
Reproduce code:
---
?
$array = array('foo' = 'bar');
if (isset($array[])) echo Something;
?
Expected result:
The expected result is to echo Something
Actual result:
--
Actual result is a Apache.exe has encountered a problem and needs to
close. We are sorry for the inconvenience. error in PHP5TS.DLL,
running as a Module on Apache 1.3.31.
Debug tool with Microsoft Visual Studio returns this:
Unhandled exception in Apache.exe (PHP5TS.DLL): 0xC005: Access
Violation
--
Edit this bug report at http://bugs.php.net/?id=29035edit=1
#29648 [Opn-Bgs]: cant throw exceptions with __autoload (to catch and handle them - workaround?)
ID: 29648
Updated by: [EMAIL PROTECTED]
Reported By: black at scene-si dot org
-Status: Open
+Status: Bogus
Bug Type: Scripting Engine problem
Operating System: debian
PHP Version: 5.0+
New Comment:
__autoload() is not allowed to fail. If it does, this is a fatal error.
This is expected behaviour = no bug.
From the manual:
By calling this function the scripting engine is given a last chance
to load the class before PHP fails with an error.
Previous Comments:
[2004-10-29 15:16:24] black at scene-si dot org
requesting feedback new versions also dont support this
[2004-08-13 12:49:39] black at scene-si dot org
And the result:
Fatal error: __autoload(object_wtf) threw an exception of type
'Exception' in /root/monotek/mono/commands/test.php on line 16
(gah)
[2004-08-13 12:47:52] black at scene-si dot org
ugh, forgot to add
if (!class_exists($classname)) {
throw new Exception();
}
after the first include_once in the example.
Ofcourse i'm throwing the exception im trying to catch ;)
[2004-08-13 12:30:17] black at scene-si dot org
Description:
I've tried to create an __autoload() function which would throw an
exception if it can't load the class name from a file depending on the
classname i request with the php code.
I couldnt catch the exception with a try/catch clause, because it
always failed (see expected/actual result below).
My workaround was to add this after the first include_once statement
inside the __autoload:
if (!class_exists($classname)) {
eval(class .$classname. { });
}
Afterwards instead of a try/catch clause i used a method_exist call to
see if a general function was defined (one that i require to have).
Reproduce code:
---
?php
function __autoload($classname) {
if (substr($classname,0,7)==object_) {
@include_once(include/object..substr($classname,7)..php);
return;
}
@include_once(class..$classname..php);
}
try {
$object = new object_wtf(hello);
} catch (Exception $e) { echo __autoload failed ; var_dump($object);
}
Expected result:
Output: __autoload failed NULL
Actual result:
--
Fatal error: Class 'object_wtf' not found in
/root/monotek/mono/commands/test.php on line 15
--
Edit this bug report at http://bugs.php.net/?id=29648edit=1
#30685 [NEW]: Malformed SOAPClient http header reequest
From: lagoni at dsw dot dk
Operating system: Fedora Core 2
PHP version: 5.0.2
PHP Bug Type: SOAP related
Bug description: Malformed SOAPClient http header reequest
Description:
Description:
I found a error in the implementation of the http header in the SOAP
extension.
The error also exist in the newest CVS version.
According to the HTTP 1.1 RFC2616, section 3.4:
HTTP character sets are identified by case-insensitive tokens. The
complete set of tokens is defined by the IANA Character Set registry[19].
charset = token
The extension is wrapping double quotes around the torken of the charset
tag.
I tried to patch it, and it seems to work:
--- php_http.c.orig 2004-06-22 14:42:17.0 +0200
+++ php_http.c 2004-11-04 15:02:48.588726799 +0100
@@ -390,14 +390,14 @@
*/
User-Agent: PHP SOAP 0.1\r\n);
if (soap_version == SOAP_1_2) {
- smart_str_append_const(soap_headers,Content-Type:
application/soap+xml; charset=\utf-8);
+ smart_str_append_const(soap_headers,Content-Type:
application/soap+xml; charset=utf-8);
if (soapaction) {
smart_str_append_const(soap_headers,\; action=\);
smart_str_appends(soap_headers, soapaction);
}
smart_str_append_const(soap_headers,\\r\n);
} else {
- smart_str_append_const(soap_headers,Content-Type: text/xml;
charset=\utf-8\\r\n);
+ smart_str_append_const(soap_headers,Content-Type: text/xml;
charset=utf-8\r\n);
if (soapaction) {
smart_str_append_const(soap_headers, SOAPAction:
\);
smart_str_appends(soap_headers, soapaction);
--
Edit bug report at http://bugs.php.net/?id=30685edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=30685r=trysnapshot4
Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=30685r=trysnapshot50
Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=30685r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=30685r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=30685r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=30685r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=30685r=needscript
Try newer version: http://bugs.php.net/fix.php?id=30685r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=30685r=support
Expected behavior: http://bugs.php.net/fix.php?id=30685r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=30685r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=30685r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=30685r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=30685r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=30685r=dst
IIS Stability: http://bugs.php.net/fix.php?id=30685r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=30685r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=30685r=float
MySQL Configuration Error: http://bugs.php.net/fix.php?id=30685r=mysqlcfg
#30619 [Bgs]: class constants cannot be accessed from withing class static method
ID: 30619
Updated by: [EMAIL PROTECTED]
Reported By: junk at pneyman dot com
Status: Bogus
Bug Type: Scripting Engine problem
Operating System: Fedora Core 2, kernel 2.6.5
PHP Version: 5.0.2
New Comment:
The line
private static $currentDb = PostgresDb;
should read
private static $currentDb = self::PostgresDb;
Example:
$ cat test.php
?php
class Foo {
const PostgresDb = 'PostgreSQL';
private static $dbname= self::PostgresDb;
public static function test() {
var_dump(self::PostgresDb, self::$dbname);
}
}
Foo::test();
?
$ php5 test.php
string(10) PostgreSQL
string(10) PostgreSQL
Previous Comments:
[2004-11-04 10:36:29] [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.
change
.. private static $currentDb = PostgresDb; ...
to
.. private static $currentDb = 'PostgresDb'; ...
[2004-10-30 07:00:33] junk at pneyman dot com
Description:
Seems that there's no way to address the class constant from within a
static method declared in the same class. Script is parsed by the
engine, but I get a warning notice: Use of undefined constant 'xxx',
assuming 'xxx'. The name of the constant assumed is identical to the
one I want to address.
The substitution then occurs correctly, and script works. However, I
couldn't find a way to call cosntant correctly to avoid warning message
and guesswork from the engine.
self:: resolution operator doesn't help either.
Reproduce code:
---
include_once(db/PostGreSqlDbProfile.php);
include_once(db/MySqlDbProfile.php);
class InitStingray {
// constants
const PostgresDb = 'PostGreSQL';
const MysqlDb = 'MySQL';
// private variables
private static $currentDb = PostgresDb;
private static $db = NULL;
// public methods
private static function initDb () {
// xxx: problem addressing constant PostgresDb
if (self::$currentDb == self::PostgresDb) {
self::$db = new PostGreSqlDbProfile();
}
// xxx: problem addressing constant MySqlDb
else if (self::$currentDb = self::MysqlDb) {
self::$db = new MySqlDbProfile();
}
}
public static function getDb () {
if (self::$db == NULL) {
self::initDb();
return self::$db;
}
else {
return self::$db;
}
}
}
Expected result:
Substitution of the name of the constant for its value should occur,
and comparisons between variable $currentDb and predefined values
Postgres and Mysql should take place. No warnings should be issued.
Actual result:
--
Warning is issued that the script cannot locate the constant I'm
addressing, however guesses that I'm trying to call a cosntant with the
same name and correctly does the substitution issuing a warning notice.
--
Edit this bug report at http://bugs.php.net/?id=30619edit=1
#30685 [Opn-Asn]: Malformed SOAPClient http header reequest
ID: 30685
Updated by: [EMAIL PROTECTED]
Reported By: lagoni at dsw dot dk
-Status: Open
+Status: Assigned
Bug Type: SOAP related
Operating System: Fedora Core 2
PHP Version: 5.0.2
-Assigned To:
+Assigned To: dmitry
Previous Comments:
[2004-11-04 15:16:08] lagoni at dsw dot dk
Description:
Description:
I found a error in the implementation of the http header in the SOAP
extension.
The error also exist in the newest CVS version.
According to the HTTP 1.1 RFC2616, section 3.4:
HTTP character sets are identified by case-insensitive tokens. The
complete set of tokens is defined by the IANA Character Set
registry[19].
charset = token
The extension is wrapping double quotes around the torken of the
charset tag.
I tried to patch it, and it seems to work:
--- php_http.c.orig 2004-06-22 14:42:17.0 +0200
+++ php_http.c 2004-11-04 15:02:48.588726799 +0100
@@ -390,14 +390,14 @@
*/
User-Agent: PHP SOAP 0.1\r\n);
if (soap_version == SOAP_1_2) {
- smart_str_append_const(soap_headers,Content-Type:
application/soap+xml; charset=\utf-8);
+ smart_str_append_const(soap_headers,Content-Type:
application/soap+xml; charset=utf-8);
if (soapaction) {
smart_str_append_const(soap_headers,\; action=\);
smart_str_appends(soap_headers, soapaction);
}
smart_str_append_const(soap_headers,\\r\n);
} else {
- smart_str_append_const(soap_headers,Content-Type: text/xml;
charset=\utf-8\\r\n);
+ smart_str_append_const(soap_headers,Content-Type: text/xml;
charset=utf-8\r\n);
if (soapaction) {
smart_str_append_const(soap_headers, SOAPAction:
\);
smart_str_appends(soap_headers, soapaction);
--
Edit this bug report at http://bugs.php.net/?id=30685edit=1
#24808 [Ana-Csd]: access to private or protected member throw __get and __set method
ID: 24808
Updated by: [EMAIL PROTECTED]
Reported By: Bertrand dot Willm at laposte dot net
-Status: Analyzed
+Status: Closed
Bug Type: Zend Engine 2 problem
Operating System: *
PHP Version: 5*
New Comment:
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
Reproduce code now returns default as expected.
--- Test script --
?php
class Foo {
private $private_member = 'private';
protected $protected_member = 'protected';
public $public_member= 'public';
function __get($name) {
return $this-{$name}.' (via __get)';
}
}
$foo= new Foo();
var_dump($foo-private_member);
var_dump($foo-protected_member);
var_dump($foo-public_member);
?
--- Output --
string(19) private (via __get)
string(21) protected (via __get)
string(6) public
Previous Comments:
[2004-07-13 16:16:50] de_bruut at hotmail dot com
Quick suggestion:
Please consider adding the same overloading functionality ( __call() )
for private and protected methods.
[2004-05-31 23:14:28] [EMAIL PROTECTED]
That seems to be the best solution.
[2004-05-30 14:43:07] [EMAIL PROTECTED]
After talking with Andi, I think it's a valid issue and what needs to
be done is to make accessors (__get/__set) be called on access to
variables that are not visible in current context. This still would not
change the fact that acessors are not called on existing variables, but
invisible variables in this context would be regarded as good as
unexisting.
[2003-10-16 05:03:46] [EMAIL PROTECTED]
The behavior is absolut correct. Since the property 'var' is declared
private it cannot be accessed. And also since it is a declared property
there is no need for the engine to execute __call(). Both __get() and
__set() are only there to handle virtual properties (aka not declared
ones).
Double check #25815 and #25199
[2003-07-28 18:50:06] alan at akbkhome dot com
This has been discussed on zend2-engine, getters and setters on
'defined' vars is a feature that a number of people would like to
see..
AFAIK It just needs a voluteer to propose some code..
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/24808
--
Edit this bug report at http://bugs.php.net/?id=24808edit=1
#30635 [Opn]: exception handler does not work
ID: 30635
Updated by: [EMAIL PROTECTED]
Reported By: support at malyweb dot cz
Status: Open
Bug Type: Zend Engine 2 problem
Operating System: winXp
PHP Version: 5CVS-2004-10-31 (dev)
New Comment:
Cannot reproduce (CLI, FreeBSD):
$ cat test.php
?php
class core_exception {
public function exceptionHandler($exception){
echo 'Uncaught exception: ', $exception-getMessage(), \n;
}
}
set_exception_handler(array(new core_exception(),
'exceptionHandler'));
throw new Exception('oh no ... ;)');
?
$ php5 test.php
Uncaught exception: oh no ... ;)
Previous Comments:
[2004-11-01 00:11:32] support at malyweb dot cz
just some more info:
I've just downgraded php back to 5.0.2 - the difference is, that the
code sometimes (irregulary :/) shows the expected result and Fatal
error: Uncaught exception 'Exception' with message 'oh no ... ;)' in
...
I wonder how is that possible - I have tried IE and Mozilla (i've
suspected the cache for a while)
the windowsXP built-in firewall is off
[2004-10-31 23:53:10] support at malyweb dot cz
Description:
the code below causes that window critical error dialog appear and no
result is shown
I tried it on 5.0.2 - it did not work so I downloaded this latest
version (5.0.3-dev) and it is still not working.
(I read this one also: http://bugs.php.net/bug.php?id=30230 but
actually do not understand it - the code is not working also)
btw: this works fine
function exceptionHandler($exception){
echo('Uncaught exception: '.$exception-getMessage());
}
set_exception_handler('exceptionHandler');
throw new Exception('oh no ... ;)');exit;
Reproduce code:
---
?php
class core_exception {
public static function exceptionHandler($exception){
echo('Uncaught exception: '.$exception-getMessage());
}
}
$_EXCEPTION = new core_exception();
set_exception_handler(array($_EXCEPTION,'exceptionHandler'));
throw new Exception('oh no ... ;)');exit;
?
Expected result:
Uncaught exception: oh no ... ;)
Actual result:
--
via browser: no result + critical error of apache
via cmdline: no result + critical error of CLI or CGI/FastCGI
via zde debugger: shows the expected result (build 1482)
--
Edit this bug report at http://bugs.php.net/?id=30635edit=1
#30394 [Opn-Csd]: Assignment operators yield wrong result with __get/__set
ID: 30394
Updated by: [EMAIL PROTECTED]
Reported By: php at hartwerk dot com
-Status: Open
+Status: Closed
Bug Type: Zend Engine 2 problem
Operating System: Linux
PHP Version: 5.0.2
New Comment:
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
Works fine with 5.1-CVS, outputting 2 - 3
Previous Comments:
[2004-10-15 18:46:51] php at hartwerk dot com
An easier work-around would be $c-a = $c-a + max( 0, 1 ), but
work-arounds do not solve bugs..
[2004-10-15 12:13:47] ante dot dfg at moj dot net
This code works if you return the value from _get via reference
try:
public function __get( $what ) {
return $this-_p[ $what ];
}
[2004-10-11 11:24:19] php at hartwerk dot com
Description:
When there is a function on the right-hand side of an assignment
operator expression, and the variable is to be accessed via
__get/__set, the operation yields wrong results.
Reproduce code:
---
class Container
{
public function __get( $what )
{
return $this-_p[ $what ];
}
public function __set( $what, $value )
{
$this-_p[ $what ] = $value;
}
private $_p = array();
}
$c = new Container();
$c-a = 1;
$c-a += 1;
print $c-a;// -- 2
print - ;
$c-a += max( 0, 1 );
print $c-a;// -- 4 (!)
Expected result:
2 - 3
Actual result:
--
2 - 4
--
Edit this bug report at http://bugs.php.net/?id=30394edit=1
#30394 [Csd-Opn]: Assignment operators yield wrong result with __get/__set
ID: 30394
Updated by: [EMAIL PROTECTED]
Reported By: php at hartwerk dot com
-Status: Closed
+Status: Open
Bug Type: Zend Engine 2 problem
Operating System: Linux
PHP Version: 5.0.2
New Comment:
It's 5.0.x specific bug.
Previous Comments:
[2004-11-04 16:06:31] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
Works fine with 5.1-CVS, outputting 2 - 3
[2004-10-15 18:46:51] php at hartwerk dot com
An easier work-around would be $c-a = $c-a + max( 0, 1 ), but
work-arounds do not solve bugs..
[2004-10-15 12:13:47] ante dot dfg at moj dot net
This code works if you return the value from _get via reference
try:
public function __get( $what ) {
return $this-_p[ $what ];
}
[2004-10-11 11:24:19] php at hartwerk dot com
Description:
When there is a function on the right-hand side of an assignment
operator expression, and the variable is to be accessed via
__get/__set, the operation yields wrong results.
Reproduce code:
---
class Container
{
public function __get( $what )
{
return $this-_p[ $what ];
}
public function __set( $what, $value )
{
$this-_p[ $what ] = $value;
}
private $_p = array();
}
$c = new Container();
$c-a = 1;
$c-a += 1;
print $c-a;// -- 2
print - ;
$c-a += max( 0, 1 );
print $c-a;// -- 4 (!)
Expected result:
2 - 3
Actual result:
--
2 - 4
--
Edit this bug report at http://bugs.php.net/?id=30394edit=1
#30686 [NEW]: comments
From: nosoftwarepatents at free dot fr Operating system: w2k PHP version: 5.0.2 PHP Bug Type: *General Issues Bug description: comments Description: while commenting out a portion of a regular expression on a single line of code, I noticed that: /* 'script[^]*?.*?/script'si; */ works fine, but that the following generate a Parse error // 'script[^]*?.*?/script'si; # 'script[^]*?.*?/script'si; Surely, comment syntax should be read first before ignoring the trailing text, no? -- Edit bug report at http://bugs.php.net/?id=30686edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=30686r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=30686r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=30686r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=30686r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=30686r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=30686r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=30686r=needscript Try newer version: http://bugs.php.net/fix.php?id=30686r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=30686r=support Expected behavior: http://bugs.php.net/fix.php?id=30686r=notwrong Not enough info: http://bugs.php.net/fix.php?id=30686r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=30686r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=30686r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=30686r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=30686r=dst IIS Stability: http://bugs.php.net/fix.php?id=30686r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=30686r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=30686r=float MySQL Configuration Error: http://bugs.php.net/fix.php?id=30686r=mysqlcfg
#29789 [Opn]: Output handler set in ini not used
ID: 29789
User updated by: sander at innove dot nl
Reported By: sander at innove dot nl
Status: Open
Bug Type: Output Control
Operating System: Linux / Windows
PHP Version: 4.3.8
New Comment:
Stil no reactions on this bug...why?
Previous Comments:
[2004-08-22 15:36:53] sander at innove dot nl
reproducing code must be:
[.htaccess]:
php_value auto_prepend_file foo.php
php_flag output_buffering on
php_value foo
[foo.php]
foo($buffer)
{
return foo . $buffer;
}
[bar.php]
echo bar;
[2004-08-22 15:34:37] sander at innove dot nl
Description:
The problem seems to occur on both Windows and Linux, using any version
from 4.3.2 or higher (5.x.x not included). When I define an
output_handler in my php.ini of .htaccess and turn output-buffering on,
the output_handler is not called before sending the output to the
browser.
Reproduce code:
---
[.htaccess]:
php_value auto_prepend_file foo.php
php_flag output_buffering on
php_value foo
[prepend.php]
foo($buffer)
{
return foo . $buffer;
}
[bar.php]
echo bar;
Expected result:
foobar
Actual result:
--
bar
--
Edit this bug report at http://bugs.php.net/?id=29789edit=1
#30683 [Opn]: Change in behavious of FILES array between 4.3.6 and 4.3.7_3
ID: 30683
User updated by: bugs at bsdfirst dot com
Reported By: bugs at bsdfirst dot com
Status: Open
-Bug Type: Zend Engine 2 problem
+Bug Type: Feature/Change Request
Operating System: FreeBSD
PHP Version: Irrelevant
New Comment:
I have just confirmed that 4.3.9 also behaves in the same manner as
4.3.7_3. It would appear that this was a bug fix to prevent a security
exploit (use paths containing ../). I wonder if there shouldn't be a
way to obtain the contents of a INPUT type=file field in it's
entirety? Particually since you cannot use php://input whilst POSTing
a mulipart mime form. This could either be another entry in the
$_FILES array, for example $_FILES['pic']['orig_path'] or
$_FILES['pic']['name'] could check for '^http:||ftp:'. The former is
probably the most compatible and the least security risk (a user could
not accidentally use it - they would have to make a deliberate choice).
What are the chances of having something like that added into the 4
series? With all of this in mind I have changed the category of this
report to Feature Request. Thanks, Patrick
Previous Comments:
[2004-11-04 06:11:17] bugs at bsdfirst dot com
Description:
Hi,
I have two FreeBSD servers detailed as follows:
lassa:
FreeBSD 4.10-STABLE
php4-4.3.7_3
apache+mod_ssl+mod_deflate-1.3.31+2.8.18+1.3.14.12+1.0.21_4
honk:
FreeBSD 4.9-RELEASE
php4-4.3.6
apache+mod_ssl+mod_deflate-1.3.29+2.8.16+1.0.20_3
I am using a HTML form (enctype=multipart/form-data) to upload image
files to each server.
On the server honk I am using the function isurlorfile to allow the
user to type a URL instead of selecting a file in the INPUT
type=file box.
Selecting a file for upload works correctly in both cases.
C:\Pics\test.png yields the following the in $_FILES array:
honk lassa:
$_FILES['pic']['name'] contains 'test.png'
However entering a URL only works on the server honk. Entering the URL
http://localhost/test.png into the INPUT type=file box on the form
yields the following results in the $_FILES array:
honk:
$_FILES['pic']['name'] contains 'http://localhost/test.png'
lassa:
$_FILES['pic']['name'] contains 'test.png'
Honk is our development server and we have written code relying on this
undocumented feature.
Obviously the behavious exhibited on the server honk is usefull as a
user can select a file or enter a URL to a file in the one input
field.
Which of these is the expected behaviour? Is there an expected
behaviour and what behaviour would I expect from a more current version
of PHP? Could I request the behaviour exibited on the server honk be a
documented feature?
Thanks,
Patrick Brennan
Reproduce code:
---
function _isurlorfile($str) {
if (is_uploaded_file($str['tmp_name']) $str['size']) {
return $str['tmp_name'];
} elseif (ereg('^http|ftp', $str['name'])) {
return $str['name'];
} else {
return 0;
}
}
--
Edit this bug report at http://bugs.php.net/?id=30683edit=1
#28976 [Com]: Ability to disable Return-Path header or use From header instead of php.ini
ID: 28976
Comment by: Charlesk at netgaintechnology dot com
Reported By: kdaniel at aosepc dot com
Status: Open
Bug Type: Mail related
Operating System: Windows\Apache
PHP Version: 4.3.6
New Comment:
It seems to me that this was thought of but never implemented. In
sendmail.c:
if (headers) {
char *pos = NULL;
size_t i;
/* Use PCRE to trim the header into the right format */
if (NULL == (headers = php_win32_mail_trim_header(headers
TSRMLS_CC))) {
*error = W32_SM_PCRE_ERROR;
return FAILURE;
}
/* Create a lowercased header for all the searches so we're finally
case
* insensitive when searching for a pattern. */
if (NULL == (headers_lc = estrdup(headers))) {
efree(headers);
*error = OUT_OF_MEMORY;
return FAILURE;
}
for (i = 0; i strlen(headers_lc); i++) {
headers_lc[i] = tolower(headers_lc[i]);
}
}
/* Fall back to sendmail_from php.ini setting */
if (mailRPath *mailRPath) {
RPath = estrdup(mailRPath);
}
else if (INI_STR(sendmail_from)) {
RPath = estrdup(INI_STR(sendmail_from));
} else {
if (headers) {
efree(headers);
efree(headers_lc);
}
*error = W32_SM_SENDMAIL_FROM_NOT_SET;
return FAILURE;
}
I would think that in the if (headers) section there should be some
code to set the mailRPath if the From header is found in headers. That
way when it falls into the if (mailRPath *mailRPath) section it will
appropriately assign the from to the return path.
Can this be fixed soon?
Thanks
Charles
Previous Comments:
[2004-08-24 19:53:10] dv at josheli dot com
http://marc.theaimsgroup.com/?l=php-devm=109286883222906w=2
[2004-08-23 19:19:30] kdaniel at aosepc dot com
Yes it is. The problem exists in sendmail.c
The code as follows:
/* Fall back to sendmail_from php.ini setting */
if (mailRPath *mailRPath) {
RPath = estrdup(mailRPath);
}
else if (INI_STR(sendmail_from)) {
RPath = estrdup(INI_STR(sendmail_from));
} else {
if (headers) {
efree(headers);
efree(headers_lc);
}
*error = W32_SM_SENDMAIL_FROM_NOT_SET;
return FAILURE;
}
Should be changed to:
/* Fall back to sendmail_from php.ini setting */
if (mailRPath *mailRPath) {
RPath = estrdup(mailRPath);
}
else if (INI_STR(sendmail_from)) {
RPath = estrdup(INI_STR(sendmail_from));
} else {
if (headers) {
efree(headers);
efree(headers_lc);
} else {
*error = W32_SM_SENDMAIL_FROM_NOT_SET;
return FAILURE;
}
}
I have not tested this, it is just a guess.
Kevin
[2004-08-23 19:02:33] joe at inexo dot com
It's not coming from php.ini.
[2004-08-18 23:07:34] dv at josheli dot com
using cli PHP 5 and latest snap (php5-win32-200408181430), the extra
From: header does not seem to work.
test.php:
?php
mail('[EMAIL PROTECTED]','subject','body',From: [EMAIL PROTECTED]);
?
Warning: mail(): sendmail_from not set in php.ini or custom From:
header missing in C:\dev\quiktests\test.php on line 3
[2004-08-06 21:39:27] kdaniel at aosepc dot com
I don't see how that is possible because there is no way for the mail
server to pick up the sendmail_from ini setting. PHP has to be using
it somewhere. There needs to be a way to disable its use.
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/28976
--
Edit this bug report at http://bugs.php.net/?id=28976edit=1
#30686 [Opn-Bgs]: comments
ID: 30686 Updated by: [EMAIL PROTECTED] Reported By: nosoftwarepatents at free dot fr -Status: Open +Status: Bogus Bug Type: *General Issues Operating System: w2k PHP Version: 5.0.2 New Comment: Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php See the part in the manual on escaping from HTML. Previous Comments: [2004-11-04 16:18:18] nosoftwarepatents at free dot fr Description: while commenting out a portion of a regular expression on a single line of code, I noticed that: /* 'script[^]*?.*?/script'si; */ works fine, but that the following generate a Parse error // 'script[^]*?.*?/script'si; # 'script[^]*?.*?/script'si; Surely, comment syntax should be read first before ignoring the trailing text, no? -- Edit this bug report at http://bugs.php.net/?id=30686edit=1
#7923 [Com]: htmlentities doesn't work for ISO 8859-2
ID: 7923 Comment by: rf at astro dot uni dot torun dot pl Reported By: muhlig at us dot edu dot pl Status: Analyzed Bug Type: Feature/Change Request Operating System: N/A PHP Version: 4.0.3pl1 New Comment: Sorry, I am not PHP programmer... I just found that Polish characters in form entries (in not my software) are converted to html entities (and displayed incorrectly); I tracked thing to happen in htmlentities() function. I am using Apache/2.0.48 (Unix) mod_ssl/2.0.48 OpenSSL/0.9.6b PHP/4.3.5-dev, it has been a few years since 2000; maybe the programmer should use another thing for checking the input... ;) regards, Previous Comments: [2002-04-27 17:29:20] [EMAIL PROTECTED] for most if the iso 8859-2 charset, there are no standard html entities, and the current behavior of htmlentities() is to leave such characters unconverted. the real problem is that the current behavior of htmlentities() when passed an unknown charset is to use the iso 8859-1 mapping. it shouldn't try to use a charset mapping in that case. [2000-11-23 07:40:20] [EMAIL PROTECTED] BTW: you can use recode(ISO8859-2..h4,$text) for this purpose. See GNU recode extension and recode docs for more information. [2000-11-22 08:17:01] muhlig at us dot edu dot pl From PHP Manual: ... htmlentities... At present, the ISO-8859-1 character set is used. I feel there is strong need to make htmlentities to support other charsets than ISO 8859-1. We, here in Poland for instance, use ISO 8859-2. Many Western/USA freeware programs use (as they of course should) htmlentities. Proper display of our diacritic chars is then impossible. We have to modify sources, removing htmlentities or defining own functions. It's a waste of time and resources. May I ask PHP developers to consider this issue? Maciek -- Edit this bug report at http://bugs.php.net/?id=7923edit=1
#30687 [NEW]: Second read attempt on memo (LONGCHAR) fields via ODBC fails
From: albin at kth dot se
Operating system: Windows XP Pro SP2
PHP version: 5CVS-2004-11-04 (dev)
PHP Bug Type: ODBC related
Bug description: Second read attempt on memo (LONGCHAR) fields via ODBC fails
Description:
There seems to be a problem reading Memo-fields (ODBC-type LONGCHAR) from
an MS-Access database via ODBC... The first attempt is successfull, but if
you try to read the same field again from the same result-set you get
nothing.
Reading non-memo-fields multiple times works OK.
Reproduce code:
---
$db = odbc_connect('DATABASE','','');
$res = odbc_exec($db, SELECT Body FROM Letters WHERE LetterID = X);
echo First attempt: .odbc_result($res, 'Body'); // displays the letter
body
echo Second attempt: .odbc_result($res,'Body'); // displays nothing
Expected result:
First attempt: [Letter body]
Second attempt: [Letter body]
Actual result:
--
First attempt: [Letter body]
Second attempt:
--
Edit bug report at http://bugs.php.net/?id=30687edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=30687r=trysnapshot4
Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=30687r=trysnapshot50
Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=30687r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=30687r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=30687r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=30687r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=30687r=needscript
Try newer version: http://bugs.php.net/fix.php?id=30687r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=30687r=support
Expected behavior: http://bugs.php.net/fix.php?id=30687r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=30687r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=30687r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=30687r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=30687r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=30687r=dst
IIS Stability: http://bugs.php.net/fix.php?id=30687r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=30687r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=30687r=float
MySQL Configuration Error: http://bugs.php.net/fix.php?id=30687r=mysqlcfg
#30688 [NEW]: imap_mail's rpath don't work
From: sirber at gmail dot com
Operating system: Gentoo Linux 2.6.9
PHP version: 4.3.9
PHP Bug Type: Mail related
Bug description: imap_mail's rpath don't work
Description:
Using imap_mail, and using the rpath setting, the mail I set is not used.
Thanks
Stéphane Bérubé
SW:
PHP 4.3.9
* Runs on apache user
Exim 4.42
* /usr/sbin/exim -bd -q15m
* Runs on mail user
* Special config:
trusted_users = apache
Reproduce code:
---
$to = [EMAIL PROTECTED];
$sujet = test;
$mime = [headers and mime encoded message];
$cc = ;
$cci = ;
$from = [EMAIL PROTECTED];
function imap_send ($to, $sujet, $mime, $cc, $cci, $from)
{
imap_mail ($to, $sujet, , $mime, $cc, $cci, $from);
}
Expected result:
Return-path: [EMAIL PROTECTED]
Actual result:
--
Return-path: [EMAIL PROTECTED]
--
Edit bug report at http://bugs.php.net/?id=30688edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=30688r=trysnapshot4
Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=30688r=trysnapshot50
Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=30688r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=30688r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=30688r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=30688r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=30688r=needscript
Try newer version: http://bugs.php.net/fix.php?id=30688r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=30688r=support
Expected behavior: http://bugs.php.net/fix.php?id=30688r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=30688r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=30688r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=30688r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=30688r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=30688r=dst
IIS Stability: http://bugs.php.net/fix.php?id=30688r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=30688r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=30688r=float
MySQL Configuration Error: http://bugs.php.net/fix.php?id=30688r=mysqlcfg
#30689 [NEW]: logical operators not working as expected
From: ioan dot nicu at ines dot ro Operating system: Linux PHP version: 4CVS-2004-11-04 (stable) PHP Bug Type: Zend Engine 2 problem Bug description: logical operators not working as expected Description: The logical operators 'and', 'or', 'xor' have unexpected results. The bug doesn't occur when using C-style logical operators ( ||, , ^^). From the php manual (Logical Operators Section): http://www.php.net/manual/en/language.operators.logical.php Example | Name | Result -- $a and $b | And | TRUE if both $a and $b are TRUE. $a or $b | Or | TRUE if either $a or $b is TRUE. $a xor $b | Xor | TRUE if either $a or $b is TRUE, but not both. This bug is reproducible on the latest stable snapshot from cvs. Reproduce code: --- ? $a1 = false or true; $a2 = true or false; $b1 = true or false; $b2 = false and true; $c = true xor true; echo(false or true = );var_dump($a1); echo(true or false = );var_dump($a2); echo(true and false = );var_dump($b1); echo(false and true = );var_dump($b2); echo(true xor true = );var_dump($c); ? Expected result: false or true = bool(true) true or false = bool(true) true and false = bool(false) false and true = bool(false) true xor true = bool(false) Actual result: -- false or true = bool(false) true or false = bool(true) true and false = bool(true) false and true = bool(false) true xor true = bool(true) -- Edit bug report at http://bugs.php.net/?id=30689edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=30689r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=30689r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=30689r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=30689r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=30689r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=30689r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=30689r=needscript Try newer version: http://bugs.php.net/fix.php?id=30689r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=30689r=support Expected behavior: http://bugs.php.net/fix.php?id=30689r=notwrong Not enough info: http://bugs.php.net/fix.php?id=30689r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=30689r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=30689r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=30689r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=30689r=dst IIS Stability: http://bugs.php.net/fix.php?id=30689r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=30689r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=30689r=float MySQL Configuration Error: http://bugs.php.net/fix.php?id=30689r=mysqlcfg
#30652 [Opn]: imagettftext different output os
ID: 30652 User updated by: info at paulinternet dot nl -Summary: imagettftext different output hosts Reported By: info at paulinternet dot nl Status: Open Bug Type: GD related -Operating System: Windows XP FreeBSD +Operating System: Windows Linux PHP Version: 4.3.9 New Comment: Description: Imagettftext produces different images on Windows and Linux. I used the Verdana font, but this happends on more(maybe all) fonts. GD version: bundled (2.0.28 compatible) Windows output: http://www.paulinternet.nl/php.net/Windows.png Linux output: http://www.paulinternet.nl/php.net/Linux.png Verdana font: http://www.paulinternet.nl/php.net/Verdana.ttf Reproduce code: --- header(Content-type: image/png); $Image = imagecreate(200, 24); imagecolorallocate($Image, 0, 0, 0); $Kleur = imagecolorallocate($Image, 255, 255, 255); imagettftext($Image, 16, 0, 2, 18, $Kleur, Pagina's/Tekst/Verdana.ttf, I have a problem); imagepng($Image); imagedestroy($Image); Previous Comments: [2004-11-01 16:00:00] info at paulinternet dot nl Description: I can run this script on the localhost and on the server of my hosting provider. The image on the localhost is a bit difference from the image on the server. Is this a bug? If not, how can I get on my computer the same output as on the server? My phpinfo: http://www.paulinternet.nl/php.net/Localhost.htm Server phpinfo: http://www.paulinternet.nl/php.net/Server.htm My output: http://www.paulinternet.nl/php.net/Localhost.png Server output: http://www.paulinternet.nl/php.net/Server.png Verdana font: http://www.paulinternet.nl/php.net/Verdana.ttf Reproduce code: --- header(Content-type: image/png); $Image = imagecreate(200, 24); imagecolorallocate($Image, 0, 0, 0); $Kleur = imagecolorallocate($Image, 255, 255, 255); imagettftext($Image, 16, 0, 2, 18, $Kleur, Pagina's/Tekst/Verdana.ttf, I have a problem); imagepng($Image); imagedestroy($Image); -- Edit this bug report at http://bugs.php.net/?id=30652edit=1
#30689 [Opn-Bgs]: logical operators not working as expected
ID: 30689 Updated by: [EMAIL PROTECTED] Reported By: ioan dot nicu at ines dot ro -Status: Open +Status: Bogus Bug Type: Zend Engine 2 problem Operating System: Linux PHP Version: 4CVS-2004-11-04 (stable) New Comment: No bug here, the = operator has a higher precedence than and, or and xor so you'll have to use parenthesis. See: http://www.php.net/manual/en/language.operators.php#language.operators.precedence Previous Comments: [2004-11-04 18:54:14] ioan dot nicu at ines dot ro Description: The logical operators 'and', 'or', 'xor' have unexpected results. The bug doesn't occur when using C-style logical operators ( ||, , ^^). From the php manual (Logical Operators Section): http://www.php.net/manual/en/language.operators.logical.php Example | Name | Result -- $a and $b | And | TRUE if both $a and $b are TRUE. $a or $b | Or | TRUE if either $a or $b is TRUE. $a xor $b | Xor | TRUE if either $a or $b is TRUE, but not both. This bug is reproducible on the latest stable snapshot from cvs. Reproduce code: --- ? $a1 = false or true; $a2 = true or false; $b1 = true or false; $b2 = false and true; $c = true xor true; echo(false or true = );var_dump($a1); echo(true or false = );var_dump($a2); echo(true and false = );var_dump($b1); echo(false and true = );var_dump($b2); echo(true xor true = );var_dump($c); ? Expected result: false or true = bool(true) true or false = bool(true) true and false = bool(false) false and true = bool(false) true xor true = bool(false) Actual result: -- false or true = bool(false) true or false = bool(true) true and false = bool(true) false and true = bool(false) true xor true = bool(true) -- Edit this bug report at http://bugs.php.net/?id=30689edit=1
#30635 [Opn]: exception handler does not work
ID: 30635
User updated by: support at malyweb dot cz
Reported By: support at malyweb dot cz
Status: Open
Bug Type: Zend Engine 2 problem
Operating System: winXp
PHP Version: 5CVS-2004-10-31 (dev)
New Comment:
the code does not work:
win XP, php 5.0.2: irregularly
Fatal error: Uncaught exception 'Exception' with message 'oh no ... ;)'
in C:\...\html\test.php:11 Stack trace: #0 {main} thrown in
C:\...\html\test.php on line 11
OR
Uncaught exception: oh no ... ;)
win2000, php5.0.1 (maybe irrelevant): only the first one
both is apache 2.0.52
Previous Comments:
[2004-11-04 16:03:44] [EMAIL PROTECTED]
Cannot reproduce (CLI, FreeBSD):
$ cat test.php
?php
class core_exception {
public function exceptionHandler($exception){
echo 'Uncaught exception: ', $exception-getMessage(), \n;
}
}
set_exception_handler(array(new core_exception(),
'exceptionHandler'));
throw new Exception('oh no ... ;)');
?
$ php5 test.php
Uncaught exception: oh no ... ;)
[2004-11-01 00:11:32] support at malyweb dot cz
just some more info:
I've just downgraded php back to 5.0.2 - the difference is, that the
code sometimes (irregulary :/) shows the expected result and Fatal
error: Uncaught exception 'Exception' with message 'oh no ... ;)' in
...
I wonder how is that possible - I have tried IE and Mozilla (i've
suspected the cache for a while)
the windowsXP built-in firewall is off
[2004-10-31 23:53:10] support at malyweb dot cz
Description:
the code below causes that window critical error dialog appear and no
result is shown
I tried it on 5.0.2 - it did not work so I downloaded this latest
version (5.0.3-dev) and it is still not working.
(I read this one also: http://bugs.php.net/bug.php?id=30230 but
actually do not understand it - the code is not working also)
btw: this works fine
function exceptionHandler($exception){
echo('Uncaught exception: '.$exception-getMessage());
}
set_exception_handler('exceptionHandler');
throw new Exception('oh no ... ;)');exit;
Reproduce code:
---
?php
class core_exception {
public static function exceptionHandler($exception){
echo('Uncaught exception: '.$exception-getMessage());
}
}
$_EXCEPTION = new core_exception();
set_exception_handler(array($_EXCEPTION,'exceptionHandler'));
throw new Exception('oh no ... ;)');exit;
?
Expected result:
Uncaught exception: oh no ... ;)
Actual result:
--
via browser: no result + critical error of apache
via cmdline: no result + critical error of CLI or CGI/FastCGI
via zde debugger: shows the expected result (build 1482)
--
Edit this bug report at http://bugs.php.net/?id=30635edit=1
#30672 [Csd-Opn]: Problem handling exif data in jpeg images at unusual places
ID: 30672 Updated by: [EMAIL PROTECTED] -Summary: exif_thumbnail fails after image has been edited in Exifer Reported By: bosse at mellberg dot org -Status: Closed +Status: Open Bug Type: *Graphics related Operating System: * PHP Version: 4.3.9, 5.0.2 Assigned To: helly New Comment: Reopen and set the summary to the real cause. You can already get your thumbnails when ignoring the warnign. Previous Comments: [2004-11-04 00:57:29] [EMAIL PROTECTED] Well it looks like you exchanged working/non working, however both are pretty fine using HEAD. If you want to verify yourself then doenload php source and edit ext/exif/exif.c and change the line #undef EXIF_DEBUG into #define EXIF_DEBUG. Then you'll see all details of the decoding process. The test script i used was: php -r 'file_put_contents($argv[1]..thumb.jpg, exif_thumbnail($argv[1]));' filename.jpg and then i looked at the generated file and both are fine. To Exifer i can only say it seems to correctly rewrite the info as expected. If you find an image that really doesn't work of it is specific to older php versions then feel free to reopen. [2004-11-04 00:09:11] bosse at mellberg dot org Example pictures can be found here: http://www.mellberg.org/exif_thumbnail [2004-11-03 21:12:46] [EMAIL PROTECTED] I need such an image because i don't have Exifer. [2004-11-03 15:15:03] bosse at mellberg dot org Description: Using the script in the documentation for exif_thumbnail, you can extract the thumbnail image from the exif-header. If you alter the exif-information (f.ex. delete the thumbnail and add it again) using Exifer, the exif_thumbnail function will no longer be able to find the thumbnail. According to the author of Exifer, this is likely because exif_thumbnail doesn't handle offsets to the thumbnail properly. -- Edit this bug report at http://bugs.php.net/?id=30672edit=1
#30672 [Opn-Csd]: Problem handling exif data in jpeg images at unusual places
ID: 30672 Updated by: [EMAIL PROTECTED] Reported By: bosse at mellberg dot org -Status: Open +Status: Closed Bug Type: *Graphics related Operating System: * PHP Version: 4.3.9, 5.0.2 Assigned To: helly New Comment: This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. After trying something more i actually really found a problem. Newer Exif versions allow data storage at places older versions didn't allow for JPEG images. Removing that check fixed your problem. Since the check is in general not really necessary i simply allow such out of space data for JPEG, too. However as already mentioned you could have got your thumbnail data anyway. Previous Comments: [2004-11-04 21:12:41] [EMAIL PROTECTED] Reopen and set the summary to the real cause. You can already get your thumbnails when ignoring the warnign. [2004-11-04 00:57:29] [EMAIL PROTECTED] Well it looks like you exchanged working/non working, however both are pretty fine using HEAD. If you want to verify yourself then doenload php source and edit ext/exif/exif.c and change the line #undef EXIF_DEBUG into #define EXIF_DEBUG. Then you'll see all details of the decoding process. The test script i used was: php -r 'file_put_contents($argv[1]..thumb.jpg, exif_thumbnail($argv[1]));' filename.jpg and then i looked at the generated file and both are fine. To Exifer i can only say it seems to correctly rewrite the info as expected. If you find an image that really doesn't work of it is specific to older php versions then feel free to reopen. [2004-11-04 00:09:11] bosse at mellberg dot org Example pictures can be found here: http://www.mellberg.org/exif_thumbnail [2004-11-03 21:12:46] [EMAIL PROTECTED] I need such an image because i don't have Exifer. [2004-11-03 15:15:03] bosse at mellberg dot org Description: Using the script in the documentation for exif_thumbnail, you can extract the thumbnail image from the exif-header. If you alter the exif-information (f.ex. delete the thumbnail and add it again) using Exifer, the exif_thumbnail function will no longer be able to find the thumbnail. According to the author of Exifer, this is likely because exif_thumbnail doesn't handle offsets to the thumbnail properly. -- Edit this bug report at http://bugs.php.net/?id=30672edit=1
#30112 [Csd]: Crash when __ToString() called from object with undefined property
ID: 30112
User updated by: jw at jwscripts dot com
Reported By: jw at jwscripts dot com
Status: Closed
Bug Type: Reproducible crash
Operating System: *
PHP Version: 5.0.2
New Comment:
Works as expected now, thanks!
Previous Comments:
[2004-11-04 13:54:07] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
Now prints out:
Fatal error: Method Foo::__toString() must return a string value in
/usr/home/thekid/test.php on line 14
[2004-09-27 14:08:19] ante dot dfg at moj dot net
I can confirm this on Win XP sp1 using Apache 1.3.31 and php 5.0.2
szAppName : Apache.exe szAppVer : 0.0.0.0 szModName :
php5ts.dll
szModVer : 5.0.2.2 offset : 0004e27f
[2004-09-25 14:40:42] [EMAIL PROTECTED]
#0 0x08136dc9 in zend_get_class_entry (zobject=0x81f735c)
at /home/johannes/src/php/php-5.0.2/Zend/zend_API.c:204
#1 0x0814d413 in zend_std_cast_object_tostring
(readobj=0x81f735c,
writeobj=0xbfffca40, type=3, should_free=0)
at /home/johannes/src/php/php-5.0.2/Zend/zend_object_handlers.c:938
#2 0x0815bd96 in zend_echo_handler
(execute_data=0xbfffcbb0,
opline=0x81f57a0, op_array=0x81f124c)
at /home/johannes/src/php/php-5.0.2/Zend/zend_execute.c:1984
#3 0x0815be3c in zend_print_handler
(execute_data=0xbfffcbb0,
opline=0x81f57a0, op_array=0x81f124c)
at /home/johannes/src/php/php-5.0.2/Zend/zend_execute.c:2002
#4 0x0815ab28 in execute (op_array=0x81f124c)
at /home/johannes/src/php/php-5.0.2/Zend/zend_execute.c:1400
#5 0x081365bf in zend_execute_scripts (type=8,
retval=0x0, file_count=3)
at /home/johannes/src/php/php-5.0.2/Zend/zend.c:1060
#6 0x080f0edc in php_execute_script
(primary_file=0xbfffeff0)
at /home/johannes/src/php/php-5.0.2/main/main.c:1629
#7 0x0816775a in main (argc=1, argv=0xb094)
at /home/johannes/src/php/php-5.0.2/sapi/cli/php_cli.c:943
[2004-09-25 13:33:35] jw at jwscripts dot com
Bug persists in version 5.0.2, the notice and fatal error are not
displayed (crash is more severe).
[2004-09-16 13:39:45] jw at jwscripts dot com
Description:
When the __toString() method is called from a returned object to return
an undefined property, Apache 2.0.48 crashes.
Reproduce code:
---
?
class Foo {
public function doSomething() {
return new Foo;
}
public function __toString () {
return $this-undefined;
}
}
$foo = new Foo;
print $foo-doSomething();
?
Expected result:
Notice: Undefined property: Foo::$undefined
Fatal error: Method Foo::__toString() must return a string value
Actual result:
--
Apache Crash:
=
szAppName : Apache.exe szAppVer : 2.0.48.0
szModName : php5ts.dll
szModVer : 5.0.1.1 offset : 0004dd7f
+ the above messages
--
Edit this bug report at http://bugs.php.net/?id=30112edit=1
#30668 [Bgs-Opn]: error_log ini inconsistent
ID: 30668
User updated by: kauschovar at sdk dot ath dot cx
Reported By: kauschovar at sdk dot ath dot cx
-Status: Bogus
+Status: Open
Bug Type: *General Issues
Operating System: Linux
PHP Version: 4.3.9
New Comment:
You're right about ini_get(). But the fact is that PHP is still
logging to the wrong log file. Furthermore, it's inconsistent between
Apache 1 and Apache 2. It doesn't work *at all* with Apache 1 (the
version of Apache recommended by the PHP team).
Previous Comments:
[2004-11-04 08:49:12] [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.
Use ini_get() instead of get_cfg_var() as the latter always returns
values from php.ini and will not show values altered with ini_set().
[2004-11-03 00:47:51] kauschovar at sdk dot ath dot cx
Description:
The php.ini setting 'error_log' doesn't seem to behave according to its
description in the manual:
http://www.php.net/manual/en/ref.errorfunc.php. It also does not
behave consistently between Apache 1.3 and Apache 2.
In both versions of Apache, 'error_log' can not be overridden in
httpd.conf, .htaccess, or by ini_set(). The example script below
demonstrates that. Only changes made to php.ini seem to be recognized.
This contradicts the manual, which says that 'error_log' has a
changeable property of PHP_INI_ALL, meaning that it can be changed in
any of the places I mentioned above.
In Apache 2, if 'error_log' is set in php.ini then it will log to the
appropriate file, but it will still not recognize changes made in any
other fashion.
In Apache 1.3, PHP will always log to Apache's error_log
(/var/log/apache/error_log on my system) regardless of what 'error_log'
is set to. Considering the stern warning against using Apache 2
(http://www.php.net/manual/en/faq.installation.php#faq.installation.apache2),
I think making 'error_log' work with Apache 1 is important.
Of course, 'log_errors' is enabled during all of this, I restarted
Apache every time I changed a setting in php.ini, httpd.conf or
.htaccess, and I made sure that the specified log file was writable by
apache (indeed it successfully wrote to it when testing Apache 2, so I
know that permissions are okay).
I tested this on two different machines with both Apache 1 and Apache
2, but both machines are running Gentoo Linux. I don't have a machine
with a different Operating system to confirm this bug with.
Reproduce code:
---
?php
echo 'pre';
ini_set('error_log', 'php_error_log');
var_dump(get_cfg_var('error_log'));
echo '/pre';
// 404.html doesn't exist. This will trigger an error which is
// supposed to be logged to the file set by 'error_log'
require_once '404.html';
?
Expected result:
Excepted to see a warning about PHP failing to open 404.html in my log
file set by 'error_log'. Also, expected to be able to override the
value set by php.ini in httpd.conf, .htaccess, or by ini_set().
Actual result:
--
From the var_dump():
string(39) /var/www/localhost/htdocs/phperrors.log
... which is the value I set in my php.ini.
Additionally (with Apache 1.3), I expected to see Warning:
main(404.html): failed to open stream and Fatal error: main(): Failed
opening required '404.html' in phperrors.log, but instead they appeared
in Apache's error_log.
--
Edit this bug report at http://bugs.php.net/?id=30668edit=1
#30668 [Opn-Bgs]: error_log ini inconsistent
ID: 30668
User updated by: kauschovar at sdk dot ath dot cx
Reported By: kauschovar at sdk dot ath dot cx
-Status: Open
+Status: Bogus
Bug Type: *General Issues
Operating System: Linux
PHP Version: 4.3.9
New Comment:
Nevermind. I rebuilt PHP manually (instead of using Gentoo's packaging
system), and it seems to be working now. Although I did have to look
through the C code for php_log_err() before I could get it to work.
Anyways, I'm re-closing this bug report while I track down the source
of the original error since it doesn't seem to be a bug in PHP. Sorry
to bother you.
Previous Comments:
[2004-11-04 23:06:14] kauschovar at sdk dot ath dot cx
You're right about ini_get(). But the fact is that PHP is still
logging to the wrong log file. Furthermore, it's inconsistent between
Apache 1 and Apache 2. It doesn't work *at all* with Apache 1 (the
version of Apache recommended by the PHP team).
[2004-11-04 08:49:12] [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.
Use ini_get() instead of get_cfg_var() as the latter always returns
values from php.ini and will not show values altered with ini_set().
[2004-11-03 00:47:51] kauschovar at sdk dot ath dot cx
Description:
The php.ini setting 'error_log' doesn't seem to behave according to its
description in the manual:
http://www.php.net/manual/en/ref.errorfunc.php. It also does not
behave consistently between Apache 1.3 and Apache 2.
In both versions of Apache, 'error_log' can not be overridden in
httpd.conf, .htaccess, or by ini_set(). The example script below
demonstrates that. Only changes made to php.ini seem to be recognized.
This contradicts the manual, which says that 'error_log' has a
changeable property of PHP_INI_ALL, meaning that it can be changed in
any of the places I mentioned above.
In Apache 2, if 'error_log' is set in php.ini then it will log to the
appropriate file, but it will still not recognize changes made in any
other fashion.
In Apache 1.3, PHP will always log to Apache's error_log
(/var/log/apache/error_log on my system) regardless of what 'error_log'
is set to. Considering the stern warning against using Apache 2
(http://www.php.net/manual/en/faq.installation.php#faq.installation.apache2),
I think making 'error_log' work with Apache 1 is important.
Of course, 'log_errors' is enabled during all of this, I restarted
Apache every time I changed a setting in php.ini, httpd.conf or
.htaccess, and I made sure that the specified log file was writable by
apache (indeed it successfully wrote to it when testing Apache 2, so I
know that permissions are okay).
I tested this on two different machines with both Apache 1 and Apache
2, but both machines are running Gentoo Linux. I don't have a machine
with a different Operating system to confirm this bug with.
Reproduce code:
---
?php
echo 'pre';
ini_set('error_log', 'php_error_log');
var_dump(get_cfg_var('error_log'));
echo '/pre';
// 404.html doesn't exist. This will trigger an error which is
// supposed to be logged to the file set by 'error_log'
require_once '404.html';
?
Expected result:
Excepted to see a warning about PHP failing to open 404.html in my log
file set by 'error_log'. Also, expected to be able to override the
value set by php.ini in httpd.conf, .htaccess, or by ini_set().
Actual result:
--
From the var_dump():
string(39) /var/www/localhost/htdocs/phperrors.log
... which is the value I set in my php.ini.
Additionally (with Apache 1.3), I expected to see Warning:
main(404.html): failed to open stream and Fatal error: main(): Failed
opening required '404.html' in phperrors.log, but instead they appeared
in Apache's error_log.
--
Edit this bug report at http://bugs.php.net/?id=30668edit=1
#30602 [Fbk-NoF]: Oracle 10.1 version not found
ID: 30602 Updated by: [EMAIL PROTECTED] Reported By: walexander at corp dot infi dot net -Status: Feedback +Status: No Feedback Bug Type: *Compile Issues Operating System: Linux PHP Version: 4.3.9 New Comment: No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to Open. Previous Comments: [2004-10-28 18:09:05] [EMAIL PROTECTED] ext/oci8/config.m4 already has this line, so you probably have some mess with sources. run ./buildconf --force and those lines should appear in ./configure too. [2004-10-28 18:02:57] walexander at corp dot infi dot net Description: There appears to be a problem w/ configure when attempting to use Oracle 10.1 client libraries. There appears to be two other bug reports related to the ext/oci8/oci8.c and ext/oci8/config.m4 which were both patched in #27093 and #27117; However it does not appear that configure was fixed. I get the following errors when compiling with the --with-oracle=/usr/lib/oracle/10.1.0.2/client --with-oci8=/usr/lib/oracle/10.1.0.2/client: configure: error: Unspported Oracle version!. I was able to resolve this using the diff -cw output below in the configure file. Thanks, Will Alexander Reproduce code: --- *** configure 2004-09-20 18:31:33.0 -0400 --- configure.will 2004-10-28 11:57:56.0 -0400 *** *** 61614,61619 --- 61614,61621 if test -s $ORACLE_DIR/orainst/unix.rgs; then ORACLE_VERSION=`grep 'ocommon' $ORACLE_DIR/orainst/unix.rgs | sed 's/ */:/g' | cut -d: -f 6 | cut -c 2-4` test -z $ORACLE_VERSION ORACLE_VERSION=7.3 + elif test -f $ORACLE_DIR/lib/libclntsh.$SHLIB_SUFFIX_NAME.10.1; then + ORACLE_VERSION=10.1 elif test -f $ORACLE_DIR/lib/libclntsh.$SHLIB_SUFFIX_NAME.9.0; then ORACLE_VERSION=9.0 elif test -f $ORACLE_DIR/lib/libclntsh.$SHLIB_SUFFIX_NAME.8.0; then *** *** 65990,65996 ;; ! 8.1|9.0) case clntsh in --- 65992,65998 ;; ! 8.1|9.0|10.1) case clntsh in -- Edit this bug report at http://bugs.php.net/?id=30602edit=1
#30690 [NEW]: Resource handle from ibase_execute becomes invalid after return
From: kobaz at kobaz dot net
Operating system: Linux 2.6.5
PHP version: 4.3.9
PHP Bug Type: InterBase related
Bug description: Resource handle from ibase_execute becomes invalid after return
Description:
Resource handle from ibase_execute becomes invalid after return
Reproduce code:
---
$conn = ibase_connect('localhost:db', 'SYSDBA', 'pass');
function DB_PQuery ($sql, $data) {
global $conn;
$prepare = ibase_prepare($conn, $sql);
$result = ibase_execute($prepare, $data);
//$A = ibase_fetch_assoc($result); // uncommenting this will show
resource is valid here
//print_r($A);
// after this function returns, the return value is no longer a valid
resource
return $result;
}
$result = DB_PQuery(SELECT * FROM testing WHERE a = ?, '1');
$A = ibase_fetch_assoc($result); // fails with: invalid statement handle
print_r($A);
Expected result:
The ibase_fetch_assoc should be successful after DB_PQuery returns.
Actual result:
--
Before DB_PQuery returns, $result is a valid resource handle that can be
used with ibase_fetch_assoc successfully.
After DB_PQuery returns, the return value is not a valid resource handle
despite that nothing in the script has modified it.
--
Edit bug report at http://bugs.php.net/?id=30690edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=30690r=trysnapshot4
Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=30690r=trysnapshot50
Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=30690r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=30690r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=30690r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=30690r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=30690r=needscript
Try newer version: http://bugs.php.net/fix.php?id=30690r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=30690r=support
Expected behavior: http://bugs.php.net/fix.php?id=30690r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=30690r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=30690r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=30690r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=30690r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=30690r=dst
IIS Stability: http://bugs.php.net/fix.php?id=30690r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=30690r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=30690r=float
MySQL Configuration Error: http://bugs.php.net/fix.php?id=30690r=mysqlcfg
