#33271 [NEW]: Session file not deleted when php-win exits
From: neo_in_matrix at msn dot com Operating system: Windows XP PRO/SP2 PHP version: 5.0.4 PHP Bug Type: Session related Bug description: Session file not deleted when php-win exits Description: Though it is a bit strange for me to find that php-win also has session support ($_SESSION), but it is even more strange for to find that when php-win exits, the session file is not deleted. Reproduce code: --- This is what I have in php.ini in %windir%: session.save_path = "d:/temp/apache/session" And my simple script is like this: $_SESSION['test'] = 123; Expected result: This script creates a session file (such as sess_b003da224c2d5c1d50a9a8c95725ddca) in d:/temp/apache/session. When the script terminates, I think php-win should delete the create session file, since it is not like php-cgi that has a session timeout. Once a script terminates, its session should be considered 'destroyed'. Actual result: -- Session file is not deleted. -- Edit bug report at http://bugs.php.net/?id=33271&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33271&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=33271&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=33271&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=33271&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=33271&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=33271&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=33271&r=needscript Try newer version: http://bugs.php.net/fix.php?id=33271&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=33271&r=support Expected behavior: http://bugs.php.net/fix.php?id=33271&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=33271&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=33271&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=33271&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33271&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=33271&r=dst IIS Stability: http://bugs.php.net/fix.php?id=33271&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=33271&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=33271&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=33271&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=33271&r=mysqlcfg
#30820 [Asn->Csd]: static member conflict with $this->member silently ignored
ID: 30820 Updated by: [EMAIL PROTECTED] Reported By: levi at alliancesoftware dot com dot au -Status: Assigned +Status: Closed Bug Type: Zend Engine 2 problem Operating System: * PHP Version: 5CVS-2005-03-06 Assigned To: andi New Comment: Fixed in CVS HEAD and PHP_5_0. Previous Comments: [2004-11-18 02:40:09] levi at alliancesoftware dot com dot au Description: If you declare a static data member (eg x), $this->x refers to a different variable without generating any warnings. Arguably, the proper behavior when setting a class variable through $this should first be to check if there are any static member variables of the same name and *then* check for instantiated member variables. Reproduce code: --- #!/usr/local/bin/php5 -q x = 5; // no warning, but refers to different variable echo ' Blah::$x = '. Blah::$x ."\n"; echo '$ this->x = '. $this->x ."\n"; } } $b = new Blah(); $b->show(); ?> Expected result: either: (preferable) Blah::$x = 5 $this->x = 5 -or- at the minimum, display a warning Actual result: -- Blah::$x = 1 $this->x = 5 -- Edit this bug report at http://bugs.php.net/?id=30820&edit=1
#33272 [NEW]: fail build php5 whith oracle 9i 64bits
From: denis dot delamarre at chu-rennes dot fr Operating system: solaris 2.10 PHP version: 5.0.3 PHP Bug Type: *Compile Issues Bug description: fail build php5 whith oracle 9i 64bits Description: build php with : ./configure --with-oracle=/prod/dba/oracle9i --with-oci8=/prod/dba/oracle9i --with-apxs=/usr/local/apache/bin/apxs --with-zlib --with-gd make fail with ld: fatal : fichier libclntsh.so : wrong elf class : ELFCLASS64 -- Edit bug report at http://bugs.php.net/?id=33272&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33272&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=33272&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=33272&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=33272&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=33272&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=33272&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=33272&r=needscript Try newer version: http://bugs.php.net/fix.php?id=33272&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=33272&r=support Expected behavior: http://bugs.php.net/fix.php?id=33272&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=33272&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=33272&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=33272&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33272&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=33272&r=dst IIS Stability: http://bugs.php.net/fix.php?id=33272&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=33272&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=33272&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=33272&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=33272&r=mysqlcfg
#32322 [Opn->Csd]: Return values by reference broken( using self::),example singleton instance
ID: 32322
Updated by: [EMAIL PROTECTED]
Reported By: rickd at commando-pernod dot net
-Status: Open
+Status: Closed
Bug Type: Zend Engine 2 problem
Operating System: Win2000
PHP Version: 5CVS-2005-03-19
New Comment:
This bug is already fixed in CVS HEAD and PHP_5_0.
Previous Comments:
[2005-03-20 06:07:13] rickd at commando-pernod dot net
myname = $value;
}
private function __clone() {}
static public function getInstance()
{
if ( self::$instance == null )
{
self::$instance = new test('Singleton1');
}
else {
echo "Using old class " . self::$instance -> myname .
"\n";
}
return self::$instance;
}
static public function getInstance2()
{
static $instance2 = null;
if ( $instance2 == null )
{
$instance2 = new test('Singleton2');
}
else {
echo "Using old class " . $instance2 -> myname . "\n";
}
return $instance2;
}
public function __destruct()
{
if ( defined('SCRIPT_END') )
{
echo "Class " . $this -> myname . " destroyed at script end
\n";
} else {
echo "Class " . $this -> myname . " destroyed beforce
script end \n";
}
}
}
echo "Try static instance inside class :\n";
$getCopyofSingleton= test::getInstance();
$getCopyofSingleton= null;
$getCopyofSingleton= &test::getInstance();
$getCopyofSingleton= null;
$getCopyofSingleton= test::getInstance();
echo "Try static instance inside function :\n";
$getCopyofSingleton2 = test::getInstance2();
$getCopyofSingleton2 = null;
$getCopyofSingleton2 = &test::getInstance2();
$getCopyofSingleton2 = null;
$getCopyofSingleton2 = test::getInstance2();
define('SCRIPT_END',1);
?>
Current result :
Try static instance inside class :
New class Singleton1 created
Using old class Singleton1
Class Singleton1 destroyed beforce script end
New class Singleton1 created
Try static instance inside function :
New class Singleton2 created
Using old class Singleton2
Using old class Singleton2
Class Singleton1 destroyed at script end
Class Singleton2 destroyed at script end
Expected result :
Try static instance inside class :
New class Singleton1 created
Using old class Singleton1
Using old class Singleton1
Try static instance inside function :
New class Singleton2 created
Using old class Singleton2
Using old class Singleton2
Class Singleton1 destroyed at script end
Class Singleton2 destroyed at script end
php setting :
allow_call_time_pass_reference Off Off
zend.ze1_compatibility_mode Off Off
What i mean whats going wrong :
to return a variable by reference, you need to define the callerĀ“s code
and function code with a & prefix, but it seems when you use the self::
and parent:: as return values
this is broken, only caller need a & prefix, that is what i mean
[2005-03-19 21:49:04] [EMAIL PROTECTED]
Please provide an example script that actually returns something. And
give the expected / actual results too.
[2005-03-15 19:54:01] rickd at commando-pernod dot net
Description:
We use a user singleton instance for our cms user authed ids that
should not be able to killed from third party addons or worse coders so
easily, but accessable from all.
But when someone get the instance with reference it can be killed easy
with setting the reference var to null, unset dont work.
If you put the static $instance holder inside the getinstance()
function it seems to be work correct and cant be deleted from setting
reference to NULL
Reproduce code:
---
class test {
static private $instance = null;
static function getinstance() {
if ( self::$instance == null ) {
return new test();
}
return self::$instance;
}
}
$user = &test::getinstance();
$user = null; // destroy singleton instance
$user = &test::getinstance();
unset( $user ); // dont destroy instance
Expected result:
singleton not destroying with setting a getted instance with
reference to null
Actual result:
--
singleton destroyed
--
Edit this bug report at http://bugs.php.net/?id=32322&edit=1
#33273 [NEW]: Use of certain kanji characters make PHP crash
From: lars dot jensen at careercross dot com Operating system: FreeBSD 5.3 PHP version: 5.0.3 PHP Bug Type: Arrays related Bug description: Use of certain kanji characters make PHP crash Description: Certain Kanji direct in source seems to be a problem - wanted to use a small array for some simple language changes between english / japanese, but with these given kanji's it fail. Viewing the Kanji's as ascii, they both hold " in it, but closing the array strings using ', it shouldnt affect the strings. Example provided at http://www.ebenkyo.com/bug.php / Lars Reproduce code: --- As the code holds kanji characters, use this page to see the source. Please ensure to see the page using shift_jis encoding http://www.ebenkyo.com/bug_source.php Expected result: The array not to fail with given Kanji's. Most Kanji sequences seem to work. Actual result: -- Parse error: parse error, unexpected T_STRING, expecting ')' in /usr/local/www/www.ebenkyo.com/bug.php on line 4 or similar -- Edit bug report at http://bugs.php.net/?id=33273&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33273&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=33273&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=33273&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=33273&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=33273&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=33273&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=33273&r=needscript Try newer version: http://bugs.php.net/fix.php?id=33273&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=33273&r=support Expected behavior: http://bugs.php.net/fix.php?id=33273&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=33273&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=33273&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=33273&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33273&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=33273&r=dst IIS Stability: http://bugs.php.net/fix.php?id=33273&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=33273&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=33273&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=33273&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=33273&r=mysqlcfg
#30140 [WFx->Asn]: Problem with array in static properties
ID: 30140
Updated by: [EMAIL PROTECTED]
Reported By: guth at fiifo dot u-psud dot fr
-Status: Wont fix
+Status: Assigned
Bug Type: Zend Engine 2 problem
Operating System: *
PHP Version: 5CVS-2005-05-07
-Assigned To: andi
+Assigned To: dmitry
New Comment:
No this is another bug. The problem is in zval_update_constant().
Reproduce code:
---
Expected result:
string(1) "x"
string(1) "y"
string(1) "z"
string(1) "x"
string(1) "y"
string(1) "z"
Actual result:
--
string(1) "x"
string(1) "y"
string(1) "z"
bool(true)
array(0) {
}
string(1) "z"
Previous Comments:
[2005-05-17 16:27:37] [EMAIL PROTECTED]
It's definitely duplicate for bug #30934.
[2005-05-09 11:34:31] [EMAIL PROTECTED]
This same thing happens with boolean too. All other types behave
correctly (or incorrectly, not sure anymore :)
Andi, (or Dmitry maybe?) can you look into this?
[2005-04-05 23:24:10] [EMAIL PROTECTED]
Yet another duplicate of bug #30934.
[2004-09-18 17:02:22] guth at fiifo dot u-psud dot fr
Description:
[ sorry for english ]
There is a problem with static properties initialized as
an array in classes.
In the following code, if you replace "public static $test
= array();" by "public static $test;" or if you initialize
the property with not an array ("public static $test =
12;" for example), it works as expected.
Reproduce code:
---
set(array('key' => 'value'));
A::view();
B::view();
?>
Expected result:
array(1) { ["key"]=> string(5) "value" }
array(1) { ["key"]=> string(5) "value" }
Actual result:
--
array(1) { ["key"]=> string(5) "value" }
array(0) { }
--
Edit this bug report at http://bugs.php.net/?id=30140&edit=1
#33274 [NEW]: Class extended from MySQLi mangles members on calling parent method
From: flying dot mushroom at gmail dot cp,
Operating system: Linux
PHP version: 5.0.3
PHP Bug Type: MySQLi related
Bug description: Class extended from MySQLi mangles members on calling parent
method
Description:
A class that extends mysqli, if passing its own members directly to the
parent constructor, will have those members mangled after the call.
Assigning member values to local variables and then passing those to the
parent solves the problem on for the user, but the above behaviour
shouldn't happen...?
(Replacing the line "parent::__construct($this->p_host, $this->p_uname,
$this->p_password);" with "parent::__construct($host, $username,
$password);" produces the expected result.)
This same problem is reported on the comment by hans at lintoo dot dk on
http://www.php.net/manual/en/ref.mysqli.php
Reproduce code:
---
p_host = $host;
$this->p_uname= $username;
$this->p_password = $password;
parent::__construct($this->p_host, $this->p_uname,
$this->p_password);
}
}
var_dump(new db_mysql('localhost', 'username', 'password'));
?>
Expected result:
object(db_mysql)#1 (3) {
["p_host:private"]=>
string(9) "localhost"
["p_uname:private"]=>
string(8) "username"
["p_password:private"]=>
string(8) "password"
}
Actual result:
--
object(db_mysql)#1 (3) {
["p_host:private"]=>
string(9) "localhost"
["p_uname:private"]=>
string(8) "username"
["p_password:private"]=>
NULL
}
--
Edit bug report at http://bugs.php.net/?id=33274&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33274&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=33274&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=33274&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=33274&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=33274&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=33274&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=33274&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=33274&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=33274&r=support
Expected behavior: http://bugs.php.net/fix.php?id=33274&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=33274&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=33274&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=33274&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33274&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=33274&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=33274&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=33274&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=33274&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=33274&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=33274&r=mysqlcfg
#33272 [Opn->Fbk]: fail build php5 whith oracle 9i 64bits
ID: 33272 Updated by: [EMAIL PROTECTED] Reported By: denis dot delamarre at chu-rennes dot fr -Status: Open +Status: Feedback Bug Type: *Compile Issues Operating System: solaris 2.10 PHP Version: 5.0.3 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 Previous Comments: [2005-06-08 10:17:58] denis dot delamarre at chu-rennes dot fr Description: build php with : ./configure --with-oracle=/prod/dba/oracle9i --with-oci8=/prod/dba/oracle9i --with-apxs=/usr/local/apache/bin/apxs --with-zlib --with-gd make fail with ld: fatal : fichier libclntsh.so : wrong elf class : ELFCLASS64 -- Edit this bug report at http://bugs.php.net/?id=33272&edit=1
#31222 [Bgs->Opn]: ocicommit not working
ID: 31222 User updated by: amonw at hotmail dot com Reported By: amonw at hotmail dot com -Status: Bogus +Status: Open Bug Type: OCI8 related Operating System: * PHP Version: 4CVS-2005-04-04 Assigned To: tony2001 New Comment: I've read your reply and thank you for trying. But I already mentioned this in the bug description: "The oddest thing is I can avoid this by doing any one of the following: 1. don't use the user defined function "query", and used it's content to replace the function calls ..." (please refer to the first comment I wrote) I know ocicommit does work fine if I code it in other ways,including the 4 methods I mentioned in the bug description. I just don't understand why it doesn't work in my case. Can you explain it? Thank you again. Previous Comments: [2005-06-02 15:17:47] [EMAIL PROTECTED] Tested and replied to you. ocicommit() works fine as I've already told you before. Even if there is an issue, it has nothing to do with ocicommit() and oci8. [2005-05-25 06:36:18] amonw at hotmail dot com I've built a test system and sent the information about it to [EMAIL PROTECTED] You can ssh2 to it and reproduce the problem. Thank you. [2005-05-23 10:13:25] [EMAIL PROTECTED] I can't fix something that I can't reproduce. ocicommit() works just PERFECTLY for me and for others, and the version of PHP doesn't really matter here. [2005-05-23 04:42:23] amonw at hotmail dot com I tried php5 yesterday and the problem doesn't exists. So can you fix it in php4? Thanks. [2005-05-18 00:14:03] [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 We really need to know if this is fixed in HEAD, so please try the snapshot. Nobody is telling you should put it on PRODUCTION machine. You do have some test/dev machines?! 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/31222 -- Edit this bug report at http://bugs.php.net/?id=31222&edit=1
#33271 [Opn->Bgs]: Session file not deleted when php-win exits
ID: 33271 Updated by: [EMAIL PROTECTED] Reported By: neo_in_matrix at msn dot com -Status: Open +Status: Bogus Bug Type: Session related Operating System: Windows XP PRO/SP2 PHP Version: 5.0.4 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 I don't see any reason to change current behaviour of session garbage collector. Read about it here: http://php.net/session Previous Comments: [2005-06-08 10:03:10] neo_in_matrix at msn dot com Description: Though it is a bit strange for me to find that php-win also has session support ($_SESSION), but it is even more strange for to find that when php-win exits, the session file is not deleted. Reproduce code: --- This is what I have in php.ini in %windir%: session.save_path = "d:/temp/apache/session" And my simple script is like this: $_SESSION['test'] = 123; Expected result: This script creates a session file (such as sess_b003da224c2d5c1d50a9a8c95725ddca) in d:/temp/apache/session. When the script terminates, I think php-win should delete the create session file, since it is not like php-cgi that has a session timeout. Once a script terminates, its session should be considered 'destroyed'. Actual result: -- Session file is not deleted. -- Edit this bug report at http://bugs.php.net/?id=33271&edit=1
#31222 [Opn->Bgs]: ocicommit not working
ID: 31222 Updated by: [EMAIL PROTECTED] Reported By: amonw at hotmail dot com -Status: Open +Status: Bogus Bug Type: OCI8 related Operating System: * PHP Version: 4CVS-2005-04-04 Assigned To: tony2001 New Comment: amonw at hotmail dot com: If there is an issue with reference counting, ocicommit() still has NO PROBLEM. As you can see yourself, ocicommit() IS working and IF there is a different issue, it has nothing to do with Oracle, OCI8 and ocicommit(). Please stop reopening this particular report. Thank you. Also there was big patch committed to the 4.4 branch recently, that fixes a lot of reference related problems. So please try latest 4.4 snapshot and tell us the results. Previous Comments: [2005-06-08 12:28:19] amonw at hotmail dot com I've read your reply and thank you for trying. But I already mentioned this in the bug description: "The oddest thing is I can avoid this by doing any one of the following: 1. don't use the user defined function "query", and used it's content to replace the function calls ..." (please refer to the first comment I wrote) I know ocicommit does work fine if I code it in other ways,including the 4 methods I mentioned in the bug description. I just don't understand why it doesn't work in my case. Can you explain it? Thank you again. [2005-06-02 15:17:47] [EMAIL PROTECTED] Tested and replied to you. ocicommit() works fine as I've already told you before. Even if there is an issue, it has nothing to do with ocicommit() and oci8. [2005-05-25 06:36:18] amonw at hotmail dot com I've built a test system and sent the information about it to [EMAIL PROTECTED] You can ssh2 to it and reproduce the problem. Thank you. [2005-05-23 10:13:25] [EMAIL PROTECTED] I can't fix something that I can't reproduce. ocicommit() works just PERFECTLY for me and for others, and the version of PHP doesn't really matter here. [2005-05-23 04:42:23] amonw at hotmail dot com I tried php5 yesterday and the problem doesn't exists. So can you fix it in php4? Thanks. 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/31222 -- Edit this bug report at http://bugs.php.net/?id=31222&edit=1
#33268 [Csd->Opn]: iconv_strlen works only with a parameter of < 3 in length
ID: 33268 User updated by: markus dot lervik at necora dot fi Reported By: markus dot lervik at necora dot fi -Status: Closed +Status: Open Bug Type: ICONV related Operating System: SuSE Linux 9.2 PHP Version: 5.0.3 New Comment: My initial bug report regarded 5.0.3 and the latest HEAD from yesterday (2005-06-07). I do still get the same problem with latest 5.1 (php-src) from CVS (checked out just 15 minutes ago, 2005-06-08), both with the glibc-provided iconv and the external libiconv (version 1.9.2) Notice: iconv_strlen() [function.iconv-strlen]: Unknown error (2) in /usr/local/apache/htdocs/test2.php on line 2 bool(false) Notice: iconv_strlen() [function.iconv-strlen]: Unknown error (2) in /usr/local/apache/htdocs/test2.php on line 5 bool(false) Notice: iconv_strlen() [function.iconv-strlen]: Unknown error (2) in /usr/local/apache/htdocs/test2.php on line 8 bool(false) int(3) int(4) Previous Comments: [2005-06-08 02:38:56] [EMAIL PROTECTED] And in HEAD (upcoming 5.1) there is no problem. [2005-06-08 00:51:52] scott at slerman dot net I confirmed this problem on Fedora using PHP 5.0.4 and Apache 2.0.54. On Windows/PHP 5.0.4 I get Notice: iconv_strlen(): Unknown error (9) in C:\PHP\test\iconv.php on line 1 On Fedora/PHP 5.0.4 CLI I get Notice: iconv_strlen(): Unknown error (25) in /home/scott/test files/iconv.php on line 1 [2005-06-08 00:28:48] markus dot lervik at necora dot fi Description: iconv_strlen seems to have a peculiar bug. It doesn't work when the string searched is less than three characters long (or an empty string), but reports Notice: iconv_strlen() [function.iconv-strlen]: Unknown error (2) in /usr/local/apache/htdocs/test2.php on line 7 This is tested on PHP 5.0.3 and 5.1 from CVS (2005-06-07), tested with the built-in (glibc 2.3.3) iconv and libiconv 1.9.2 from gnu.org. This problem doesn't seem to surface on my Debian 3.1 development server, but I get it on my SuSE 9.2 desktop. I have tried to set the encodings with iconv_set_encoding() and I have tried to set the encoding as a parameter to iconv_strlen(), both produce the same error. The other iconv-functions (iconv_strpos, iconv_substr, iconv_strrpos) work fine. Since the iconv-functions do not seem to work from the commandline (produces an Unknown error(29)), I cannot get a proper strace (strace seems to say that iconv is trying to seek on /dev/pts/5, which apparently is impossible). It doesn't crash apache either, so I'm not sure where I'd grab the backtrace. List of modules: [EMAIL PROTECTED]:~> php -m [PHP Modules] bz2 ctype curl dom exif gd iconv libxml openssl pcre PDO pdo_sqlite pgsql posix session SimpleXML soap SPL standard tokenizer wddx xml xmlrpc xsl zlib [Zend Modules] PHP version: [EMAIL PROTECTED]:~> php --version PHP 5.1.0-dev (cli) (built: Jun 7 2005 21:30:37) (DEBUG) Copyright (c) 1997-2005 The PHP Group Zend Engine v2.1.0-dev, Copyright (c) 1998-2004 Zend Technologies configure line: './configure' '--with-apxs=/usr/local/apache/bin/apxs' '--with-openssl' '--with-curl' '--with-zlib' '--with-bz2' '--enable-exif' '--with-gd' '--with-pgsql=/usr' '--enable-soap' '--enable-wddx' '--without-sqlite' '--with-xmlrpc' '--with-xsl' '--with-jpeg-dir=/usr/local/' '--with-png-dir=/usr/local/' '--without-mysql' '--with-xslt-sablot' '--with-iconv=/usr/local/' '--enable-debug' Reproduce code: --- Expected result: bool(false) Actual result: -- Notice: iconv_strlen() [function.iconv-strlen]: Unknown error (2) in /usr/local/apache/htdocs/test2.php on line 2 bool(false) -- Edit this bug report at http://bugs.php.net/?id=33268&edit=1
#33275 [NEW]: strip_tags() strips everything after "<="
From: slawek at truxe dot com Operating system: Windows 2003 Server PHP version: 4.3.11 PHP Bug Type: Strings related Bug description: strip_tags() strips everything after "<=" Description: // strip_tags() strips everything after "<=" // strings like >= not affected // result of print $sql_query; select * from anytable where anycolumn // should be select * from anytable where anycolumn <= '10' Reproduce code: --- // strip_tags() strips everything after "<=" // strings like >= not affected Expected result: select * from anytable where anycolumn <= '10' Actual result: -- select * from anytable where anycolumn -- Edit bug report at http://bugs.php.net/?id=33275&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33275&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=33275&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=33275&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=33275&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=33275&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=33275&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=33275&r=needscript Try newer version: http://bugs.php.net/fix.php?id=33275&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=33275&r=support Expected behavior: http://bugs.php.net/fix.php?id=33275&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=33275&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=33275&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=33275&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33275&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=33275&r=dst IIS Stability: http://bugs.php.net/fix.php?id=33275&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=33275&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=33275&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=33275&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=33275&r=mysqlcfg
#25876 [Com]: session_start(): Failed to initialize storage module
ID: 25876 Comment by: tech at c64-wiki dot de Reported By: golden at riscom dot com Status: No Feedback Bug Type: Session related Operating System: freebsd 4.8 PHP Version: 4.3.9-4.3.10 Assigned To: sniper New Comment: Same problem here as described by "gul_murjani at yahoo dot com". PHP 4.3.10 is the version in use (phpinfo() can be seen at http://www.c64-wiki.de/test.php). I tried to change session.save_path to a different path (by adding a php_value line into .htaccess), made the new directory world-writeable and verified that the session files do indeed appear there. They do appear there, and there's plenty of space for that directoty available (about 1GB, should be 'nuff for a few of these session files with <100 bytes each). And the bug still appears at extremely random intervals! Best regards, Klaus Previous Comments: [2005-05-22 12:06:42] dmih at in-solve dot ru Please someone in PHP team confirm that you are reading from this bug (it has 'No Feedback' status). Or may be we are writing for ourselves here? [2005-05-21 14:30:13] gul_murjani at yahoo dot com Hi, I'm experiencing this problem in at least 2 sites. Since it's a error that appears in random, I wrote a simple script to try and reproduce the error. This is the script: All it does is invoke "session_start()" and use one session variable. It then reloads itself every 10 seconds. On HOSTMANIL.ORG and HOSTMANIL.NET, the error comes up. But there is no pattern at all. Sometimes out of 20 refreshes, there's an error, half the time. If the error comes up, I have to do a manual refresh. I notice that the session variable is not destroyed at all. It continues counting from where it stopped. The problem is at one point in HOSTMANILA.ORG, it kept on coming up every 2 auto refreshes (and I do an F5). But now, it's was good for 45 straign auto refreshes before the error came up. That's how random the error is. I do a lot of programming, mostly in PHP but I'm not "deep" technical. So I'm not sure if I'm missing something. I'm running the scripts on 5 sites. These are all on different servers although all of them are from shared hosting services using cPanel / WHM. http://www.hostmanila.org/test.php http://www.hostmanila.biz/test.php http://www.hostmanila.net/test.php http://www.vcdpix.com/test.php http://www.smokedbangus.com/test.php So far, it's only happened on HOSTMANILA.ORG and HOSTMANILA.NET. Here's the rundown on each site: HOSTMANILA.ORG (error) Linux 2.4.30-gator_r1 Apache 1.3.33 (Unix) PERL 5.8.4 PHP 4.3.11 cPanel 9.9.9-STABLE 15 HOSTMANILA.BIZ (fine) Linux 2.4.30-1-s5 Apache 1.3.33 (Unix) PERL 5.8.3 PHP 4.3.11 cPanel 10.2.0-RELEASE 82 HOSTMANILA.NET (error) Linux 2.4.26-grsec Apache 1.3.33 (Unix) PERL 5.8.0 PHP 4.3.11 cPanel 10.0.0-RELEASE 7 VCDPIX.COM (fine) Linux 2.4.20-24.9 Apache 1.3.33 (Unix) PERL 5.8.1 PHP 4.3.9 cPanel 10.0.0-RELEASE 7 SMOKEDBANGUS.COM (fine) Linux 2.4.20-20.7smp Apache 1.3.33 (Unix) PERL 5.8.4 PHP 4.3.10 cPanel 10.0.0-CURRENT 107 I can't imagine developing anything in PHP without making use of session_start() so I hope the issue is resolved. Regards, Gul hostmanila.com [2005-05-21 01:24:55] jspec at bellsouth dot net I have now experienced this beast with a completely different hosting company. They are both running 4.3.10 - is this fixed in 4.3.11? [2005-05-18 22:48:45] dmih at in-solve dot ru We (as hosting company) are hoping that PHP team will track this bug down some day. Indeed, we can do not much to help or to fix it. This bug is hard to fix because it appears randomly, and there is no definite recreate scenario. There is assumption that this is http://bugs.php.net/bug.php?id=32330 bug, but I am not completely sure. You may suggest your hosting company to lower average server load - it will help this bug to happen rarely or even at no times. Lower - I mean - something lower than 50% avg CPU load on 1CPU server or 80% on 2+ CPU server. But that is only our hosting company workaround, not the solution. [2005-05-17 18:00:36] jspec at bellsouth dot net My hosting company is unable to fix the random "Failed to initialize storage module" error and it is making my account unusable. They cannot seem to fix it. What is the story with this!? 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/25876 -- Edit this bug report at http://bugs.php.net/?id=25876&edit=1
#33271 [Bgs]: Session file not deleted when php-win exits
ID: 33271 User updated by: neo_in_matrix at msn dot com Reported By: neo_in_matrix at msn dot com Status: Bogus Bug Type: Session related Operating System: Windows XP PRO/SP2 PHP Version: 5.0.4 New Comment: Okay, I see I must call session_destory manually to let the session files delted. But, I think since it is not like what we need in Web server environment, php-win should call session_destory automatically when it exists, just like it cleans up opened file handles. Right? I hope my argument makes sense. Previous Comments: [2005-06-08 12:29:55] [EMAIL PROTECTED] Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php I don't see any reason to change current behaviour of session garbage collector. Read about it here: http://php.net/session [2005-06-08 10:03:10] neo_in_matrix at msn dot com Description: Though it is a bit strange for me to find that php-win also has session support ($_SESSION), but it is even more strange for to find that when php-win exits, the session file is not deleted. Reproduce code: --- This is what I have in php.ini in %windir%: session.save_path = "d:/temp/apache/session" And my simple script is like this: $_SESSION['test'] = 123; Expected result: This script creates a session file (such as sess_b003da224c2d5c1d50a9a8c95725ddca) in d:/temp/apache/session. When the script terminates, I think php-win should delete the create session file, since it is not like php-cgi that has a session timeout. Once a script terminates, its session should be considered 'destroyed'. Actual result: -- Session file is not deleted. -- Edit this bug report at http://bugs.php.net/?id=33271&edit=1
#25876 [Com]: session_start(): Failed to initialize storage module
ID: 25876
Comment by: tech at c64-wiki dot de
Reported By: golden at riscom dot com
Status: No Feedback
Bug Type: Session related
Operating System: freebsd 4.8
PHP Version: 4.3.9-4.3.10
Assigned To: sniper
New Comment:
I added the following line near the beginning of my PHP code:
ini_set("session.save_handler", "files");
I have not seen the bug again after that, so far (clicked around like
an idiot and everything worked fine). Which does not mean a lot, of
course, due to the extremely random nature of that bug.
Can anybody else confirm that this workaround works (or maybe not)? If
it does "solve" the problem, the root cause may seem to be that PHP
sometimes takes the wrong session handler (not the one which is defined
in PHP.INI, which is "files" as well (while the error message seems to
indicate "user"?)).
Best regards, Klaus
Previous Comments:
[2005-06-08 14:18:42] tech at c64-wiki dot de
Same problem here as described by "gul_murjani at yahoo dot com". PHP
4.3.10 is the version in use (phpinfo() can be seen at
http://www.c64-wiki.de/test.php). I tried to change session.save_path
to a different path (by adding a php_value line into .htaccess), made
the new directory world-writeable and verified that the session files
do indeed appear there. They do appear there, and there's plenty of
space for that directoty available (about 1GB, should be 'nuff for a
few of these session files with <100 bytes each). And the bug still
appears at extremely random intervals!
Best regards, Klaus
[2005-05-22 12:06:42] dmih at in-solve dot ru
Please someone in PHP team confirm that you are reading from this bug
(it has 'No Feedback' status).
Or may be we are writing for ourselves here?
[2005-05-21 14:30:13] gul_murjani at yahoo dot com
Hi,
I'm experiencing this problem in at least 2 sites.
Since it's a error that appears in random, I wrote a simple script to
try and reproduce the error. This is the script:
All it does is invoke "session_start()" and use one session variable.
It then reloads itself every 10 seconds. On HOSTMANIL.ORG and
HOSTMANIL.NET, the error comes up. But there is no pattern at all.
Sometimes out of 20 refreshes, there's an error, half the time. If the
error comes up, I have to do a manual refresh. I notice that the
session variable is not destroyed at all. It continues counting from
where it stopped.
The problem is at one point in HOSTMANILA.ORG, it kept on coming up
every 2 auto refreshes (and I do an F5). But now, it's was good for 45
straign auto refreshes before the error came up. That's how random the
error is.
I do a lot of programming, mostly in PHP but I'm not "deep" technical.
So I'm not sure if I'm missing something.
I'm running the scripts on 5 sites. These are all on different servers
although all of them are from shared hosting services using cPanel /
WHM.
http://www.hostmanila.org/test.php
http://www.hostmanila.biz/test.php
http://www.hostmanila.net/test.php
http://www.vcdpix.com/test.php
http://www.smokedbangus.com/test.php
So far, it's only happened on HOSTMANILA.ORG and HOSTMANILA.NET.
Here's the rundown on each site:
HOSTMANILA.ORG (error)
Linux 2.4.30-gator_r1
Apache 1.3.33 (Unix)
PERL 5.8.4
PHP 4.3.11
cPanel 9.9.9-STABLE 15
HOSTMANILA.BIZ (fine)
Linux 2.4.30-1-s5
Apache 1.3.33 (Unix)
PERL 5.8.3
PHP 4.3.11
cPanel 10.2.0-RELEASE 82
HOSTMANILA.NET (error)
Linux 2.4.26-grsec
Apache 1.3.33 (Unix)
PERL 5.8.0
PHP 4.3.11
cPanel 10.0.0-RELEASE 7
VCDPIX.COM (fine)
Linux 2.4.20-24.9
Apache 1.3.33 (Unix)
PERL 5.8.1
PHP 4.3.9
cPanel 10.0.0-RELEASE 7
SMOKEDBANGUS.COM (fine)
Linux 2.4.20-20.7smp
Apache 1.3.33 (Unix)
PERL 5.8.4
PHP 4.3.10
cPanel 10.0.0-CURRENT 107
I can't imagine developing anything in PHP without making use of
session_start() so I hope the issue is resolved.
Regards,
Gul
hostmanila.com
[2005-05-21 01:24:55] jspec at bellsouth dot net
I have now experienced this beast with a completely different hosting
company. They are both running 4.3.10 - is this fixed in 4.3.11?
[2005-05-18 22:48:45] dmih at in-solve dot ru
We (as hosting company) are hoping that PHP team will track this bug
down some day.
Indeed, we can do not much to help or to fix it.
This bug is hard to fix because it appears randomly, and there is no
definite recreate scenario. There is assumption that this is
http://bugs.php.net/bug.php?id=32330 bug, but I am not completely
sure.
You may suggest your hosting company to lower average server load - it
will help this bug to happen rarely or even at no times. Lower - I mean
- something lower tha
#33270 [Com]: Typecasting an object with a __toString() function returns the string 'Object'.
ID: 33270
Comment by: nick dot telford at gmail dot com
Reported By: Jesselnz at gmail dot com
Status: Open
Bug Type: Strings related
Operating System: All
PHP Version: 5.0.3
New Comment:
This is not a bug, as stated in the docs (www.php.net/oop5)
__toString() will only be automatically called if directly combined
with echo/print with NOTHING BEFORE THE OBJECT! (not even a cast).
echo (string) $obj;
would print Object, since __toString() is not invoked.
__toString()'s implementation is going to be changed/removed completely
in PHP5.1
Previous Comments:
[2005-06-08 03:42:19] Jesselnz at gmail dot com
Description:
Typecasting an object with a __toString() function returns the string
'Object' and doesn't run __toString().
Reproduce code:
---
Expected result:
__toString() was run.
require ('./includes/foobar.php');
Actual result:
--
require ('Object');
--
Edit this bug report at http://bugs.php.net/?id=33270&edit=1
#33275 [Com]: strip_tags() strips everything after "<="
ID: 33275 Comment by: nick dot telford at gmail dot com Reported By: slawek at truxe dot com Status: Open Bug Type: Strings related Operating System: Windows 2003 Server PHP Version: 4.3.11 New Comment: Not really much of a bug, strip_tags() simply strips everything between a pair of angle brackets. It's not designed to be an incredibly intelligent function. For your case, where you wish to strip tags out of input to an SQL query, simply do something like this. $sql = "SELECT something FROM table WHERE field <= " . strip_tags($number); A glance over the Database Security pages in the PHP docs might prove beneficial: www.php.net/security.database Previous Comments: [2005-06-08 13:55:46] slawek at truxe dot com Description: // strip_tags() strips everything after "<=" // strings like >= not affected // result of print $sql_query; select * from anytable where anycolumn // should be select * from anytable where anycolumn <= '10' Reproduce code: --- // strip_tags() strips everything after "<=" // strings like >= not affected Expected result: select * from anytable where anycolumn <= '10' Actual result: -- select * from anytable where anycolumn -- Edit this bug report at http://bugs.php.net/?id=33275&edit=1
#30140 [Asn->Csd]: Problem with array in static properties
ID: 30140
Updated by: [EMAIL PROTECTED]
Reported By: guth at fiifo dot u-psud dot fr
-Status: Assigned
+Status: Closed
Bug Type: Zend Engine 2 problem
Operating System: *
PHP Version: 5CVS-2005-05-07
Assigned To: dmitry
New Comment:
Fixed in CVS HEAD and PHP_5_0.
Previous Comments:
[2005-06-08 11:18:53] [EMAIL PROTECTED]
No this is another bug. The problem is in zval_update_constant().
Reproduce code:
---
Expected result:
string(1) "x"
string(1) "y"
string(1) "z"
string(1) "x"
string(1) "y"
string(1) "z"
Actual result:
--
string(1) "x"
string(1) "y"
string(1) "z"
bool(true)
array(0) {
}
string(1) "z"
[2005-05-17 16:27:37] [EMAIL PROTECTED]
It's definitely duplicate for bug #30934.
[2005-05-09 11:34:31] [EMAIL PROTECTED]
This same thing happens with boolean too. All other types behave
correctly (or incorrectly, not sure anymore :)
Andi, (or Dmitry maybe?) can you look into this?
[2005-04-05 23:24:10] [EMAIL PROTECTED]
Yet another duplicate of bug #30934.
[2004-09-18 17:02:22] guth at fiifo dot u-psud dot fr
Description:
[ sorry for english ]
There is a problem with static properties initialized as
an array in classes.
In the following code, if you replace "public static $test
= array();" by "public static $test;" or if you initialize
the property with not an array ("public static $test =
12;" for example), it works as expected.
Reproduce code:
---
set(array('key' => 'value'));
A::view();
B::view();
?>
Expected result:
array(1) { ["key"]=> string(5) "value" }
array(1) { ["key"]=> string(5) "value" }
Actual result:
--
array(1) { ["key"]=> string(5) "value" }
array(0) { }
--
Edit this bug report at http://bugs.php.net/?id=30140&edit=1
#33275 [Opn->Bgs]: strip_tags() strips everything after "<="
ID: 33275 Updated by: [EMAIL PROTECTED] Reported By: slawek at truxe dot com -Status: Open +Status: Bogus Bug Type: Strings related Operating System: Windows 2003 Server PHP Version: 4.3.11 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 Why are you running strip tags on SQL anyway? :) Previous Comments: [2005-06-08 15:14:01] nick dot telford at gmail dot com Not really much of a bug, strip_tags() simply strips everything between a pair of angle brackets. It's not designed to be an incredibly intelligent function. For your case, where you wish to strip tags out of input to an SQL query, simply do something like this. $sql = "SELECT something FROM table WHERE field <= " . strip_tags($number); A glance over the Database Security pages in the PHP docs might prove beneficial: www.php.net/security.database [2005-06-08 13:55:46] slawek at truxe dot com Description: // strip_tags() strips everything after "<=" // strings like >= not affected // result of print $sql_query; select * from anytable where anycolumn // should be select * from anytable where anycolumn <= '10' Reproduce code: --- // strip_tags() strips everything after "<=" // strings like >= not affected Expected result: select * from anytable where anycolumn <= '10' Actual result: -- select * from anytable where anycolumn -- Edit this bug report at http://bugs.php.net/?id=33275&edit=1
#33275 [Bgs]: strip_tags() strips everything after "<="
ID: 33275 User updated by: slawek at truxe dot com Reported By: slawek at truxe dot com Status: Bogus Bug Type: Strings related Operating System: Windows 2003 Server PHP Version: 4.3.11 New Comment: Yes, but in manual states that strip_trags() wipes everything between html comment tags (forced&silently), and I assume that everything else can be set as "string allowable_tags". Html comments looks like "
#33275 [Bgs]: strip_tags() strips everything after "<="
ID: 33275 Updated by: [EMAIL PROTECTED] Reported By: slawek at truxe dot com Status: Bogus Bug Type: Strings related Operating System: Windows 2003 Server PHP Version: 4.3.11 New Comment: That's not what the manual says actually. It says it *also* strips HTML comments. And below that it says, "Because strip_tags() does not actually validate the HTML, partial, or broken tags can result in the removal of more text/data than expected." So I would say the behaviour you are reporting is documented. Previous Comments: [2005-06-08 15:49:47] slawek at truxe dot com Yes, but in manual states that strip_trags() wipes everything between html comment tags (forced&silently), and I assume that everything else can be set as "string allowable_tags". Html comments looks like "
#32486 [Com]: odbc_fetch_into returns wrong data
ID: 32486 Comment by: nick dot telford at gmail dot com Reported By: tho at e-dict dot net Status: Open Bug Type: Adabas-D related Operating System: Linux PHP Version: 4.3.9 New Comment: Can you provide more information on how this is occuring? The script that is causing it would be helpful, along with a guess at roughly how often this problem occurs. I have so far failed to replicate this bug on PHP4.3.11, i've written a script to get some test data from a local ODBC db 100 times and detect if the overflow is present. Running it now. Previous Comments: [2005-06-06 18:12:27] tho at e-dict dot net still happens with php4-STABLE-200505171238 [2005-05-25 01:00:04] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2005-05-17 09:10:43] [EMAIL PROTECTED] (or did you make a typo with the snapshot name?) [2005-05-17 09:10:18] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip [2005-05-11 16:30:24] tho at e-dict dot net Tried php4-STABLE-200501211130 and still get wrong results. The \0 issue described before could not be reproduced since the field in the second line was longer then in the first line. But I found out, that in all cases the \0 issue occoured, there was a date field right before the string field and this date field contained the data from the previous line. e.g. 1992-09-09, [EMAIL PROTECTED] 1960-01-09, [EMAIL PROTECTED] results in 1992-09-09, [EMAIL PROTECTED] 1992-09-09, [EMAIL PROTECTED] 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/32486 -- Edit this bug report at http://bugs.php.net/?id=32486&edit=1
#33275 [Bgs]: strip_tags() strips everything after "<="
ID: 33275 User updated by: slawek at truxe dot com Reported By: slawek at truxe dot com Status: Bogus Bug Type: Strings related Operating System: Windows 2003 Server PHP Version: 4.3.11 New Comment: That's right, You ascertain me. But I think that "...strips everything between a pair of angle brackets..." tells little bit more than "... also broken broken tags...". Thanks for attention and engagement. Slawek Previous Comments: [2005-06-08 15:56:08] [EMAIL PROTECTED] That's not what the manual says actually. It says it *also* strips HTML comments. And below that it says, "Because strip_tags() does not actually validate the HTML, partial, or broken tags can result in the removal of more text/data than expected." So I would say the behaviour you are reporting is documented. [2005-06-08 15:49:47] slawek at truxe dot com Yes, but in manual states that strip_trags() wipes everything between html comment tags (forced&silently), and I assume that everything else can be set as "string allowable_tags". Html comments looks like "
#32486 [Com]: odbc_fetch_into returns wrong data
ID: 32486 Comment by: nick dot telford at gmail dot com Reported By: tho at e-dict dot net Status: Open Bug Type: Adabas-D related Operating System: Linux PHP Version: 4.3.9 New Comment: Also, since it's ODBC, we'll need to know the database you're using and the version. It's quite possible that the database itself is returning invalid data and PHP isn't compensating for it. Previous Comments: [2005-06-08 16:03:33] nick dot telford at gmail dot com Can you provide more information on how this is occuring? The script that is causing it would be helpful, along with a guess at roughly how often this problem occurs. I have so far failed to replicate this bug on PHP4.3.11, i've written a script to get some test data from a local ODBC db 100 times and detect if the overflow is present. Running it now. [2005-06-06 18:12:27] tho at e-dict dot net still happens with php4-STABLE-200505171238 [2005-05-25 01:00:04] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2005-05-17 09:10:43] [EMAIL PROTECTED] (or did you make a typo with the snapshot name?) [2005-05-17 09:10:18] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip 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/32486 -- Edit this bug report at http://bugs.php.net/?id=32486&edit=1
#25922 [Csd->Asn]: In error handler, modifying 5th arg (errcontext) may result in seg fault
ID: 25922
Updated by: [EMAIL PROTECTED]
Reported By: jeroen at derks dot it
-Status: Closed
+Status: Assigned
Bug Type: Scripting Engine problem
Operating System: Linux 2.4.20 Debian 3.0
PHP Version: 4-STABLE-CVS-20031021
-Assigned To:
+Assigned To: dmitry
New Comment:
The bug is still reprodusabe in PHP_4_4 and HEAD.
Previous Comments:
[2003-10-22 19:49:40] [EMAIL PROTECTED]
This bug has been fixed in CVS.
In case this was a PHP problem, snapshots of the sources are packaged
every three hours; this change will be in the next snapshot. You can
grab the snapshot at http://snaps.php.net/.
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.
In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
Thank you for the report, and for helping us make PHP better.
[2003-10-21 06:16:08] [EMAIL PROTECTED]
With PHP 4.3.4RC3-dev:
[Tue Oct 21 13:11:19 2003] Script: 't.php'
---
zend_opcode.c(152) : Block 0x08508470 status:
Beginning: Overrun (magic=0x084E8D58, expected=0x7312F8DC)
End: Unknown
---
[Tue Oct 21 13:11:19 2003] Script: 't.php'
---
zend_opcode.c(159) : Block 0x08509568 status:
zend_variables.c(44) : Actual location (location was relayed)
Beginning: Overrun (magic=0x084E8D58, expected=0x7312F8DC)
End: Unknown
---
[Tue Oct 21 13:11:19 2003] Script: 't.php'
---
zend_opcode.c(159) : Block 0x085095A0 status:
zend_variables.c(44) : Actual location (location was relayed)
Beginning: Overrun (magic=0x085095D0, expected=0x7312F8DC)
End: Unknown
---
[Tue Oct 21 13:11:19 2003] Script: 't.php'
---
zend_opcode.c(165) : Block 0x085095D8 status:
zend_variables.c(44) : Actual location (location was relayed)
Beginning: Overrun (magic=0x08509608, expected=0x7312F8DC)
End: Unknown
---
[Tue Oct 21 13:11:19 2003] Script: 't.php'
---
zend_opcode.c(159) : Block 0x08509610 status:
zend_variables.c(44) : Actual location (location was relayed)
Beginning: Overrun (magic=0x08509640, expected=0x7312F8DC)
End: Unknown
---
[Tue Oct 21 13:11:19 2003] Script: 't.php'
---
zend_opcode.c(165) : Block 0x08509648 status:
zend_variables.c(44) : Actual location (location was relayed)
Beginning: Overrun (magic=0x08509678, expected=0x7312F8DC)
End: Unknown
...and so on. GDB backtrace:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384 (LWP 14715)]
0x08259de8 in _efree (ptr=0x85096b4, __zend_filename=0x8361d00
"zend_opcode.c",
__zend_lineno=169, __zend_orig_filename=0x0, __zend_orig_lineno=0)
at zend_alloc.c:259
259 REMOVE_POINTER_FROM_LIST(p);
(gdb) bt
#0 0x08259de8 in _efree (ptr=0x85096b4, __zend_filename=0x8361d00
"zend_opcode.c",
__zend_lineno=169, __zend_orig_filename=0x0, __zend_orig_lineno=0)
at zend_alloc.c:259
#1 0x08265895 in destroy_op_array (op_array=0x8508af8) at
zend_opcode.c:169
#2 0x0826566b in destroy_zend_function (function=0x8508af8) at
zend_opcode.c:100
#3 0x08272fa7 in zend_hash_destroy (ht=0x8415848) at zend_hash.c:553
#4 0x0826cb30 in zend_shutdown () at zend.c:559
#5 0x082358bf in php_module_shutdown () at main.c:1284
#6 0x08290fb0 in main (argc=2, argv=0xbc84) at php_cli.c:876
Note: Works fine with PHP 5.
[2003-10-20 14:11:56] [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
[2003-10-20 07:54:21] jeroen at derks dot it
Description:
Modifying 5th parameter of error handler will make PHP crash when
leaving the error handler.
NB: This seems to happen only when the error was generated in a
function (possibly also in a member function). Please see the code.
NB2: When changing function test()'s parameter name into $args, PHP
exitted normally.
Reproduce code:
---
function my_error_handler( $error, $errmsg = '', $errfile = '',
$errline = 0, $errcontext = '' )
{
$errcontext = '';
}
set_error_handler( 'my_error_handler
#33273 [Com]: Use of certain kanji characters make PHP crash
ID: 33273 Comment by: nick dot telford at ntlworld dot com Reported By: lars dot jensen at careercross dot com Status: Open Bug Type: Arrays related Operating System: FreeBSD 5.3 PHP Version: 5.0.3 New Comment: If that source is causing that error it's not because of the kanji sequences. You've got an extra comma (,) at the end of your array() statement. Your code: $foo = array ( 'One Text' => 'some kanji', 'Another Text' => 'more kanji', ); The last comma, should not be present, as PHP expects another argument to follow it. Simply remove it: $foo = array ( 'One Text' => 'some kanji', 'Another Text' => 'more kanji' ); On a related note, if you wish to code using non-western character sets, full Unicode support is being added into PHP5 (most likely, the next major release after 5.1 will have it). This should be of great use to you when it's released. Nicholas Telford Previous Comments: [2005-06-08 10:47:09] lars dot jensen at careercross dot com Description: Certain Kanji direct in source seems to be a problem - wanted to use a small array for some simple language changes between english / japanese, but with these given kanji's it fail. Viewing the Kanji's as ascii, they both hold " in it, but closing the array strings using ', it shouldnt affect the strings. Example provided at http://www.ebenkyo.com/bug.php / Lars Reproduce code: --- As the code holds kanji characters, use this page to see the source. Please ensure to see the page using shift_jis encoding http://www.ebenkyo.com/bug_source.php Expected result: The array not to fail with given Kanji's. Most Kanji sequences seem to work. Actual result: -- Parse error: parse error, unexpected T_STRING, expecting ')' in /usr/local/www/www.ebenkyo.com/bug.php on line 4 or similar -- Edit this bug report at http://bugs.php.net/?id=33273&edit=1
#33273 [Opn]: Use of certain kanji characters make PHP crash
ID: 33273 Updated by: [EMAIL PROTECTED] Reported By: lars dot jensen at careercross dot com Status: Open Bug Type: Arrays related Operating System: FreeBSD 5.3 PHP Version: 5.0.3 New Comment: Nicholas, that is bullshit. You can have trailing comma's in arrays - just like in C. And Unicode is also not added in PHP 5 or PHp 5.1. Please refrain from commenting if you're not 100% sure about things. Previous Comments: [2005-06-08 16:17:56] nick dot telford at ntlworld dot com If that source is causing that error it's not because of the kanji sequences. You've got an extra comma (,) at the end of your array() statement. Your code: $foo = array ( 'One Text' => 'some kanji', 'Another Text' => 'more kanji', ); The last comma, should not be present, as PHP expects another argument to follow it. Simply remove it: $foo = array ( 'One Text' => 'some kanji', 'Another Text' => 'more kanji' ); On a related note, if you wish to code using non-western character sets, full Unicode support is being added into PHP5 (most likely, the next major release after 5.1 will have it). This should be of great use to you when it's released. Nicholas Telford [2005-06-08 10:47:09] lars dot jensen at careercross dot com Description: Certain Kanji direct in source seems to be a problem - wanted to use a small array for some simple language changes between english / japanese, but with these given kanji's it fail. Viewing the Kanji's as ascii, they both hold " in it, but closing the array strings using ', it shouldnt affect the strings. Example provided at http://www.ebenkyo.com/bug.php / Lars Reproduce code: --- As the code holds kanji characters, use this page to see the source. Please ensure to see the page using shift_jis encoding http://www.ebenkyo.com/bug_source.php Expected result: The array not to fail with given Kanji's. Most Kanji sequences seem to work. Actual result: -- Parse error: parse error, unexpected T_STRING, expecting ')' in /usr/local/www/www.ebenkyo.com/bug.php on line 4 or similar -- Edit this bug report at http://bugs.php.net/?id=33273&edit=1
#33273 [Opn]: Use of certain kanji characters make PHP crash
ID: 33273 User updated by: lars dot jensen at careercross dot com Reported By: lars dot jensen at careercross dot com Status: Open Bug Type: Arrays related Operating System: FreeBSD 5.3 PHP Version: 5.0.3 New Comment: This was a very stripped down version, if I exchange the kanji with say "abc", it works fine. It also works with other kanji sequences, katakana, hiragana ect. These two samples is the only two out of about 75 causing problems Previous Comments: [2005-06-08 16:20:07] [EMAIL PROTECTED] Nicholas, that is bullshit. You can have trailing comma's in arrays - just like in C. And Unicode is also not added in PHP 5 or PHp 5.1. Please refrain from commenting if you're not 100% sure about things. [2005-06-08 16:17:56] nick dot telford at ntlworld dot com If that source is causing that error it's not because of the kanji sequences. You've got an extra comma (,) at the end of your array() statement. Your code: $foo = array ( 'One Text' => 'some kanji', 'Another Text' => 'more kanji', ); The last comma, should not be present, as PHP expects another argument to follow it. Simply remove it: $foo = array ( 'One Text' => 'some kanji', 'Another Text' => 'more kanji' ); On a related note, if you wish to code using non-western character sets, full Unicode support is being added into PHP5 (most likely, the next major release after 5.1 will have it). This should be of great use to you when it's released. Nicholas Telford [2005-06-08 10:47:09] lars dot jensen at careercross dot com Description: Certain Kanji direct in source seems to be a problem - wanted to use a small array for some simple language changes between english / japanese, but with these given kanji's it fail. Viewing the Kanji's as ascii, they both hold " in it, but closing the array strings using ', it shouldnt affect the strings. Example provided at http://www.ebenkyo.com/bug.php / Lars Reproduce code: --- As the code holds kanji characters, use this page to see the source. Please ensure to see the page using shift_jis encoding http://www.ebenkyo.com/bug_source.php Expected result: The array not to fail with given Kanji's. Most Kanji sequences seem to work. Actual result: -- Parse error: parse error, unexpected T_STRING, expecting ')' in /usr/local/www/www.ebenkyo.com/bug.php on line 4 or similar -- Edit this bug report at http://bugs.php.net/?id=33273&edit=1
#33273 [Opn]: Use of certain kanji characters make PHP crash
ID: 33273 Updated by: [EMAIL PROTECTED] Reported By: lars dot jensen at careercross dot com Status: Open Bug Type: Arrays related Operating System: FreeBSD 5.3 PHP Version: 5.0.3 New Comment: It's because in latin one it looks like this: 'One Text'=>'[EMAIL PROTECTED]', you see the \ in the last char č½ escaping the '. Previous Comments: [2005-06-08 16:21:24] lars dot jensen at careercross dot com This was a very stripped down version, if I exchange the kanji with say "abc", it works fine. It also works with other kanji sequences, katakana, hiragana ect. These two samples is the only two out of about 75 causing problems [2005-06-08 16:20:07] [EMAIL PROTECTED] Nicholas, that is bullshit. You can have trailing comma's in arrays - just like in C. And Unicode is also not added in PHP 5 or PHp 5.1. Please refrain from commenting if you're not 100% sure about things. [2005-06-08 16:17:56] nick dot telford at ntlworld dot com If that source is causing that error it's not because of the kanji sequences. You've got an extra comma (,) at the end of your array() statement. Your code: $foo = array ( 'One Text' => 'some kanji', 'Another Text' => 'more kanji', ); The last comma, should not be present, as PHP expects another argument to follow it. Simply remove it: $foo = array ( 'One Text' => 'some kanji', 'Another Text' => 'more kanji' ); On a related note, if you wish to code using non-western character sets, full Unicode support is being added into PHP5 (most likely, the next major release after 5.1 will have it). This should be of great use to you when it's released. Nicholas Telford [2005-06-08 10:47:09] lars dot jensen at careercross dot com Description: Certain Kanji direct in source seems to be a problem - wanted to use a small array for some simple language changes between english / japanese, but with these given kanji's it fail. Viewing the Kanji's as ascii, they both hold " in it, but closing the array strings using ', it shouldnt affect the strings. Example provided at http://www.ebenkyo.com/bug.php / Lars Reproduce code: --- As the code holds kanji characters, use this page to see the source. Please ensure to see the page using shift_jis encoding http://www.ebenkyo.com/bug_source.php Expected result: The array not to fail with given Kanji's. Most Kanji sequences seem to work. Actual result: -- Parse error: parse error, unexpected T_STRING, expecting ')' in /usr/local/www/www.ebenkyo.com/bug.php on line 4 or similar -- Edit this bug report at http://bugs.php.net/?id=33273&edit=1
#33273 [Opn->Bgs]: Use of certain kanji characters make PHP crash
ID: 33273 Updated by: [EMAIL PROTECTED] Reported By: lars dot jensen at careercross dot com -Status: Open +Status: Bogus Bug Type: Arrays related Operating System: FreeBSD 5.3 PHP Version: 5.0.3 New Comment: So this is not a bug as PHP simply doesn't support this yet. Previous Comments: [2005-06-08 16:23:46] [EMAIL PROTECTED] It's because in latin one it looks like this: 'One Text'=>'[EMAIL PROTECTED]', you see the \ in the last char č½ escaping the '. [2005-06-08 16:21:24] lars dot jensen at careercross dot com This was a very stripped down version, if I exchange the kanji with say "abc", it works fine. It also works with other kanji sequences, katakana, hiragana ect. These two samples is the only two out of about 75 causing problems [2005-06-08 16:20:07] [EMAIL PROTECTED] Nicholas, that is bullshit. You can have trailing comma's in arrays - just like in C. And Unicode is also not added in PHP 5 or PHp 5.1. Please refrain from commenting if you're not 100% sure about things. [2005-06-08 16:17:56] nick dot telford at ntlworld dot com If that source is causing that error it's not because of the kanji sequences. You've got an extra comma (,) at the end of your array() statement. Your code: $foo = array ( 'One Text' => 'some kanji', 'Another Text' => 'more kanji', ); The last comma, should not be present, as PHP expects another argument to follow it. Simply remove it: $foo = array ( 'One Text' => 'some kanji', 'Another Text' => 'more kanji' ); On a related note, if you wish to code using non-western character sets, full Unicode support is being added into PHP5 (most likely, the next major release after 5.1 will have it). This should be of great use to you when it's released. Nicholas Telford [2005-06-08 10:47:09] lars dot jensen at careercross dot com Description: Certain Kanji direct in source seems to be a problem - wanted to use a small array for some simple language changes between english / japanese, but with these given kanji's it fail. Viewing the Kanji's as ascii, they both hold " in it, but closing the array strings using ', it shouldnt affect the strings. Example provided at http://www.ebenkyo.com/bug.php / Lars Reproduce code: --- As the code holds kanji characters, use this page to see the source. Please ensure to see the page using shift_jis encoding http://www.ebenkyo.com/bug_source.php Expected result: The array not to fail with given Kanji's. Most Kanji sequences seem to work. Actual result: -- Parse error: parse error, unexpected T_STRING, expecting ')' in /usr/local/www/www.ebenkyo.com/bug.php on line 4 or similar -- Edit this bug report at http://bugs.php.net/?id=33273&edit=1
#33273 [Bgs]: Use of certain kanji characters make PHP crash
ID: 33273 User updated by: lars dot jensen at careercross dot com Reported By: lars dot jensen at careercross dot com Status: Bogus Bug Type: Arrays related Operating System: FreeBSD 5.3 PHP Version: 5.0.3 New Comment: Any idea when to expect support for this ? Will need to develop a workaround tomorrow anyway as we need the given kanji's in the included language file Previous Comments: [2005-06-08 16:24:32] [EMAIL PROTECTED] So this is not a bug as PHP simply doesn't support this yet. [2005-06-08 16:23:46] [EMAIL PROTECTED] It's because in latin one it looks like this: 'One Text'=>'[EMAIL PROTECTED]', you see the \ in the last char č½ escaping the '. [2005-06-08 16:21:24] lars dot jensen at careercross dot com This was a very stripped down version, if I exchange the kanji with say "abc", it works fine. It also works with other kanji sequences, katakana, hiragana ect. These two samples is the only two out of about 75 causing problems [2005-06-08 16:20:07] [EMAIL PROTECTED] Nicholas, that is bullshit. You can have trailing comma's in arrays - just like in C. And Unicode is also not added in PHP 5 or PHp 5.1. Please refrain from commenting if you're not 100% sure about things. [2005-06-08 16:17:56] nick dot telford at ntlworld dot com If that source is causing that error it's not because of the kanji sequences. You've got an extra comma (,) at the end of your array() statement. Your code: $foo = array ( 'One Text' => 'some kanji', 'Another Text' => 'more kanji', ); The last comma, should not be present, as PHP expects another argument to follow it. Simply remove it: $foo = array ( 'One Text' => 'some kanji', 'Another Text' => 'more kanji' ); On a related note, if you wish to code using non-western character sets, full Unicode support is being added into PHP5 (most likely, the next major release after 5.1 will have it). This should be of great use to you when it's released. Nicholas Telford 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/33273 -- Edit this bug report at http://bugs.php.net/?id=33273&edit=1
#33276 [NEW]: CGI scripts no longer accepting POST data
From: ymalik at cs dot stevens dot edu Operating system: NetBSD 2.0.3 PHP version: 5.0.4 PHP Bug Type: Unknown/Other Function Bug description: CGI scripts no longer accepting POST data Description: The following are two HTML forms along with their corresponding handlers: (1) a. http://www.cs.stevens-tech.edu/~ymalik/tmp/index.html b. http://www.cs.stevens-tech.edu/~ymalik/tmp/action.php (2) a. http://www.cs.stevens-tech.edu/~ymalik/tmp/index2.html b. http://www.cs.stevens-tech.edu/~ymalik/tmp/action.cgi 2.a is exactly the same as 1.a except the handler is action.cgi. Accordingly, 2.b is exactly the same as 1.b (with the shbang of course). When you submit using 1.a, the form data is displayed in the handler script. However, when you submit using 2.a, the data isn't displayed. This used to work fine before with PHP 4(I think about 1.5 years ago; I haven't used PHP with form data in a long time). Using CGI is not necessary is this case, but it is when interacting with the database; this has been done for "security reasons." Our sysadmin can't figure this one out, though. Here is the output for phpinfo(): http://www.cs.stevens.edu/~ymalik/phpinfo.php I have queried the bug system, but I have only found this problem with PHP 4. Thanks. Reproduce code: --- Here is the code for action.php: and the code for action.cgi: #!/usr/pkg/bin/php Expected result: I expect to see the same output in action.cgi as I did in action.php Actual result: -- $_POST has no data in action.cgi. -- Edit bug report at http://bugs.php.net/?id=33276&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33276&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=33276&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=33276&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=33276&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=33276&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=33276&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=33276&r=needscript Try newer version: http://bugs.php.net/fix.php?id=33276&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=33276&r=support Expected behavior: http://bugs.php.net/fix.php?id=33276&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=33276&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=33276&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=33276&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33276&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=33276&r=dst IIS Stability: http://bugs.php.net/fix.php?id=33276&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=33276&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=33276&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=33276&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=33276&r=mysqlcfg
#33274 [Opn]: Class extended from MySQLi mangles members on calling parent method
ID: 33274
User updated by: flying dot mushroom at gmail dot com
-Reported By: flying dot mushroom at gmail dot cp,
+Reported By: flying dot mushroom at gmail dot com
Status: Open
Bug Type: MySQLi related
Operating System: Linux
PHP Version: 5.0.3
New Comment:
Oops; mistyped my email. Should read flying dot mushroom at gmail dot
com
Previous Comments:
[2005-06-08 12:27:00] flying dot mushroom at gmail dot com
Description:
A class that extends mysqli, if passing its own members directly to the
parent constructor, will have those members mangled after the call.
Assigning member values to local variables and then passing those to
the parent solves the problem on for the user, but the above behaviour
shouldn't happen...?
(Replacing the line "parent::__construct($this->p_host, $this->p_uname,
$this->p_password);" with "parent::__construct($host, $username,
$password);" produces the expected result.)
This same problem is reported on the comment by hans at lintoo dot dk
on http://www.php.net/manual/en/ref.mysqli.php
Reproduce code:
---
p_host = $host;
$this->p_uname= $username;
$this->p_password = $password;
parent::__construct($this->p_host, $this->p_uname,
$this->p_password);
}
}
var_dump(new db_mysql('localhost', 'username', 'password'));
?>
Expected result:
object(db_mysql)#1 (3) {
["p_host:private"]=>
string(9) "localhost"
["p_uname:private"]=>
string(8) "username"
["p_password:private"]=>
string(8) "password"
}
Actual result:
--
object(db_mysql)#1 (3) {
["p_host:private"]=>
string(9) "localhost"
["p_uname:private"]=>
string(8) "username"
["p_password:private"]=>
NULL
}
--
Edit this bug report at http://bugs.php.net/?id=33274&edit=1
#32261 [Opn->Asn]: Session variable changes into reference
ID: 32261 Updated by: [EMAIL PROTECTED] Reported By: takayana at egate1 dot com -Status: Open +Status: Assigned Bug Type: Session related Operating System: * PHP Version: 4CVS-2005-03-23 Assigned To: derick Previous Comments: [2005-06-08 02:46:03] takayana at egate1 dot com It is not fixed. [2005-06-07 15:50:55] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip [2005-05-10 15:24:50] [EMAIL PROTECTED] Assigning to Derick (another reference thing..) [2005-03-25 02:40:34] takayana at egate1 dot com In my long code Result at the time of performing by PHP4.3.9 The normal value outputted and I thought that it was the problem of PHP4.3.10. It seems that it is the same when the code of bug #24485 is seen. Are they things even if it becomes easier to find a bug in PHP4.3.10? [2005-03-24 21:49:06] [EMAIL PROTECTED] bug #24485 seems to be same issue as this. 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/32261 -- Edit this bug report at http://bugs.php.net/?id=32261&edit=1
#33276 [Opn->Bgs]: CGI scripts no longer accepting POST data
ID: 33276 Updated by: [EMAIL PROTECTED] Reported By: ymalik at cs dot stevens dot edu -Status: Open +Status: Bogus -Bug Type: Unknown/Other Function +Bug Type: CGI related Operating System: NetBSD 2.0.3 PHP Version: 5.0.4 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. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. Previous Comments: [2005-06-08 16:29:23] ymalik at cs dot stevens dot edu Description: The following are two HTML forms along with their corresponding handlers: (1) a. http://www.cs.stevens-tech.edu/~ymalik/tmp/index.html b. http://www.cs.stevens-tech.edu/~ymalik/tmp/action.php (2) a. http://www.cs.stevens-tech.edu/~ymalik/tmp/index2.html b. http://www.cs.stevens-tech.edu/~ymalik/tmp/action.cgi 2.a is exactly the same as 1.a except the handler is action.cgi. Accordingly, 2.b is exactly the same as 1.b (with the shbang of course). When you submit using 1.a, the form data is displayed in the handler script. However, when you submit using 2.a, the data isn't displayed. This used to work fine before with PHP 4(I think about 1.5 years ago; I haven't used PHP with form data in a long time). Using CGI is not necessary is this case, but it is when interacting with the database; this has been done for "security reasons." Our sysadmin can't figure this one out, though. Here is the output for phpinfo(): http://www.cs.stevens.edu/~ymalik/phpinfo.php I have queried the bug system, but I have only found this problem with PHP 4. Thanks. Reproduce code: --- Here is the code for action.php: and the code for action.cgi: #!/usr/pkg/bin/php Expected result: I expect to see the same output in action.cgi as I did in action.php Actual result: -- $_POST has no data in action.cgi. -- Edit this bug report at http://bugs.php.net/?id=33276&edit=1
#33270 [Opn->Bgs]: Typecasting an object with a __toString() function returns the string 'Object'.
ID: 33270
Updated by: [EMAIL PROTECTED]
Reported By: Jesselnz at gmail dot com
-Status: Open
+Status: Bogus
Bug Type: Strings related
Operating System: All
PHP Version: 5.0.3
New Comment:
what he said
Previous Comments:
[2005-06-08 15:07:03] nick dot telford at gmail dot com
This is not a bug, as stated in the docs (www.php.net/oop5)
__toString() will only be automatically called if directly combined
with echo/print with NOTHING BEFORE THE OBJECT! (not even a cast).
echo (string) $obj;
would print Object, since __toString() is not invoked.
__toString()'s implementation is going to be changed/removed completely
in PHP5.1
[2005-06-08 03:42:19] Jesselnz at gmail dot com
Description:
Typecasting an object with a __toString() function returns the string
'Object' and doesn't run __toString().
Reproduce code:
---
Expected result:
__toString() was run.
require ('./includes/foobar.php');
Actual result:
--
require ('Object');
--
Edit this bug report at http://bugs.php.net/?id=33270&edit=1
#33268 [Opn->Ver]: iconv_strlen works only with a parameter of < 3 in length
ID: 33268 Updated by: [EMAIL PROTECTED] Reported By: markus dot lervik at necora dot fi -Status: Open +Status: Verified Bug Type: ICONV related Operating System: SuSE Linux 9.2 -PHP Version: 5.0.3 +PHP Version: 5.* New Comment: Reproduced (having error_reporting = E_ALL helps :) Previous Comments: [2005-06-08 12:42:47] markus dot lervik at necora dot fi My initial bug report regarded 5.0.3 and the latest HEAD from yesterday (2005-06-07). I do still get the same problem with latest 5.1 (php-src) from CVS (checked out just 15 minutes ago, 2005-06-08), both with the glibc-provided iconv and the external libiconv (version 1.9.2) Notice: iconv_strlen() [function.iconv-strlen]: Unknown error (2) in /usr/local/apache/htdocs/test2.php on line 2 bool(false) Notice: iconv_strlen() [function.iconv-strlen]: Unknown error (2) in /usr/local/apache/htdocs/test2.php on line 5 bool(false) Notice: iconv_strlen() [function.iconv-strlen]: Unknown error (2) in /usr/local/apache/htdocs/test2.php on line 8 bool(false) int(3) int(4) [2005-06-08 02:38:56] [EMAIL PROTECTED] And in HEAD (upcoming 5.1) there is no problem. [2005-06-08 00:51:52] scott at slerman dot net I confirmed this problem on Fedora using PHP 5.0.4 and Apache 2.0.54. On Windows/PHP 5.0.4 I get Notice: iconv_strlen(): Unknown error (9) in C:\PHP\test\iconv.php on line 1 On Fedora/PHP 5.0.4 CLI I get Notice: iconv_strlen(): Unknown error (25) in /home/scott/test files/iconv.php on line 1 [2005-06-08 00:28:48] markus dot lervik at necora dot fi Description: iconv_strlen seems to have a peculiar bug. It doesn't work when the string searched is less than three characters long (or an empty string), but reports Notice: iconv_strlen() [function.iconv-strlen]: Unknown error (2) in /usr/local/apache/htdocs/test2.php on line 7 This is tested on PHP 5.0.3 and 5.1 from CVS (2005-06-07), tested with the built-in (glibc 2.3.3) iconv and libiconv 1.9.2 from gnu.org. This problem doesn't seem to surface on my Debian 3.1 development server, but I get it on my SuSE 9.2 desktop. I have tried to set the encodings with iconv_set_encoding() and I have tried to set the encoding as a parameter to iconv_strlen(), both produce the same error. The other iconv-functions (iconv_strpos, iconv_substr, iconv_strrpos) work fine. Since the iconv-functions do not seem to work from the commandline (produces an Unknown error(29)), I cannot get a proper strace (strace seems to say that iconv is trying to seek on /dev/pts/5, which apparently is impossible). It doesn't crash apache either, so I'm not sure where I'd grab the backtrace. List of modules: [EMAIL PROTECTED]:~> php -m [PHP Modules] bz2 ctype curl dom exif gd iconv libxml openssl pcre PDO pdo_sqlite pgsql posix session SimpleXML soap SPL standard tokenizer wddx xml xmlrpc xsl zlib [Zend Modules] PHP version: [EMAIL PROTECTED]:~> php --version PHP 5.1.0-dev (cli) (built: Jun 7 2005 21:30:37) (DEBUG) Copyright (c) 1997-2005 The PHP Group Zend Engine v2.1.0-dev, Copyright (c) 1998-2004 Zend Technologies configure line: './configure' '--with-apxs=/usr/local/apache/bin/apxs' '--with-openssl' '--with-curl' '--with-zlib' '--with-bz2' '--enable-exif' '--with-gd' '--with-pgsql=/usr' '--enable-soap' '--enable-wddx' '--without-sqlite' '--with-xmlrpc' '--with-xsl' '--with-jpeg-dir=/usr/local/' '--with-png-dir=/usr/local/' '--without-mysql' '--with-xslt-sablot' '--with-iconv=/usr/local/' '--enable-debug' Reproduce code: --- Expected result: bool(false) Actual result: -- Notice: iconv_strlen() [function.iconv-strlen]: Unknown error (2) in /usr/local/apache/htdocs/test2.php on line 2 bool(false) -- Edit this bug report at http://bugs.php.net/?id=33268&edit=1
#32486 [Opn]: odbc_fetch_into returns wrong data
ID: 32486
User updated by: tho at e-dict dot net
Reported By: tho at e-dict dot net
Status: Open
Bug Type: Adabas-D related
Operating System: Linux
PHP Version: 4.3.9
New Comment:
We're using Adabas with kernel version 12.01.26. What the script
basicly does is
$dbhandle = odbc_pconnect();
odbc_autocommit($dbhandle, 0);
odbc_rollback( $dbhandle );
$queryid = odbc_exec($dbhandle, $sql);
while (odbc_fetch_into( $queryid, $row )) {
}
odbc_commit($dbhandle);
The overflow occours once in 2-10 days with abound 50 seeks a day. And
of course the database itself could be responsible - I just started
tcpdump to see whether the db or php causes the problem.
Previous Comments:
[2005-06-08 16:05:53] nick dot telford at gmail dot com
Also, since it's ODBC, we'll need to know the database you're using and
the version. It's quite possible that the database itself is returning
invalid data and PHP isn't compensating for it.
[2005-06-08 16:03:33] nick dot telford at gmail dot com
Can you provide more information on how this is occuring? The script
that is causing it would be helpful, along with a guess at roughly how
often this problem occurs.
I have so far failed to replicate this bug on PHP4.3.11, i've written a
script to get some test data from a local ODBC db 100 times and detect
if the overflow is present. Running it now.
[2005-06-06 18:12:27] tho at e-dict dot net
still happens with php4-STABLE-200505171238
[2005-05-25 01:00:04] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
[2005-05-17 09:10:43] [EMAIL PROTECTED]
(or did you make a typo with the snapshot name?)
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/32486
--
Edit this bug report at http://bugs.php.net/?id=32486&edit=1
#33274 [Opn->Fbk]: Class extended from MySQLi mangles members on calling parent method
ID: 33274
Updated by: [EMAIL PROTECTED]
Reported By: flying dot mushroom at gmail dot com
-Status: Open
+Status: Feedback
Bug Type: MySQLi related
Operating System: Linux
PHP Version: 5.0.3
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
Previous Comments:
[2005-06-08 12:27:00] flying dot mushroom at gmail dot com
Description:
A class that extends mysqli, if passing its own members directly to the
parent constructor, will have those members mangled after the call.
Assigning member values to local variables and then passing those to
the parent solves the problem on for the user, but the above behaviour
shouldn't happen...?
(Replacing the line "parent::__construct($this->p_host, $this->p_uname,
$this->p_password);" with "parent::__construct($host, $username,
$password);" produces the expected result.)
This same problem is reported on the comment by hans at lintoo dot dk
on http://www.php.net/manual/en/ref.mysqli.php
Reproduce code:
---
p_host = $host;
$this->p_uname= $username;
$this->p_password = $password;
parent::__construct($this->p_host, $this->p_uname,
$this->p_password);
}
}
var_dump(new db_mysql('localhost', 'username', 'password'));
?>
Expected result:
object(db_mysql)#1 (3) {
["p_host:private"]=>
string(9) "localhost"
["p_uname:private"]=>
string(8) "username"
["p_password:private"]=>
string(8) "password"
}
Actual result:
--
object(db_mysql)#1 (3) {
["p_host:private"]=>
string(9) "localhost"
["p_uname:private"]=>
string(8) "username"
["p_password:private"]=>
NULL
}
--
Edit this bug report at http://bugs.php.net/?id=33274&edit=1
#33263 [Fbk->Opn]: parent::real_connect() can not be used, hence cant use option flags.
ID: 33263
User updated by: daarius at hotmail dot com
Reported By: daarius at hotmail dot com
-Status: Feedback
+Status: Open
Bug Type: MySQLi related
Operating System: WinXP
PHP Version: 5.0.4
New Comment:
I have used latest win32 version, and the problem is same. is there any
other way of doing this in the new version?
Previous Comments:
[2005-06-08 00:25:09] [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
[2005-06-07 14:08:31] daarius at hotmail dot com
Description:
class mydb extends mysqli {
public function __construct() {
parent::real_connect(); // can not use
parent::__construct(); // doesnt support 7th parameter of flags.
}
}
as above, the real_connect() gives some errors, and may be not allowed
to be used, but in there the 7th parameter of flags are not present in
connect() of mysqli. so what to do?
also, as real_connect() is not allowed, i can not use parent::options()
for setting the config options before connect. as this gives errors too.
--
Edit this bug report at http://bugs.php.net/?id=33263&edit=1
#33277 [NEW]: private method accessed by child class
From: [EMAIL PROTECTED]
Operating system: *
PHP version: 5CVS-2005-06-08 (dev)
PHP Bug Type: Zend Engine 2 problem
Bug description: private method accessed by child class
Description:
Code below produces "private!" - meaning that object is allowed to access
private methods of the parent class, which is, of course, wrong.
Reproduce code:
---
bar();
}
}
class foo2son extends fooson {
function bar() {
echo "public!\n";
}
}
$b = new foo2son();
$b->barson();
?>
Expected result:
public!
Actual result:
--
private!
--
Edit bug report at http://bugs.php.net/?id=33277&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33277&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=33277&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=33277&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=33277&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=33277&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=33277&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=33277&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=33277&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=33277&r=support
Expected behavior: http://bugs.php.net/fix.php?id=33277&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=33277&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=33277&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=33277&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33277&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=33277&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=33277&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=33277&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=33277&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=33277&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=33277&r=mysqlcfg
#33279 [NEW]: array_count_values casts number-like strings to ints
From: graced at monroe dot wednet dot edu
Operating system: Linux 2.4.21/RHAS 3
PHP version: 5.0.4
PHP Bug Type: Arrays related
Bug description: array_count_values casts number-like strings to ints
Description:
See:
bug #28435 array_count_values() problem
http://www.php.net/manual/en/language.types.array.php
array_count_values() casts numeric strings (i.e. "72") to integers (72).
This is correct (although annoying) behavior as described at
http://www.php.net/manual/en/language.types.array.php, except for one
catch.
The documentation states (emphasis mine)
"If a key is the standard representation of an integer, it will be
interpreted as such (i.e. "8" will be interpreted as 8, ***while "08" will
be interpreted as "08"***).
However, array_count_values() will strip the leading zeroes and turn those
strings into integers, which causes errors in code later on when (string)
8 is compared against (string) "08" and the comparison fails.
Reproduce code:
---
int(1)
}
Actual result:
--
array(1) {
[12345]=>
int(1)
}
--
Edit bug report at http://bugs.php.net/?id=33279&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33279&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=33279&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=33279&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=33279&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=33279&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=33279&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=33279&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=33279&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=33279&r=support
Expected behavior: http://bugs.php.net/fix.php?id=33279&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=33279&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=33279&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=33279&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33279&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=33279&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=33279&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=33279&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=33279&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=33279&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=33279&r=mysqlcfg
#33142 [Fbk->Opn]: Session info not getting saved correctly
ID: 33142 User updated by: jkump at everestgt dot com Reported By: jkump at everestgt dot com -Status: Feedback +Status: Open Bug Type: Session related Operating System: Solaris 9 PHP Version: 5.0.4 New Comment: It seems as though the simplexml_load_string object is clobbering the Session object. http://www.fastcarrot.net/index.php Previous Comments: [2005-06-08 02:40:42] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , is max. 10-20 lines long and does not require any external resources such as databases, etc. If possible, make the script source available online and provide an URL to it here. Try to avoid embedding huge scripts into the report. [2005-06-07 06:34:15] jkump at everestgt dot com Please check this bug report with regard to sessions and simplexml_load_string() Thanks [2005-06-02 23:01:46] jkump at everestgt dot com This problem occurs when simplexml_load_string is used within the session. [2005-05-26 19:40:44] [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. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. This is not a support forum where you ask how to use PHP.. (Thre is no bug here, sessions work just fine) [2005-05-26 02:35:43] jkump at everestgt dot com That is fine. I will try that but, this is the error that I am getting when I come back in and nothing is available in the $_SESSION superglobal. [24-May-2005 16:06:22] PHP Warning: session_start() [function.session-start]: Node no longer exists in /export/home/httpd/corp/my_everestkc_net/modules/BillOnline/session.class.php on line 64 [24-May-2005 16:06:22] PHP Warning: session_start() [function.session-start]: Cannot send session cookie - headers already sent by (output started at /export/home/httpd/corp/my_everestkc_net/modules/BillOnline/session.class.php:64) in /export/home/httpd/corp/my_everestkc_net/modules/BillOnline/session.class.php on line 64 [24-May-2005 16:06:22] PHP Warning: session_start() [function.session-start]: Cannot send session cache limiter - headers already sent (output started at /export/home/httpd/corp/my_everestkc_net/modules/BillOnline/session.class.php:64) in /export/home/httpd/corp/my_everestkc_net/modules/BillOnline/session.class.php on line 64 These show up on the second trip into the code. I cant initialize the session again. When I assign stuff to $_SESSION['foo'] and then exit the script. come back into the script via a link on the page. The session is no longer valid and the $_SESSION info is gone. The code works correctly in php 4.3.11. and it fails on 5.0.4. I can try and setup an external area so you can see what is happening. THanks 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/33142 -- Edit this bug report at http://bugs.php.net/?id=33142&edit=1
#33279 [Opn]: array_count_values casts number-like strings to ints
ID: 33279
User updated by: graced at monroe dot wednet dot edu
Reported By: graced at monroe dot wednet dot edu
Status: Open
Bug Type: Arrays related
Operating System: Linux 2.4.21/RHAS 3
PHP Version: 5.0.4
New Comment:
For what it's worth, *this* works:
var_dump(array("012345" => 'yay'));
array(1) {
["012345"]=>
string(3) "yay"
}
so it looks like it's an issue with array_count_values() itself and not
something at a deeper level.
Previous Comments:
[2005-06-08 19:35:24] graced at monroe dot wednet dot edu
Description:
See:
bug #28435 array_count_values() problem
http://www.php.net/manual/en/language.types.array.php
array_count_values() casts numeric strings (i.e. "72") to integers
(72). This is correct (although annoying) behavior as described at
http://www.php.net/manual/en/language.types.array.php, except for one
catch.
The documentation states (emphasis mine)
"If a key is the standard representation of an integer, it will be
interpreted as such (i.e. "8" will be interpreted as 8, ***while "08"
will be interpreted as "08"***).
However, array_count_values() will strip the leading zeroes and turn
those strings into integers, which causes errors in code later on when
(string) 8 is compared against (string) "08" and the comparison fails.
Reproduce code:
---
int(1)
}
Actual result:
--
array(1) {
[12345]=>
int(1)
}
--
Edit this bug report at http://bugs.php.net/?id=33279&edit=1
#33279 [Opn->Bgs]: array_count_values casts number-like strings to ints
ID: 33279
Updated by: [EMAIL PROTECTED]
Reported By: graced at monroe dot wednet dot edu
-Status: Open
+Status: Bogus
Bug Type: Arrays related
Operating System: Linux 2.4.21/RHAS 3
PHP Version: 5.0.4
New Comment:
Please do not submit the same bug more than once. An existing
bug report already describes this very problem. Even if you feel
that your issue is somewhat different, the resolution is likely
to be the same.
Thank you for your interest in PHP.
Please *always* try latest snapshot before reporting a bug.
See bug #30833.
Previous Comments:
[2005-06-08 21:23:33] graced at monroe dot wednet dot edu
For what it's worth, *this* works:
var_dump(array("012345" => 'yay'));
array(1) {
["012345"]=>
string(3) "yay"
}
so it looks like it's an issue with array_count_values() itself and not
something at a deeper level.
[2005-06-08 19:35:24] graced at monroe dot wednet dot edu
Description:
See:
bug #28435 array_count_values() problem
http://www.php.net/manual/en/language.types.array.php
array_count_values() casts numeric strings (i.e. "72") to integers
(72). This is correct (although annoying) behavior as described at
http://www.php.net/manual/en/language.types.array.php, except for one
catch.
The documentation states (emphasis mine)
"If a key is the standard representation of an integer, it will be
interpreted as such (i.e. "8" will be interpreted as 8, ***while "08"
will be interpreted as "08"***).
However, array_count_values() will strip the leading zeroes and turn
those strings into integers, which causes errors in code later on when
(string) 8 is compared against (string) "08" and the comparison fails.
Reproduce code:
---
int(1)
}
Actual result:
--
array(1) {
[12345]=>
int(1)
}
--
Edit this bug report at http://bugs.php.net/?id=33279&edit=1
#32740 [Com]: signal 11 on make install-pear-installer, xml_parse
ID: 32740 Comment by: ben dot peter at gmx dot net Reported By: dev at stalkerbox dot net Status: No Feedback Bug Type: Reproducible crash Operating System: cygwin/xp PHP Version: 5.0.4 New Comment: Just confirming that this happens for php5-STABLE-200506082034 on cygwin / xp-sp2. Previous Comments: [2005-06-03 01:00:03] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2005-05-26 16:14:05] thild at silicom dot fr Still segfault, here is the backtrace. I'll recompile with debug enabled and if the behavior is the same, I'll send you a more complete backtrace: #0 0x0c8025ff in ?? () #1 0x004d2d2a in _start_element_handler (user=0x1036ede8, name=0x1039f353 "package", attributes=0x103a1bc0) at /cygdrive/c/Temp/php5-STABLE-200505260839/ext/xml/compat.c:65 #2 0x009299d8 in xmlParseStartTag () from /usr/bin/cygxml2-2.dll #3 0x009357fb in xmlParseChunk () from /usr/bin/cygxml2-2.dll #4 0x004d368a in php_XML_Parse (parser=0x1036ede8, data=0x1036f1b0 "\n\n\n Archive_Tar\n Tar file management class\n Th"..., data_len=2601, is_final=1) at /cygdrive/c/Temp/php5-STABLE-200505260839/ext/xml/compat.c:512 #5 0x004d1d84 in zif_xml_parse (ht=3, return_value=0x1039f2f8, this_ptr=0x0, return_value_used=1) at /cygdrive/c/Temp/php5-STABLE-200505260839/ext/xml/xml.c:1340 #6 0x0052f456 in zend_do_fcall_common_helper (execute_data=0x2276b0, opline=0x1019e198, op_array=0x102c7d08) at /cygdrive/c/Temp/php5-STABLE-200505260839/Zend/zend_execute.c:2747 #7 0x0052c139 in execute (op_array=0x102c7d08) at /cygdrive/c/Temp/php5-STABLE-200505260839/Zend/zend_execute.c:1417 #8 0x0052f24d in zend_do_fcall_common_helper (execute_data=0x227a00, opline=0x10185fa0, op_array=0x102c7c20) at /cygdrive/c/Temp/php5-STABLE-200505260839/Zend/zend_execute.c:2776 #9 0x0052c139 in execute (op_array=0x102c7c20) at /cygdrive/c/Temp/php5-STABLE-200505260839/Zend/zend_execute.c:1417 #10 0x0052f24d in zend_do_fcall_common_helper (execute_data=0x22b4d0, opline=0x1012c5b8, op_array=0x10104e08) at /cygdrive/c/Temp/php5-STABLE-200505260839/Zend/zend_execute.c:2776 #11 0x0052c139 in execute (op_array=0x10104e08) at /cygdrive/c/Temp/php5-STABLE-200505260839/Zend/zend_execute.c:1417 #12 0x0052f24d in zend_do_fcall_common_helper (execute_data=0x22d9b0, opline=0x1009dfd0, op_array=0x1008e1d0) at /cygdrive/c/Temp/php5-STABLE-200505260839/Zend/zend_execute.c:2776 #13 0x0052c139 in execute (op_array=0x1008e1d0) at /cygdrive/c/Temp/php5-STABLE-200505260839/Zend/zend_execute.c:1417 #14 0x0050d485 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /cygdrive/c/Temp/php5-STABLE-200505260839/Zend/zend.c:1084 #15 0x004d6fcd in php_execute_script (primary_file=0x22eed0) at /cygdrive/c/Temp/php5-STABLE-200505260839/main/main.c:1646 #16 0x00536a11 in main (argc=12, argv=0x10012ab0) at /cygdrive/c/Temp/php5-STABLE-200505260839/sapi/cli/php_cli.c:946 [2005-05-26 15:28:30] [EMAIL PROTECTED] Still can't reproduce. Try to run this command (in the sources root): ./sapi/cli/php -n -dshort_open_tag=0 -dsafe_mode=0 ./pear/install-pear.php -d /tmp -b "/usr/local/stow/php5-STABLE-200505260839/bin/" ./pear/package-*.xml And if it fails - generate GDB backtrace. [2005-05-26 14:08:49] thild at silicom dot fr I have the same behavior with the following snapshot: php5-STABLE-200505260839 $ ./configure --prefix=/usr/local/stow/php5-STABLE-200505260839 --enable-discard-path --enable-fastcgi ... everything is fine ... $ make ... everything is fine ... $ make install Installing PHP SAPI module: cgi Installing PHP CGI into: /usr/local/stow/php5-STABLE-200505260839/bin/ Installing PEAR environment: /usr/local/stow/php5-STABLE-200505260839/lib/php/ Signal 11 make[1]: *** [install-pear-installer] Error 139 make: *** [install-pear] Error 2 I can add an strace if asked for. [2005-05-05 01:00:04] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". 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/32740
#33280 [NEW]: range() stops script without error when used in delcaring class member variable
From: phpbugs at s8 dot org
Operating system: Linux 2.4.29
PHP version: 4.3.10
PHP Bug Type: Class/Object related
Bug description: range() stops script without error when used in delcaring
class member variable
Description:
When defining the initial value of a member variable of a class using the
range () function, the php script does not execute and no error message is
displayed. (I triple-checked that display_errors was set to true.) If I
take cut the line using range and move it outside of the class definition
(and remove the var keyword as well) the script executes normally.
Reproduce code:
---
print ( "Hello" );
class test
{
var $test = array ( 1,2,3,4,5 );
var $test_too = range ( 1, 5 );
}
print ( " World!" );
Expected result:
"Hello World!" is printed out.
Actual result:
--
Blank page. No error messages, nothing. I don't even see "Hello" printed
to the screen.
--
Edit bug report at http://bugs.php.net/?id=33280&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33280&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=33280&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=33280&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=33280&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=33280&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=33280&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=33280&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=33280&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=33280&r=support
Expected behavior: http://bugs.php.net/fix.php?id=33280&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=33280&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=33280&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=33280&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33280&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=33280&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=33280&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=33280&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=33280&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=33280&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=33280&r=mysqlcfg
#33280 [Opn->Bgs]: range() stops script without error when used in delcaring class member variable
ID: 33280
Updated by: [EMAIL PROTECTED]
Reported By: phpbugs at s8 dot org
-Status: Open
+Status: Bogus
Bug Type: Class/Object related
Operating System: Linux 2.4.29
PHP Version: 4.3.10
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
The code you've shown is invalid, you cannot set default property
values based on output of functions.
Previous Comments:
[2005-06-08 23:50:42] phpbugs at s8 dot org
Description:
When defining the initial value of a member variable of a class using
the range () function, the php script does not execute and no error
message is displayed. (I triple-checked that display_errors was set to
true.) If I take cut the line using range and move it outside of the
class definition (and remove the var keyword as well) the script
executes normally.
Reproduce code:
---
print ( "Hello" );
class test
{
var $test = array ( 1,2,3,4,5 );
var $test_too = range ( 1, 5 );
}
print ( " World!" );
Expected result:
"Hello World!" is printed out.
Actual result:
--
Blank page. No error messages, nothing. I don't even see "Hello"
printed to the screen.
--
Edit this bug report at http://bugs.php.net/?id=33280&edit=1
#33268 [Ver->Csd]: iconv_strlen works only with a parameter of < 3 in length
ID: 33268 Updated by: [EMAIL PROTECTED] Reported By: markus dot lervik at necora dot fi -Status: Verified +Status: Closed Bug Type: ICONV related Operating System: * PHP Version: 5.* (2005-06-08) New Comment: This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. Previous Comments: [2005-06-08 17:31:34] [EMAIL PROTECTED] Reproduced (having error_reporting = E_ALL helps :) [2005-06-08 12:42:47] markus dot lervik at necora dot fi My initial bug report regarded 5.0.3 and the latest HEAD from yesterday (2005-06-07). I do still get the same problem with latest 5.1 (php-src) from CVS (checked out just 15 minutes ago, 2005-06-08), both with the glibc-provided iconv and the external libiconv (version 1.9.2) Notice: iconv_strlen() [function.iconv-strlen]: Unknown error (2) in /usr/local/apache/htdocs/test2.php on line 2 bool(false) Notice: iconv_strlen() [function.iconv-strlen]: Unknown error (2) in /usr/local/apache/htdocs/test2.php on line 5 bool(false) Notice: iconv_strlen() [function.iconv-strlen]: Unknown error (2) in /usr/local/apache/htdocs/test2.php on line 8 bool(false) int(3) int(4) [2005-06-08 00:28:48] markus dot lervik at necora dot fi Description: iconv_strlen seems to have a peculiar bug. It doesn't work when the string searched is less than three characters long (or an empty string), but reports Notice: iconv_strlen() [function.iconv-strlen]: Unknown error (2) in /usr/local/apache/htdocs/test2.php on line 7 This is tested on PHP 5.0.3 and 5.1 from CVS (2005-06-07), tested with the built-in (glibc 2.3.3) iconv and libiconv 1.9.2 from gnu.org. This problem doesn't seem to surface on my Debian 3.1 development server, but I get it on my SuSE 9.2 desktop. I have tried to set the encodings with iconv_set_encoding() and I have tried to set the encoding as a parameter to iconv_strlen(), both produce the same error. The other iconv-functions (iconv_strpos, iconv_substr, iconv_strrpos) work fine. Since the iconv-functions do not seem to work from the commandline (produces an Unknown error(29)), I cannot get a proper strace (strace seems to say that iconv is trying to seek on /dev/pts/5, which apparently is impossible). It doesn't crash apache either, so I'm not sure where I'd grab the backtrace. List of modules: [EMAIL PROTECTED]:~> php -m [PHP Modules] bz2 ctype curl dom exif gd iconv libxml openssl pcre PDO pdo_sqlite pgsql posix session SimpleXML soap SPL standard tokenizer wddx xml xmlrpc xsl zlib [Zend Modules] PHP version: [EMAIL PROTECTED]:~> php --version PHP 5.1.0-dev (cli) (built: Jun 7 2005 21:30:37) (DEBUG) Copyright (c) 1997-2005 The PHP Group Zend Engine v2.1.0-dev, Copyright (c) 1998-2004 Zend Technologies configure line: './configure' '--with-apxs=/usr/local/apache/bin/apxs' '--with-openssl' '--with-curl' '--with-zlib' '--with-bz2' '--enable-exif' '--with-gd' '--with-pgsql=/usr' '--enable-soap' '--enable-wddx' '--without-sqlite' '--with-xmlrpc' '--with-xsl' '--with-jpeg-dir=/usr/local/' '--with-png-dir=/usr/local/' '--without-mysql' '--with-xslt-sablot' '--with-iconv=/usr/local/' '--enable-debug' Reproduce code: --- Expected result: bool(false) Actual result: -- Notice: iconv_strlen() [function.iconv-strlen]: Unknown error (2) in /usr/local/apache/htdocs/test2.php on line 2 bool(false) -- Edit this bug report at http://bugs.php.net/?id=33268&edit=1
#33114 [Fbk->Csd]: SIGSEGV in zend_shutdown/memory leak
ID: 33114 User updated by: K dot Kaczkowski at eisp dot pl Reported By: K dot Kaczkowski at eisp dot pl -Status: Feedback +Status: Closed Bug Type: Reproducible crash Operating System: Linux 2.4.30 PHP Version: 5CVS, 4CVS (2005-05-26) Assigned To: derick New Comment: Ok, that fixed it. Thanks! Previous Comments: [2005-06-07 15:50:43] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip [2005-05-24 10:51:25] K dot Kaczkowski at eisp dot pl > Derick: This is interesting: works with PHP 4.3.9 ? Yes, 4.3.9 and below are ok, it seems that this bug came in as a side effect of bugfixes in 4.3.10 I'm currently forced to use 4.3.9 on one of my webservers because of that. [2005-05-24 10:00:21] [EMAIL PROTECTED] HEAD gives this valgrind output: ==25325== Conditional jump or move depends on uninitialised value(s) ==25325==at 0x839BB4E: ZEND_RETURN_SPEC_CV_HANDLER (zend_vm_execute.h:18606) ==25325==by 0x836907A: execute (zend_vm_execute.h:78) ==25325==by 0x83694AF: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:204) ==25325==by 0x8369B4D: ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (zend_vm_execute.h:290) ==25325== [2005-05-24 09:34:36] [EMAIL PROTECTED] Derick: This is interesting: works with PHP 4.3.9 ? [2005-05-24 01:27:47] K dot Kaczkowski at eisp dot pl Description: I have a problem with reproducible crashes during zend_shutdown when PHP is compiled with --disable-debug. When the same script is run under --enable-debug, it only reports memory leaks. Unfortunately I wasn't able to isolate simple test case for php crash, but I have script causing memory leak and I'm pretty sure it's the same bug and fixing leak will also fix crashes. This bug was introduced in 4.3.10 version, all versions above behave similar with small difference: in 4.3.10/4.3.11 bad free happens in shutdown_memory_manager called from php_request_shutdown instead of zend_shutdown from php_module_shutdown in latest snapshot. 4.3.9 works without any problems. Backtrace for crash case: Program received signal SIGSEGV, Segmentation fault. 0x400fdd43 in free () from /lib/libc.so.6 (gdb) bt #0 0x400fdd43 in free () from /lib/libc.so.6 #1 0x400fdaa3 in free () from /lib/libc.so.6 #2 0x08101670 in zend_hash_destroy (ht=0x8157de0) at /usr/src/php4-STABLE-200505232041/Zend/zend_hash.c:561 #3 0x080fd6d6 in zend_shutdown () at /usr/src/php4-STABLE-200505232041/Zend/zend.c:581 #4 0x080d91d2 in php_module_shutdown () at /usr/src/php4-STABLE-200505232041/main/main.c:1294 #5 0x08115b3c in main (argc=2, argv=0xbfffd724) at /usr/src/php4-STABLE-200505232041/sapi/cli/php_cli.c:885 Output for crash case when compiled with --enable-debug: /usr/src/php4-STABLE-200505232041/Zend/zend_execute.c(1749) : Freeing 0x081FD6EC (5 bytes), script=test1.php /usr/src/php4-STABLE-200505232041/Zend/zend_variables.c(111) : Actual location (location was relayed) Last leak repeated 3 times Details for "memory leak only" case are below. Reproduce code: --- Expected result: nothing/no memory leak Actual result: -- /usr/src/php4-STABLE-200505232041/Zend/zend_execute.c(1749) : Freeing 0x081D1014 (5 bytes), script=test2.php /usr/src/php4-STABLE-200505232041/Zend/zend_variables.c(111) : Actual location (location was relayed) Last leak repeated 1 time -- Edit this bug report at http://bugs.php.net/?id=33114&edit=1
#33267 [Bgs->Opn]: DES_CRYPTED_LENGTH
ID: 33267 User updated by: ceo at l-i-e dot com Reported By: ceo at l-i-e dot com -Status: Bogus +Status: Open -Bug Type: Documentation problem +Bug Type: Feature/Change Request Operating System: All -PHP Version: Irrelevant +PHP Version: PHP 5.1 New Comment: Sorry! I must have missed the menu selection by a one-off error... It's definitely a Feature Request, not Documentation. Previous Comments: [2005-06-08 00:02:55] [EMAIL PROTECTED] This sort of thing doesn't belong in the PHP docs. [2005-06-07 23:40:48] ceo at l-i-e dot com Description: It would be Really Nifty if there were constants for the output lengths of the various CRYPT algorithms. EG: MD5_CRYPTED_LENGTH 32 Cuz I can never remember how long the various crypt thingies go, and I always need to build the table to hold them, so I spend an hour digging around for the number I need. -- Edit this bug report at http://bugs.php.net/?id=33267&edit=1
#33179 [Bgs]: backslash is not an escape character in correct CSV
ID: 33179 User updated by: fsb at thefsb dot org Reported By: fsb at thefsb dot org Status: Bogus Bug Type: Filesystem function related Operating System: os x 10.3 and freebsd 5.3 PHP Version: 4.3.10 New Comment: snipper, both are turned off. since you changed the state back to bogus i assume that your note was not a request for more information about the bug. i suppose i should take the hint and just stop bothering people. Previous Comments: [2005-06-06 10:25:31] [EMAIL PROTECTED] Check you magic_quotes_* settings in php.ini.. [2005-06-04 01:49:45] fsb at thefsb dot org iliaa, please see my update from 6/1. i omitted to change the status to open when i submitted it. [2005-06-01 02:25:24] fsb at thefsb dot org if backslash were an escape character to PHP then it would not appear in the parsed values from the following csv file: abc,123,abc,123,abc,123 abc,\ 123,abc,123,abc,123 abc,123\ ,abc,123,abc,123 abc,123,abc\,123,abc,123 abc,123,\"abc",123,abc,123 abc,123,"a\""bc",123,abc,123 abc,123,"a"\"bc",123,abc,123 abc,123,"a""bc"\ ,123,abc,123 in every case above, the backslash preceeds a special caracter in the csv file format. if backshalsh were generally an escape character then in these positions it should be removed by the csv parser leaving the following character as literal. [2005-05-31 01:18:39] [EMAIL PROTECTED] Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php As far as PHP is concerned backslash is an escape characte, which makes the demonstrated behaviour expected. [2005-05-30 02:22:52] fsb at thefsb dot org Description: why can i have a \ at the end of a field but not if i wrap it in " field delimiters? e.g. abc,123\,abc works fine but "abc","123\",abc produces only two columns this question has been asked before (#29278, #30476, etc.) and [EMAIL PROTECTED] rejects the bug as bogus. i don't agree. if this is not a bug then this unusual use of \ to escape only closing field delimiting double quotes but not escape any other instances of double qotes or (it would appear) any other character SHOULD be documented. it is not. moreover this undocumented feature is not consistent with the specification of the CSV file format found here: http://www.creativyst.com/Doc/Articles/CSV/ CSV01.htm this csv spec suggests that backslash has no special meaning in the CSV format at all. indeed, in all my tests, fgetcsv appears to accord it no special meaning _except_ in this one particular case. such a surprising behaviour that deviates from common CSV file format conventions SHOULD be documented (or corrected). -- Edit this bug report at http://bugs.php.net/?id=33179&edit=1
