#32654 [NEW]: Magic __parent property (or method)
From: bart at mediawave dot nl
Operating system: Any
PHP version: 5CVS-2005-04-10 (dev)
PHP Bug Type: Feature/Change Request
Bug description: Magic __parent property (or method)
Description:
When writing code with complex object structures I often need a reference
to the parent object. Let's say we have an object "parent" that has a
property which is an object "child":
class parentClass {
var $child;
var $dummyVar;
function __construct() {
$this->child = new childClass($this);
$this->dummyVar = 'hello';
}
}
class childClass {
var $parent;
function __construct($parent) {
$this->parent = $parent;
echo $this->parent->dummyVar;
}
}
$example = new parentClass;
// prints: hello
I very often need to create my code like this because I very often need to
be able to have a reference to the parent object of an object.
Shouldn't PHP have such a reference by default? There could always be a
Magic reference like:
$myParent = $this->__parent;
Or maybe a Magic method:
$myParent = $this->__parent();
This would then always return the parent object or eventually reach the
main script scope.
--
Edit bug report at http://bugs.php.net/?id=32654&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=32654&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=32654&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=32654&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=32654&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=32654&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=32654&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=32654&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=32654&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=32654&r=support
Expected behavior: http://bugs.php.net/fix.php?id=32654&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=32654&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=32654&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=32654&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=32654&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=32654&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=32654&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=32654&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=32654&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=32654&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=32654&r=mysqlcfg
#32654 [Opn->Bgs]: Magic __parent property (or method)
ID: 32654
Updated by: [EMAIL PROTECTED]
Reported By: bart at mediawave dot nl
-Status: Open
+Status: Bogus
Bug Type: Feature/Change Request
-Operating System: Any
+Operating System: *
-PHP Version: 5CVS-2005-04-10 (dev)
+PHP Version: *
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
There is no such thing as a parent object. Use 'parent::''()'
to access methods of the parent.
Previous Comments:
[2005-04-10 10:14:44] bart at mediawave dot nl
Description:
When writing code with complex object structures I often need a
reference to the parent object. Let's say we have an object "parent"
that has a property which is an object "child":
class parentClass {
var $child;
var $dummyVar;
function __construct() {
$this->child = new childClass($this);
$this->dummyVar = 'hello';
}
}
class childClass {
var $parent;
function __construct($parent) {
$this->parent = $parent;
echo $this->parent->dummyVar;
}
}
$example = new parentClass;
// prints: hello
I very often need to create my code like this because I very often need
to be able to have a reference to the parent object of an object.
Shouldn't PHP have such a reference by default? There could always be a
Magic reference like:
$myParent = $this->__parent;
Or maybe a Magic method:
$myParent = $this->__parent();
This would then always return the parent object or eventually reach the
main script scope.
--
Edit this bug report at http://bugs.php.net/?id=32654&edit=1
#32642 [Opn->Bgs]: execution of php.exe causes Error in Application
ID: 32642 Updated by: [EMAIL PROTECTED] Reported By: dandracom at yahoo dot de -Status: Open +Status: Bogus Bug Type: CGI related Operating System: windows 2000 SP4 PHP Version: 4.3.11 New Comment: Works fine for me under Windows XP. There's something wrong with your installation of PHP or in your system. Previous Comments: [2005-04-09 13:25:25] dandracom at yahoo dot de Description: This happens since 4.3.11 and in the latest Snapshot php4-STABLE-200504091039. A simple calling the php.exe causes the Error: command in "0x0126b0c6" points to the memory in "0x00080145". The event/action "read" can't executed on the memory. (I translated the error message - I'm using a german Win2k) The only call I got an output was: C:\>php -version Error in argument 1, char 4: option not found r Usage: php [-q] [-h] [-s] [-v] [-i] [-f ] php [args...] -a Run interactively -C Do not chdir to the script's directory -c | Look for php.ini file in this directory -n No php.ini file will be used -d foo[=bar] Define INI entry foo with value 'bar' -e Generate extended information for debugger/profiler -f Parse . Implies `-q' -h This help -i PHP information -l Syntax check only (lint) -m Show compiled in modules -q Quiet-mode. Suppress HTTP Header output. -s Display colour syntax highlighted source. -v Version number -w Display source with stripped comments and whitespace. -z Load Zend extension . Reproduce code: --- Yes. Allways the same. Moving back the hole system to 4.3.10 is a workaround. Expected result: shoul work ;) Actual result: -- using the workaround. :\ -- Edit this bug report at http://bugs.php.net/?id=32642&edit=1
#32655 [NEW]: sscanf not correctly works with language distinct from English
From: dia-lagl at yandex dot ru Operating system: WinXP SP1 PHP version: 4.3.11 PHP Bug Type: Strings related Bug description: sscanf not correctly works with language distinct from English Description: sscanf() not correctly works with language distinct from English language. For example in Russian language. Reproduce code: --- >From the documentation in Russian Expected result: "Óçåë 2350001 áûë èçãîòîâëåí: 2000-ßíâàðü-1 " Actual result: -- "Óçåë 2350001 áûë èçãîòîâëåí: -ß- " or something another -- Edit bug report at http://bugs.php.net/?id=32655&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=32655&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=32655&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=32655&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=32655&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=32655&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=32655&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=32655&r=needscript Try newer version: http://bugs.php.net/fix.php?id=32655&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=32655&r=support Expected behavior: http://bugs.php.net/fix.php?id=32655&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=32655&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=32655&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=32655&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=32655&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=32655&r=dst IIS Stability: http://bugs.php.net/fix.php?id=32655&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=32655&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=32655&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=32655&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=32655&r=mysqlcfg
#32654 [Bgs->Opn]: Magic __parent property (or method)
ID: 32654
User updated by: bart at mediawave dot nl
Reported By: bart at mediawave dot nl
-Status: Bogus
+Status: Open
Bug Type: Feature/Change Request
Operating System: *
PHP Version: *
New Comment:
I think my explanation might have been too vague. The "parent" you're
referring to (parent::) is for accessing methods and properties when a
class extends another class. I'm talking about objects.
A good example is the Document Object Model. Each html tag is
represented by an object. Each tag can have child tags. In DOM child
tags are called childNodes. In DOM there is also a property for
accessing parentNodes via the parentNode property. This is the property
I'm talking about.
Another good example is Flash. In Flash you have "movie clips" which
are objects. When a movie clip is inside another movie clip you can
reference the "parent" movie clip via the this.parent property.
Or another example. let's say we have a bicycle:
$mountainBike = new bicycle;
Of course we want the bicycle to have padels:
$padel = new padel;
$mountainBike->addPadel($padel);
Now, let's say we always want the padels to have the same color as the
bicycle. In padel we could have some code like:
function __construct() {
$this->color = $this->__parent->color;
}
So, as you can see there are such things as parent and child objects.
I'm always able to access child objects from within parent objects. I
just thought it would be nice if there's also a way to access parent
objects from within child objects.
Previous Comments:
[2005-04-10 12:22:26] [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
There is no such thing as a parent object. Use 'parent::''()'
to access methods of the parent.
[2005-04-10 10:14:44] bart at mediawave dot nl
Description:
When writing code with complex object structures I often need a
reference to the parent object. Let's say we have an object "parent"
that has a property which is an object "child":
class parentClass {
var $child;
var $dummyVar;
function __construct() {
$this->child = new childClass($this);
$this->dummyVar = 'hello';
}
}
class childClass {
var $parent;
function __construct($parent) {
$this->parent = $parent;
echo $this->parent->dummyVar;
}
}
$example = new parentClass;
// prints: hello
I very often need to create my code like this because I very often need
to be able to have a reference to the parent object of an object.
Shouldn't PHP have such a reference by default? There could always be a
Magic reference like:
$myParent = $this->__parent;
Or maybe a Magic method:
$myParent = $this->__parent();
This would then always return the parent object or eventually reach the
main script scope.
--
Edit this bug report at http://bugs.php.net/?id=32654&edit=1
#32649 [Bgs->Opn]: config.m4 change breaks --with-ibm-db2 configure option
ID: 32649 User updated by: dan dot scott at ca dot ibm dot com Reported By: dan dot scott at ca dot ibm dot com -Status: Bogus +Status: Open Bug Type: ODBC related Operating System: Red Hat Enterprise Linux 4.0 PHP Version: 5CVS-2005-04-09 (dev) New Comment: Jani: Hmm, can we call it a usability bug in ext/odbc/config.m4 then? If you're changing the configure method in a way that is known to break some existing build scenarios by introducing new requirements, it would be good to communicate the change. One way to do that is to provide a more helpful error message if the user tries to compile --with-ibm-db2 but fails. Even "Try sourcing the DB2 environment first, dummy!" would be a better hint than the current message. My recommendation would be "Ensure that you have installed the DB2 application development headers (sqllib/include/sqlcli1.h), and that you have sourced the DB2 environment, before running configure again." If tony2001 could make the requested config.m4 error message change, I would be happy to add the new requirement to the docs for Unified ODBC. That way, if the user actually reads the docs before they compile they will have a good chance of succeeding; and if they don't, and out of old habit suddenly find their configure command breaks, they will have a very good idea of how to correct the problem without having to go back to the docs. And no, DB2 does not add itself to /etc/ld.so.conf (or the equivalent on other operating systems). Part of the install of DB2 creates a new user, the purpose of which is to contain the DB2-related settings and environment. Previous Comments: [2005-04-10 12:30:41] [EMAIL PROTECTED] There is no bug here. Usually when you build something, you build it within same environment you RUN it. Some programs REQUIRE this. Before we've used flawed 'if-file-with-this-name-exist-assume-it-is-the-library' which of course won't work for everyone. The current behaviour is the correct one and that will not be changed. We will actually change all the places with the flawed method to use the correct one so you can expect other extensions to "break" also. (unless your LD_LIBRARY_PATH is correct) And doesn't that IBM-DB2 add it's libline into /etc/ld.so.conf?? [2005-04-09 21:58:53] dan dot scott at ca dot ibm dot com Description: Revision 1.70 breaks Unified ODBC compile against IBM DB2 on Linux (RHEL 4.0) if user has not sourced their DB2 environment. Reproduce code: --- Configure options: ./configure --without-sqlite --with-ibm-db2=/home/db2inst1/sqllib --with-pdo-odbc=ibm-db2,/home/db2inst1/sqllib Expected result: I expect configure to find the DB2 header files and libraries, have its requirements satisfied, and complete the configuration. This configure line has worked for at least five years (well, okay, drop the sqlite and pdo-odbc parts). Actual result: -- The configure command results in: checking for IBM DB2 support... no configure: error: build test failed. Please check the config.log for details. config.log notes that the gconftest failed because it cannot load libdb2.so.1. Why does this occur now? Due to the recent changes to the config.m4 file (to provide better cross-platform support), a stricter and not at all obvious requirement has been introduced: the user must now source the DB2 environment before running ./configure. If the user has sourced the $IBM_DB2/db2profile in their environment first, then the ./configure command succeeds. The reason is that one of the environment changes db2profile makes is to modify LD_LIBRARY_PATH and LIBPATH in the user's environment to include the DB2 libraries. If you want to keep the current, stricter, behavior, I would strongly urge you to change the 'build test failed' message to include a suggestion along the lines of: 'Perhaps you need to source your DB2 environment: (. $IBM_DB2/db2profile) before configuring PHP.' You could try modifying config.m4 to source the DB2 environment before attempting to compile gconftest, but that will fail if the user has pointed to /opt/IBM/db2/V8.1 instead of to a DB2 instance user. You could also try modifying LD_LIBRARY_PATH, LIBPATH, etc. before attempting to compile gconftest -- although that will likely introduce more cross-platform issues. -- Edit this bug report at http://bugs.php.net/?id=32649&edit=1
#32656 [NEW]: array_rand does not return array
From: yagi at thinkware dot jp
Operating system: any
PHP version: 4.3.11
PHP Bug Type: *General Issues
Bug description: array_rand does not return array
Description:
array_rand doesn't return array but a key as string when
given mixed array which has only one value(and key).
Reproduce code:
---
$array = array("test");
$rand_key = array_rand($array, count($array));
print_r($rand_key);
print("\n");
$array2 = array("test" => "value");
$rand_key2 = array_rand($array2, count($array2));
print_r($rand_key2);
print("\n");
$array3 = array("test" => "value", "test2" => "value2");
$rand_key3 = array_rand($array3, count($array3));
print_r($rand_key3);
print("\n");
Expected result:
Array([0] => 0)
Array([0] => test)
Array
(
[0] => test
[1] => test2
)
*the last one is right. Above two are not expected
result.
Actual result:
--
0
test
Array
(
[0] => test
[1] => test2
)
--
Edit bug report at http://bugs.php.net/?id=32656&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=32656&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=32656&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=32656&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=32656&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=32656&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=32656&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=32656&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=32656&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=32656&r=support
Expected behavior: http://bugs.php.net/fix.php?id=32656&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=32656&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=32656&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=32656&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=32656&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=32656&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=32656&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=32656&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=32656&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=32656&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=32656&r=mysqlcfg
#32657 [NEW]: return statements in includes from a method always return null
From: LoN_Kamikaze at gmx dot de Operating system: WinXP SP2 PHP version: 5.0.4 PHP Bug Type: Output Control Bug description: return statements in includes from a method always return null Description: As the PHP Documentation says: "When a file is included, the code it contains inherits the variable scope of the line on which the include occurs. Any variables available at that line in the calling file will be available within the called file, from that point forward." >From this I take that if an include occurs in a method, the included script should be able to use a return statement. Doing this terminates the method, but the returned value is always null. Reproduce code: --- index.php test(); ?> test.php Expected result: Test return statement. -- Edit bug report at http://bugs.php.net/?id=32657&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=32657&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=32657&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=32657&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=32657&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=32657&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=32657&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=32657&r=needscript Try newer version: http://bugs.php.net/fix.php?id=32657&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=32657&r=support Expected behavior: http://bugs.php.net/fix.php?id=32657&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=32657&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=32657&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=32657&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=32657&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=32657&r=dst IIS Stability: http://bugs.php.net/fix.php?id=32657&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=32657&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=32657&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=32657&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=32657&r=mysqlcfg
#32657 [Opn]: return statements in includes from a method always return null
ID: 32657 User updated by: LoN_Kamikaze at gmx dot de Reported By: LoN_Kamikaze at gmx dot de Status: Open Bug Type: Output Control Operating System: WinXP SP2 PHP Version: 5.0.4 New Comment: Line 9 of the index.php reproduce code has of course to be echo $test->test(); Previous Comments: [2005-04-10 18:44:10] LoN_Kamikaze at gmx dot de Description: As the PHP Documentation says: "When a file is included, the code it contains inherits the variable scope of the line on which the include occurs. Any variables available at that line in the calling file will be available within the called file, from that point forward." >From this I take that if an include occurs in a method, the included script should be able to use a return statement. Doing this terminates the method, but the returned value is always null. Reproduce code: --- index.php test(); ?> test.php Expected result: Test return statement. -- Edit this bug report at http://bugs.php.net/?id=32657&edit=1
#32658 [NEW]: Exceptions in includes from a method are invisible
From: LoN_Kamikaze at gmx dot de Operating system: WinXP PHP version: 5.0.4 PHP Bug Type: Output Control Bug description: Exceptions in includes from a method are invisible Description: If you throw an exception in a script that has been called via include in a method, it terminates the script, but it does not show an error message and it is not loged in the php error logfile. I suspect this bug is related to another one I submited: http://bugs.php.net/bug.php?id=32657 But I am not sure, thus I submited it as a new bug. Reproduce code: --- index.php test(); ?> test.php Expected result: Fatal error: Uncaught exception 'Exception' with message 'I wish that would work' in... -- Edit bug report at http://bugs.php.net/?id=32658&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=32658&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=32658&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=32658&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=32658&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=32658&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=32658&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=32658&r=needscript Try newer version: http://bugs.php.net/fix.php?id=32658&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=32658&r=support Expected behavior: http://bugs.php.net/fix.php?id=32658&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=32658&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=32658&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=32658&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=32658&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=32658&r=dst IIS Stability: http://bugs.php.net/fix.php?id=32658&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=32658&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=32658&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=32658&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=32658&r=mysqlcfg
#32659 [NEW]: PCRE makes apache 1.3.33 crash
From: appaquet at gmail dot com Operating system: FreeBSD 5.2.1 PHP version: 4.3.11 PHP Bug Type: PCRE related Bug description: PCRE makes apache 1.3.33 crash Description: When I start apache with PHP enabled, it crashes without any error (only a segfault in the /var/log/messages). I disabled all extensions one by one to see what was the problem and discovered that PCRE is making apache crash. Pcre in CLI mode is working fine. It also work fine if I load it with the dl() command. I tried to run apache with gdb. It says that apache has exited normally. -- Edit bug report at http://bugs.php.net/?id=32659&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=32659&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=32659&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=32659&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=32659&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=32659&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=32659&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=32659&r=needscript Try newer version: http://bugs.php.net/fix.php?id=32659&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=32659&r=support Expected behavior: http://bugs.php.net/fix.php?id=32659&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=32659&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=32659&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=32659&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=32659&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=32659&r=dst IIS Stability: http://bugs.php.net/fix.php?id=32659&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=32659&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=32659&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=32659&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=32659&r=mysqlcfg
#32657 [Opn->Bgs]: return statements in includes from a method always return null
ID: 32657 Updated by: [EMAIL PROTECTED] Reported By: LoN_Kamikaze at gmx dot de -Status: Open +Status: Bogus Bug Type: Output Control Operating System: WinXP SP2 PHP Version: 5.0.4 New Comment: Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php Previous Comments: [2005-04-10 18:52:15] LoN_Kamikaze at gmx dot de Line 9 of the index.php reproduce code has of course to be echo $test->test(); [2005-04-10 18:44:10] LoN_Kamikaze at gmx dot de Description: As the PHP Documentation says: "When a file is included, the code it contains inherits the variable scope of the line on which the include occurs. Any variables available at that line in the calling file will be available within the called file, from that point forward." >From this I take that if an include occurs in a method, the included script should be able to use a return statement. Doing this terminates the method, but the returned value is always null. Reproduce code: --- index.php test(); ?> test.php Expected result: Test return statement. -- Edit this bug report at http://bugs.php.net/?id=32657&edit=1
#32656 [Opn->Bgs]: array_rand does not return array
ID: 32656
Updated by: [EMAIL PROTECTED]
Reported By: yagi at thinkware dot jp
-Status: Open
+Status: Bogus
Bug Type: *General Issues
Operating System: any
PHP Version: 4.3.11
New Comment:
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
Previous Comments:
[2005-04-10 17:21:17] yagi at thinkware dot jp
Description:
array_rand doesn't return array but a key as string when
given mixed array which has only one value(and key).
Reproduce code:
---
$array = array("test");
$rand_key = array_rand($array, count($array));
print_r($rand_key);
print("\n");
$array2 = array("test" => "value");
$rand_key2 = array_rand($array2, count($array2));
print_r($rand_key2);
print("\n");
$array3 = array("test" => "value", "test2" => "value2");
$rand_key3 = array_rand($array3, count($array3));
print_r($rand_key3);
print("\n");
Expected result:
Array([0] => 0)
Array([0] => test)
Array
(
[0] => test
[1] => test2
)
*the last one is right. Above two are not expected
result.
Actual result:
--
0
test
Array
(
[0] => test
[1] => test2
)
--
Edit this bug report at http://bugs.php.net/?id=32656&edit=1
#32659 [Opn->Fbk]: PCRE makes apache 1.3.33 crash
ID: 32659 Updated by: [EMAIL PROTECTED] Reported By: appaquet at gmail dot com -Status: Open +Status: Feedback Bug Type: PCRE related Operating System: FreeBSD 5.2.1 PHP Version: 4.3.11 New Comment: Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to "Open". Thank you for your interest in PHP. Previous Comments: [2005-04-10 19:08:05] appaquet at gmail dot com Description: When I start apache with PHP enabled, it crashes without any error (only a segfault in the /var/log/messages). I disabled all extensions one by one to see what was the problem and discovered that PCRE is making apache crash. Pcre in CLI mode is working fine. It also work fine if I load it with the dl() command. I tried to run apache with gdb. It says that apache has exited normally. -- Edit this bug report at http://bugs.php.net/?id=32659&edit=1
#32655 [Opn->Bgs]: sscanf not correctly works with language distinct from English
ID: 32655 Updated by: [EMAIL PROTECTED] Reported By: dia-lagl at yandex dot ru -Status: Open +Status: Bogus Bug Type: Strings related Operating System: WinXP SP1 PHP Version: 4.3.11 New Comment: Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. Previous Comments: [2005-04-10 13:27:17] dia-lagl at yandex dot ru Description: sscanf() not correctly works with language distinct from English language. For example in Russian language. Reproduce code: --- >From the documentation in Russian Expected result: "Óçåë 2350001 áûë èçãîòîâëåí: 2000-ßíâàðü-1 " Actual result: -- "Óçåë 2350001 áûë èçãîòîâëåí: -ß- " or something another -- Edit this bug report at http://bugs.php.net/?id=32655&edit=1
#32649 [Opn->Csd]: config.m4 change breaks --with-ibm-db2 configure option
ID: 32649 Updated by: [EMAIL PROTECTED] Reported By: dan dot scott at ca dot ibm dot com -Status: Open +Status: Closed Bug Type: ODBC related Operating System: Red Hat Enterprise Linux 4.0 PHP Version: 5CVS-2005-04-09 (dev) New Comment: Added the more detailed error message into CVS (both HEAD / PHP_5_0 branches in which the original patch was added to) Previous Comments: [2005-04-10 16:42:10] dan dot scott at ca dot ibm dot com Jani: Hmm, can we call it a usability bug in ext/odbc/config.m4 then? If you're changing the configure method in a way that is known to break some existing build scenarios by introducing new requirements, it would be good to communicate the change. One way to do that is to provide a more helpful error message if the user tries to compile --with-ibm-db2 but fails. Even "Try sourcing the DB2 environment first, dummy!" would be a better hint than the current message. My recommendation would be "Ensure that you have installed the DB2 application development headers (sqllib/include/sqlcli1.h), and that you have sourced the DB2 environment, before running configure again." If tony2001 could make the requested config.m4 error message change, I would be happy to add the new requirement to the docs for Unified ODBC. That way, if the user actually reads the docs before they compile they will have a good chance of succeeding; and if they don't, and out of old habit suddenly find their configure command breaks, they will have a very good idea of how to correct the problem without having to go back to the docs. And no, DB2 does not add itself to /etc/ld.so.conf (or the equivalent on other operating systems). Part of the install of DB2 creates a new user, the purpose of which is to contain the DB2-related settings and environment. [2005-04-10 12:30:41] [EMAIL PROTECTED] There is no bug here. Usually when you build something, you build it within same environment you RUN it. Some programs REQUIRE this. Before we've used flawed 'if-file-with-this-name-exist-assume-it-is-the-library' which of course won't work for everyone. The current behaviour is the correct one and that will not be changed. We will actually change all the places with the flawed method to use the correct one so you can expect other extensions to "break" also. (unless your LD_LIBRARY_PATH is correct) And doesn't that IBM-DB2 add it's libline into /etc/ld.so.conf?? [2005-04-09 21:58:53] dan dot scott at ca dot ibm dot com Description: Revision 1.70 breaks Unified ODBC compile against IBM DB2 on Linux (RHEL 4.0) if user has not sourced their DB2 environment. Reproduce code: --- Configure options: ./configure --without-sqlite --with-ibm-db2=/home/db2inst1/sqllib --with-pdo-odbc=ibm-db2,/home/db2inst1/sqllib Expected result: I expect configure to find the DB2 header files and libraries, have its requirements satisfied, and complete the configuration. This configure line has worked for at least five years (well, okay, drop the sqlite and pdo-odbc parts). Actual result: -- The configure command results in: checking for IBM DB2 support... no configure: error: build test failed. Please check the config.log for details. config.log notes that the gconftest failed because it cannot load libdb2.so.1. Why does this occur now? Due to the recent changes to the config.m4 file (to provide better cross-platform support), a stricter and not at all obvious requirement has been introduced: the user must now source the DB2 environment before running ./configure. If the user has sourced the $IBM_DB2/db2profile in their environment first, then the ./configure command succeeds. The reason is that one of the environment changes db2profile makes is to modify LD_LIBRARY_PATH and LIBPATH in the user's environment to include the DB2 libraries. If you want to keep the current, stricter, behavior, I would strongly urge you to change the 'build test failed' message to include a suggestion along the lines of: 'Perhaps you need to source your DB2 environment: (. $IBM_DB2/db2profile) before configuring PHP.' You could try modifying config.m4 to source the DB2 environment before attempting to compile gconftest, but that will fail if the user has pointed to /opt/IBM/db2/V8.1 instead of to a DB2 instance user. You could also try modifying LD_LIBRARY_PATH, LIBPATH, etc. before attempting to compile gconftest -- although that will likely introduce more cross-platform issues. -- Edit this bug report at http://bugs.php.net/?id=32649&edit=1
#32637 [Opn->Fbk]: No libphp5.so is created when using --with-mysql option
ID: 32637 Updated by: [EMAIL PROTECTED] Reported By: Anand dot Murugesan at eds dot com -Status: Open +Status: Feedback Bug Type: Apache related Operating System: Solaris 10 / Sparc PHP Version: 5CVS-2005-04-08 (dev) New Comment: No, the --with-apxs2 is correct option to use with Apache2. What does it say during configure for the apxs2 config? What MPM does your apache2 use? Do you really HAVE Apache2 installed?? Previous Comments: [2005-04-09 17:38:40] Anand dot Murugesan at eds dot com Nope no luck on the CVS-latest for unix either. I saw it mentiones aspx2 a experimental, should I try and use a different option to configure? Thanks. [2005-04-09 09:31:52] [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-04-09 04:30:48] Anand dot Murugesan at eds dot com Solaris 10 sparcv9 --- Configure Line - ./configure --with-mysql= --with-apsx2=/bin/apsx --- gcc version 3.4.2 Configured with: ../gcc-3.4.2/configure --prefix=/opt/sfw --with-ld=/usr/ccs/bin/ld --with-gnu-as --with-as=/opt/sfw/bin/gas --enable-shared --disable-libgcj Thread model: posix [2005-04-09 02:39:35] [EMAIL PROTECTED] What Operating system? What configure line? What GCC?? READ THIS: http://bugs.php.net/how-to-report.php [2005-04-08 19:22:07] Anand dot Murugesan at eds dot com Description: libphp5.so dosen't get create when using --with-mysql option. Without which it gets created. I see no errors during configure or make. here is the output from >make install #make install Installing PHP SAPI module: cgi Installing PHP CGI into: /usr/local/bin/ Installing PEAR environment: /usr/local/lib/php/ [PEAR] Archive_Tar- already installed: 1.1 [PEAR] Console_Getopt - already installed: 1.2 [PEAR] PEAR - already installed: 1.3.5 Wrote PEAR system config file at: /usr/local/etc/pear.conf You may want to add: /usr/local/lib/php to your php.ini include_path [PEAR] HTML_Template_IT- already installed: 1.1 [PEAR] Net_UserAgent_Detect- already installed: 2.0.1 [PEAR] XML_RPC- already installed: 1.2.2 Installing build environment: /usr/local/lib/php/build/ Installing header files: /usr/local/include/php/ Installing helper programs: /usr/local/bin/ program: phpize program: php-config program: phpextdist Installing PDO headers: /usr/local/include/php/ext/pdo/ I have tried it several times with the same result. -- Edit this bug report at http://bugs.php.net/?id=32637&edit=1
#32644 [Opn->Fbk]: move_uploaded_file() relative path
ID: 32644
Updated by: [EMAIL PROTECTED]
Reported By: tck at tcknetwork dot com
-Status: Open
+Status: Feedback
Bug Type: Filesystem function related
Operating System: WinXP(SP2)
PHP Version: 5.0.4
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
Also add this to be first line in your script handling the upload:
error_reporting(E_ALL); ini_set('display_errors', 1);
Previous Comments:
[2005-04-09 17:17:08] tck at tcknetwork dot com
This happens both if I use zend optimizer or not (I doubted it could be
a possible source of problems. Note as well that my Apache (2.0.53,
using php as a module) root is on D:\Server if it may help.
[2005-04-09 16:53:29] tck at tcknetwork dot com
Description:
The move_uploaded_file() use the root of the hard disk in some special
cases instead of using the relative path from the script.
So far require() is not affected by this problem. I think it is just
this function that handles not properly the path.
Reproduce code:
---
My file system is built like this :
D:\Data (directory)
D:\Web\data (directory << note the ressemblance)
D:\Web\test\up.php (my script)
My script contains the following :
">
Expected result:
When I send a file, I expect it to be uploaded into
dirname("D:\Web\test\up.php")."../data/demo.jpg"
it means "D:\Web\data\demo.jpg".
In fact when I submit a file with my script twice, the following
happens :
1st submit : File uploaded into "D:\Data\demo.jpg"
(using the root instead of relative path)
2nd submit : File uploaded into "D:\Web\data\demo.jpg"
(working as expected only if the file "D:\Data\demo.jpg" exists)
Actual result:
--
Actually the PHP developer can fix this bug by changing the upload
line
@move_uploaded_file($f,"../data/demo.jpg");
by
@move_uploaded_file($f,dirname($_SERVER["SCRIPT_FILENAME"])."/../data/demo.jpg");
note that if the directory D:\Data
does not exists, the function will place the file properly into
D:\Web\data
--
Edit this bug report at http://bugs.php.net/?id=32644&edit=1
#32614 [Opn->Asn]: Crash occured in function fread from module /usr/lib/libc.so.1
ID: 32614 Updated by: [EMAIL PROTECTED] Reported By: Oscar dot Castillo at jpl dot nasa dot gov -Status: Open +Status: Assigned Bug Type: iPlanet related Operating System: Solaris 9 PHP Version: 5CVS-2005-04-07 (dev) Assigned To: thetaphi Previous Comments: [2005-04-09 01:48:08] Oscar dot Castillo at jpl dot nasa dot gov By default, iPlanet is not configured to core dump. Some special flags must be enabled to allow core dumping. I do not know the specific syntax to enable core dumping and I must then open a trouble ticket with Sun. I am attempting your suggestion from bug report #32491 to enable PHP as a CGI/Fastcgi via your cgibytex CGI enabler. As of the last 7 hours, PHP is working perfectly. I shall keep you posted. [2005-04-08 17:30:37] [EMAIL PROTECTED] Something other: can you load the "core" file the crashing server produces into dbx or gdb and send me the output? [2005-04-08 09:48:00] [EMAIL PROTECTED] Info about the solaris "bug": http://docs.sun.com/app/docs/doc/816-5168/6mbb3hr5q?a=view (see under "USAGE") In 64bit solaris it would work, but SunONE is a 32 bit server. [2005-04-08 09:37:01] [EMAIL PROTECTED] I found the reason for the bug. The problem is not the file upload here that works now. The problem is now the same stdio related bug which leads to the segmentation fault. I fixed the CVS now not to crash the webserver in this error condition (missing an errorchecking at fdopen() which works on all platform without errors, on solaris fails when the filedescriptor>255). But the problem should still be there but you should get a message in your PHP script. Looking into your code I exspect the "execute" functions to fail because they need to cast a stream from posix to stdio. Please test the new CVS and tell me when the further handling of your uploaded file fails. [2005-04-07 18:27:43] Oscar dot Castillo at jpl dot nasa dot gov I also forgot to mention that I am running PHP 5.0.5-dev on 2 other web servers that are used for testing and development of Java, PERL and PHP applications prior to being delivered to the production environment. All flavors of PHP have always worked in the test and development environments, but never in the production environment. The only difference between the 3 environments is that the production environment has a much heavier load than the test and development environments put together. The OS, OS patches, iPlanet version and PHP version are all exactly the same in all 3 web server environments. The fact that you cannot produce the crash in your environment can be related to the light load on your test set up. As mentioned in my last bug report (#32491), I have Java enabled (Very memory intensive) on the web server and our production environment mostly uses JSP and Java servlets. 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/32614 -- Edit this bug report at http://bugs.php.net/?id=32614&edit=1
#29032 [Com]: Session are closed before all object destructors executed.
ID: 29032
Comment by: spam at cimmanon dot org
Reported By: antonr at game dot permonline dot ru
Status: No Feedback
Bug Type: Session related
Operating System: Irrelevant
PHP Version: 5CVS-2004-07-06 (dev)
New Comment:
This bug still persists in PHP 5.0.4 (my problem is related to output
buffers being cleared before destructors are executed). Is the "latest
CVS snapshot" mentioned by [EMAIL PROTECTED] [6 Mar 8:35pm CET] reflected
in the 5.0.4 release [31 Mar]?
Previous Comments:
[2005-03-14 01:00:10] 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-03-06 20:35:59] [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
[2004-12-06 05:34:29] anthony at ectrolinux dot com
For reference, this bug appears to be synonymous to bug #30578, with
the same cause but a different effect.
[2004-10-26 02:40:15] auroraeosrose at hotmail dot com
Modifying $_SESSION in the destructor ONLY works if you call
unset($object) before the end of your script, however this is a pain in
the rear - and if you have references to that object elsewhere it
doesn't work properly.
There is a workaround... You CAN use register_shutdown_function in the
constructor of your class
public function __construct()
{
register_shutdown_function(array($this, '__destruct');
}
and then the destruct is called early enough that you can modify
$_SESSION. But this defeats the whole purpose of a destructor - I could
do that in every class if php5 didn't support destructors (in fact I did
in php4) but I thought the point was to eliminate messy workarounds.
Now why in the world the sessions are closed in between when shutdown
functions and destructors are called is beyond me.
[2004-07-06 16:58:15] antonr at game dot permonline dot ru
Description:
Session are closed before all object destructors executed. It seems to
be wrong, cause objects desctructors may save information in opened
session.
Reproduce code:
---
number = @$_SESSION["number"];
}
public function Process()
{ $this->number++;
}
public function __destruct()
{ $_SESSION["number"] = $this->number;
session_write_close();
}
}
$ss = new MySession();
$ss->Process();
echo $ss->number;
?>
Expected result:
With every page reloading number in the page must increase by 1.
Actual result:
--
Everytime number is equal 1.
--
Edit this bug report at http://bugs.php.net/?id=29032&edit=1
#32660 [NEW]: Assignment by reference causes crash when field access is overloaded (__get)
From: ladislav dot prosek at matfyz dot cz
Operating system: Windows XP SP2
PHP version: 5.0.4
PHP Bug Type: Zend Engine 2 problem
Bug description: Assignment by reference causes crash when field access is
overloaded (__get)
Description:
There is probably a bug in memory allocation related to property getters.
Note that the behavior depends on lengths of the two strings and also on
the way the $q property is initialized.
Reproduce code:
---
class A
{
var $q;
function __construct()
{
$this->q = array();
}
function __get($name)
{
return $this->q;
}
};
$a = new A;
$b = "short";
$a->whatever =& $b;
$b = "much longer";
var_dump($a);
Expected result:
// as __get does not return a reference
// the output should IMHO look like this:
object(A)#1 (1) {
["q"]=>
array(0) {
}
}
// if you guys think the output should be
// different, please do explain it!
Actual result:
--
object(A)#1 (1) {
["q"]=>
CRASH!
--
Edit bug report at http://bugs.php.net/?id=32660&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=32660&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=32660&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=32660&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=32660&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=32660&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=32660&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=32660&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=32660&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=32660&r=support
Expected behavior: http://bugs.php.net/fix.php?id=32660&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=32660&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=32660&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=32660&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=32660&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=32660&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=32660&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=32660&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=32660&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=32660&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=32660&r=mysqlcfg
#32657 [Bgs]: return statements in includes from a method always return null
ID: 32657 User updated by: LoN_Kamikaze at gmx dot de Reported By: LoN_Kamikaze at gmx dot de Status: Bogus Bug Type: Output Control Operating System: WinXP SP2 PHP Version: 5.0.4 New Comment: If it is not a bug, shouldn't return cause an error? It's a bug one way or another. Previous Comments: [2005-04-10 20:29:04] [EMAIL PROTECTED] Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php [2005-04-10 18:52:15] LoN_Kamikaze at gmx dot de Line 9 of the index.php reproduce code has of course to be echo $test->test(); [2005-04-10 18:44:10] LoN_Kamikaze at gmx dot de Description: As the PHP Documentation says: "When a file is included, the code it contains inherits the variable scope of the line on which the include occurs. Any variables available at that line in the calling file will be available within the called file, from that point forward." >From this I take that if an include occurs in a method, the included script should be able to use a return statement. Doing this terminates the method, but the returned value is always null. Reproduce code: --- index.php test(); ?> test.php Expected result: Test return statement. -- Edit this bug report at http://bugs.php.net/?id=32657&edit=1
#32657 [Bgs]: return statements in includes from a method always return null
ID: 32657 Updated by: [EMAIL PROTECTED] Reported By: LoN_Kamikaze at gmx dot de Status: Bogus Bug Type: Output Control Operating System: WinXP SP2 PHP Version: 5.0.4 New Comment: You return from the included script not from testReturn::test(). Please ask further support questions in the support forums/lists... Previous Comments: [2005-04-10 22:22:39] LoN_Kamikaze at gmx dot de If it is not a bug, shouldn't return cause an error? It's a bug one way or another. [2005-04-10 20:29:04] [EMAIL PROTECTED] Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php [2005-04-10 18:52:15] LoN_Kamikaze at gmx dot de Line 9 of the index.php reproduce code has of course to be echo $test->test(); [2005-04-10 18:44:10] LoN_Kamikaze at gmx dot de Description: As the PHP Documentation says: "When a file is included, the code it contains inherits the variable scope of the line on which the include occurs. Any variables available at that line in the calling file will be available within the called file, from that point forward." >From this I take that if an include occurs in a method, the included script should be able to use a return statement. Doing this terminates the method, but the returned value is always null. Reproduce code: --- index.php test(); ?> test.php Expected result: Test return statement. -- Edit this bug report at http://bugs.php.net/?id=32657&edit=1
#32614 [Asn]: Crash occured in function fread from module /usr/lib/libc.so.1
ID: 32614 Updated by: [EMAIL PROTECTED] Reported By: Oscar dot Castillo at jpl dot nasa dot gov Status: Assigned Bug Type: iPlanet related Operating System: Solaris 9 PHP Version: 5CVS-2005-04-07 (dev) Assigned To: thetaphi New Comment: Yes, CGI works perfect because crashes of PHP does not affect PHP and the FD limit is not applicable, too. For higher load webservers CGI could be a performance issue. For servers that only have a few PHP scripts it should be enough. A solution with the same performance like NSAPI would be using Zend's FastCGI enabler - but its not open source as I know. My servers produced with SunONE 6.0 a coredump when I debugged the revised NSAPI module two years ago, but with 6.1 I do not know. The only problem is to find the core dump because it is not in the directory the server binaries are. They are in the CWD of the process (usually in the base dir of the running instance). I am still trying to eliminate all Sun stdio problems. The next would be replacing popen() by posix functions in the exec/system functions. One tip by Wez Furlong: Instead of exec/system use the group of functions around proc_open(). They use POSIX io. Previous Comments: [2005-04-09 01:48:08] Oscar dot Castillo at jpl dot nasa dot gov By default, iPlanet is not configured to core dump. Some special flags must be enabled to allow core dumping. I do not know the specific syntax to enable core dumping and I must then open a trouble ticket with Sun. I am attempting your suggestion from bug report #32491 to enable PHP as a CGI/Fastcgi via your cgibytex CGI enabler. As of the last 7 hours, PHP is working perfectly. I shall keep you posted. [2005-04-08 17:30:37] [EMAIL PROTECTED] Something other: can you load the "core" file the crashing server produces into dbx or gdb and send me the output? [2005-04-08 09:48:00] [EMAIL PROTECTED] Info about the solaris "bug": http://docs.sun.com/app/docs/doc/816-5168/6mbb3hr5q?a=view (see under "USAGE") In 64bit solaris it would work, but SunONE is a 32 bit server. [2005-04-08 09:37:01] [EMAIL PROTECTED] I found the reason for the bug. The problem is not the file upload here that works now. The problem is now the same stdio related bug which leads to the segmentation fault. I fixed the CVS now not to crash the webserver in this error condition (missing an errorchecking at fdopen() which works on all platform without errors, on solaris fails when the filedescriptor>255). But the problem should still be there but you should get a message in your PHP script. Looking into your code I exspect the "execute" functions to fail because they need to cast a stream from posix to stdio. Please test the new CVS and tell me when the further handling of your uploaded file fails. [2005-04-07 18:27:43] Oscar dot Castillo at jpl dot nasa dot gov I also forgot to mention that I am running PHP 5.0.5-dev on 2 other web servers that are used for testing and development of Java, PERL and PHP applications prior to being delivered to the production environment. All flavors of PHP have always worked in the test and development environments, but never in the production environment. The only difference between the 3 environments is that the production environment has a much heavier load than the test and development environments put together. The OS, OS patches, iPlanet version and PHP version are all exactly the same in all 3 web server environments. The fact that you cannot produce the crash in your environment can be related to the light load on your test set up. As mentioned in my last bug report (#32491), I have Java enabled (Very memory intensive) on the web server and our production environment mostly uses JSP and Java servlets. 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/32614 -- Edit this bug report at http://bugs.php.net/?id=32614&edit=1
#32644 [Fbk->Opn]: move_uploaded_file() relative path
ID: 32644
User updated by: tck at tcknetwork dot com
Reported By: tck at tcknetwork dot com
-Status: Feedback
+Status: Open
Bug Type: Filesystem function related
Operating System: WinXP(SP2)
PHP Version: 5.0.4
New Comment:
As recommended, I upgraded to the 5.1.0-dev snapshot (php5ts.dll &
php5apache2.dll) and deleted my php.ini to be sure there wouldn't be
any misconfigured option.
On top of that I edited my script like this (I added all warnings as
demanded and a little fix to avoid a warning message not related to the
bug) :
">
I tried to run my script twice (like before) but the problem remains
exactely the same.
The hard disk root is still taken as the "current directory" instead of
the script's directory.
I'm nearly sure that the bug happened when I upgraded from 5.0.3 to
5.0.4.
Does this bug come from a "default include directory" or something like
that where the engine decide to go first ?
The most annoying is that once the file in D:\Data\demo.jpg exists, the
function works as expected...
Previous Comments:
[2005-04-10 21:38:25] [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
Also add this to be first line in your script handling the upload:
error_reporting(E_ALL); ini_set('display_errors', 1);
[2005-04-09 17:17:08] tck at tcknetwork dot com
This happens both if I use zend optimizer or not (I doubted it could be
a possible source of problems. Note as well that my Apache (2.0.53,
using php as a module) root is on D:\Server if it may help.
[2005-04-09 16:53:29] tck at tcknetwork dot com
Description:
The move_uploaded_file() use the root of the hard disk in some special
cases instead of using the relative path from the script.
So far require() is not affected by this problem. I think it is just
this function that handles not properly the path.
Reproduce code:
---
My file system is built like this :
D:\Data (directory)
D:\Web\data (directory << note the ressemblance)
D:\Web\test\up.php (my script)
My script contains the following :
">
Expected result:
When I send a file, I expect it to be uploaded into
dirname("D:\Web\test\up.php")."../data/demo.jpg"
it means "D:\Web\data\demo.jpg".
In fact when I submit a file with my script twice, the following
happens :
1st submit : File uploaded into "D:\Data\demo.jpg"
(using the root instead of relative path)
2nd submit : File uploaded into "D:\Web\data\demo.jpg"
(working as expected only if the file "D:\Data\demo.jpg" exists)
Actual result:
--
Actually the PHP developer can fix this bug by changing the upload
line
@move_uploaded_file($f,"../data/demo.jpg");
by
@move_uploaded_file($f,dirname($_SERVER["SCRIPT_FILENAME"])."/../data/demo.jpg");
note that if the directory D:\Data
does not exists, the function will place the file properly into
D:\Web\data
--
Edit this bug report at http://bugs.php.net/?id=32644&edit=1
#32644 [Opn]: move_uploaded_file() relative path
ID: 32644
User updated by: tck at tcknetwork dot com
Reported By: tck at tcknetwork dot com
Status: Open
Bug Type: Filesystem function related
Operating System: WinXP(SP2)
PHP Version: 5.0.4
New Comment:
The next question will be probably "what if you dismiss the ../" ? The
answer is that it works properly :
move_uploaded_file($_FILES["myfile"]["tmp_name"],"data/demo.jpg");
move properly the file into D:\Web\test\data, but the problem still
remains if I have
move_uploaded_file($_FILES["myfile"]["tmp_name"],"../data/demo.jpg")
In fact the bug happen only if you go backward in the filesystem tree,
no matter how deep you are (I tried from
D:\Web\test\test\demo\up\up.php > D:\Web\test\test\demo\data but the
file went still into D:\data)
Previous Comments:
[2005-04-10 22:35:21] tck at tcknetwork dot com
As recommended, I upgraded to the 5.1.0-dev snapshot (php5ts.dll &
php5apache2.dll) and deleted my php.ini to be sure there wouldn't be
any misconfigured option.
On top of that I edited my script like this (I added all warnings as
demanded and a little fix to avoid a warning message not related to the
bug) :
">
I tried to run my script twice (like before) but the problem remains
exactely the same.
The hard disk root is still taken as the "current directory" instead of
the script's directory.
I'm nearly sure that the bug happened when I upgraded from 5.0.3 to
5.0.4.
Does this bug come from a "default include directory" or something like
that where the engine decide to go first ?
The most annoying is that once the file in D:\Data\demo.jpg exists, the
function works as expected...
[2005-04-10 21:38:25] [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
Also add this to be first line in your script handling the upload:
error_reporting(E_ALL); ini_set('display_errors', 1);
[2005-04-09 17:17:08] tck at tcknetwork dot com
This happens both if I use zend optimizer or not (I doubted it could be
a possible source of problems. Note as well that my Apache (2.0.53,
using php as a module) root is on D:\Server if it may help.
[2005-04-09 16:53:29] tck at tcknetwork dot com
Description:
The move_uploaded_file() use the root of the hard disk in some special
cases instead of using the relative path from the script.
So far require() is not affected by this problem. I think it is just
this function that handles not properly the path.
Reproduce code:
---
My file system is built like this :
D:\Data (directory)
D:\Web\data (directory << note the ressemblance)
D:\Web\test\up.php (my script)
My script contains the following :
">
Expected result:
When I send a file, I expect it to be uploaded into
dirname("D:\Web\test\up.php")."../data/demo.jpg"
it means "D:\Web\data\demo.jpg".
In fact when I submit a file with my script twice, the following
happens :
1st submit : File uploaded into "D:\Data\demo.jpg"
(using the root instead of relative path)
2nd submit : File uploaded into "D:\Web\data\demo.jpg"
(working as expected only if the file "D:\Data\demo.jpg" exists)
Actual result:
--
Actually the PHP developer can fix this bug by changing the upload
line
@move_uploaded_file($f,"../data/demo.jpg");
by
@move_uploaded_file($f,dirname($_SERVER["SCRIPT_FILENAME"])."/../data/demo.jpg");
note that if the directory D:\Data
does not exists, the function will place the file properly into
D:\Web\data
--
Edit this bug report at http://bugs.php.net/?id=32644&edit=1
#32540 [Fbk->NoF]: Bad ntwdblib.dll
ID: 32540 Updated by: php-bugs@lists.php.net Reported By: jon at crystaltech dot com -Status: Feedback +Status: No Feedback Bug Type: MSSQL related Operating System: Windows 2003 Server PHP Version: 4.3.11 New Comment: No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". Previous Comments: [2005-04-03 16:38:45] [EMAIL PROTECTED] Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to "Open". Thank you for your interest in PHP. [2005-04-02 06:20:55] jon at crystaltech dot com Description: Connect phpBB 2.13 to MS SQL 2000 Server. Had this issue with 4.3.10, and had to use the php_mssql.dll from the 4.3.11-Dev extensions folder. Now with 4.3.11, I have to use the old ntwdblib.dll file for the system32 folder for some php / mssql connections to work. Expected result: Should connect with no error Actual result: -- Error Failed to Connect to SQL Server -- Edit this bug report at http://bugs.php.net/?id=32540&edit=1
#32637 [Fbk->Opn]: No libphp5.so is created when using --with-mysql option
ID: 32637 User updated by: Anand dot Murugesan at eds dot com Reported By: Anand dot Murugesan at eds dot com -Status: Feedback +Status: Open Bug Type: Apache2 related Operating System: Solaris 10 / Sparc PHP Version: 5CVS-2005-04-08 (dev) New Comment: I didn't add anything specific, I just picked the default other than --enable-so option. Here is the httpd -l output Compiled in modules: core.c prefork.c http_core.c mod_so.c - I do get these error messges on the latest build.. configure: warning: You will need re2c 0.94 or later if you want to regenerate PHP parsers. configure: warning: You will need flex 2.5.4 if you want to regenerate Zend/PHP lexical parsers. ./configure: !: not found -- And there is no mention of apxs2 or apache in the "configure" output Can those warnings have something to do with it? - Hehehe Yeah I do have apache2 installed. Server version: Apache/2.0.53 Server built: Apr 9 2005 01:48:51 Previous Comments: [2005-04-10 21:31:14] [EMAIL PROTECTED] No, the --with-apxs2 is correct option to use with Apache2. What does it say during configure for the apxs2 config? What MPM does your apache2 use? Do you really HAVE Apache2 installed?? [2005-04-09 17:38:40] Anand dot Murugesan at eds dot com Nope no luck on the CVS-latest for unix either. I saw it mentiones aspx2 a experimental, should I try and use a different option to configure? Thanks. [2005-04-09 09:31:52] [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-04-09 04:30:48] Anand dot Murugesan at eds dot com Solaris 10 sparcv9 --- Configure Line - ./configure --with-mysql= --with-apsx2=/bin/apsx --- gcc version 3.4.2 Configured with: ../gcc-3.4.2/configure --prefix=/opt/sfw --with-ld=/usr/ccs/bin/ld --with-gnu-as --with-as=/opt/sfw/bin/gas --enable-shared --disable-libgcj Thread model: posix [2005-04-09 02:39:35] [EMAIL PROTECTED] What Operating system? What configure line? What GCC?? READ THIS: http://bugs.php.net/how-to-report.php 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/32637 -- Edit this bug report at http://bugs.php.net/?id=32637&edit=1
#30819 [Opn->Fbk]: Patch to properly support LDAP SASL binds
ID: 30819
Updated by: [EMAIL PROTECTED]
Reported By: quanah at stanford dot edu
-Status: Open
+Status: Feedback
Bug Type: LDAP related
Operating System: *
PHP Version: 5CVS-2005-02-21
New Comment:
Please try this modified patch:
http://www.php.net/~jani/patches/bug30819.patch
I added some convenience constants and made all the
parameters optional (except for the 1st one).
I tried it with your script here but it didn't work for me.
Previous Comments:
[2004-11-18 00:50:52] dhawes at vt dot edu
I attempted to get a similar patch submitted last May, but discussion
came to a standstill. Quanah and I have tested this with GSSAPI,
EXTERNAL, and (I believe) DIGEST-MD5. I would like to see this patch
included in PHP so I can stop requiring users to patch their source.
[2004-11-18 00:16:46] quanah at stanford dot edu
Description:
Hello,
I've written a patch against PHP-5.0.2 that properly impelments LDAP
SASL binds for all mechanisms. The current code in 5.0.2 does not
support LDAP SASL binds at all, although the function exists.
The patch can be found at:
http://www.stanford.edu/services/directory/clients/examples/ldap-sasl
It follows the PHP development guidelines.
This patch has been tested with multiple SASL authentication
mechanisms.
Regards,
Quanah
Reproduce code:
---
#!/usr/local/bin/php
";
print("\n");
$info = ldap_get_entries($ldap,$result);
echo "Data for " . $info["count"] . " items returned:";
print("\n");
for($i=0;$i<$info["count"];$i++) {
echo "dn is: " . $info[$i]["dn"] . "";
print("\n");
echo "first cn entry is: " . $info[$i]["cn"][0] . "";
print("\n");
echo "first email is: " . $info[$i]["mail"][0] . " ";
print("\n");
}
}
ldap_close($ldap);
}
?>
Expected result:
I'd expect this to work in PHP
Actual result:
--
Doesn't work at all without my patch.
Works correctly with my patch.
--
Edit this bug report at http://bugs.php.net/?id=30819&edit=1
#32647 [Ver->Asn]: Register_shutdown_function can crash apache2
ID: 32647 Updated by: [EMAIL PROTECTED] Reported By: interghost at crovortex dot com -Status: Verified +Status: Assigned Bug Type: Reproducible crash Operating System: * PHP Version: 4.*, 5.* -Assigned To: +Assigned To: sniper Previous Comments: [2005-04-09 21:05:43] interghost at crovortex dot com Description: When calling register_shutdown_function with an array argument in which the first index is an unset variable or if the first index is numeric 0 and the second any string variable apache2 crashes...I've tested it on Apache v2.0.52 and v2.0.53. In the server's error log it says: [Sat Apr 09 20:37:19 2005] [notice] Parent: child process exited with status 3221225477 -- Restarting. [Sat Apr 09 20:37:19 2005] [notice] Apache/2.0.53 (Win32) PHP/5.0.4 configured -- resuming normal operations [Sat Apr 09 20:37:19 2005] [notice] Server built: Feb 10 2005 06:11:34 [Sat Apr 09 20:37:19 2005] [notice] Parent: Created child process 3900 [Sat Apr 09 20:37:19 2005] [notice] Child 3900: Child process is running [Sat Apr 09 20:37:19 2005] [notice] Child 3900: Acquired the start mutex. [Sat Apr 09 20:37:19 2005] [notice] Child 3900: Starting 250 worker threads. Reproduce code: --- unset($obj); register_shutdown_function(array($obj,"")); register_shutdown_function(array($obj,"some string")); register_shutdown_function(array(0,"")); register_shutdown_function(array(0,"some string")); -- Edit this bug report at http://bugs.php.net/?id=32647&edit=1
#32644 [Opn->Fbk]: move_uploaded_file() relative path
ID: 32644
Updated by: [EMAIL PROTECTED]
Reported By: tck at tcknetwork dot com
-Status: Open
+Status: Feedback
Bug Type: Filesystem function related
Operating System: WinXP(SP2)
PHP Version: 5.0.4
New Comment:
And you are aware that Apache does an internal 'cwd /' ?
(changes working directory to root)
Previous Comments:
[2005-04-10 22:45:31] tck at tcknetwork dot com
The next question will be probably "what if you dismiss the ../" ? The
answer is that it works properly :
move_uploaded_file($_FILES["myfile"]["tmp_name"],"data/demo.jpg");
move properly the file into D:\Web\test\data, but the problem still
remains if I have
move_uploaded_file($_FILES["myfile"]["tmp_name"],"../data/demo.jpg")
In fact the bug happen only if you go backward in the filesystem tree,
no matter how deep you are (I tried from
D:\Web\test\test\demo\up\up.php > D:\Web\test\test\demo\data but the
file went still into D:\data)
[2005-04-10 22:35:21] tck at tcknetwork dot com
As recommended, I upgraded to the 5.1.0-dev snapshot (php5ts.dll &
php5apache2.dll) and deleted my php.ini to be sure there wouldn't be
any misconfigured option.
On top of that I edited my script like this (I added all warnings as
demanded and a little fix to avoid a warning message not related to the
bug) :
">
I tried to run my script twice (like before) but the problem remains
exactely the same.
The hard disk root is still taken as the "current directory" instead of
the script's directory.
I'm nearly sure that the bug happened when I upgraded from 5.0.3 to
5.0.4.
Does this bug come from a "default include directory" or something like
that where the engine decide to go first ?
The most annoying is that once the file in D:\Data\demo.jpg exists, the
function works as expected...
[2005-04-10 21:38:25] [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
Also add this to be first line in your script handling the upload:
error_reporting(E_ALL); ini_set('display_errors', 1);
[2005-04-09 17:17:08] tck at tcknetwork dot com
This happens both if I use zend optimizer or not (I doubted it could be
a possible source of problems. Note as well that my Apache (2.0.53,
using php as a module) root is on D:\Server if it may help.
[2005-04-09 16:53:29] tck at tcknetwork dot com
Description:
The move_uploaded_file() use the root of the hard disk in some special
cases instead of using the relative path from the script.
So far require() is not affected by this problem. I think it is just
this function that handles not properly the path.
Reproduce code:
---
My file system is built like this :
D:\Data (directory)
D:\Web\data (directory << note the ressemblance)
D:\Web\test\up.php (my script)
My script contains the following :
">
Expected result:
When I send a file, I expect it to be uploaded into
dirname("D:\Web\test\up.php")."../data/demo.jpg"
it means "D:\Web\data\demo.jpg".
In fact when I submit a file with my script twice, the following
happens :
1st submit : File uploaded into "D:\Data\demo.jpg"
(using the root instead of relative path)
2nd submit : File uploaded into "D:\Web\data\demo.jpg"
(working as expected only if the file "D:\Data\demo.jpg" exists)
Actual result:
--
Actually the PHP developer can fix this bug by changing the upload
line
@move_uploaded_file($f,"../data/demo.jpg");
by
@move_uploaded_file($f,dirname($_SERVER["SCRIPT_FILENAME"])."/../data/demo.jpg");
note that if the directory D:\Data
does not exists, the function will place the file properly into
D:\Web\data
--
Edit this bug report at http://bugs.php.net/?id=32644&edit=1
#32662 [NEW]: A few acuted letters don't recongnized
From: aeoris at gmail dot com Operating system: All PHP version: 5.0.4 PHP Bug Type: Unknown/Other Function Bug description: A few acuted letters don't recongnized Description: PHP don't recognize letters like "acuted R" (in fact any acutted letter distinct from [aeiouy]) as "letters". Reproduce code: --- Expected result: bool(true) bool(true) int(1) int(1) Actual result: -- bool(false) bool(false) int(0) int(0) -- Edit bug report at http://bugs.php.net/?id=32662&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=32662&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=32662&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=32662&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=32662&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=32662&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=32662&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=32662&r=needscript Try newer version: http://bugs.php.net/fix.php?id=32662&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=32662&r=support Expected behavior: http://bugs.php.net/fix.php?id=32662&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=32662&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=32662&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=32662&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=32662&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=32662&r=dst IIS Stability: http://bugs.php.net/fix.php?id=32662&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=32662&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=32662&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=32662&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=32662&r=mysqlcfg
#32660 [Opn->Ver]: Assignment by reference causes crash when field access is overloaded (__get)
ID: 32660
Updated by: [EMAIL PROTECTED]
Reported By: ladislav dot prosek at matfyz dot cz
-Status: Open
+Status: Verified
Bug Type: Zend Engine 2 problem
-Operating System: Windows XP SP2
+Operating System: *
-PHP Version: 5.0.4
+PHP Version: 5CVS-2005-04-11
New Comment:
object(A)#1 (1) {
["q"]=>
&UNKNOWN:0
}
/usr/src/php/php5/Zend/zend_execute.c(891) : Freeing 0x0A117D6C (16
bytes), script=/home/jani/t.php
/usr/src/php/php5/Zend/zend_variables.h(45) : Freeing 0x0A117D2C (12
bytes), script=/home/jani/t.php
/usr/src/php/php5/Zend/zend_variables.c(120) : Actual location
(location was relayed)
=== Total 2 memory leaks detected ===
Previous Comments:
[2005-04-10 22:22:04] ladislav dot prosek at matfyz dot cz
Description:
There is probably a bug in memory allocation related to property
getters. Note that the behavior depends on lengths of the two strings
and also on the way the $q property is initialized.
Reproduce code:
---
class A
{
var $q;
function __construct()
{
$this->q = array();
}
function __get($name)
{
return $this->q;
}
};
$a = new A;
$b = "short";
$a->whatever =& $b;
$b = "much longer";
var_dump($a);
Expected result:
// as __get does not return a reference
// the output should IMHO look like this:
object(A)#1 (1) {
["q"]=>
array(0) {
}
}
// if you guys think the output should be
// different, please do explain it!
Actual result:
--
object(A)#1 (1) {
["q"]=>
CRASH!
--
Edit this bug report at http://bugs.php.net/?id=32660&edit=1
#32662 [Opn->Bgs]: A few acuted letters don't recongnized
ID: 32662 Updated by: [EMAIL PROTECTED] Reported By: aeoris at gmail dot com -Status: Open +Status: Bogus Bug Type: *Languages/Translation Operating System: All PHP Version: 5.0.4 New Comment: Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. Previous Comments: [2005-04-11 02:04:31] aeoris at gmail dot com Description: PHP don't recognize letters like "acuted R" (in fact any acutted letter distinct from [aeiouy]) as "letters". Reproduce code: --- Expected result: bool(true) bool(true) int(1) int(1) Actual result: -- bool(false) bool(false) int(0) int(0) -- Edit this bug report at http://bugs.php.net/?id=32662&edit=1
#32637 [Opn->Fbk]: No libphp5.so is created when using --with-mysql option
ID: 32637 Updated by: [EMAIL PROTECTED] Reported By: Anand dot Murugesan at eds dot com -Status: Open +Status: Feedback Bug Type: Apache2 related Operating System: Solaris 10 / Sparc PHP Version: 5CVS-2005-04-08 (dev) New Comment: In what part of the configure output is that "./configure: !: not found" ?? (paste 5 lines before, 5 lines after) Previous Comments: [2005-04-11 01:38:45] Anand dot Murugesan at eds dot com I didn't add anything specific, I just picked the default other than --enable-so option. Here is the httpd -l output Compiled in modules: core.c prefork.c http_core.c mod_so.c - I do get these error messges on the latest build.. configure: warning: You will need re2c 0.94 or later if you want to regenerate PHP parsers. configure: warning: You will need flex 2.5.4 if you want to regenerate Zend/PHP lexical parsers. ./configure: !: not found -- And there is no mention of apxs2 or apache in the "configure" output Can those warnings have something to do with it? - Hehehe Yeah I do have apache2 installed. Server version: Apache/2.0.53 Server built: Apr 9 2005 01:48:51 [2005-04-10 21:31:14] [EMAIL PROTECTED] No, the --with-apxs2 is correct option to use with Apache2. What does it say during configure for the apxs2 config? What MPM does your apache2 use? Do you really HAVE Apache2 installed?? [2005-04-09 17:38:40] Anand dot Murugesan at eds dot com Nope no luck on the CVS-latest for unix either. I saw it mentiones aspx2 a experimental, should I try and use a different option to configure? Thanks. [2005-04-09 09:31:52] [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-04-09 04:30:48] Anand dot Murugesan at eds dot com Solaris 10 sparcv9 --- Configure Line - ./configure --with-mysql= --with-apsx2=/bin/apsx --- gcc version 3.4.2 Configured with: ../gcc-3.4.2/configure --prefix=/opt/sfw --with-ld=/usr/ccs/bin/ld --with-gnu-as --with-as=/opt/sfw/bin/gas --enable-shared --disable-libgcj Thread model: posix 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/32637 -- Edit this bug report at http://bugs.php.net/?id=32637&edit=1
#32637 [Fbk->Opn]: No libphp5.so is created when using --with-mysql option
ID: 32637 User updated by: Anand dot Murugesan at eds dot com Reported By: Anand dot Murugesan at eds dot com -Status: Feedback +Status: Open Bug Type: Apache2 related Operating System: Solaris 10 / Sparc PHP Version: 5CVS-2005-04-08 (dev) New Comment: When I configure with --with-apxs and point it to the apache1.33 this check is done checking for chosen SAPI module... apache which is not done with apxs2. Previous Comments: [2005-04-11 02:08:31] [EMAIL PROTECTED] In what part of the configure output is that "./configure: !: not found" ?? (paste 5 lines before, 5 lines after) [2005-04-11 01:38:45] Anand dot Murugesan at eds dot com I didn't add anything specific, I just picked the default other than --enable-so option. Here is the httpd -l output Compiled in modules: core.c prefork.c http_core.c mod_so.c - I do get these error messges on the latest build.. configure: warning: You will need re2c 0.94 or later if you want to regenerate PHP parsers. configure: warning: You will need flex 2.5.4 if you want to regenerate Zend/PHP lexical parsers. ./configure: !: not found -- And there is no mention of apxs2 or apache in the "configure" output Can those warnings have something to do with it? - Hehehe Yeah I do have apache2 installed. Server version: Apache/2.0.53 Server built: Apr 9 2005 01:48:51 [2005-04-10 21:31:14] [EMAIL PROTECTED] No, the --with-apxs2 is correct option to use with Apache2. What does it say during configure for the apxs2 config? What MPM does your apache2 use? Do you really HAVE Apache2 installed?? [2005-04-09 17:38:40] Anand dot Murugesan at eds dot com Nope no luck on the CVS-latest for unix either. I saw it mentiones aspx2 a experimental, should I try and use a different option to configure? Thanks. [2005-04-09 09:31:52] [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 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/32637 -- Edit this bug report at http://bugs.php.net/?id=32637&edit=1
#32637 [Opn]: No libphp5.so is created when using --with-mysql option
ID: 32637 User updated by: Anand dot Murugesan at eds dot com Reported By: Anand dot Murugesan at eds dot com Status: Open Bug Type: Apache2 related Operating System: Solaris 10 / Sparc PHP Version: 5CVS-2005-04-08 (dev) New Comment: Here you go checking ODBC v3 driver for PDO... no checking for PostgreSQL support for PDO... no checking for sqlite 3 driver for PDO... yes checking for PDO includes... /usr/share/src/php5-200504091430/ext checking size of char *... (cached) 4 ./configure: !: not found checking for usleep... (cached) yes checking for nanosleep... (cached) no checking for time.h... (cached) yes Previous Comments: [2005-04-11 02:30:24] Anand dot Murugesan at eds dot com When I configure with --with-apxs and point it to the apache1.33 this check is done checking for chosen SAPI module... apache which is not done with apxs2. [2005-04-11 02:08:31] [EMAIL PROTECTED] In what part of the configure output is that "./configure: !: not found" ?? (paste 5 lines before, 5 lines after) [2005-04-11 01:38:45] Anand dot Murugesan at eds dot com I didn't add anything specific, I just picked the default other than --enable-so option. Here is the httpd -l output Compiled in modules: core.c prefork.c http_core.c mod_so.c - I do get these error messges on the latest build.. configure: warning: You will need re2c 0.94 or later if you want to regenerate PHP parsers. configure: warning: You will need flex 2.5.4 if you want to regenerate Zend/PHP lexical parsers. ./configure: !: not found -- And there is no mention of apxs2 or apache in the "configure" output Can those warnings have something to do with it? - Hehehe Yeah I do have apache2 installed. Server version: Apache/2.0.53 Server built: Apr 9 2005 01:48:51 [2005-04-10 21:31:14] [EMAIL PROTECTED] No, the --with-apxs2 is correct option to use with Apache2. What does it say during configure for the apxs2 config? What MPM does your apache2 use? Do you really HAVE Apache2 installed?? [2005-04-09 17:38:40] Anand dot Murugesan at eds dot com Nope no luck on the CVS-latest for unix either. I saw it mentiones aspx2 a experimental, should I try and use a different option to configure? Thanks. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/32637 -- Edit this bug report at http://bugs.php.net/?id=32637&edit=1
#32637 [Opn]: No libphp5.so is created when using --with-mysql option
ID: 32637 User updated by: Anand dot Murugesan at eds dot com Reported By: Anand dot Murugesan at eds dot com Status: Open Bug Type: Apache2 related Operating System: Solaris 10 / Sparc PHP Version: 5CVS-2005-04-08 (dev) New Comment: Never mind my previous comment about apxs not in configure... It does seem to do the check checking for Apache 2.0 handler-module support via DSO through APXS... yes Previous Comments: [2005-04-11 02:35:17] Anand dot Murugesan at eds dot com Here you go checking ODBC v3 driver for PDO... no checking for PostgreSQL support for PDO... no checking for sqlite 3 driver for PDO... yes checking for PDO includes... /usr/share/src/php5-200504091430/ext checking size of char *... (cached) 4 ./configure: !: not found checking for usleep... (cached) yes checking for nanosleep... (cached) no checking for time.h... (cached) yes [2005-04-11 02:30:24] Anand dot Murugesan at eds dot com When I configure with --with-apxs and point it to the apache1.33 this check is done checking for chosen SAPI module... apache which is not done with apxs2. [2005-04-11 02:08:31] [EMAIL PROTECTED] In what part of the configure output is that "./configure: !: not found" ?? (paste 5 lines before, 5 lines after) [2005-04-11 01:38:45] Anand dot Murugesan at eds dot com I didn't add anything specific, I just picked the default other than --enable-so option. Here is the httpd -l output Compiled in modules: core.c prefork.c http_core.c mod_so.c - I do get these error messges on the latest build.. configure: warning: You will need re2c 0.94 or later if you want to regenerate PHP parsers. configure: warning: You will need flex 2.5.4 if you want to regenerate Zend/PHP lexical parsers. ./configure: !: not found -- And there is no mention of apxs2 or apache in the "configure" output Can those warnings have something to do with it? - Hehehe Yeah I do have apache2 installed. Server version: Apache/2.0.53 Server built: Apr 9 2005 01:48:51 [2005-04-10 21:31:14] [EMAIL PROTECTED] No, the --with-apxs2 is correct option to use with Apache2. What does it say during configure for the apxs2 config? What MPM does your apache2 use? Do you really HAVE Apache2 installed?? 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/32637 -- Edit this bug report at http://bugs.php.net/?id=32637&edit=1
#32663 [NEW]: odbc_fetch_row fails to get single selected MySQL text column
From: mizmerize at yahoo dot com Operating system: Windows 2000 Advanced Server SP3 PHP version: 5.0.4 PHP Bug Type: ODBC related Bug description: odbc_fetch_row fails to get single selected MySQL text column Description: I used ODBC Unified using a MyODBC driver version 3.51.11 and connected to a table with a varchar and a TEXT column. Then I created a query like this: $sql="SELECT Title FROM tbllibrarymaterials" .. the odbc_exec function does good. It provides a non-false result. but if I have to get the rows by using odbc_fetch_row, this function returns false and I could not get a record. But... If I defined another column along with the query: $sql="SELECT Title, Call_Number FROM tbllibrarymaterials" ...I get the expected results. [PHP.INI] odbc.longreadlen=65535 odbc.binmode=1 I set this because it may be the problem with long columns. But this settings did not change anything. Reproduce code: --- To reproduce the bug, you must create a table called "tbllibmaterials" (or any name) in MySQL with a varchar(50) for the Call_Number and TEXT column for the Title, and use odbc_fetch_row running the query: $sql="SELECT Title FROM tbllibrarymaterials" Expected result: No records can be retrieved. Actual result: -- No records can be retrieved. -- Edit bug report at http://bugs.php.net/?id=32663&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=32663&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=32663&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=32663&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=32663&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=32663&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=32663&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=32663&r=needscript Try newer version: http://bugs.php.net/fix.php?id=32663&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=32663&r=support Expected behavior: http://bugs.php.net/fix.php?id=32663&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=32663&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=32663&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=32663&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=32663&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=32663&r=dst IIS Stability: http://bugs.php.net/fix.php?id=32663&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=32663&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=32663&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=32663&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=32663&r=mysqlcfg
#32664 [NEW]: public class function can be assigned like a public variable
From: mizmerize at yahoo dot com
Operating system: Windows 2000 Advanced Server SP3
PHP version: 5.0.4
PHP Bug Type: Class/Object related
Bug description: public class function can be assigned like a public variable
Description:
I made a class that has a public function. If I assign a value to the
function, PHP will allow to assign a value, and if I started to retrieve
the value, it will return the value.
Reproduce code:
---
/*example*/
class Field {
function GetField(){
}
}
/*usage*/
$m_Field=new Field;
$m_Field->GetField="Hello";
echo $m_Field->GetField; /* please note the absence of parenthesis*/
Expected result:
it should produce a fatal error, concerning the assigning of the data in a
function;
Actual result:
--
Hello
/* returns the value you have set.*/
--
Edit bug report at http://bugs.php.net/?id=32664&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=32664&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=32664&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=32664&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=32664&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=32664&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=32664&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=32664&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=32664&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=32664&r=support
Expected behavior: http://bugs.php.net/fix.php?id=32664&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=32664&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=32664&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=32664&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=32664&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=32664&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=32664&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=32664&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=32664&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=32664&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=32664&r=mysqlcfg
#32637 [Opn]: No libphp5.so is created when using --with-mysql option
ID: 32637 User updated by: Anand dot Murugesan at eds dot com Reported By: Anand dot Murugesan at eds dot com Status: Open Bug Type: Apache2 related Operating System: Solaris 10 / Sparc PHP Version: 5CVS-2005-04-08 (dev) New Comment: The newest - newest tar ball work. Thanks Guy. Previous Comments: [2005-04-11 02:40:51] Anand dot Murugesan at eds dot com Never mind my previous comment about apxs not in configure... It does seem to do the check checking for Apache 2.0 handler-module support via DSO through APXS... yes [2005-04-11 02:35:17] Anand dot Murugesan at eds dot com Here you go checking ODBC v3 driver for PDO... no checking for PostgreSQL support for PDO... no checking for sqlite 3 driver for PDO... yes checking for PDO includes... /usr/share/src/php5-200504091430/ext checking size of char *... (cached) 4 ./configure: !: not found checking for usleep... (cached) yes checking for nanosleep... (cached) no checking for time.h... (cached) yes [2005-04-11 02:30:24] Anand dot Murugesan at eds dot com When I configure with --with-apxs and point it to the apache1.33 this check is done checking for chosen SAPI module... apache which is not done with apxs2. [2005-04-11 02:08:31] [EMAIL PROTECTED] In what part of the configure output is that "./configure: !: not found" ?? (paste 5 lines before, 5 lines after) [2005-04-11 01:38:45] Anand dot Murugesan at eds dot com I didn't add anything specific, I just picked the default other than --enable-so option. Here is the httpd -l output Compiled in modules: core.c prefork.c http_core.c mod_so.c - I do get these error messges on the latest build.. configure: warning: You will need re2c 0.94 or later if you want to regenerate PHP parsers. configure: warning: You will need flex 2.5.4 if you want to regenerate Zend/PHP lexical parsers. ./configure: !: not found -- And there is no mention of apxs2 or apache in the "configure" output Can those warnings have something to do with it? - Hehehe Yeah I do have apache2 installed. Server version: Apache/2.0.53 Server built: Apr 9 2005 01:48:51 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/32637 -- Edit this bug report at http://bugs.php.net/?id=32637&edit=1
#32664 [Opn->Bgs]: public class function can be assigned like a public variable
ID: 32664
Updated by: [EMAIL PROTECTED]
Reported By: mizmerize at yahoo dot com
-Status: Open
+Status: Bogus
Bug Type: Class/Object related
Operating System: Windows 2000 Advanced Server SP3
PHP Version: 5.0.4
New Comment:
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
.
Previous Comments:
[2005-04-11 03:41:17] mizmerize at yahoo dot com
Description:
I made a class that has a public function. If I assign a value to the
function, PHP will allow to assign a value, and if I started to
retrieve the value, it will return the value.
Reproduce code:
---
/*example*/
class Field {
function GetField(){
}
}
/*usage*/
$m_Field=new Field;
$m_Field->GetField="Hello";
echo $m_Field->GetField; /* please note the absence of parenthesis*/
Expected result:
it should produce a fatal error, concerning the assigning of the data
in a function;
Actual result:
--
Hello
/* returns the value you have set.*/
--
Edit this bug report at http://bugs.php.net/?id=32664&edit=1
#32665 [NEW]: Premature flushing of output buffer when register_shutdown function called
From: prathap at ee dot pdn dot ac dot lk
Operating system: Gentoo Linux
PHP version: 5.0.3
PHP Bug Type: Output Control
Bug description: Premature flushing of output buffer when register_shutdown
function called
Description:
Hello,
I've posted a miniature version of my code here to explain my doubt.
This simply does not work the way it should. i.e ob_get_contents doen't
return
any string and the buffer just gets flushed by itself at termination.
Though the PHP manual says it is not possible to retrieve the contents of
any
output buffers using ob_get_contents() with PHP < 4.0.6. But I am using
PHP 5.
x.x
I posted this problem in the mailing list and I got this response from
skrol29:
I've tested your code on PHP 4.3.3 and I have the same behavior has yours.
"Hello" is output at the end of the PhpInfo data, followed by a PHP notice
:
Notice: ob_end_clean(): failed to delete buffer. No buffer to delete. in
...
And there is an empty "logfile" file created in the Apache directory
insteaf
of the script's directory.
If you change in your script:
***
register_shutdown_function("hello");
echo ("HELLO ");
die();
***
by
***
// register_shutdown_function("hello");
echo ("HELLO ");
hello()
die();
***
then it runs as expected and the "logfile" file is created in the script's
directory.
It seems that when calling the shutdown function, all the buffered output
is
immedialty sent to the client and the buffer mode is closed.
You maybe have PHP bug here, or the manual is wrong about the possibility
to
retrieve the contents.
But we can notice that this also happens at the end of a script when there
is no shutdown function.
I am still not sure if this is a bug. But I would be very grateful if
someone generously volunteers to see to this.
Thank you and congrats on for the good work you have been carrying on all
throughout.
Prathap
--
Edit bug report at http://bugs.php.net/?id=32665&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=32665&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=32665&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=32665&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=32665&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=32665&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=32665&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=32665&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=32665&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=32665&r=support
Expected behavior: http://bugs.php.net/fix.php?id=32665&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=32665&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=32665&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=32665&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=32665&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=32665&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=32665&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=32665&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=32665&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=32665&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=32665&r=mysqlcfg
#31984 [Opn]: sessions fail randomly, causes a segmentation fault in apache
ID: 31984
User updated by: root at mediamonks dot net
Reported By: root at mediamonks dot net
Status: Open
Bug Type: Session related
Operating System: FreeBSD 4.11-STABLE
-PHP Version: 5CVS-2005-03-21
+PHP Version: 5CVS-2005-04-11
New Comment:
I thought I'd try attaching gdb to an apache child and provoke a
segfault with the latest stable CVS snapshot.
The result is:
Continuing.
Program received signal SIGSEGV, Segmentation fault.
0x285d9179 in php_apache_sapi_ub_write (
str=0x80ca924 "\nFatal error: Unknown: Cannot find
save handler \002 in Unknown on line 0\n",
str_length=105) at
/home/terrence/php/php5-STABLE-200504110038/sapi/apache2handler/sapi_apache2.c:76
76 r = ctx->r;
(gdb) bt
#0 0x285d9179 in php_apache_sapi_ub_write (
str=0x80ca924 "\nFatal error: Unknown: Cannot find
save handler \002 in Unknown on line 0\n",
str_length=105) at
/home/terrence/php/php5-STABLE-200504110038/sapi/apache2handler/sapi_apache2.c:76
#1 0x2857567f in php_ub_body_write_no_header (
str=0x80ca924 "\nFatal error: Unknown: Cannot find
save handler \002 in Unknown on line 0\n",
str_length=105) at
/home/terrence/php/php5-STABLE-200504110038/main/output.c:684
#2 0x28574592 in php_body_write (
str=0x80ca924 "\nFatal error: Unknown: Cannot find
save handler \002 in Unknown on line 0\n",
str_length=105) at
/home/terrence/php/php5-STABLE-200504110038/main/output.c:119
#3 0x28564667 in php_printf (format=0x285f5f20 "%s\n%s:
%s in %s on line %d\n%s")
at /home/terrence/php/php5-STABLE-200504110038/main/main.c:399
#4 0x28565192 in php_error_cb (type=1, error_filename=0x28611b8b
"Unknown", error_lineno=0, format=0x285f5cb4 "%s",
args=0xbfbff1e0 "$\2174\b\021]_(0") at
/home/terrence/php/php5-STABLE-200504110038/main/main.c:740
#5 0x285a857b in zend_error (type=1, format=0x285f5cb4 "%s") at
/home/terrence/php/php5-STABLE-200504110038/Zend/zend.c:921
#6 0x28564aff in php_verror (docref=0x0, params=0x285f5b58 "", type=1,
format=0x285dcf77 "Cannot find save handler %s",
args=0xbfbff294 "ä~4\bÀ\221b(ä~4\bàò¿¿\233~[(") at
/home/terrence/php/php5-STABLE-200504110038/main/main.c:539
#7 0x28564c3d in php_error_docref0 (docref=0x0, type=1,
format=0x285dcf77 "Cannot find save handler %s")
at /home/terrence/php/php5-STABLE-200504110038/main/main.c:559
#8 0x284d2d3e in OnUpdateSaveHandler (entry=0x82f7a00,
new_value=0x8347ee4 "\002", new_value_length=5, mh_arg1=0x0,
mh_arg2=0x0,
mh_arg3=0x0, stage=16) at
/home/terrence/php/php5-STABLE-200504110038/ext/session/session.c:102
#9 0x285b7e9b in zend_alter_ini_entry (name=0x835d0e0
"session.save_handler", name_length=21, new_value=0x835c600 "\002",
new_value_length=5, modify_type=2, stage=16) at
/home/terrence/php/php5-STABLE-200504110038/Zend/zend_ini.c:227
#10 0x285da754 in apply_config (dummy=0x8107350)
at
/home/terrence/php/php5-STABLE-200504110038/sapi/apache2handler/apache_config.c:169
#11 0x285d9c1c in php_handler (r=0x8355050) at
/home/terrence/php/php5-STABLE-200504110038/sapi/apache2handler/sapi_apache2.c:452
#12 0x8063f34 in ap_run_handler ()
#13 0x806448d in ap_invoke_handler ()
#14 0x806173f in ap_process_request ()
#15 0x805d217 in ap_process_http_connection ()
#16 0x806cc10 in ap_run_process_connection ()
#17 0x806ced4 in ap_process_connection ()
#18 0x8062b3b in child_main ()
#19 0x8062c92 in make_child ()
#20 0x8062cee in startup_children ()
#21 0x8063037 in ap_mpm_run ()
#22 0x8068aac in main ()
#23 0x805ce2e in _start ()
Previous Comments:
[2005-03-22 06:36:23] root at mediamonks dot net
Every time I tried, I downloaded the latest stable CVS snapshot and
deleted the old dirs.
php5-200503220330 does not change anything about the error or the
effects.
[2005-03-21 23:39:02] [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-03-21 23:37:42] [EMAIL PROTECTED]
You tried it with latest CVS snapshot? Fresh sources?
(delete config.cache always before reconfigure, and 'make clean' before
'make')
[2005-03-21 12:21:55] root at mediamonks dot net
does not change anything
[2005-03-21 11:13:32] [EMAIL PROTECTED]
Try without --enable-versioning
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/31984
--
Edit this bug report at http://bugs.php.net/?id=31984&edit=1
#31984 [Opn]: sessions fail randomly, causes a segmentation fault in apache
ID: 31984
User updated by: root at mediamonks dot net
Reported By: root at mediamonks dot net
Status: Open
Bug Type: Session related
Operating System: FreeBSD 4.11-STABLE
PHP Version: 5CVS-2005-04-11
New Comment:
The following "patch" fixes all the errors, and everything works as
usual after applying it:
--- session.c Thu Mar 24 02:32:45 2005
+++ session-new.c Mon Apr 11 08:39:38 2005
@@ -96,6 +96,8 @@
{
SESSION_CHECK_ACTIVE_STATE;
+ new_value="files";
PS(mod) = _php_find_ps_module(new_value TSRMLS_CC);
if (PG(modules_activated) && !PS(mod)) {
Previous Comments:
[2005-04-11 08:24:46] root at mediamonks dot net
I thought I'd try attaching gdb to an apache child and provoke a
segfault with the latest stable CVS snapshot.
The result is:
Continuing.
Program received signal SIGSEGV, Segmentation fault.
0x285d9179 in php_apache_sapi_ub_write (
str=0x80ca924 "\nFatal error: Unknown: Cannot find
save handler \002 in Unknown on line 0\n",
str_length=105) at
/home/terrence/php/php5-STABLE-200504110038/sapi/apache2handler/sapi_apache2.c:76
76 r = ctx->r;
(gdb) bt
#0 0x285d9179 in php_apache_sapi_ub_write (
str=0x80ca924 "\nFatal error: Unknown: Cannot find
save handler \002 in Unknown on line 0\n",
str_length=105) at
/home/terrence/php/php5-STABLE-200504110038/sapi/apache2handler/sapi_apache2.c:76
#1 0x2857567f in php_ub_body_write_no_header (
str=0x80ca924 "\nFatal error: Unknown: Cannot find
save handler \002 in Unknown on line 0\n",
str_length=105) at
/home/terrence/php/php5-STABLE-200504110038/main/output.c:684
#2 0x28574592 in php_body_write (
str=0x80ca924 "\nFatal error: Unknown: Cannot find
save handler \002 in Unknown on line 0\n",
str_length=105) at
/home/terrence/php/php5-STABLE-200504110038/main/output.c:119
#3 0x28564667 in php_printf (format=0x285f5f20 "%s\n%s:
%s in %s on line %d\n%s")
at /home/terrence/php/php5-STABLE-200504110038/main/main.c:399
#4 0x28565192 in php_error_cb (type=1, error_filename=0x28611b8b
"Unknown", error_lineno=0, format=0x285f5cb4 "%s",
args=0xbfbff1e0 "$\2174\b\021]_(0") at
/home/terrence/php/php5-STABLE-200504110038/main/main.c:740
#5 0x285a857b in zend_error (type=1, format=0x285f5cb4 "%s") at
/home/terrence/php/php5-STABLE-200504110038/Zend/zend.c:921
#6 0x28564aff in php_verror (docref=0x0, params=0x285f5b58 "", type=1,
format=0x285dcf77 "Cannot find save handler %s",
args=0xbfbff294 "ä~4\bÀ\221b(ä~4\bàò¿¿\233~[(") at
/home/terrence/php/php5-STABLE-200504110038/main/main.c:539
#7 0x28564c3d in php_error_docref0 (docref=0x0, type=1,
format=0x285dcf77 "Cannot find save handler %s")
at /home/terrence/php/php5-STABLE-200504110038/main/main.c:559
#8 0x284d2d3e in OnUpdateSaveHandler (entry=0x82f7a00,
new_value=0x8347ee4 "\002", new_value_length=5, mh_arg1=0x0,
mh_arg2=0x0,
mh_arg3=0x0, stage=16) at
/home/terrence/php/php5-STABLE-200504110038/ext/session/session.c:102
#9 0x285b7e9b in zend_alter_ini_entry (name=0x835d0e0
"session.save_handler", name_length=21, new_value=0x835c600 "\002",
new_value_length=5, modify_type=2, stage=16) at
/home/terrence/php/php5-STABLE-200504110038/Zend/zend_ini.c:227
#10 0x285da754 in apply_config (dummy=0x8107350)
at
/home/terrence/php/php5-STABLE-200504110038/sapi/apache2handler/apache_config.c:169
#11 0x285d9c1c in php_handler (r=0x8355050) at
/home/terrence/php/php5-STABLE-200504110038/sapi/apache2handler/sapi_apache2.c:452
#12 0x8063f34 in ap_run_handler ()
#13 0x806448d in ap_invoke_handler ()
#14 0x806173f in ap_process_request ()
#15 0x805d217 in ap_process_http_connection ()
#16 0x806cc10 in ap_run_process_connection ()
#17 0x806ced4 in ap_process_connection ()
#18 0x8062b3b in child_main ()
#19 0x8062c92 in make_child ()
#20 0x8062cee in startup_children ()
#21 0x8063037 in ap_mpm_run ()
#22 0x8068aac in main ()
#23 0x805ce2e in _start ()
[2005-03-22 06:36:23] root at mediamonks dot net
Every time I tried, I downloaded the latest stable CVS snapshot and
deleted the old dirs.
php5-200503220330 does not change anything about the error or the
effects.
[2005-03-21 23:39:02] [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-03-21 23:37:42] [EMAIL PROTECTED]
You tried it with latest CVS snapshot? Fresh sources?
(delete config.cache always before reconfigure, and 'make clean' before
'make')
[2005-03-21 12:21:55] root at mediamonks dot net
does not change anything
---
