#34802 [Opn-Fbk]: new PDORow crashes Apache
ID: 34802 Updated by: [EMAIL PROTECTED] Reported By: stochnagara at hotmail dot com -Status: Open +Status: Feedback Bug Type: PDO related Operating System: windows xp PHP Version: 5.1.0RC1 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-10-10 07:57:01] stochnagara at hotmail dot com Description: Creating a new PDORow object crashes my Apache. The error log contains the correct error message for this case: PHP Fatal error: PDORow::__construct() [a href='function.--construct'function.--construct/a]: You should not create a PDOStatement manually in ...\pdo.php on line 2 But crashing Apache is not the correct behaviour. Reproduce code: --- ? $q= new PDORow(); ? Expected result: PHP Fatal error: PDORow::__construct() [a href='function.--construct'function.--construct/a]: You should not create a PDOStatement manually in ...\pdo.php on line 2 Actual result: -- Apache crashes. -- Edit this bug report at http://bugs.php.net/?id=34802edit=1
#34798 [Fbk-Bgs]: mysqli-set_charset is an undefined method
ID: 34798 Updated by: [EMAIL PROTECTED] Reported By: jarnix at jarnix dot com -Status: Feedback +Status: Bogus Bug Type: MySQLi related Operating System: Windows XP SP2 PHP Version: 5.1.0RC1 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 You have to compile PHP with a newer MySQL client library. For MySQL 4.1 you need 4.1.13 or above, for MySQL 5.0 you need MySQL 5.0.5 or above Previous Comments: [2005-10-10 07:48:54] [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-10-09 23:36:29] jarnix at jarnix dot com Description: set_charset method is undefined Reproduce code: --- $mysqli = new mysqli(localhost, root, , mysql); $mysqli-set_charset(utf8); Expected result: nothing Actual result: -- Fatal error: Call to undefined method mysqli::set_charset() (...) on line 2 -- Edit this bug report at http://bugs.php.net/?id=34798edit=1
#29985 [Csd-Opn]: unserialize()/ __PHP_Incomplete_class does not report correctly class name
ID: 29985
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Closed
+Status: Open
Bug Type: Session related
Operating System: *
PHP Version: 5CVS-2005-10-06 (snap)
Assigned To: helly
New Comment:
Sorry, this has nothing to do with CLI. It also happens in a much more
complex (mod_php) web enviroment.
There is no unknown in my reproduction code and I can't see, what
---
Fatal error: main(): The script tried to execute a method or access a
property of an incomplete object. Please ensure that the class
definition bar of the object you are trying to operate on was loaded
_before_ unserialize() gets called or provide a __autoload() function
to
load the class definition in C:\Dokumente und
Einstellungen\nohn_s\Desktop\php5.1-win32-200510031830\test.php on
line
2
---
has to do with the CLI or the causing location.
Previous Comments:
[2005-10-09 15:36:10] [EMAIL PROTECTED]
Thank you for your bug report. This issue has already been fixed
in the latest released version of PHP, which you can download at
http://www.php.net/downloads.php
This is fixed in all actrive branches, 4.3.*, 5.0.*, 5.1.*, HEAD. The
'Unknown' comes from cli and specifies the causing location and has
nothing to do with the class name.
[2005-10-09 15:27:25] [EMAIL PROTECTED]
I claimed fixed in CVS which is HEAD which will be 6 not any 5.*
[2005-10-06 18:27:38] [EMAIL PROTECTED]
Marcus, you claimed to have fixed this. Can you check it out?
[2005-10-06 15:40:02] [EMAIL PROTECTED]
Yes, it is reproducible:
C:\Dokumente und
Einstellungen\nohn_s\Desktop\php5.1-win32-200510031830php test.php
object(__PHP_Incomplete_Class)#1 (2) {
[__PHP_Incomplete_Class_Name]=
string(3) bar
[someProp]=
int(2)
}
Fatal error: main(): The script tried to execute a method or access a
property of an incomplete object. Please ensure that the class
definition bar of the object you are trying to operate on was loaded
_before_ unserialize() gets called or provide a __autoload() function
to load the class definition in C:\Dokumente und
Einstellungen\nohn_s\Desktop\php5.1-win32-200510031830\test.php on line
2
[2005-10-06 15:15:23] [EMAIL PROTECTED]
Can you reproduce with 5.1-dev?
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/29985
--
Edit this bug report at http://bugs.php.net/?id=29985edit=1
#34802 [Fbk-Opn]: new PDORow crashes Apache
ID: 34802 User updated by: stochnagara at hotmail dot com Reported By: stochnagara at hotmail dot com -Status: Feedback +Status: Open Bug Type: PDO related Operating System: windows xp PHP Version: 5.1.0RC1 New Comment: Still present in latest version. Previous Comments: [2005-10-10 08:54:19] [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-10-10 07:57:01] stochnagara at hotmail dot com Description: Creating a new PDORow object crashes my Apache. The error log contains the correct error message for this case: PHP Fatal error: PDORow::__construct() [a href='function.--construct'function.--construct/a]: You should not create a PDOStatement manually in ...\pdo.php on line 2 But crashing Apache is not the correct behaviour. Reproduce code: --- ? $q= new PDORow(); ? Expected result: PHP Fatal error: PDORow::__construct() [a href='function.--construct'function.--construct/a]: You should not create a PDOStatement manually in ...\pdo.php on line 2 Actual result: -- Apache crashes. -- Edit this bug report at http://bugs.php.net/?id=34802edit=1
#34746 [Fbk-Opn]: SOAP_PERSISTENCE_SESSION no longer works
ID: 34746 User updated by: brent at jeneral dot com Reported By: brent at jeneral dot com -Status: Feedback +Status: Open Bug Type: SOAP related Operating System: Freebsd 5.4 PHP Version: 5.0.5 New Comment: Still fails...If I have a working down-graded system and rebuild the 5.0.5 or latest php base package, it works. But until I build the php-soap extension based on either 5.0.5 or later, it fails. Maybe the php5-soap extension is bad? Previous Comments: [2005-10-06 13:33:55] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.0-win32-latest.zip Can't reproduce both with 5.0.6-dev 5.1-dev. [2005-10-06 01:51:13] brent at jeneral dot com The whole test script: http://www.jeneral.com/sessionTest.zip [2005-10-06 01:06:28] [EMAIL PROTECTED] Just put it somewhere and paste the link here. [2005-10-06 01:05:30] brent at jeneral dot com The bug web interface gives me a Please do not SPAM our bug system when adding the .wsdl file contents. I sent it to your email. Please let me know if that's a valid email. [2005-10-06 00:47:45] [EMAIL PROTECTED] Please provide the .wsdl file too. 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/34746 -- Edit this bug report at http://bugs.php.net/?id=34746edit=1
#34804 [NEW]: More information about class methods
From: toomuchphp-phpbugs at yahoo dot com
Operating system: Any
PHP version: 5.1.0RC1
PHP Bug Type: Feature/Change Request
Bug description: More information about class methods
Description:
Inside any class method, there are as many as 3 related class and it would
be useful to have all of them as magic constants, and also in the
debug_backtrace function.
Currently only __CLASS__ is available (the name of the direct owner of the
method). It would be good to know the name of the child class (if the
method was called as part of a child class), and the name of the calling
class if the method was called statically (the same as get_class($this)
inside a static method).
This information would be most useful in the debug_backtrace() array.
debug_backtrace() was recently modified to report the direct owner class
name rather than the inheriting class' name (see bug #30828) but it would
really be more helpful in debugging to have all three possible class names
available.
Reproduce code:
---
class A {
function A() {
echo 'direct owner: '.__CLASS__.\n;
echo 'called as part of: '.__INHERITED_BY__.\n;
echo 'called by instance of: '.__STATIC_CALLER__.\n;
}
}
class B extends A { }
class C {
function __construct() {
B::A();
}
}
new C();
Expected result:
direct owner: A
called as part of: B
called by instance of: C
--
Edit bug report at http://bugs.php.net/?id=34804edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=34804r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=34804r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=34804r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=34804r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=34804r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=34804r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=34804r=needscript
Try newer version: http://bugs.php.net/fix.php?id=34804r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=34804r=support
Expected behavior: http://bugs.php.net/fix.php?id=34804r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=34804r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=34804r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=34804r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=34804r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=34804r=dst
IIS Stability: http://bugs.php.net/fix.php?id=34804r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=34804r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=34804r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=34804r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=34804r=mysqlcfg
#28639 [Com]: imageCreateFromGif infinite loop. max processor
ID: 28639 Comment by: thegobot at gmail dot com Reported By: jim at bluedojo dot com Status: No Feedback Bug Type: GD related Operating System: Windows XP PHP Version: 4.3.7 New Comment: imagecreatefromgif(img.gif); Child process of Apache usage 95% CPU and infinite loop The img.gif is corrupt Previous Comments: [2005-03-09 23:12:32] ericvanblokland at gmail dot com PS: how do I re-open this bug? [2005-03-09 23:11:50] ericvanblokland at gmail dot com I've experienced this bug with latest stable php5 release. However, I do not believe the gif is corrupted, just odd formated (which you may very well call corrupt if you like). Due to the fact most programs just read these gifs whatsoever, as well as create them, our stupid customers will continue using them. Would be nice to be able to work with them or rejecting them without timeing out the script. [2005-01-22 01:00:08] 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-01-14 18:51:50] [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 Can not reproduce. [2004-06-18 17:15:21] scottmacvicar at ntlworld dot com Problem is in GetDataBlock_ it doesn't even return -1 so constantly loops within the end code handling part of LWZReadByte_ while ((count = GetDataBlock(fd, buf)) 0) is the loop in question in libgd/gd_gif_in.c I dont have enough time to see whats wrong with that function but its there its looping. 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/28639 -- Edit this bug report at http://bugs.php.net/?id=28639edit=1
#28639 [NoF-Bgs]: imageCreateFromGif infinite loop. max processor
ID: 28639 Updated by: [EMAIL PROTECTED] Reported By: jim at bluedojo dot com -Status: No Feedback +Status: Bogus Bug Type: GD related Operating System: Windows XP PHP Version: 4.3.7 -Assigned To: +Assigned To: pajoye 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. Duplicate of #33220. Partiallly fixed there, please try snapshots. Previous Comments: [2005-10-10 10:48:43] thegobot at gmail dot com imagecreatefromgif(img.gif); Child process of Apache usage 95% CPU and infinite loop The img.gif is corrupt [2005-03-09 23:12:32] ericvanblokland at gmail dot com PS: how do I re-open this bug? [2005-03-09 23:11:50] ericvanblokland at gmail dot com I've experienced this bug with latest stable php5 release. However, I do not believe the gif is corrupted, just odd formated (which you may very well call corrupt if you like). Due to the fact most programs just read these gifs whatsoever, as well as create them, our stupid customers will continue using them. Would be nice to be able to work with them or rejecting them without timeing out the script. [2005-01-22 01:00:08] 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-01-14 18:51:50] [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 Can not reproduce. 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/28639 -- Edit this bug report at http://bugs.php.net/?id=28639edit=1
#34802 [Opn-Asn]: new PDORow crashes Apache
ID: 34802 Updated by: [EMAIL PROTECTED] Reported By: stochnagara at hotmail dot com -Status: Open +Status: Assigned Bug Type: PDO related Operating System: windows xp -PHP Version: 5.1.0RC1 +PHP Version: 5CVS-2005-10-10 (snap) -Assigned To: +Assigned To: wez New Comment: Assigned to maintainer. Previous Comments: [2005-10-10 09:43:23] stochnagara at hotmail dot com Still present in latest version. [2005-10-10 08:54:19] [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-10-10 07:57:01] stochnagara at hotmail dot com Description: Creating a new PDORow object crashes my Apache. The error log contains the correct error message for this case: PHP Fatal error: PDORow::__construct() [a href='function.--construct'function.--construct/a]: You should not create a PDOStatement manually in ...\pdo.php on line 2 But crashing Apache is not the correct behaviour. Reproduce code: --- ? $q= new PDORow(); ? Expected result: PHP Fatal error: PDORow::__construct() [a href='function.--construct'function.--construct/a]: You should not create a PDOStatement manually in ...\pdo.php on line 2 Actual result: -- Apache crashes. -- Edit this bug report at http://bugs.php.net/?id=34802edit=1
#34746 [Opn-Fbk]: SOAP_PERSISTENCE_SESSION no longer works
ID: 34746 Updated by: [EMAIL PROTECTED] Reported By: brent at jeneral dot com -Status: Open +Status: Feedback Bug Type: SOAP related Operating System: Freebsd 5.4 PHP Version: 5.0.5 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip Previous Comments: [2005-10-10 09:49:24] brent at jeneral dot com Still fails...If I have a working down-graded system and rebuild the 5.0.5 or latest php base package, it works. But until I build the php-soap extension based on either 5.0.5 or later, it fails. Maybe the php5-soap extension is bad? [2005-10-06 13:33:55] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.0-win32-latest.zip Can't reproduce both with 5.0.6-dev 5.1-dev. [2005-10-06 01:51:13] brent at jeneral dot com The whole test script: http://www.jeneral.com/sessionTest.zip [2005-10-06 01:06:28] [EMAIL PROTECTED] Just put it somewhere and paste the link here. [2005-10-06 01:05:30] brent at jeneral dot com The bug web interface gives me a Please do not SPAM our bug system when adding the .wsdl file contents. I sent it to your email. Please let me know if that's a valid email. 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/34746 -- Edit this bug report at http://bugs.php.net/?id=34746edit=1
#29985 [Opn-Asn]: unserialize()/ __PHP_Incomplete_class does not report correctly class name
ID: 29985
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Assigned
Bug Type: Session related
Operating System: *
PHP Version: 5CVS-2005-10-06 (snap)
Assigned To: helly
New Comment:
Marcus..?
Previous Comments:
[2005-10-10 09:42:15] [EMAIL PROTECTED]
Sorry, this has nothing to do with CLI. It also happens in a much more
complex (mod_php) web enviroment.
There is no unknown in my reproduction code and I can't see, what
---
Fatal error: main(): The script tried to execute a method or access a
property of an incomplete object. Please ensure that the class
definition bar of the object you are trying to operate on was loaded
_before_ unserialize() gets called or provide a __autoload() function
to
load the class definition in C:\Dokumente und
Einstellungen\nohn_s\Desktop\php5.1-win32-200510031830\test.php on
line
2
---
has to do with the CLI or the causing location.
[2005-10-09 15:36:10] [EMAIL PROTECTED]
Thank you for your bug report. This issue has already been fixed
in the latest released version of PHP, which you can download at
http://www.php.net/downloads.php
This is fixed in all actrive branches, 4.3.*, 5.0.*, 5.1.*, HEAD. The
'Unknown' comes from cli and specifies the causing location and has
nothing to do with the class name.
[2005-10-09 15:27:25] [EMAIL PROTECTED]
I claimed fixed in CVS which is HEAD which will be 6 not any 5.*
[2005-10-06 18:27:38] [EMAIL PROTECTED]
Marcus, you claimed to have fixed this. Can you check it out?
[2005-10-06 15:40:02] [EMAIL PROTECTED]
Yes, it is reproducible:
C:\Dokumente und
Einstellungen\nohn_s\Desktop\php5.1-win32-200510031830php test.php
object(__PHP_Incomplete_Class)#1 (2) {
[__PHP_Incomplete_Class_Name]=
string(3) bar
[someProp]=
int(2)
}
Fatal error: main(): The script tried to execute a method or access a
property of an incomplete object. Please ensure that the class
definition bar of the object you are trying to operate on was loaded
_before_ unserialize() gets called or provide a __autoload() function
to load the class definition in C:\Dokumente und
Einstellungen\nohn_s\Desktop\php5.1-win32-200510031830\test.php on line
2
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/29985
--
Edit this bug report at http://bugs.php.net/?id=29985edit=1
#34765 [Opn-Bgs]: Parameter checking, especially in date/time functions
ID: 34765 Updated by: [EMAIL PROTECTED] Reported By: csg at diatom dot de -Status: Open +Status: Bogus Bug Type: Feature/Change Request Operating System: Linux, probably all PHP Version: 4.4.0 New Comment: There is nothing wrong with those parameters. Negative or zero params are perfectly valid for mktime(). Previous Comments: [2005-10-06 18:35:45] csg at diatom dot de Description: Giving some functions -like mktime()- invalid parameters, the result will be unpredictable - at least from users point of view (see Bug-ID 34760, marked as Bogus - sorry for my mistakes there). Suggestion: I suggest to emit at least a warning, if functions internal to PHP get wrong parameters (like an invalid [octal] number) - instead of silently ignoring the problem and return unexpected results (as it is currently the case). Rem.: Of course, numbers with leading zero as in the code example below will be treated as octal numbers and digit 8 is not allowed there - but usually date and time values *will* be given in a 2 or 4 digit format, so using mktime() this way is at least error prone. So, a warning emited in such a case would be ***very*** fine resp. would help, to find such errors easier. Reproduce code: --- ?php mktime(15,0,0,10,08,2005); ? Expected result: A Timestamp for Oct-08-2005 15:00, e.g. the number 1 128 776 400 (without the spaces, of course). Actual result: -- A Timestamp for Sep-30-2005 15:00, e.g. number 1 128 085 200. -- Edit this bug report at http://bugs.php.net/?id=34765edit=1
#34467 [Asn-Csd]: foreach + __get + __set incosistency
ID: 34467
Updated by: [EMAIL PROTECTED]
Reported By: stochnagara at hotmail dot com
-Status: Assigned
+Status: Closed
Bug Type: Class/Object related
Operating System: *
PHP Version: 5CVS-2005-09-11
Assigned To: dmitry
New Comment:
Fixed in HEAD and PHP_5_1.
Previous Comments:
[2005-09-12 13:27:47] [EMAIL PROTECTED]
Dmitry, check this out please. I get some leaks too with latest CVS.
(PHP_5_1 branch)
[2005-09-12 11:36:41] stochnagara at hotmail dot com
That's the shortest I can (run this sample with function __get too).
?
class abc {
function __set ($key, $value) { $this-arr[$key] = $value; }
function __get ($key) { return $this-arr[$key]; }
private $arr;
}
$abc = new abc();
foreach (array (1,2,3) as $abc-k = $v) print_r($abc);
$abc-k = 4;
foreach (array (1,2,3) as $abc-k = $v) print_r($abc);
$abc_value = new abc();
foreach (array (1,2,3) as $v = $abc_value-k) print_r($abc_value);
?
[2005-09-12 10:13:52] stochnagara at hotmail dot com
This is the link to a zip containing all 6 test cases.
http://debian.fmi.uni-sofia.bg/~kapitancho/bug34667.zip
In tests 4, 5 and 6 function __get returns by reference while in 1, 2
and 3 does not.
Tests 1 and 4 show foreach behavoiur when the overloaded property used
as key is not initialized.
Tests 2 and 5 show foreach behavoiur when the overloaded property used
as key is initialized.
Tests 3 and 4 show foreach behavoiur when the overloaded property is
used as value.
If you need more information I will provide it:)
[2005-09-12 00:33:13] [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 ?php and ends with ?,
is max. 10-20 lines long and does not require any external
resources such as databases, etc.
If possible, make the script source available online and provide
an URL to it here. Try to avoid embedding huge scripts into the report.
[2005-09-11 22:27:25] stochnagara at hotmail dot com
Description:
There is some incostistency with foreach and a class which has __get
and __set methods. I don't know what is the intended behaviour but
there is a problem there when assigning a foreach key or value to an
overloaded member of such class.
See comments in the expected result region.
Reproduce code:
---
? class abc {
function __set ($key, $value) { echo __set ($key,$value)br/;
$this-arr[$key] = $value; }
function /**/ __get ($key) { echo __get ($key)br/; return
$this-arr[$key]; }
function __isset ($key) { echo __isset ($key)br/; return isset
($this-arr[$key]); }
function __unset ($key) { echo __unset ($key)br/; unset
($this-arr[$key]); }
private $arr;
}
$abc = new abc();
foreach (array (1,2,3) as $abc-k = $v) {
print_r($abc);echo ';'; var_dump($abc-k);echo ';';
}
$abc-k = 4;
echo '-br/';
foreach (array (1,2,3) as $abc-k = $v) {
print_r($abc);echo ';'; var_dump($abc-k);echo ';';
}
echo 'br/-br/';
$abc_value = new abc();
foreach (array (1,2,3) as $v = $abc_value-k) {
print_r($abc_value);echo ';'; var_dump($abc_value-k);echo ';';
}
Expected result:
Depends of specification.
Case 1 : First foreach fills $arr with keys. Others are ok.
Case 2 : Second foreach does not fill $arr with keys.
Note 1!
When __get is changed to return by reference, first foreach behaves
exactly like the second one.
Note 2!
Third foreach calls __set while first and second do not.
Actual result:
--
__get (k)
abc Object ( [arr:private] = Array ( ) ) ;__get (k)
NULL ;__get (k)
abc Object ( [arr:private] = Array ( ) ) ;__get (k)
NULL ;__set (k,4)
-
__get (k)
abc Object ( [arr:private] = Array ( [k] = 0 ) ) ;__get (k)
int(0) ;__get (k)
abc Object ( [arr:private] = Array ( [k] = 1 ) ) ;__get (k)
int(1) ;
-
__set (k,1)
abc Object ( [arr:private] = Array ( [k] = 1 ) ) ;__get (k)
int(1) ;__set (k,2)
abc Object ( [arr:private] = Array ( [k] = 2 ) ) ;__get (k)
int(2) ;
--
Edit this bug report at http://bugs.php.net/?id=34467edit=1
#34806 [Opn-Bgs]: strtotime ceases to work on future years
ID: 34806 Updated by: [EMAIL PROTECTED] Reported By: alex at magickal dot co dot uk -Status: Open +Status: Bogus Bug Type: Date/time related Operating System: Windows XP PHP Version: 5.1.0RC1 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. See bug #34805 Previous Comments: [2005-10-10 12:11:53] alex at magickal dot co dot uk Description: strtotime converts dates into nice handlable integers. This should work on ALL dates. I can see no reason whatsoever why it should cease half way through a century! Its a bit too much like the millenium bug! And as such IS a bug. Alex Reproduce code: --- $defaultdate = strtotime(01 January 2050); echo $defaultdate; Expected result: expected result would be an integer NOT -1. Actual result: -- -1 -- Edit this bug report at http://bugs.php.net/?id=34806edit=1
#32223 [Fbk-Opn]: weird behaviour of pg_last_notice
ID: 32223
User updated by: valiak at gmail dot com
Reported By: valiak at gmail dot com
-Status: Feedback
+Status: Open
Bug Type: PostgreSQL related
Operating System: *
-PHP Version: 5CVS-2005-09-02
+PHP Version: 5CVS-2005-10-10
Assigned To: helly
New Comment:
i tried with the new version problem still exists (it does not exists
in version 4)
your script differs from the one I have posted, the main difference is
that I use constant to store the return value of pg_connect, the code
is in funcion, and the include must appear bellow pg_connect, try this
test:
--TEST--
Bug #32223 (weird behaviour of pg_last_notice)
--SKIPIF--
?php
require_once('skipif.inc');
@pg_query($conn, CREATE LANGUAGE 'plpgsql' HANDLER
plpgsql_call_handler LANCOMPILER 'PL/pgSQL');
$res = @pg_query($conn, CREATE OR REPLACE FUNCTION test_notice()
RETURNS boolean AS '
begin
RAISE NOTICE ''1'';
return ''f'';
end;
' LANGUAGE plpgsql;);
if (!$res) die('skip PLPGSQL not available');
?
--FILE--
?php
require('config.inc');
define ('dbh', pg_connect($conn_str));
require('config.inc');
if (!dbh) {
die (Could not connect to the server);
}
//@pg_query(dbh, CREATE LANGUAGE 'plpgsql' HANDLER
plpgsql_call_handler LANCOMPILER 'PL/pgSQL');
$res = pg_query(dbh, CREATE OR REPLACE FUNCTION test_notice() RETURNS
boolean AS '
begin
RAISE NOTICE ''1'';
return ''f'';
end;
' LANGUAGE plpgsql;);
function tester() {
$res = pg_query(dbh, 'SELECT test_notice()');
$row = pg_fetch_row($res, 0);
var_dump($row);
pg_free_result($res);
if ($row[0] == 'f')
{
var_dump(pg_last_notice(dbh));
}
}
tester();
pg_close(dbh);
?
===DONE===
--EXPECTF--
array(1) {
[0]=
string(1) f
}
string(14) NOTICE: 1
===DONE===
Previous Comments:
[2005-10-09 18:07:55] [EMAIL PROTECTED]
I made up a php test script for this: ext/pgsql/tests/80_bug32223.phpt
But i cannot reproduce your behavior with 5.1-dev or HEAD.
Maybe it is postgres?
marcus=# select version();
version
--
PostgreSQL 8.0.1 on i586-mandrake-linux-gnu, compiled by GCC
i586-mandrake-linux-gnu-gcc (GCC) 3.4.3 (Mandrakelinux 10.2
3.4.3-7mdk)
Works in all versions for me. So please try the following:
php run-tests.php ext/pgsql/tests/80_bug32223.phpt
If that fails, can you do a 'memcheck' on that?
And tell me your postgres version.
[2005-09-24 20:36:28] [EMAIL PROTECTED]
Assigned to the maintainer.
[2005-09-23 15:55:35] valiak at gmail dot com
the code snipped is presented in the bug report and is
quite easily reproduced on any machine with postgresql and
php5 I have tried, there were some other users confirming
the problem, but are deleted from the bug report.
It has external resources such as databases, etc.
because it is a database related bug!!
I use Short tags because it is written here
http://www.php.net/manual/en/language.basic-syntax.php
that I can use them.
Anyway . here is even more short version of the
bug
(but still with external resources!!! and two files)
http://ce.noxis.net/pg_last_notice/test.php // the main
file
http://ce.noxis.net/pg_last_notice/test.inc.php // the
include
http://ce.noxis.net/pg_last_notice/db.sql // the database
schema - only one function
[2005-09-21 12:24:39] [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 ?php and ends with ?,
is max. 10-20 lines long and does not require any external
resources such as databases, etc.
If possible, make the script source available online and provide
an URL to it here. Try to avoid embedding huge scripts into the report.
[2005-09-02 14:48:49] valiak at gmail dot com
still do not work correctly, there is no output even with
E_ALL
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/32223
--
Edit this bug report at http://bugs.php.net/?id=32223edit=1
#34805 [Opn-Asn]: strtotime ceases to work on future years
ID: 34805 Updated by: [EMAIL PROTECTED] Reported By: alex at magickal dot co dot uk -Status: Open +Status: Assigned Bug Type: Date/time related -Operating System: Windows XP +Operating System: * -PHP Version: 5.1.0RC1 +PHP Version: 5CVS-2005-10-10 (cvs) -Assigned To: +Assigned To: derick New Comment: And within Linux it returns bool(false), Derick, anything you can do about this or do we just document it or reclassify this as feature request? :) Previous Comments: [2005-10-10 12:11:05] alex at magickal dot co dot uk Description: strtotime converts dates into nice handlable integers. This should work on ALL dates. I can see no reason whatsoever why it should cease half way through a century! Its a bit too much like the millenium bug! And as such IS a bug. Alex Reproduce code: --- $defaultdate = strtotime(01 January 2050); echo $defaultdate; Expected result: expected result would be an integer NOT -1. Actual result: -- -1 -- Edit this bug report at http://bugs.php.net/?id=34805edit=1
#32223 [Opn-Asn]: weird behaviour of pg_last_notice
ID: 32223
Updated by: [EMAIL PROTECTED]
Reported By: valiak at gmail dot com
-Status: Open
+Status: Assigned
Bug Type: PostgreSQL related
Operating System: *
PHP Version: 5CVS-2005-10-10
Assigned To: helly
New Comment:
Marcus?
Previous Comments:
[2005-10-10 12:24:06] valiak at gmail dot com
i tried with the new version problem still exists (it does not exists
in version 4)
your script differs from the one I have posted, the main difference is
that I use constant to store the return value of pg_connect, the code
is in funcion, and the include must appear bellow pg_connect, try this
test:
--TEST--
Bug #32223 (weird behaviour of pg_last_notice)
--SKIPIF--
?php
require_once('skipif.inc');
@pg_query($conn, CREATE LANGUAGE 'plpgsql' HANDLER
plpgsql_call_handler LANCOMPILER 'PL/pgSQL');
$res = @pg_query($conn, CREATE OR REPLACE FUNCTION test_notice()
RETURNS boolean AS '
begin
RAISE NOTICE ''1'';
return ''f'';
end;
' LANGUAGE plpgsql;);
if (!$res) die('skip PLPGSQL not available');
?
--FILE--
?php
require('config.inc');
define ('dbh', pg_connect($conn_str));
require('config.inc');
if (!dbh) {
die (Could not connect to the server);
}
//@pg_query(dbh, CREATE LANGUAGE 'plpgsql' HANDLER
plpgsql_call_handler LANCOMPILER 'PL/pgSQL');
$res = pg_query(dbh, CREATE OR REPLACE FUNCTION test_notice() RETURNS
boolean AS '
begin
RAISE NOTICE ''1'';
return ''f'';
end;
' LANGUAGE plpgsql;);
function tester() {
$res = pg_query(dbh, 'SELECT test_notice()');
$row = pg_fetch_row($res, 0);
var_dump($row);
pg_free_result($res);
if ($row[0] == 'f')
{
var_dump(pg_last_notice(dbh));
}
}
tester();
pg_close(dbh);
?
===DONE===
--EXPECTF--
array(1) {
[0]=
string(1) f
}
string(14) NOTICE: 1
===DONE===
[2005-10-09 18:07:55] [EMAIL PROTECTED]
I made up a php test script for this: ext/pgsql/tests/80_bug32223.phpt
But i cannot reproduce your behavior with 5.1-dev or HEAD.
Maybe it is postgres?
marcus=# select version();
version
--
PostgreSQL 8.0.1 on i586-mandrake-linux-gnu, compiled by GCC
i586-mandrake-linux-gnu-gcc (GCC) 3.4.3 (Mandrakelinux 10.2
3.4.3-7mdk)
Works in all versions for me. So please try the following:
php run-tests.php ext/pgsql/tests/80_bug32223.phpt
If that fails, can you do a 'memcheck' on that?
And tell me your postgres version.
[2005-09-24 20:36:28] [EMAIL PROTECTED]
Assigned to the maintainer.
[2005-09-23 15:55:35] valiak at gmail dot com
the code snipped is presented in the bug report and is
quite easily reproduced on any machine with postgresql and
php5 I have tried, there were some other users confirming
the problem, but are deleted from the bug report.
It has external resources such as databases, etc.
because it is a database related bug!!
I use Short tags because it is written here
http://www.php.net/manual/en/language.basic-syntax.php
that I can use them.
Anyway . here is even more short version of the
bug
(but still with external resources!!! and two files)
http://ce.noxis.net/pg_last_notice/test.php // the main
file
http://ce.noxis.net/pg_last_notice/test.inc.php // the
include
http://ce.noxis.net/pg_last_notice/db.sql // the database
schema - only one function
[2005-09-02 14:48:49] valiak at gmail dot com
still do not work correctly, there is no output even with
E_ALL
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/32223
--
Edit this bug report at http://bugs.php.net/?id=32223edit=1
#34808 [Opn-Bgs]: Interface is forced on child classes even though parent class has implemented.
ID: 34808
Updated by: [EMAIL PROTECTED]
Reported By: daarius at hotmail dot com
-Status: Open
+Status: Bogus
Bug Type: Class/Object related
Operating System: WinXP
PHP Version: 5.0.5
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.
See bug #34807
Previous Comments:
[2005-10-10 12:29:22] daarius at hotmail dot com
Description:
The interface of a parent class is also forced to be implemented on to
the children classes if they use methods with same name as in
Interface. Even though the parent class has implemented the methods
declared in the Interface legally.
Reproduce code:
---
interface MyInterface {
public function Z($s);
}
class MyClass implements MyInterface {
public function Z($s) {}
}
class MySubClass extends MyClass {
public function Z() {}
}
Expected result:
Above should be legal (at least i think), because parent is
implementing the interface, the child is just extending the parent's
method.
But, if we remove the method completely from child class, then there is
no error message and Interface is no longer being forced on to child.
This suggests inconsistency.
Also, if we remove the interface from the code, then the parent child
extension of the same method name is still legal, as the number of
arguments is not being checked anymore.
Actual result:
--
Fatal error: Declaration of MySubClass::Z() must be compatible with
that of MyInterface::Z() in C:\httpd\PHPObject3.0\index.php on line 12
--
Edit this bug report at http://bugs.php.net/?id=34808edit=1
#34807 [Opn-Fbk]: Interface is forced on child classes even though parent class has implemented.
ID: 34807
Updated by: [EMAIL PROTECTED]
Reported By: daarius at hotmail dot com
-Status: Open
+Status: Feedback
Bug Type: Class/Object related
Operating System: WinXP
PHP Version: 5.0.5
New Comment:
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
Previous Comments:
[2005-10-10 12:27:02] daarius at hotmail dot com
Description:
The interface of a parent class is also forced to be implemented on to
the children classes if they use methods with same name as in
Interface. Even though the parent class has implemented the methods
declared in the Interface legally.
Reproduce code:
---
interface MyInterface {
public function Z($s);
}
class MyClass implements MyInterface {
public function Z($s) {}
}
class MySubClass extends MyClass {
public function Z() {}
}
Expected result:
Above should be legal (at least i think), because parent is
implementing the interface, the child is just extending the parent's
method.
But, if we remove the method completely from child class, then there is
no error message and Interface is no longer being forced on to child.
This suggests inconsistency.
Also, if we remove the interface from the code, then the parent child
extension of the same method name is still legal, as the number of
arguments is not being checked anymore.
Actual result:
--
Fatal error: Declaration of MySubClass::Z() must be compatible with
that of MyInterface::Z() in C:\httpd\PHPObject3.0\index.php on line 12
--
Edit this bug report at http://bugs.php.net/?id=34807edit=1
#34805 [Asn-Bgs]: strtotime ceases to work on future years
ID: 34805 Updated by: [EMAIL PROTECTED] Reported By: alex at magickal dot co dot uk -Status: Assigned +Status: Bogus Bug Type: Date/time related Operating System: * PHP Version: 5CVS-2005-10-10 (cvs) Assigned To: derick New Comment: Can't do anything about this, as PHP's int is only 32bit signed. The unix timestamp runs out of positions in this field somewhere in 2038. If you want to use dates like this, you have to wait until can enable the new date/time routines that allow you to deal with this properly (although you won't get a timestamp back). An example of how the new code looks like: ?php $d = date_create(01 January 2050); echo date_format($d, DATE_RFC822), \n ? (But you'll have to wait until PHP 5.1.1) Previous Comments: [2005-10-10 12:24:30] [EMAIL PROTECTED] And within Linux it returns bool(false), Derick, anything you can do about this or do we just document it or reclassify this as feature request? :) [2005-10-10 12:11:05] alex at magickal dot co dot uk Description: strtotime converts dates into nice handlable integers. This should work on ALL dates. I can see no reason whatsoever why it should cease half way through a century! Its a bit too much like the millenium bug! And as such IS a bug. Alex Reproduce code: --- $defaultdate = strtotime(01 January 2050); echo $defaultdate; Expected result: expected result would be an integer NOT -1. Actual result: -- -1 -- Edit this bug report at http://bugs.php.net/?id=34805edit=1
#33383 [Asn-Csd]: PHP crashes while retrieving data from Oracle
ID: 33383
Updated by: [EMAIL PROTECTED]
Reported By: johnny at ouranous dot idv dot tw
-Status: Assigned
+Status: Closed
Bug Type: OCI8 related
Operating System: Solaris 9
PHP Version: 5CVS-2005-10-06 (snap, oci8-beta)
Assigned To: tony2001
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-10-07 14:00:26] johnny at ouranous dot idv dot tw
Even if I remove the lines of dynamic loading and load oci8 in php.ini,
the script still crashed.
And this time it cannot even print the first record.
[2005-10-07 09:33:45] [EMAIL PROTECTED]
Do not load the extension with dl()!! Put it in php.ini.
Using dl() is known to cause crashes in all usual and unusual ways..
[2005-10-07 06:36:32] johnny at ouranous dot idv dot tw
Description:
Crashed where clob field contains no data.
Reproduce code:
---
?php
if (!extension_loaded('oci8'))
{
dl('oci8.so');
}
$db_connect_id = OCINLogon( username, passwd, dbserver );
$query = SELECT guid,objcontent FROM objectcontent WHERE rownum 10;
$stmt = OCIParse ($db_connect_id, $query);
OCIExecute($stmt, OCI_DEFAULT);
while( true )
{
if( !OCIFetchInto($stmt, $arr, OCI_ASSOC|OCI_RETURN_LOBS) )
break;
while( list($key,$val)=each($arr) )
{
echo Key:.$key.\tVal:.$val.\n;
}
}
?
Expected result:
Key:GUIDVal:0011856596F1-423F9E4F-05E6-C367-9C3C
Key:OBJCONTENT Val:¢Xþ³ ïy ¡Óa ü îûec Ä2 ®:
Key:GUIDVal:0011856596F1-423F906A-0575-4A3D-F21A
Key:OBJCONTENT Val:
Key:GUIDVal:0011856596F1-423F906C-01C6-8953-3638
Key:OBJCONTENT Val:
Key:GUIDVal:0011856596F1-423F906E-02D6-EED9-B606
Key:OBJCONTENT Val:¢Xþ³ ïy ¡Óa ü îûec Ä2 ®:
Key:GUIDVal:0011856596F1-423F9070-002C-1E4F-B904
Key:OBJCONTENT Val:¢Xþ³ ïy ¡Óa ü îûec Ä2 ®:
Key:GUIDVal:0011856596F1-423F9072-022E-F935-14B2
Key:OBJCONTENT Val:¢Xþ³ ïy ¡Óa ü îûec Ä2 ®:
Key:GUIDVal:0011856596F1-423F9074-0118-D30B-B890
Key:OBJCONTENT Val:¢Xþ³ ïy ¡Óa ü îûec Ä2 ®:
Key:GUIDVal:0011856596F1-423F9075-0489-6151-A41E
Key:OBJCONTENT Val:¢Xþ³ ïy ¡Óa ü îûec Ä2 ®:
Actual result:
--
Key:GUIDVal:0011856596F1-423F9E4F-05E6-C367-9C3C
Key:OBJCONTENT Val:¢Xþ³ ïy ¡Óa ü îûec Ä2 ®:
Segmentation Fault (core dumped)
[2005-10-04 08:54:10] johnny at ouranous dot idv dot tw
oci8-beta still got crashed. And there was something I forgot to
mention. My Oracle 9i is configured to use UTF8.
[2005-09-08 11:51:36] [EMAIL PROTECTED]
Please try OCI8 v.1.1, which is available in CVS HEAD and PECL (use
`pear install oci8-beta` to install it).
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/33383
--
Edit this bug report at http://bugs.php.net/?id=33383edit=1
#34786 [Asn-Csd]: 2 @ results in change to error_reporting() to random value
ID: 34786 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Assigned +Status: Closed Bug Type: Scripting Engine problem Operating System: linux (gentoo) PHP Version: 5CVS-2005-10-08 (CVS) Assigned To: tony2001 New Comment: Fixed in CVS HEAD and PHP_5_1. Previous Comments: [2005-10-08 14:22:46] [EMAIL PROTECTED] Assigned to the engine expert. :) [2005-10-08 04:09:29] [EMAIL PROTECTED] Description: This is a critical bug in PHP 5.1 (PHP_5_1) latest CVS. running make install-pear results in all kinds of E_STRICT warnings. This is in spite of an explicit -derror_reporting=E_ALL I traced the problem using var_dump(error_reporting()); peppered throughout the source of install-pear.phar to a single line located in cvs at pear-core/Archive/Tar.php on line 706: @fseek($this-_file, @ftell($this-_file)+($p_len*512)); removing the second @ in front of ftell() fixes the problem. Reproduce code: --- make install-pear.phar use http://pear.php.net/~greg/install-pear.phar for a debug .phar that has inserted a few var_dump(error_reporting()); around the offending line. int(2047) is E_ALL, and after the line, there are 2 var_dump(error_reporting()) that spit out random integers, ranging from 10 to numbers like 14803908 to -14378917. A valgrind trace is at: http://pear.php.net/~greg/pearcrash.txt Expected result: works with no warnings Actual result: -- install works sometimes, but there are lots of E_STRICT warnings. -- Edit this bug report at http://bugs.php.net/?id=34786edit=1
#34809 [NEW]: PDO FETCH_INTO crashes Apache
From: stochnagara at hotmail dot com
Operating system: windows xp
PHP version: 5CVS-2005-10-10 (snap)
PHP Bug Type: PDO related
Bug description: PDO FETCH_INTO crashes Apache
Description:
The code bellow crashes Apache server. The crash is similar to bug #34802
but the crash code is quite different.
Reproduce code:
---
?
$pdo = new PDO('mysql:host=localhost;dbname=borovo');
$sth = $pdo-prepare ('SELECT nid,type FROM node');
$sth-execute();
var_dump ($sth-fetch (PDO::FETCH_INTO, 3));
Expected result:
Warning: PDOStatement::fetch() [function.fetch]: SQLSTATE[HY000]: General
error: PDO_FETCH_FUNC is only allowed in PDOStatement::fetchAll() in
C:\Program Files\Apache Group\Apache2\htdocs\boroinvest\test.php on line
5
bool(false)
Actual result:
--
Apache crashes.
Log message:
Parent: child process exited with status 3221225477 -- Restarting.
--
Edit bug report at http://bugs.php.net/?id=34809edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=34809r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=34809r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=34809r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=34809r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=34809r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=34809r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=34809r=needscript
Try newer version: http://bugs.php.net/fix.php?id=34809r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=34809r=support
Expected behavior: http://bugs.php.net/fix.php?id=34809r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=34809r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=34809r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=34809r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=34809r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=34809r=dst
IIS Stability: http://bugs.php.net/fix.php?id=34809r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=34809r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=34809r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=34809r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=34809r=mysqlcfg
#34809 [Opn]: PDO FETCH_INTO crashes Apache
ID: 34809
User updated by: stochnagara at hotmail dot com
Reported By: stochnagara at hotmail dot com
Status: Open
Bug Type: PDO related
Operating System: windows xp
PHP Version: 5CVS-2005-10-10 (snap)
New Comment:
Sorry,
General error: PDO_FETCH_FUNC is only allowed in
should be read as
General error: PDO_FETCH_INTO is only allowed in
or just fetch record in mode FETCH_INTO if this is allowed.
Previous Comments:
[2005-10-10 12:58:41] stochnagara at hotmail dot com
Description:
The code bellow crashes Apache server. The crash is similar to bug
#34802 but the crash code is quite different.
Reproduce code:
---
?
$pdo = new PDO('mysql:host=localhost;dbname=borovo');
$sth = $pdo-prepare ('SELECT nid,type FROM node');
$sth-execute();
var_dump ($sth-fetch (PDO::FETCH_INTO, 3));
Expected result:
Warning: PDOStatement::fetch() [function.fetch]: SQLSTATE[HY000]:
General error: PDO_FETCH_FUNC is only allowed in
PDOStatement::fetchAll() in C:\Program Files\Apache
Group\Apache2\htdocs\boroinvest\test.php on line 5
bool(false)
Actual result:
--
Apache crashes.
Log message:
Parent: child process exited with status 3221225477 -- Restarting.
--
Edit this bug report at http://bugs.php.net/?id=34809edit=1
#34809 [Opn-Asn]: PDO FETCH_INTO crashes Apache
ID: 34809
Updated by: [EMAIL PROTECTED]
Reported By: stochnagara at hotmail dot com
-Status: Open
+Status: Assigned
Bug Type: PDO related
Operating System: windows xp
PHP Version: 5CVS-2005-10-10 (snap)
-Assigned To:
+Assigned To: wez
New Comment:
Assigned to the maintainer.
Previous Comments:
[2005-10-10 13:03:23] stochnagara at hotmail dot com
Sorry,
General error: PDO_FETCH_FUNC is only allowed in
should be read as
General error: PDO_FETCH_INTO is only allowed in
or just fetch record in mode FETCH_INTO if this is allowed.
[2005-10-10 12:58:41] stochnagara at hotmail dot com
Description:
The code bellow crashes Apache server. The crash is similar to bug
#34802 but the crash code is quite different.
Reproduce code:
---
?
$pdo = new PDO('mysql:host=localhost;dbname=borovo');
$sth = $pdo-prepare ('SELECT nid,type FROM node');
$sth-execute();
var_dump ($sth-fetch (PDO::FETCH_INTO, 3));
Expected result:
Warning: PDOStatement::fetch() [function.fetch]: SQLSTATE[HY000]:
General error: PDO_FETCH_FUNC is only allowed in
PDOStatement::fetchAll() in C:\Program Files\Apache
Group\Apache2\htdocs\boroinvest\test.php on line 5
bool(false)
Actual result:
--
Apache crashes.
Log message:
Parent: child process exited with status 3221225477 -- Restarting.
--
Edit this bug report at http://bugs.php.net/?id=34809edit=1
#34810 [NEW]: mysqli::init() and others use wrong $this pointer without checks
From: antony at zend dot com
Operating system: Linux
PHP version: 5.1.0RC1
PHP Bug Type: Reproducible crash
Bug description: mysqli::init() and others use wrong $this pointer without
checks
Description:
mysqli::init(), mysqli::connect() and mysqli_warning::__construct() use
wrong inherited $this pointer without checking if this_ptr really points
to the mysqli_object.
In particular conditions this can lead to segfault.
Reproduce code:
---
class DbConnection {
private $link = NULL;
public function connect() {
$this-link = mysqli::init();
var_dump($this-link);
}
}
$db = new DbConnection();
$db-connect();
Actual result:
--
*** glibc detected *** free(): invalid pointer: 0xbfffece4 ***
Program received signal SIGABRT, Aborted.
[Switching to Thread 1076990336 (LWP 24078)]
0xe410 in ?? ()
(gdb) bt
#0 0xe410 in ?? ()
#1 0xbfffe224 in ?? ()
#2 0x0006 in ?? ()
#3 0x5e0e in ?? ()
#4 0x400ec2c1 in raise () from /lib/tls/libc.so.6
#5 0x400edb75 in abort () from /lib/tls/libc.so.6
#6 0x401207aa in __libc_message () from /lib/tls/libc.so.6
#7 0x40126007 in malloc_printerr () from /lib/tls/libc.so.6
#8 0x401276cb in free () from /lib/tls/libc.so.6
#9 0x080c1364 in mysqli_objects_destroy_object (object=0x85585a8,
handle=3) at /usr/src/dev/orig/php-src_5_1/ext/mysqli/mysqli.c:152
#10 0x0826ed46 in zend_objects_store_call_destructors (objects=0x84b36ec)
at /usr/src/dev/orig/php-src_5_1/Zend/zend_objects_API.c:55
#11 0x08249416 in shutdown_destructors () at
/usr/src/dev/orig/php-src_5_1/Zend/zend_execute_API.c:190
#12 0x082559a6 in zend_call_destructors () at
/usr/src/dev/orig/php-src_5_1/Zend/zend.c:817
#13 0x08214b38 in php_request_shutdown (dummy=0x0) at
/usr/src/dev/orig/php-src_5_1/main/main.c:1210
#14 0x082c1093 in main (argc=2, argv=0xbfffefb4) at
/usr/src/dev/orig/php-src_5_1/sapi/cli/php_cli.c:1142
--
Edit bug report at http://bugs.php.net/?id=34810edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=34810r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=34810r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=34810r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=34810r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=34810r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=34810r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=34810r=needscript
Try newer version: http://bugs.php.net/fix.php?id=34810r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=34810r=support
Expected behavior: http://bugs.php.net/fix.php?id=34810r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=34810r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=34810r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=34810r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=34810r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=34810r=dst
IIS Stability: http://bugs.php.net/fix.php?id=34810r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=34810r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=34810r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=34810r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=34810r=mysqlcfg
#34810 [Opn-Asn]: mysqli::init() and others use wrong $this pointer without checks
ID: 34810
Updated by: [EMAIL PROTECTED]
Reported By: antony at zend dot com
-Status: Open
+Status: Assigned
Bug Type: Reproducible crash
Operating System: Linux
PHP Version: 5.1.0RC1
-Assigned To:
+Assigned To: tony2001
Previous Comments:
[2005-10-10 14:37:56] antony at zend dot com
Description:
mysqli::init(), mysqli::connect() and mysqli_warning::__construct() use
wrong inherited $this pointer without checking if this_ptr really points
to the mysqli_object.
In particular conditions this can lead to segfault.
Reproduce code:
---
class DbConnection {
private $link = NULL;
public function connect() {
$this-link = mysqli::init();
var_dump($this-link);
}
}
$db = new DbConnection();
$db-connect();
Actual result:
--
*** glibc detected *** free(): invalid pointer: 0xbfffece4 ***
Program received signal SIGABRT, Aborted.
[Switching to Thread 1076990336 (LWP 24078)]
0xe410 in ?? ()
(gdb) bt
#0 0xe410 in ?? ()
#1 0xbfffe224 in ?? ()
#2 0x0006 in ?? ()
#3 0x5e0e in ?? ()
#4 0x400ec2c1 in raise () from /lib/tls/libc.so.6
#5 0x400edb75 in abort () from /lib/tls/libc.so.6
#6 0x401207aa in __libc_message () from /lib/tls/libc.so.6
#7 0x40126007 in malloc_printerr () from /lib/tls/libc.so.6
#8 0x401276cb in free () from /lib/tls/libc.so.6
#9 0x080c1364 in mysqli_objects_destroy_object (object=0x85585a8,
handle=3) at /usr/src/dev/orig/php-src_5_1/ext/mysqli/mysqli.c:152
#10 0x0826ed46 in zend_objects_store_call_destructors
(objects=0x84b36ec) at
/usr/src/dev/orig/php-src_5_1/Zend/zend_objects_API.c:55
#11 0x08249416 in shutdown_destructors () at
/usr/src/dev/orig/php-src_5_1/Zend/zend_execute_API.c:190
#12 0x082559a6 in zend_call_destructors () at
/usr/src/dev/orig/php-src_5_1/Zend/zend.c:817
#13 0x08214b38 in php_request_shutdown (dummy=0x0) at
/usr/src/dev/orig/php-src_5_1/main/main.c:1210
#14 0x082c1093 in main (argc=2, argv=0xbfffefb4) at
/usr/src/dev/orig/php-src_5_1/sapi/cli/php_cli.c:1142
--
Edit this bug report at http://bugs.php.net/?id=34810edit=1
#34810 [Asn-Csd]: mysqli::init() and others use wrong $this pointer without checks
ID: 34810
Updated by: [EMAIL PROTECTED]
Reported By: antony at zend dot com
-Status: Assigned
+Status: Closed
Bug Type: Reproducible crash
Operating System: Linux
PHP Version: 5.1.0RC1
Assigned To: tony2001
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-10-10 14:37:56] antony at zend dot com
Description:
mysqli::init(), mysqli::connect() and mysqli_warning::__construct() use
wrong inherited $this pointer without checking if this_ptr really points
to the mysqli_object.
In particular conditions this can lead to segfault.
Reproduce code:
---
class DbConnection {
private $link = NULL;
public function connect() {
$this-link = mysqli::init();
var_dump($this-link);
}
}
$db = new DbConnection();
$db-connect();
Actual result:
--
*** glibc detected *** free(): invalid pointer: 0xbfffece4 ***
Program received signal SIGABRT, Aborted.
[Switching to Thread 1076990336 (LWP 24078)]
0xe410 in ?? ()
(gdb) bt
#0 0xe410 in ?? ()
#1 0xbfffe224 in ?? ()
#2 0x0006 in ?? ()
#3 0x5e0e in ?? ()
#4 0x400ec2c1 in raise () from /lib/tls/libc.so.6
#5 0x400edb75 in abort () from /lib/tls/libc.so.6
#6 0x401207aa in __libc_message () from /lib/tls/libc.so.6
#7 0x40126007 in malloc_printerr () from /lib/tls/libc.so.6
#8 0x401276cb in free () from /lib/tls/libc.so.6
#9 0x080c1364 in mysqli_objects_destroy_object (object=0x85585a8,
handle=3) at /usr/src/dev/orig/php-src_5_1/ext/mysqli/mysqli.c:152
#10 0x0826ed46 in zend_objects_store_call_destructors
(objects=0x84b36ec) at
/usr/src/dev/orig/php-src_5_1/Zend/zend_objects_API.c:55
#11 0x08249416 in shutdown_destructors () at
/usr/src/dev/orig/php-src_5_1/Zend/zend_execute_API.c:190
#12 0x082559a6 in zend_call_destructors () at
/usr/src/dev/orig/php-src_5_1/Zend/zend.c:817
#13 0x08214b38 in php_request_shutdown (dummy=0x0) at
/usr/src/dev/orig/php-src_5_1/main/main.c:1210
#14 0x082c1093 in main (argc=2, argv=0xbfffefb4) at
/usr/src/dev/orig/php-src_5_1/sapi/cli/php_cli.c:1142
--
Edit this bug report at http://bugs.php.net/?id=34810edit=1
#34429 [Com]: Output buffering cannot be turned off with FastCGI
ID: 34429
Comment by: pdxtechie at gmail dot com
Reported By: zimage at icdsoft dot com
Status: Open
Bug Type: CGI related
Operating System: *
PHP Version: 5CVS, 4CVS (2005-09-12)
New Comment:
This would also be useful for Ajax (using, for example, the
RicoAjaxEngine.) If you are unable to disable buffering, there is no
way to stream XML for progress updates through Ajax.
Previous Comments:
[2005-09-12 16:08:04] zimage at icdsoft dot com
It could be also used for writing progress bars. On a random shared
hosting server:
locate .php |wc -l
25147
locate .php |xargs -n1 -i grep -H -e flush *( {}
641
So people are using it for some reason... I can see flush() used in
Moveable Type, Word Press, MediaWiki and so on.
[2005-09-12 15:49:27] [EMAIL PROTECTED]
Writing such things using PHP is pretty useless IMO, but if it works
with other SAPIs..
[2005-09-12 15:47:25] zimage at icdsoft dot com
This is how you could write a chat client for example. Connection is
kept open for the duration of chat session and php script is looping
over the client and server messages.
[2005-09-10 22:56:11] [EMAIL PROTECTED]
How would it be useful to be able to turn it off?
[2005-09-09 11:25:26] zimage at icdsoft dot com
And strace of php process looks like:
read(4, ?php\n\tfor ($i=0; $i4; $i++){\n\t..., 8192) = 65
read(4, , 4096) = 0
read(4, , 8192) = 0
close(4)= 0
munmap(0x4056b000, 4096)= 0
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
rt_sigaction(SIGCHLD, NULL, {SIG_DFL}, 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
nanosleep({1, 0}, {1, 0}) = 0
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
rt_sigaction(SIGCHLD, NULL, {SIG_DFL}, 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
nanosleep({1, 0}, {1, 0}) = 0
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
rt_sigaction(SIGCHLD, NULL, {SIG_DFL}, 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
nanosleep({1, 0}, {1, 0}) = 0
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
rt_sigaction(SIGCHLD, NULL, {SIG_DFL}, 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
nanosleep({1, 0}, {1, 0}) = 0
setitimer(ITIMER_PROF, {it_interval={0, 0}, it_value={0, 0}}, NULL) =
0
write(3, [EMAIL PROTECTED]: text/html\r..., 96) = 96
I.e. there are 4 calls to sleep and the script output is writen at
once. Any
pointers to documentation or further tests that I should perform are
welcome.
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/34429
--
Edit this bug report at http://bugs.php.net/?id=34429edit=1
#29985 [Asn]: unserialize()/ __PHP_Incomplete_class does not report correctly class name
ID: 29985 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Assigned Bug Type: Session related Operating System: * PHP Version: 5CVS-2005-10-06 (snap) Assigned To: helly New Comment: Could also reproduce that simple testcase with mod_php/Apache 1.3/Win32 mod_php/Apache 2.0/Linux (not with the latest CVS but with PHP 5.0.4 (which does not matter if it's only fixed in HEAD) Previous Comments: [2005-10-10 11:38:23] [EMAIL PROTECTED] Marcus..? [2005-10-10 09:42:15] [EMAIL PROTECTED] Sorry, this has nothing to do with CLI. It also happens in a much more complex (mod_php) web enviroment. There is no unknown in my reproduction code and I can't see, what --- Fatal error: main(): The script tried to execute a method or access a property of an incomplete object. Please ensure that the class definition bar of the object you are trying to operate on was loaded _before_ unserialize() gets called or provide a __autoload() function to load the class definition in C:\Dokumente und Einstellungen\nohn_s\Desktop\php5.1-win32-200510031830\test.php on line 2 --- has to do with the CLI or the causing location. [2005-10-09 15:36:10] [EMAIL PROTECTED] Thank you for your bug report. This issue has already been fixed in the latest released version of PHP, which you can download at http://www.php.net/downloads.php This is fixed in all actrive branches, 4.3.*, 5.0.*, 5.1.*, HEAD. The 'Unknown' comes from cli and specifies the causing location and has nothing to do with the class name. [2005-10-09 15:27:25] [EMAIL PROTECTED] I claimed fixed in CVS which is HEAD which will be 6 not any 5.* [2005-10-06 18:27:38] [EMAIL PROTECTED] Marcus, you claimed to have fixed this. Can you check it out? 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/29985 -- Edit this bug report at http://bugs.php.net/?id=29985edit=1
#34811 [NEW]: fdf_get_value max size
From: kc at netspirit dot ch Operating system: Linux PHP version: 4.4.0 PHP Bug Type: FDF related Bug description: fdf_get_value max size Description: Problem getting value of PDF-Multiline-Fields if the value is loger than 256 chars. found ASInt32 nr, size = 256; in PHP_FUNCTION(fdf_get_value) in ext/fdf/fdf.c Reproduce code: --- Reprodiction: - go to: http://www.anyform.ch/test/132.pdf - fill in the big field - click on Ausgabe-Optionen Expected result: strText32 is of type string hdsfj ... sdfhjsd Actual result: -- strText32 is of type boolean -- Edit bug report at http://bugs.php.net/?id=34811edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=34811r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=34811r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=34811r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=34811r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=34811r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=34811r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=34811r=needscript Try newer version: http://bugs.php.net/fix.php?id=34811r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=34811r=support Expected behavior: http://bugs.php.net/fix.php?id=34811r=notwrong Not enough info: http://bugs.php.net/fix.php?id=34811r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=34811r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=34811r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=34811r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=34811r=dst IIS Stability: http://bugs.php.net/fix.php?id=34811r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=34811r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=34811r=float No Zend Extensions: http://bugs.php.net/fix.php?id=34811r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=34811r=mysqlcfg
#34811 [Opn-Fbk]: fdf_get_value max size
ID: 34811 Updated by: [EMAIL PROTECTED] Reported By: kc at netspirit dot ch -Status: Open +Status: Feedback Bug Type: FDF related Operating System: Linux PHP Version: 4.4.0 New Comment: Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with ?php and ends with ?, is max. 10-20 lines long and does not require any external resources such as databases, etc. If possible, make the script source available online and provide an URL to it here. Try to avoid embedding huge scripts into the report. Previous Comments: [2005-10-10 15:45:00] kc at netspirit dot ch Description: Problem getting value of PDF-Multiline-Fields if the value is loger than 256 chars. found ASInt32 nr, size = 256; in PHP_FUNCTION(fdf_get_value) in ext/fdf/fdf.c Reproduce code: --- Reprodiction: - go to: http://www.anyform.ch/test/132.pdf - fill in the big field - click on Ausgabe-Optionen Expected result: strText32 is of type string hdsfj ... sdfhjsd Actual result: -- strText32 is of type boolean -- Edit this bug report at http://bugs.php.net/?id=34811edit=1
#34811 [Fbk-Opn]: fdf_get_value max size
ID: 34811
User updated by: kc at netspirit dot ch
Reported By: kc at netspirit dot ch
-Status: Feedback
+Status: Open
Bug Type: FDF related
Operating System: Linux
PHP Version: 4.4.0
New Comment:
code i used:
?php
$pdformp = fopen(./test.dat, w);
$fdf = fdf_open_string($HTTP_FDF_DATA);
while ($field = fdf_next_field_name($fdf, $field)) {
echo $field is of type . gettype ( fdf_get_value ( $fdf, $field ) )
. \ . fdf_get_value ( $fdf, $field ) . \ ;
fwrite($pdformp, $field= . fdf_get_value ( $fdf, $field ) . \n);
}
fdf_close($fdf);
fclose($pdformp);
?
Previous Comments:
[2005-10-10 15:50:56] [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 ?php and ends with ?,
is max. 10-20 lines long and does not require any external
resources such as databases, etc.
If possible, make the script source available online and provide
an URL to it here. Try to avoid embedding huge scripts into the report.
[2005-10-10 15:45:00] kc at netspirit dot ch
Description:
Problem getting value of PDF-Multiline-Fields if the value is loger
than 256 chars.
found ASInt32 nr, size = 256; in PHP_FUNCTION(fdf_get_value) in
ext/fdf/fdf.c
Reproduce code:
---
Reprodiction:
- go to: http://www.anyform.ch/test/132.pdf
- fill in the big field
- click on Ausgabe-Optionen
Expected result:
strText32 is of type string hdsfj ... sdfhjsd
Actual result:
--
strText32 is of type boolean
--
Edit this bug report at http://bugs.php.net/?id=34811edit=1
#34812 [NEW]: socket_write will not write a string ending in 0 Zero
From: shane at 71software dot com
Operating system: Windows XP
PHP version: 5.1.0RC1
PHP Bug Type: Sockets related
Bug description: socket_write will not write a string ending in 0 Zero
Description:
I am using sockets to log in to a Cisco router. I need to issues the
command terminal length 0. The 0 must return a FALSE or NULL status to
socket_write or maybe socket_read is what is actually returning false I am
not sure. But it will not work in Binary, ASCII, OCTAL, HEX anything.
Reproduce code:
---
$IosCmdExec = 'terminal length 0' . \n;
socket_write($socket, $IosCmdExec, strlen($IosCmdExec));
$makeCaptureFile = 'C:\rtrconfig\config.txt';
$captureFile = fopen($makeCaptureFile,'a');
$out = '';
while ($out = socket_read($socket, 1024)){
ereg_replace(\r, ' ', $out);
fwrite($captureFile, $out);
}
$sep =
'***';
fwrite($captureFile, $sep);
socket_shutdown($socket, 2);
socket_close($socket);
Expected result:
I expect the writing of 'terminal length 0' to the Cisco CLI. It works
fine as long as the digit is not 0. 1-512 etc.
xx#terminal length 512
Building configuration...
Current configuration : 26921 bytes
!
! Last configuration change at 07:00:37 CDT Tue Jun 28 2005 by amschultz
! NVRAM config last updated at 06:38:49 CDT Mon Jun 20
!
version 12.2
no service pad
service timestamps debug datetime msec localtime show-timezone
service timestamps log datetime msec localtime show-timezone
service password-encryption
service compress-config
!
hostname xx
!
logging buffered 512000 debugging
aaa new-model
aaa authentication login default group tacacs+ local
etc..
Actual result:
--
xxx#terminal length
***
NOTE: 'xxx#' being the router prompt
--
Edit bug report at http://bugs.php.net/?id=34812edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=34812r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=34812r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=34812r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=34812r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=34812r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=34812r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=34812r=needscript
Try newer version: http://bugs.php.net/fix.php?id=34812r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=34812r=support
Expected behavior: http://bugs.php.net/fix.php?id=34812r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=34812r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=34812r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=34812r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=34812r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=34812r=dst
IIS Stability: http://bugs.php.net/fix.php?id=34812r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=34812r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=34812r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=34812r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=34812r=mysqlcfg
#34807 [Fbk-Opn]: Interface is forced on child classes even though parent class has implemented.
ID: 34807
User updated by: daarius at hotmail dot com
Reported By: daarius at hotmail dot com
-Status: Feedback
+Status: Open
Bug Type: Class/Object related
Operating System: WinXP
PHP Version: 5.0.5
New Comment:
I have tried the latest snapshot. The error is some on there too.
Previous Comments:
[2005-10-10 12:32:22] [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-10-10 12:27:02] daarius at hotmail dot com
Description:
The interface of a parent class is also forced to be implemented on to
the children classes if they use methods with same name as in
Interface. Even though the parent class has implemented the methods
declared in the Interface legally.
Reproduce code:
---
interface MyInterface {
public function Z($s);
}
class MyClass implements MyInterface {
public function Z($s) {}
}
class MySubClass extends MyClass {
public function Z() {}
}
Expected result:
Above should be legal (at least i think), because parent is
implementing the interface, the child is just extending the parent's
method.
But, if we remove the method completely from child class, then there is
no error message and Interface is no longer being forced on to child.
This suggests inconsistency.
Also, if we remove the interface from the code, then the parent child
extension of the same method name is still legal, as the number of
arguments is not being checked anymore.
Actual result:
--
Fatal error: Declaration of MySubClass::Z() must be compatible with
that of MyInterface::Z() in C:\httpd\PHPObject3.0\index.php on line 12
--
Edit this bug report at http://bugs.php.net/?id=34807edit=1
#34809 [Asn-Csd]: PDO FETCH_INTO crashes Apache
ID: 34809
Updated by: [EMAIL PROTECTED]
Reported By: stochnagara at hotmail dot com
-Status: Assigned
+Status: Closed
Bug Type: PDO related
Operating System: windows xp
PHP Version: 5CVS-2005-10-10 (snap)
Assigned To: wez
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-10-10 13:05:13] [EMAIL PROTECTED]
Assigned to the maintainer.
[2005-10-10 13:03:23] stochnagara at hotmail dot com
Sorry,
General error: PDO_FETCH_FUNC is only allowed in
should be read as
General error: PDO_FETCH_INTO is only allowed in
or just fetch record in mode FETCH_INTO if this is allowed.
[2005-10-10 12:58:41] stochnagara at hotmail dot com
Description:
The code bellow crashes Apache server. The crash is similar to bug
#34802 but the crash code is quite different.
Reproduce code:
---
?
$pdo = new PDO('mysql:host=localhost;dbname=borovo');
$sth = $pdo-prepare ('SELECT nid,type FROM node');
$sth-execute();
var_dump ($sth-fetch (PDO::FETCH_INTO, 3));
Expected result:
Warning: PDOStatement::fetch() [function.fetch]: SQLSTATE[HY000]:
General error: PDO_FETCH_FUNC is only allowed in
PDOStatement::fetchAll() in C:\Program Files\Apache
Group\Apache2\htdocs\boroinvest\test.php on line 5
bool(false)
Actual result:
--
Apache crashes.
Log message:
Parent: child process exited with status 3221225477 -- Restarting.
--
Edit this bug report at http://bugs.php.net/?id=34809edit=1
#34802 [Asn-Csd]: new PDORow crashes Apache
ID: 34802 Updated by: [EMAIL PROTECTED] Reported By: stochnagara at hotmail dot com -Status: Assigned +Status: Closed Bug Type: PDO related Operating System: windows xp PHP Version: 5CVS-2005-10-10 (snap) Assigned To: wez 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-10-10 11:35:16] [EMAIL PROTECTED] Assigned to maintainer. [2005-10-10 09:43:23] stochnagara at hotmail dot com Still present in latest version. [2005-10-10 08:54:19] [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-10-10 07:57:01] stochnagara at hotmail dot com Description: Creating a new PDORow object crashes my Apache. The error log contains the correct error message for this case: PHP Fatal error: PDORow::__construct() [a href='function.--construct'function.--construct/a]: You should not create a PDOStatement manually in ...\pdo.php on line 2 But crashing Apache is not the correct behaviour. Reproduce code: --- ? $q= new PDORow(); ? Expected result: PHP Fatal error: PDORow::__construct() [a href='function.--construct'function.--construct/a]: You should not create a PDOStatement manually in ...\pdo.php on line 2 Actual result: -- Apache crashes. -- Edit this bug report at http://bugs.php.net/?id=34802edit=1
#34798 [Bgs]: mysqli-set_charset is an undefined method
ID: 34798 User updated by: jarnix at jarnix dot com Reported By: jarnix at jarnix dot com Status: Bogus Bug Type: MySQLi related Operating System: Windows XP SP2 PHP Version: 5.1.0RC1 New Comment: Here is an extract from the phpinfo() output : mysqli Client API version 5.0.13-rc I use the latest versions of PHP and Mysql client. I'm using a Windows build. Maybe there is something wrong with this build ? Previous Comments: [2005-10-10 09:37:47] [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 You have to compile PHP with a newer MySQL client library. For MySQL 4.1 you need 4.1.13 or above, for MySQL 5.0 you need MySQL 5.0.5 or above [2005-10-10 07:48:54] [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-10-09 23:36:29] jarnix at jarnix dot com Description: set_charset method is undefined Reproduce code: --- $mysqli = new mysqli(localhost, root, , mysql); $mysqli-set_charset(utf8); Expected result: nothing Actual result: -- Fatal error: Call to undefined method mysqli::set_charset() (...) on line 2 -- Edit this bug report at http://bugs.php.net/?id=34798edit=1
#34814 [Opn-Fbk]: Query in a function for execution on shutdown
ID: 34814
Updated by: [EMAIL PROTECTED]
Reported By: egrossi at simplestnet dot com
-Status: Open
+Status: Feedback
Bug Type: MySQLi related
Operating System: Win2k, WinXP
PHP Version: 5.0.5
New Comment:
Please try using this CVS snapshot:
http://snaps.php.net/php5-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.0-win32-latest.zip
Previous Comments:
[2005-10-10 18:38:58] egrossi at simplestnet dot com
Description:
SQL Query like INSERT, inside a function called by
register_shutdown_function() doesn't work on PHP 5.0.5 but work
perferctly in PHP 5.0.4 and before or with MySQL extension.
Note: the MySQL link identifier is created and passed in arguments of
shutdown function.
Reproduce code:
---
function cb_shutdown( $lk ) {
mysqli_query($lk, INSERT INTO `log`
(`ip`, `data`)
VALUES ('127.0.0.1', 'test'));
}
$link = mysqli_connect( localhost, $db_user, $db_pass, $db_name);
register_shutdown_function(cb_shutdown, $link);
Expected result:
A new record in `log` table.
Actual result:
--
No record added and warning:
Couldn't fetch mysqli
--
Edit this bug report at http://bugs.php.net/?id=34814edit=1
#34814 [Opn-Csd]: Query in a function for execution on shutdown
ID: 34814
Updated by: [EMAIL PROTECTED]
Reported By: egrossi at simplestnet dot com
-Status: Open
+Status: Closed
Bug Type: MySQLi related
Operating System: Win2k, WinXP
PHP Version: 5.0.5
New Comment:
Good, that means it's fixed then :)
Previous Comments:
[2005-10-10 19:00:20] egrossi at simplestnet dot com
Work well with this CVS snapshot of 2005 oct 10:
http://snaps.php.net/win32/php5.0-win32-latest.zip
[2005-10-10 18:44:45] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.0-win32-latest.zip
[2005-10-10 18:38:58] egrossi at simplestnet dot com
Description:
SQL Query like INSERT, inside a function called by
register_shutdown_function() doesn't work on PHP 5.0.5 but work
perferctly in PHP 5.0.4 and before or with MySQL extension.
Note: the MySQL link identifier is created and passed in arguments of
shutdown function.
Reproduce code:
---
function cb_shutdown( $lk ) {
mysqli_query($lk, INSERT INTO `log`
(`ip`, `data`)
VALUES ('127.0.0.1', 'test'));
}
$link = mysqli_connect( localhost, $db_user, $db_pass, $db_name);
register_shutdown_function(cb_shutdown, $link);
Expected result:
A new record in `log` table.
Actual result:
--
No record added and warning:
Couldn't fetch mysqli
--
Edit this bug report at http://bugs.php.net/?id=34814edit=1
#34815 [NEW]: Unable compile php 5 with informix csdk 2.90 UC3 and apache 1.3.33.
From: info at aplext dot com Operating system: Fedora Core 3 PHP version: 5.0.5 PHP Bug Type: Compile Failure Bug description: Unable compile php 5 with informix csdk 2.90 UC3 and apache 1.3.33. Description: I compile php 5 with informix csdk 2.90 UC3 and apache 1.3.33 on fedora core 3 Reproduce code: --- parameters of configure: --with-informix --with-apxs2 Expected result: no errors Actual result: -- /usr/lib/gcc/i386-redhat-linux/3.4.2/../../../crt1.o(.text+0x18): In function `_start': : undefined reference to `main' ext/standard/info.lo(.text+0x7): In function `php_info_print_table_start': /opt/web/php/php-5.0.5/ext/standard/info.c:731: undefined reference to `sapi_module' ext/standard/info.lo(.text+0x18):/opt/web/php/php-5.0.5/ext/standard/info.c:734: undefined reference to `php_printf' ext/standard/info.lo(.text+0x2d):/opt/web/php/php-5.0.5/ext/standard/info.c:734: undefined reference to `php_printf' ext/standard/info.lo(.text+0x40): In function `php_info_print_table_end': /opt/web/php/php-5.0.5/ext/standard/info.c:740: undefined reference to `sapi_module' ext/standard/info.lo(.text+0x55):/opt/web/php/php-5.0.5/ext/standard/info.c:741: undefined reference to `php_printf' ext/standard/info.lo(.text+0x6c): In function `php_info_print_style': /opt/web/php/php-5.0.5/ext/standard/info.c:204: undefined reference to `php_printf' ext/standard/info.lo(.text+0x71):/opt/web/php/php-5.0.5/ext/standard/info.c:205: undefined reference to `php_info_print_css' ext/standard/info.lo(.text+0x7d):/opt/web/php/php-5.0.5/ext/standard/info.c:206: undefined reference to `php_printf' ext/standard/info.lo(.text+0xaa): In function `php_info_html_esc': /opt/web/php/php-5.0.5/ext/standard/info.c:216: undefined reference to `php_escape_html_entities' -- Edit bug report at http://bugs.php.net/?id=34815edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=34815r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=34815r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=34815r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=34815r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=34815r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=34815r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=34815r=needscript Try newer version: http://bugs.php.net/fix.php?id=34815r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=34815r=support Expected behavior: http://bugs.php.net/fix.php?id=34815r=notwrong Not enough info: http://bugs.php.net/fix.php?id=34815r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=34815r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=34815r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=34815r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=34815r=dst IIS Stability: http://bugs.php.net/fix.php?id=34815r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=34815r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=34815r=float No Zend Extensions: http://bugs.php.net/fix.php?id=34815r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=34815r=mysqlcfg
#34816 [NEW]: Inconsitent behavior in ArrayObject for multi-dimensional data
From: adove at booyahnetworks dot com
Operating system: WinXP
PHP version: 5.1.0RC1
PHP Bug Type: SPL related
Bug description: Inconsitent behavior in ArrayObject for multi-dimensional data
Description:
If you create an ArrayObject with mutli-dimensional array data, you can
access unique element paths fine but you can not change/add any
multi-dimensional paths due to the dreaded Fatal error: Objects used as
arrays in post/pre increment/decrement must return values by reference
error. Note this happens in BOTH 5.0.5 AND 5.1.0RC1.
IMHO, either the documentation for ArrayObject should clearly indicate
that it supports uni-dimenisional data get/set and ONLY get for
multi-dimensional. OR, the object walk the passed data and turn all arrays
into ArrayObject instances?
Reproduce code:
---
$a = array(
test = array(
one = dunno,
two = array(
peekabo = do you see me?,
anyone = array(there)
)
)
);
$oArray = new ArrayObject($a);
var_dump($oArray);
echo \n\\test\\one == . $oArray[test][one] . \n\n;
// NEITHER of the two below will work!
$oArray[test][one] = Yes I do!;
$oArray[test][yes] = array(
hello = Goodbye!
);
var_dump($oArray);
Expected result:
object(ArrayObject)#1 (1) {
[test]=
array(2) {
[one]=
string(5) dunno
[two]=
array(2) {
[peekabo]=
string(14) do you see me?
[anyone]=
array(1) {
[0]=
string(5) there
}
}
}
}
\test\one == dunno
object(ArrayObject)#1 (1) {
[test]=
array(2) {
[one]=
string(5) Yes I do!
[two]=
array(2) {
[peekabo]=
string(14) do you see me?
[anyone]=
array(1) {
[0]=
string(5) there
}
}
[yes]=
array(1) {
[hello]=
string(8) Goodbye!
}
}
}
Actual result:
--
object(ArrayObject)#1 (1) {
[test]=
array(2) {
[one]=
string(5) dunno
[two]=
array(2) {
[peekabo]=
string(14) do you see me?
[anyone]=
array(1) {
[0]=
string(5) there
}
}
}
}
\test\one == dunno
Fatal error: Objects used as arrays in post/pre increment/decrement must
return values by reference in array_obje_test.php on line 16
--
Edit bug report at http://bugs.php.net/?id=34816edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=34816r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=34816r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=34816r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=34816r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=34816r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=34816r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=34816r=needscript
Try newer version: http://bugs.php.net/fix.php?id=34816r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=34816r=support
Expected behavior: http://bugs.php.net/fix.php?id=34816r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=34816r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=34816r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=34816r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=34816r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=34816r=dst
IIS Stability: http://bugs.php.net/fix.php?id=34816r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=34816r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=34816r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=34816r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=34816r=mysqlcfg
#34816 [Opn-Asn]: Inconsitent behavior in ArrayObject for multi-dimensional data
ID: 34816
Updated by: [EMAIL PROTECTED]
Reported By: adove at booyahnetworks dot com
-Status: Open
+Status: Assigned
Bug Type: SPL related
Operating System: WinXP
PHP Version: 5.1.0RC1
-Assigned To:
+Assigned To: helly
New Comment:
marcus, this is your baby :)
Previous Comments:
[2005-10-10 19:42:23] adove at booyahnetworks dot com
Description:
If you create an ArrayObject with mutli-dimensional array data, you can
access unique element paths fine but you can not change/add any
multi-dimensional paths due to the dreaded Fatal error: Objects used
as arrays in post/pre increment/decrement must return values by
reference error. Note this happens in BOTH 5.0.5 AND 5.1.0RC1.
IMHO, either the documentation for ArrayObject should clearly indicate
that it supports uni-dimenisional data get/set and ONLY get for
multi-dimensional. OR, the object walk the passed data and turn all
arrays into ArrayObject instances?
Reproduce code:
---
$a = array(
test = array(
one = dunno,
two = array(
peekabo = do you see me?,
anyone = array(there)
)
)
);
$oArray = new ArrayObject($a);
var_dump($oArray);
echo \n\\test\\one == . $oArray[test][one] . \n\n;
// NEITHER of the two below will work!
$oArray[test][one] = Yes I do!;
$oArray[test][yes] = array(
hello = Goodbye!
);
var_dump($oArray);
Expected result:
object(ArrayObject)#1 (1) {
[test]=
array(2) {
[one]=
string(5) dunno
[two]=
array(2) {
[peekabo]=
string(14) do you see me?
[anyone]=
array(1) {
[0]=
string(5) there
}
}
}
}
\test\one == dunno
object(ArrayObject)#1 (1) {
[test]=
array(2) {
[one]=
string(5) Yes I do!
[two]=
array(2) {
[peekabo]=
string(14) do you see me?
[anyone]=
array(1) {
[0]=
string(5) there
}
}
[yes]=
array(1) {
[hello]=
string(8) Goodbye!
}
}
}
Actual result:
--
object(ArrayObject)#1 (1) {
[test]=
array(2) {
[one]=
string(5) dunno
[two]=
array(2) {
[peekabo]=
string(14) do you see me?
[anyone]=
array(1) {
[0]=
string(5) there
}
}
}
}
\test\one == dunno
Fatal error: Objects used as arrays in post/pre increment/decrement
must return values by reference in array_obje_test.php on line 16
--
Edit this bug report at http://bugs.php.net/?id=34816edit=1
#34816 [Asn-Bgs]: Inconsitent behavior in ArrayObject for multi-dimensional data
ID: 34816
Updated by: [EMAIL PROTECTED]
Reported By: adove at booyahnetworks dot com
-Status: Assigned
+Status: Bogus
Bug Type: SPL related
Operating System: WinXP
PHP Version: 5.1.0RC1
Assigned To: helly
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
ArrayObject/ArrayIterator simply implement the ArrayAccess imnterface
which doesn't handle multi dimensional array syntax. As you pointer out
already you could have ArrayObject store ArrayObjects itself. Thus the
solution is to overwrite ArrayObject.
Previous Comments:
[2005-10-10 19:51:36] [EMAIL PROTECTED]
marcus, this is your baby :)
[2005-10-10 19:42:23] adove at booyahnetworks dot com
Description:
If you create an ArrayObject with mutli-dimensional array data, you can
access unique element paths fine but you can not change/add any
multi-dimensional paths due to the dreaded Fatal error: Objects used
as arrays in post/pre increment/decrement must return values by
reference error. Note this happens in BOTH 5.0.5 AND 5.1.0RC1.
IMHO, either the documentation for ArrayObject should clearly indicate
that it supports uni-dimenisional data get/set and ONLY get for
multi-dimensional. OR, the object walk the passed data and turn all
arrays into ArrayObject instances?
Reproduce code:
---
$a = array(
test = array(
one = dunno,
two = array(
peekabo = do you see me?,
anyone = array(there)
)
)
);
$oArray = new ArrayObject($a);
var_dump($oArray);
echo \n\\test\\one == . $oArray[test][one] . \n\n;
// NEITHER of the two below will work!
$oArray[test][one] = Yes I do!;
$oArray[test][yes] = array(
hello = Goodbye!
);
var_dump($oArray);
Expected result:
object(ArrayObject)#1 (1) {
[test]=
array(2) {
[one]=
string(5) dunno
[two]=
array(2) {
[peekabo]=
string(14) do you see me?
[anyone]=
array(1) {
[0]=
string(5) there
}
}
}
}
\test\one == dunno
object(ArrayObject)#1 (1) {
[test]=
array(2) {
[one]=
string(5) Yes I do!
[two]=
array(2) {
[peekabo]=
string(14) do you see me?
[anyone]=
array(1) {
[0]=
string(5) there
}
}
[yes]=
array(1) {
[hello]=
string(8) Goodbye!
}
}
}
Actual result:
--
object(ArrayObject)#1 (1) {
[test]=
array(2) {
[one]=
string(5) dunno
[two]=
array(2) {
[peekabo]=
string(14) do you see me?
[anyone]=
array(1) {
[0]=
string(5) there
}
}
}
}
\test\one == dunno
Fatal error: Objects used as arrays in post/pre increment/decrement
must return values by reference in array_obje_test.php on line 16
--
Edit this bug report at http://bugs.php.net/?id=34816edit=1
#34818 [NEW]: new mysqli_stmt() crashes if first parameter is not a valid mysqli_link
From: squasar at eternalviper dot net
Operating system: *
PHP version: 5.1.0RC1
PHP Bug Type: MySQLi related
Bug description: new mysqli_stmt() crashes if first parameter is not a valid
mysqli_link
Description:
Calling __construct() on mysqli_stmt with an unset variable
as the mysqli_link crashes PHP in mysqli_stmt_construct.
Note that this is actually 5.1.0RC2 (CVS tag
php_5_1_0RC2_PRE). This may affect other MySQLi functions
(?). A possible fix, minus a more informative error message
is here, but my instinct says there may be more going on
behind this than the check in MYSQLI_FETCH_RESOURCE() since
passing a literal NULL or similar instead of an undefined
variable gives an error message instead of crashing.
Index: ext/mysqli/php_mysqli.h
===
RCS file: /repository/php-src/ext/mysqli/php_mysqli.h,v
retrieving revision 1.54
diff -u -r1.54 php_mysqli.h
--- ext/mysqli/php_mysqli.h 3 Aug 2005 14:07:31 -
1.54
+++ ext/mysqli/php_mysqli.h 10 Oct 2005 19:17:35 -
@@ -202,7 +202,12 @@
#define MYSQLI_FETCH_RESOURCE(__ptr, __type, __id, __name)
\
{ \
MYSQLI_RESOURCE *my_res; \
- mysqli_object *intern = (mysqli_object *)
zend_object_store_get_object(*(__id) TSRMLS_CC);\
+ mysqli_object *intern = NULL; \
+ if (Z_TYPE_PP(__id) != IS_OBJECT) {\
+ php_error(E_WARNING, Object parameter
invalid); \
+ RETURN_NULL(); \
+ } \
+ intern = (mysqli_object *)
zend_object_store_get_object(*(__id) TSRMLS_CC);\
if (!(my_res = (MYSQLI_RESOURCE *)intern-ptr)) {\
php_error(E_WARNING, Couldn't fetch %s,
intern-zo.ce-name);\
RETURN_NULL();\
Reproduce code:
---
?php $s = new mysqli_stmt( $undefined, SELECT 1 FROM DUAL ); ?
Expected result:
Warning: Object parameter invalid in - on line 1
Actual result:
--
Bus error
Thread 0 Crashed:
0 php 0x000c1bb8 zif_mysqli_stmt_construct + 252
(mysqli.c:675)
1 php 0x0020ab88 zend_do_fcall_common_helper_SPEC + 1560
(zend_vm_execute.h:184)
2 php 0x0020a4c4 execute + 520 (zend_vm_execute.h:87)
3 php 0x001e0630 zend_execute_scripts + 444 (zend.c:
1079)
4 php 0x00195334 php_execute_script + 780 (main.c:1679)
5 php 0x002921ac main + 3684 (php_cli.c:1040)
6 php 0x2b58 _start + 344 (crt.c:272)
7 php 0x29fc start + 60
--
Edit bug report at http://bugs.php.net/?id=34818edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=34818r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=34818r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=34818r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=34818r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=34818r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=34818r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=34818r=needscript
Try newer version: http://bugs.php.net/fix.php?id=34818r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=34818r=support
Expected behavior: http://bugs.php.net/fix.php?id=34818r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=34818r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=34818r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=34818r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=34818r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=34818r=dst
IIS Stability: http://bugs.php.net/fix.php?id=34818r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=34818r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=34818r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=34818r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=34818r=mysqlcfg
#34818 [Opn-Asn]: new mysqli_stmt() crashes if first parameter is not a valid mysqli_link
ID: 34818
Updated by: [EMAIL PROTECTED]
Reported By: squasar at eternalviper dot net
-Status: Open
+Status: Assigned
Bug Type: MySQLi related
Operating System: *
PHP Version: 5.1.0RC1
-Assigned To:
+Assigned To: tony2001
Previous Comments:
[2005-10-10 21:24:40] squasar at eternalviper dot net
Description:
Calling __construct() on mysqli_stmt with an unset variable
as the mysqli_link crashes PHP in mysqli_stmt_construct.
Note that this is actually 5.1.0RC2 (CVS tag
php_5_1_0RC2_PRE). This may affect other MySQLi functions
(?). A possible fix, minus a more informative error message
is here, but my instinct says there may be more going on
behind this than the check in MYSQLI_FETCH_RESOURCE() since
passing a literal NULL or similar instead of an undefined
variable gives an error message instead of crashing.
Index: ext/mysqli/php_mysqli.h
===
RCS file: /repository/php-src/ext/mysqli/php_mysqli.h,v
retrieving revision 1.54
diff -u -r1.54 php_mysqli.h
--- ext/mysqli/php_mysqli.h 3 Aug 2005 14:07:31 -
1.54
+++ ext/mysqli/php_mysqli.h 10 Oct 2005 19:17:35 -
@@ -202,7 +202,12 @@
#define MYSQLI_FETCH_RESOURCE(__ptr, __type, __id, __name)
\
{ \
MYSQLI_RESOURCE *my_res; \
- mysqli_object *intern = (mysqli_object *)
zend_object_store_get_object(*(__id) TSRMLS_CC);\
+ mysqli_object *intern = NULL; \
+ if (Z_TYPE_PP(__id) != IS_OBJECT) {\
+ php_error(E_WARNING, Object parameter
invalid); \
+ RETURN_NULL(); \
+ } \
+ intern = (mysqli_object *)
zend_object_store_get_object(*(__id) TSRMLS_CC);\
if (!(my_res = (MYSQLI_RESOURCE *)intern-ptr)) {\
php_error(E_WARNING, Couldn't fetch %s,
intern-zo.ce-name);\
RETURN_NULL();\
Reproduce code:
---
?php $s = new mysqli_stmt( $undefined, SELECT 1 FROM DUAL ); ?
Expected result:
Warning: Object parameter invalid in - on line 1
Actual result:
--
Bus error
Thread 0 Crashed:
0 php 0x000c1bb8 zif_mysqli_stmt_construct + 252
(mysqli.c:675)
1 php 0x0020ab88 zend_do_fcall_common_helper_SPEC + 1560
(zend_vm_execute.h:184)
2 php 0x0020a4c4 execute + 520 (zend_vm_execute.h:87)
3 php 0x001e0630 zend_execute_scripts + 444 (zend.c:
1079)
4 php 0x00195334 php_execute_script + 780 (main.c:1679)
5 php 0x002921ac main + 3684 (php_cli.c:1040)
6 php 0x2b58 _start + 344 (crt.c:272)
7 php 0x29fc start + 60
--
Edit this bug report at http://bugs.php.net/?id=34818edit=1
#34767 [Com]: Zend Engine 1 Compatibility not copying objects correctly
ID: 34767 Comment by: jason at jasonjustman dot com Reported By: dstarr at allofe dot net Status: Assigned Bug Type: Scripting Engine problem Operating System: * PHP Version: 5CVS-2005-10-06 (cvs) Assigned To: dmitry New Comment: if you're going to nuke ze1_compat then add the clone keyword into the 4.x branch (like i recommended A YEAR AGO: http://bugs.php.net/bug.php?id=30332). j Previous Comments: [2005-10-06 20:56:31] [EMAIL PROTECTED] The expected result you do get without setting the option..so.. :) [2005-10-06 20:55:38] [EMAIL PROTECTED] Dmitry, this thing doesn't really seem to work. Somehow I'm getting the impression that it would be much better to just nuke this option and make people fix their scripts.. [2005-10-06 20:49:00] dstarr at allofe dot net Description: When zend.ze1_compatibility_mode is On, copying objects that have references to other objects the object that was referenced is copied instead of the reference itself. The Expected Results were obtained by using PHP 4.4.0 The Actual is a result of running on 5.0.5 Reproduce code: --- $a-y = new stdClass(); print_r($a); echo br/; $b = $a; $a-y-z = 1; print_r($b); Expected result: // Expected Output // stdClass Object ( [y] = stdClass Object ( ) ) // stdClass Object ( [y] = stdClass Object ( [z] = 1 ) ) Actual result: -- // Actual Output // stdClass Object ( [y] = stdClass Object ( ) ) // stdClass Object ( [y] = stdClass Object ( ) ) -- Edit this bug report at http://bugs.php.net/?id=34767edit=1
#34820 [NEW]: 'HTTP_ACCEPT_ENCODING' not set in $_SERVER
From: AlReece45 at yahoo dot com Operating system: Windows XP Home SP1 PHP version: 4.4.0 PHP Bug Type: Scripting Engine problem Bug description: 'HTTP_ACCEPT_ENCODING' not set in $_SERVER Description: While it was working before, the $_SERVER['HTTP_ACCEPT_ENCODING'] is not longer being set. I'm using Apache 2 with the PHP Module. Note this is not a problem of Content-Encoding being sent Reproduce code: --- ?php var_export($_SERVER['HTTP_ACCEPT_ENCODING']); ? Expected result: 'gzip, deflate' Actual result: -- NULL -- Edit bug report at http://bugs.php.net/?id=34820edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=34820r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=34820r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=34820r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=34820r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=34820r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=34820r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=34820r=needscript Try newer version: http://bugs.php.net/fix.php?id=34820r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=34820r=support Expected behavior: http://bugs.php.net/fix.php?id=34820r=notwrong Not enough info: http://bugs.php.net/fix.php?id=34820r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=34820r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=34820r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=34820r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=34820r=dst IIS Stability: http://bugs.php.net/fix.php?id=34820r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=34820r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=34820r=float No Zend Extensions: http://bugs.php.net/fix.php?id=34820r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=34820r=mysqlcfg
#34820 [Opn-Fbk]: 'HTTP_ACCEPT_ENCODING' not set in $_SERVER
ID: 34820 Updated by: [EMAIL PROTECTED] Reported By: AlReece45 at yahoo dot com -Status: Open +Status: Feedback Bug Type: Scripting Engine problem Operating System: Windows XP Home SP1 PHP Version: 4.4.0 New Comment: While it was working before it was working before *what*? And what your phpinfo() tells about it? Or there is no Accept-Encoding too? Previous Comments: [2005-10-10 22:22:16] AlReece45 at yahoo dot com Description: While it was working before, the $_SERVER['HTTP_ACCEPT_ENCODING'] is not longer being set. I'm using Apache 2 with the PHP Module. Note this is not a problem of Content-Encoding being sent Reproduce code: --- ?php var_export($_SERVER['HTTP_ACCEPT_ENCODING']); ? Expected result: 'gzip, deflate' Actual result: -- NULL -- Edit this bug report at http://bugs.php.net/?id=34820edit=1
#34815 [Opn-Fbk]: Unable compile php 5 with informix csdk 2.90 UC3 and apache 1.3.33.
ID: 34815 Updated by: [EMAIL PROTECTED] Reported By: info at aplext dot com -Status: Open +Status: Feedback Bug Type: Compile Failure Operating System: Fedora Core 3 PHP Version: 5.0.5 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php5-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.0-win32-latest.zip Previous Comments: [2005-10-10 19:11:17] info at aplext dot com Description: I compile php 5 with informix csdk 2.90 UC3 and apache 1.3.33 on fedora core 3 Reproduce code: --- parameters of configure: --with-informix --with-apxs2 Expected result: no errors Actual result: -- /usr/lib/gcc/i386-redhat-linux/3.4.2/../../../crt1.o(.text+0x18): In function `_start': : undefined reference to `main' ext/standard/info.lo(.text+0x7): In function `php_info_print_table_start': /opt/web/php/php-5.0.5/ext/standard/info.c:731: undefined reference to `sapi_module' ext/standard/info.lo(.text+0x18):/opt/web/php/php-5.0.5/ext/standard/info.c:734: undefined reference to `php_printf' ext/standard/info.lo(.text+0x2d):/opt/web/php/php-5.0.5/ext/standard/info.c:734: undefined reference to `php_printf' ext/standard/info.lo(.text+0x40): In function `php_info_print_table_end': /opt/web/php/php-5.0.5/ext/standard/info.c:740: undefined reference to `sapi_module' ext/standard/info.lo(.text+0x55):/opt/web/php/php-5.0.5/ext/standard/info.c:741: undefined reference to `php_printf' ext/standard/info.lo(.text+0x6c): In function `php_info_print_style': /opt/web/php/php-5.0.5/ext/standard/info.c:204: undefined reference to `php_printf' ext/standard/info.lo(.text+0x71):/opt/web/php/php-5.0.5/ext/standard/info.c:205: undefined reference to `php_info_print_css' ext/standard/info.lo(.text+0x7d):/opt/web/php/php-5.0.5/ext/standard/info.c:206: undefined reference to `php_printf' ext/standard/info.lo(.text+0xaa): In function `php_info_html_esc': /opt/web/php/php-5.0.5/ext/standard/info.c:216: undefined reference to `php_escape_html_entities' -- Edit this bug report at http://bugs.php.net/?id=34815edit=1
#34813 [Opn-Fbk]: PHP 4 will not load under Apache 2.1.8
ID: 34813 Updated by: [EMAIL PROTECTED] Reported By: uzomadu at gmail dot com -Status: Open +Status: Feedback Bug Type: Apache2 related Operating System: OS X 10.4.2 PHP Version: 4.4.0 New Comment: I have just upgraded to Apache 2.1.8 on OS X 10.4.2 Try to rebuild PHP? Since it's just an Apache module I think it's quite obvious that PHP compiled against some Apache version may not work with another one. Previous Comments: [2005-10-10 17:34:55] uzomadu at gmail dot com Description: Hi, I have just upgraded to Apache 2.1.8 on OS X 10.4.2 and am having a problem trying to load php 4. Reproduce code: --- Specified in httpd.conf # PHP4 configuration LoadModule php4_module modules/libphp4.so AddType application/x-httpd-php .php .phtml AddType application/x-httpd-php-source .phps and the libphp4.so module is located as specified, in the modules folder. The error specified in the 'actual results' section occurs when I try to shutdown or start Apache 2.1.8 Expected result: I expected Apache 2.1.8 under OS X 10.4.2 to load successfully. Actual result: -- httpd: Syntax error on line 444 of /usr/local/apache2/conf/httpd.conf: Cannot load /usr/local/apache2/modules/libphp4.so into server: Library not loaded: /Library/Apache2/lib/libaprutil-0.0.dylib\n Referenced from: /usr/local/apache2/modules/libphp4.so\n Reason: image not found -- Edit this bug report at http://bugs.php.net/?id=34813edit=1
#34820 [Fbk-Opn]: 'HTTP_ACCEPT_ENCODING' not set in $_SERVER
ID: 34820 User updated by: AlReece45 at yahoo dot com Reported By: AlReece45 at yahoo dot com -Status: Feedback +Status: Open Bug Type: Scripting Engine problem Operating System: Windows XP Home SP1 PHP Version: 4.4.0 New Comment: Sorry if this posts twice... What I meant is that is was set before. And phpinfo() does not it either. I checked both there and using the code: ?php var_export($_SERVER); ? to check to see if I was just using the wrong index or just a documentation bug. Nothing in the $_SERVER variable, or $GLOBALS (checked it too) has anything with gzip in it. It isn't a browser problem b/c I checked by sending a request manually using telnet. Previous Comments: [2005-10-10 22:30:38] [EMAIL PROTECTED] While it was working before it was working before *what*? And what your phpinfo() tells about it? Or there is no Accept-Encoding too? [2005-10-10 22:22:16] AlReece45 at yahoo dot com Description: While it was working before, the $_SERVER['HTTP_ACCEPT_ENCODING'] is not longer being set. I'm using Apache 2 with the PHP Module. Note this is not a problem of Content-Encoding being sent Reproduce code: --- ?php var_export($_SERVER['HTTP_ACCEPT_ENCODING']); ? Expected result: 'gzip, deflate' Actual result: -- NULL -- Edit this bug report at http://bugs.php.net/?id=34820edit=1
#34820 [Opn-Fbk]: 'HTTP_ACCEPT_ENCODING' not set in $_SERVER
ID: 34820 Updated by: [EMAIL PROTECTED] Reported By: AlReece45 at yahoo dot com -Status: Open +Status: Feedback Bug Type: Scripting Engine problem Operating System: Windows XP Home SP1 PHP Version: 4.4.0 New Comment: 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 What I meant is that is was set before. Once again: before what happened? Yes, I got that before it stopped working, but I guess you did something as if it just magically disappeared - that's not PHP problem. Btw, it works just fine here. It isn't a browser problem b/c I checked by sending a request manually using telnet. How exactly did you check it? Previous Comments: [2005-10-10 22:38:24] AlReece45 at yahoo dot com Sorry if this posts twice... What I meant is that is was set before. And phpinfo() does not it either. I checked both there and using the code: ?php var_export($_SERVER); ? to check to see if I was just using the wrong index or just a documentation bug. Nothing in the $_SERVER variable, or $GLOBALS (checked it too) has anything with gzip in it. It isn't a browser problem b/c I checked by sending a request manually using telnet. [2005-10-10 22:30:38] [EMAIL PROTECTED] While it was working before it was working before *what*? And what your phpinfo() tells about it? Or there is no Accept-Encoding too? [2005-10-10 22:22:16] AlReece45 at yahoo dot com Description: While it was working before, the $_SERVER['HTTP_ACCEPT_ENCODING'] is not longer being set. I'm using Apache 2 with the PHP Module. Note this is not a problem of Content-Encoding being sent Reproduce code: --- ?php var_export($_SERVER['HTTP_ACCEPT_ENCODING']); ? Expected result: 'gzip, deflate' Actual result: -- NULL -- Edit this bug report at http://bugs.php.net/?id=34820edit=1
#34821 [NEW]: zlib encoders fail on widely varying binary data
From: [EMAIL PROTECTED]
Operating system: *
PHP version: 5CVS-2005-10-10 (CVS)
PHP Bug Type: Zlib Related
Bug description: zlib encoders fail on widely varying binary data
Description:
Probably an edge case, but so nobody could claim I didn't report it ;) It
starts to fail with ~200k+.
Reproduce code:
---
?php
$j = 20;
$s = '';
srand(time());
for ($i = 0; $i $j; ++$i) {
$s .= chr(rand(0,255));
}
gzencode($s); // fails with buffer error
$r = array();
echo \nCharcode stats:\n;
for ($i = 0; $i $j; ++$i) {
$x = ord($s{$i});
$r[$x] = isset($r[$x]) ? $r[$x]+1 : 1;
}
asort($r);
printf(MIN: %d -- AVG: %d -- MAX: %d\n, current($r),
array_sum($r)/count($r), end($r));
?
Expected result:
No error
Actual result:
--
Warning: gzencode(): buffer error in C:\Webserver\mike\zone\gzencode.php
on line 10
--
Edit bug report at http://bugs.php.net/?id=34821edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=34821r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=34821r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=34821r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=34821r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=34821r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=34821r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=34821r=needscript
Try newer version: http://bugs.php.net/fix.php?id=34821r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=34821r=support
Expected behavior: http://bugs.php.net/fix.php?id=34821r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=34821r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=34821r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=34821r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=34821r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=34821r=dst
IIS Stability: http://bugs.php.net/fix.php?id=34821r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=34821r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=34821r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=34821r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=34821r=mysqlcfg
#34820 [Fbk-Opn]: 'HTTP_ACCEPT_ENCODING' not set in $_SERVER
ID: 34820 User updated by: AlReece45 at yahoo dot com Reported By: AlReece45 at yahoo dot com -Status: Feedback +Status: Open Bug Type: Scripting Engine problem Operating System: Windows XP Home SP1 PHP Version: 4.4.0 New Comment: I copied what Firefox sent using LiveHTTPHeaders and sent it using telnet via the Command Prompt to request a script that outputed $_SERVER. telnet o localhost 80 GET /test.php HTTP/1.1 Host: localhost User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050908 Firefox/1.4 Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5 Accept-Language: en-us,en;q=0.5 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive I can give you the results if you want. I'll test the snapshot as soon as I can compile it (a few hours). If its not a php problem, what would it be? I put outputed every variable in a seperate page from my scripts and it still wasn't showing up. And I believe it stopped working when I updated to v4.4.0 Previous Comments: [2005-10-10 22:47:49] [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 What I meant is that is was set before. Once again: before what happened? Yes, I got that before it stopped working, but I guess you did something as if it just magically disappeared - that's not PHP problem. Btw, it works just fine here. It isn't a browser problem b/c I checked by sending a request manually using telnet. How exactly did you check it? [2005-10-10 22:38:24] AlReece45 at yahoo dot com Sorry if this posts twice... What I meant is that is was set before. And phpinfo() does not it either. I checked both there and using the code: ?php var_export($_SERVER); ? to check to see if I was just using the wrong index or just a documentation bug. Nothing in the $_SERVER variable, or $GLOBALS (checked it too) has anything with gzip in it. It isn't a browser problem b/c I checked by sending a request manually using telnet. [2005-10-10 22:30:38] [EMAIL PROTECTED] While it was working before it was working before *what*? And what your phpinfo() tells about it? Or there is no Accept-Encoding too? [2005-10-10 22:22:16] AlReece45 at yahoo dot com Description: While it was working before, the $_SERVER['HTTP_ACCEPT_ENCODING'] is not longer being set. I'm using Apache 2 with the PHP Module. Note this is not a problem of Content-Encoding being sent Reproduce code: --- ?php var_export($_SERVER['HTTP_ACCEPT_ENCODING']); ? Expected result: 'gzip, deflate' Actual result: -- NULL -- Edit this bug report at http://bugs.php.net/?id=34820edit=1
#34820 [Opn-Fbk]: 'HTTP_ACCEPT_ENCODING' not set in $_SERVER
ID: 34820 Updated by: [EMAIL PROTECTED] Reported By: AlReece45 at yahoo dot com -Status: Open +Status: Feedback Bug Type: Scripting Engine problem Operating System: Windows XP Home SP1 PHP Version: 4.4.0 New Comment: Please reopen the report only when you tried the latest snapshot. And try with some other browser. Previous Comments: [2005-10-10 23:17:56] AlReece45 at yahoo dot com I copied what Firefox sent using LiveHTTPHeaders and sent it using telnet via the Command Prompt to request a script that outputed $_SERVER. telnet o localhost 80 GET /test.php HTTP/1.1 Host: localhost User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050908 Firefox/1.4 Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5 Accept-Language: en-us,en;q=0.5 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive I can give you the results if you want. I'll test the snapshot as soon as I can compile it (a few hours). If its not a php problem, what would it be? I put outputed every variable in a seperate page from my scripts and it still wasn't showing up. And I believe it stopped working when I updated to v4.4.0 [2005-10-10 22:47:49] [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 What I meant is that is was set before. Once again: before what happened? Yes, I got that before it stopped working, but I guess you did something as if it just magically disappeared - that's not PHP problem. Btw, it works just fine here. It isn't a browser problem b/c I checked by sending a request manually using telnet. How exactly did you check it? [2005-10-10 22:38:24] AlReece45 at yahoo dot com Sorry if this posts twice... What I meant is that is was set before. And phpinfo() does not it either. I checked both there and using the code: ?php var_export($_SERVER); ? to check to see if I was just using the wrong index or just a documentation bug. Nothing in the $_SERVER variable, or $GLOBALS (checked it too) has anything with gzip in it. It isn't a browser problem b/c I checked by sending a request manually using telnet. [2005-10-10 22:30:38] [EMAIL PROTECTED] While it was working before it was working before *what*? And what your phpinfo() tells about it? Or there is no Accept-Encoding too? [2005-10-10 22:22:16] AlReece45 at yahoo dot com Description: While it was working before, the $_SERVER['HTTP_ACCEPT_ENCODING'] is not longer being set. I'm using Apache 2 with the PHP Module. Note this is not a problem of Content-Encoding being sent Reproduce code: --- ?php var_export($_SERVER['HTTP_ACCEPT_ENCODING']); ? Expected result: 'gzip, deflate' Actual result: -- NULL -- Edit this bug report at http://bugs.php.net/?id=34820edit=1
#34790 [Opn-Asn]: preg_match_all(), named capturing groups, variable assignment/return = crash
ID: 34790
Updated by: [EMAIL PROTECTED]
Reported By: savzen at gmail dot com
-Status: Open
+Status: Assigned
Bug Type: PCRE related
Operating System: Linux
PHP Version: 5CVS, 4CVS (2005-10-08) (snap)
-Assigned To:
+Assigned To: dmitry
New Comment:
I've reproduced it with PHP 5.1. I haven't tried anything else.
Dmitry probably is the best guy to look at this, as it seems an engine
problem.
Previous Comments:
[2005-10-10 01:14:45] savzen at gmail dot com
I get errors in output and a segmentation fault.
Reproduce code:
-
?php
function func1(){
$string = 'what the word and the other word the';
preg_match_all('/(?Pwordthe)/', $string, $matches);
return $matches['word'];
}
$words = func1();
var_dump($words);
?
Expected result:
array(4) {
[0]=
string(3) the
[1]=
string(3) the
[2]=
string(3) the
[3]=
string(3) the
}
Actual result:
---
array(4) {
[0]=
string(3) the
[1]=
string(3) the
[2]=
string(3) the
[3]=
string(3) q9
}
Segmentation fault
This is the backtrace without --enable-debug, because it doesn't crash
with it enabled. Only output is UNKNOWN:0
--
(gdb) bt
#0 0x402429fc in malloc () from /lib/i686/libc.so.6
#1 0x083047f8 in ?? ()
#2 0x402ec6a0 in __check_rhosts_file () from /lib/i686/libc.so.6
Cannot access memory at address 0x1
[2005-10-09 20:48:17] [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
Tried latest CVS, works fine and no valgrind errors.
[2005-10-09 01:42:25] [EMAIL PROTECTED]
I've tried to fix the bug, but I couldn't find a clue.
The problem is triggered when destroying a hash table (in zend_hash.c),
but I don't know which hash table is. This should be much easier to a
Engine expert.
Anyway, I've made a simpler reproduce script, which is enough to
trigger valgrind errors.
? preg_match_all('/(?Pwordthe)/', '', $matches); ?
[2005-10-09 00:17:13] [EMAIL PROTECTED]
Ouch... 193 valgrind errors :)
[2005-10-08 19:27:59] savzen at gmail dot com
Description:
I used the function preg_match_all () WITHIN a function being called by
another function, with a named capturing group and assigned the match to
a variable using the named group as a key (name or number).
The variable assigned the value of the return becomes NULL
This happens in both the latest snapshots of PHP-4 and PHP-5 with PHP-5
giving a segmentation fault after NULL when error_reporting (E_ALL) is
at the top of the script
When the configure option --enable-debug is used PHP-5 gives UNKNOWN:0
instead of NULL and no segmentation fault
When NOT using a Named capturing group name and instead use a normal
capturing group the behaviour seems to stop. Assigning the matched
value by reference also seems to stop the behaviour. ie
var2=var['named_key']
Reproduce code:
---
error_reporting(E_ALL);
function func1(){
$words = func2();
var_dump($words);
$this_words = $words;
return $this_words;
}
function func2(){
$pattern = '(?Pword(?:the))';
$string = 'what the word and the other word the';
preg_match_all('/'.$pattern.'/i', $string, $matches);
$words = $matches['word'];
$this_words = $words;
var_dump($this_words);
return $words;
}
func1();
Expected result:
array(4) {
[0]=
string(3) the
[1]=
string(3) the
[2]=
string(3) the
[3]=
string(3) the
}
array(4) {
[0]=
string(3) the
[1]=
string(3) the
[2]=
string(3) the
[3]=
string(3) the
}
Actual result:
--
array(4) {
[0]=
string(3) the
[1]=
string(3) the
[2]=
string(3) the
[3]=
string(3) the
}
NULL{php -4} UNKNOWN:0 {php-5 --enable-debug}
segmentation fault {php-5 without --enable-debug}
Backtrace (PHP-5 latest without enable-debug because it doesn't crash
when it is used)
---
(gdb) bt
#0 0x402429f2 in malloc () from /lib/i686/libc.so.6
Cannot access memory at address 0x18
(gdb)
--
Edit this bug report at http://bugs.php.net/?id=34790edit=1
#32107 [Com]: fclose (STDIN|STDOUT|STDERR) not working
ID: 32107 Comment by: valerio at wnet dot it Reported By: php at the-eend dot org Status: No Feedback Bug Type: CGI related Operating System: Redhat ES3 PHP Version: 4.3.10 New Comment: This bug is still present in php 4.3.10. Any chance to have it fixed in the 4.3 tree? Previous Comments: [2005-08-06 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-07-29 15:35:13] [EMAIL PROTECTED] Please try it with PHP 5 [2005-07-29 13:01:57] Andreas dot Oesterhelt at InTradeSys dot com Here's the test case requested by [EMAIL PROTECTED]: ?php fclose(STDOUT); /* This now fails..*/ fwrite (STDOUT, Test); /* but this still works: */ echo Stdout still open\n; /* * Standard output is still open. * The process is therefore unable to detach from its terminal. * See PHP Bug #27865 (PHP5, fixed) */ ? Tested in PHP 4.3.10 (cli) [2005-03-20 18:01:30] [EMAIL PROTECTED] No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to Open. Thank you. [2005-02-25 14:09:02] [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 ?php and ends with ?, is max. 10-20 lines long and does not require any external resources such as databases, etc. If possible, make the script source available online and provide an URL to it here. Try to avoid embedding huge scripts into the report. 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/32107 -- Edit this bug report at http://bugs.php.net/?id=32107edit=1
#34790 [Asn]: preg_match_all(), named capturing groups, variable assignment/return = crash
ID: 34790
Updated by: [EMAIL PROTECTED]
Reported By: savzen at gmail dot com
Status: Assigned
Bug Type: PCRE related
Operating System: Linux
PHP Version: 5CVS, 4CVS (2005-10-08) (snap)
Assigned To: dmitry
New Comment:
This is what I get with Zend MM disabled:
http://tony2001.phpclub.net/dev/tmp/pcre_valgrind.txt
Previous Comments:
[2005-10-10 23:26:54] [EMAIL PROTECTED]
I've reproduced it with PHP 5.1. I haven't tried anything else.
Dmitry probably is the best guy to look at this, as it seems an engine
problem.
[2005-10-10 01:14:45] savzen at gmail dot com
I get errors in output and a segmentation fault.
Reproduce code:
-
?php
function func1(){
$string = 'what the word and the other word the';
preg_match_all('/(?Pwordthe)/', $string, $matches);
return $matches['word'];
}
$words = func1();
var_dump($words);
?
Expected result:
array(4) {
[0]=
string(3) the
[1]=
string(3) the
[2]=
string(3) the
[3]=
string(3) the
}
Actual result:
---
array(4) {
[0]=
string(3) the
[1]=
string(3) the
[2]=
string(3) the
[3]=
string(3) q9
}
Segmentation fault
This is the backtrace without --enable-debug, because it doesn't crash
with it enabled. Only output is UNKNOWN:0
--
(gdb) bt
#0 0x402429fc in malloc () from /lib/i686/libc.so.6
#1 0x083047f8 in ?? ()
#2 0x402ec6a0 in __check_rhosts_file () from /lib/i686/libc.so.6
Cannot access memory at address 0x1
[2005-10-09 20:48:17] [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
Tried latest CVS, works fine and no valgrind errors.
[2005-10-09 01:42:25] [EMAIL PROTECTED]
I've tried to fix the bug, but I couldn't find a clue.
The problem is triggered when destroying a hash table (in zend_hash.c),
but I don't know which hash table is. This should be much easier to a
Engine expert.
Anyway, I've made a simpler reproduce script, which is enough to
trigger valgrind errors.
? preg_match_all('/(?Pwordthe)/', '', $matches); ?
[2005-10-09 00:17:13] [EMAIL PROTECTED]
Ouch... 193 valgrind errors :)
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/34790
--
Edit this bug report at http://bugs.php.net/?id=34790edit=1
#34822 [NEW]: PHP writing empty files
From: jshay at dakotacom dot net
Operating system: RedHat Enterprise 3.0
PHP version: 4.4.0
PHP Bug Type: *General Issues
Bug description: PHP writing empty files
Description:
A simple upload script uploads the file, fully intact, but then a few
seconds later zero's out the file making a zero byte length file.
Reproduce code:
---
?
$size = exec(ls -l $upload_item);
if ($upload_item) {
print(br /uploading to section = $section\n);
print(br /file name = $upload_item_name\n);
print(br /file size = $upload_item_size bytes\n);
print(br /file in tmp = $size\n);
if (copy ($upload_item, ./$upload_item_name)) {
print(htmlbody\n);
print(pbyour file was successfully
uploaded!/b/p\n);
print(p\n);
print(please note your file name -
b$upload_item_name/b\n);
print(br /you will need to enter it in the
appropriate form.\n);
print(/p\n);
print(/body/html);
} else {
print(can't be copied - there may be another file
with this name\n);
}
}
?
Expected result:
The file should get written to the directory specified from the form and
named the same name as the uploaded file.
Actual result:
--
Appropriate directories are writable by the apache user/group. Not a quota
issue. 'upload_max_filesize' is set to 55 megs. No error log is generated
as PHP has, as far as it thinks, written the file.
What happens is the file gets uploaded to /tmp (full permisssions on /tmp)
and then copied to the requested directory. I can grab a directory listing
and see it in the specified directory in whole - original size and name.
If I refresh the page again the file is zero'd out but with the original
filename.
I'm hesitant to call this a bug but having bounced this off other contacts
in the industry I am left with no choice.
--
Edit bug report at http://bugs.php.net/?id=34822edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=34822r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=34822r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=34822r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=34822r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=34822r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=34822r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=34822r=needscript
Try newer version: http://bugs.php.net/fix.php?id=34822r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=34822r=support
Expected behavior: http://bugs.php.net/fix.php?id=34822r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=34822r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=34822r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=34822r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=34822r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=34822r=dst
IIS Stability: http://bugs.php.net/fix.php?id=34822r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=34822r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=34822r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=34822r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=34822r=mysqlcfg
#34822 [Opn-Fbk]: PHP writing empty files
ID: 34822
Updated by: [EMAIL PROTECTED]
Reported By: jshay at dakotacom dot net
-Status: Open
+Status: Feedback
Bug Type: *General Issues
Operating System: RedHat Enterprise 3.0
PHP Version: 4.4.0
New Comment:
Can you please provide us with a *short* script that consistently
reproduces this bug and that we can run? As it is now, you've only
provided us with what looks like an excerpt of the script, and if we
can't reproduce the issue, we can't tell you if it is a bug or not.
Limiting the code to an accurate representation of the problem will
help you troubleshoot anything that might be wrong with your code and,
if there's something broken with PHP, it will help us isolate it so
that we can fix it efficiently.
Thanks!
Previous Comments:
[2005-10-11 03:08:44] jshay at dakotacom dot net
Description:
A simple upload script uploads the file, fully intact, but then a few
seconds later zero's out the file making a zero byte length file.
Reproduce code:
---
?
$size = exec(ls -l $upload_item);
if ($upload_item) {
print(br /uploading to section = $section\n);
print(br /file name = $upload_item_name\n);
print(br /file size = $upload_item_size bytes\n);
print(br /file in tmp = $size\n);
if (copy ($upload_item, ./$upload_item_name)) {
print(htmlbody\n);
print(pbyour file was successfully
uploaded!/b/p\n);
print(p\n);
print(please note your file name -
b$upload_item_name/b\n);
print(br /you will need to enter it in the
appropriate form.\n);
print(/p\n);
print(/body/html);
} else {
print(can't be copied - there may be another
file with this name\n);
}
}
?
Expected result:
The file should get written to the directory specified from the form
and named the same name as the uploaded file.
Actual result:
--
Appropriate directories are writable by the apache user/group. Not a
quota issue. 'upload_max_filesize' is set to 55 megs. No error log is
generated as PHP has, as far as it thinks, written the file.
What happens is the file gets uploaded to /tmp (full permisssions on
/tmp) and then copied to the requested directory. I can grab a
directory listing and see it in the specified directory in whole -
original size and name. If I refresh the page again the file is zero'd
out but with the original filename.
I'm hesitant to call this a bug but having bounced this off other
contacts in the industry I am left with no choice.
--
Edit this bug report at http://bugs.php.net/?id=34822edit=1
#31347 [Com]: is_dir and is_file (incorrectly) return true for any string 255 characters
ID: 31347 Comment by: nunbot at gmail dot com Reported By: gilad dot buzi at concatel dot com Status: Verified Bug Type: Filesystem function related Operating System: win32 only PHP Version: 5CVS, 4CVS (2005-03-06) New Comment: I've seen this in 5.0.4 build 2600 using win32. Unfortunately the string length does not seem to matter at all on both is_dir() and is_file(). ~nunbot Previous Comments: [2005-02-22 15:52:52] [EMAIL PROTECTED] Win32 specific bug, due to the stat() function not having handling in place for filenames 255 chars. [2005-02-20 16:21:11] smith at backendmedia dot com You can add file_exists() to the list of functions that have this error. I tested this with php4-win32-STABLE-200502081330.zip [2004-12-30 10:43:57] gilad dot buzi at concatel dot com Description: is_dir() and is_file() (incorrectly) return true for any string larger than 255 characters. I tried this on two different machines, with the out of the box, precompiled/downloaded Windows version of php 5.0.3. No changes were made to the standard php.ini-dist. No extra extensions were loaded. We are using PHP as an Apache2 module (php2apache2.dll). We also tried the latest CVS snapshot (5CVS-2004-12-30 (dev)) and got the same results. We tried, and could NOT reproduce this on Linux. It only failed on windows platforms. Curiously (or maybe not so curious), file_exists() DOES work fine. Reproduce code: --- ? $myfilename=aaaccsaccss; echo myfilename is: $myfilename; echo brmyfilename is .strlen($myfilename). characters long; echo bris_dir: .is_dir($myfilename); echo brfile_exists: .file_exists($myfilename); echo bris_file: .is_file($myfilename); $myfilename=ccsaccss; echo brbrmyfilename is: $myfilename; echo brmyfilename is .strlen($myfilename). characters long; echo bris_dir: .is_dir($myfilename); echo brfile_exists: .file_exists($myfilename); echo bris_file: .is_file($myfilename); ? Expected result: is_dir() and is_file() should return false if the file or directory does not exist, regardless of the length of the string they are passed. Actual result: -- Result for above script is: myfilename is: aaaccsaccss myfilename is 255 characters long is_dir: file_exists: is_file: myfilename is: ccsaccss myfilename is 256 characters long is_dir: 1 file_exists: 1 is_file: -- Edit this bug report at http://bugs.php.net/?id=31347edit=1
