#19937 [Com]: dynamic extension loading fails
ID: 19937
Comment by: jens_0 at hotmail dot com
Reported By: ryan dot smith at openwave dot com
Status: No Feedback
Bug Type: Dynamic loading
Operating System: AIX 5.1
PHP Version: 4.3.0-dev
New Comment:
Same thing here with Apache/1.3.31 (Unix) PHP/4.0.6 using HP-UX or AIX
concening libgd.so.
The extension won't load:
PHP Warning: Unable to load dynamic library
'/usr/local/lib/php/extensions/no-debug-non-zts/libgd.so' - Invalid
argument in Unknown on line 0
Previous Comments:
[2003-07-18 18:49:39] [EMAIL PROTECTED]
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to Open. Thank you.
[2003-07-10 18:08:00] [EMAIL PROTECTED]
Here's an url to it:
http://www.php.net/~jani/dlopen_patch.txt
[2003-07-10 18:05:55] [EMAIL PROTECTED]
Could you try this patch:
Index: zend.h
===
RCS file: /repository/Zend/Attic/zend.h,v
retrieving revision 1.164.2.8
diff -u -r1.164.2.8 zend.h
--- zend.h 31 May 2003 01:37:43 - 1.164.2.8
+++ zend.h 10 Jul 2003 23:05:38 -
@@ -89,7 +89,11 @@
# define RTLD_GLOBAL 0
# endif
-# define DL_LOAD(libname) dlopen(libname,
RTLD_LAZY | RTLD_GLOBAL)
+# ifndef RTLD_PARENT
+# define RTLD_PARENT 0
+# endif
+
+# define DL_LOAD(libname) dlopen(libname,
RTLD_LAZY | RTLD_GLOBAL | RTLD_PARENT)
# define DL_UNLOAD dlclose
# if DLSYM_NEEDS_UNDERSCORE
# define DL_FETCH_SYMBOL(h,s) dlsym((h), _ s)
[2003-05-02 06:51:16] francois dot turi at globecast dot com
The following patch should fix problem of loading extension under AIX
4.3.3 like the java extension.
Under AIX, shared object are different from shared library.
The default library construction (as in the construction of
the JAVA extension) doesnt work correctly as it relies on dynamic
linking from a library when only a shared object is given.
An exception appear as illegal instruction.
The following configuration are missing:
First of all:
=
one should construct correctly the export definition of libphp4.so.
In configure the following line should be changed:
diff configure configure.orig (sorry no -b available under AIX)
78084,78086c78084
# FTU export_symbols_cmds='$NM $libobjs $convenience |
$global_symbol_pipe | sed '\''s/.* //'\'' | sort | uniq
$export_symbols'
export_symbols_cmds='$NM $libobjs $convenience | $global_symbol_pipe
| sed '\''s/.* //'\'' | sort | uniq|awk -vlib=$SOHOME/$soname
'\''BEGIN{printf #!%s\n,lib}{print \$0}'\'' $export_symbols'
echo FTU export_symbols_cmds=$export_symbols_cmds
---
export_symbols_cmds='$NM $libobjs $convenience | $global_symbol_pipe
| sed '\''s/.* //'\'' | sort | uniq $export_symbols'
***
I added awk -vlib=$SOHOME/$soname
'\''BEGIN{printf #!%s\n,lib}{print \$0}'\''
To the pipe so the first line will be read as:
#!/your/path/to/your/libphp4.so
And the rest is identical.
Before compiling your library you should setup the SOHOME variable as
the path where your shared object (libphp4.so.0) will be running:
export SOHOME=/s00/opendata/build/SSOD/php.430/current
Second important point:
Refer the export file of php shared object in the construction of the
java extension:
When compiling the JAVA extension you have to setup the following
environement VARIABLE
*
export JAVA_SHARED_LIBADD=-Wl,-bI:.libs/libphp4.exp
*
That line state that in the linking process (ld), the java extension
will use the libphp4.exp file to find undefined function or global
variable. By defaut such function will be resolve as running time.
On AIX such binding doesnt work because the libphp4.so is not a shared
library (doesnt appear in the genmkd listing) but a share object.
You have to specify the full path to your share object while linking it
to make him resolve correctly the reference to the Zend API.
Nota: the default exemple given to make an extension doesnt have that
problem because it doesnt call any Zend API function stored in the
libphp4.so.
External reference:
The followings redbooks explain the subtle difference between share
objects and shared library under AIX:
Understanding C and C++ development on AIX
chapter 3 Compiling and Linking
original
http://www.redbooks.ibm.com/pubs/pdfs/redbooks/sg245674.pdf
#37152 [NEW]: __autoload is called with 'self'
From: buchner dot johannes at gmx dot at
Operating system: Any
PHP version: 5.1.2
PHP Bug Type: Scripting Engine problem
Bug description: __autoload is called with 'self'
Description:
autoloader shouldn't be called with the parameter 'self' or
call_user_func(array('self','method')) shouldn't be working.
Reproduce code:
---
class A{
function A(){
call_user_func(array(self,f));
}
function f(){
echo A::f()br/;
}
}
function __autoload($class){
echo autoloader: $class br/;
}
$a = new A();
Expected result:
just: A::f()
Actual result:
--
autoloader: self
A::f()
autoloader is called with the argument self as classname.
Of course,
call_user_func(array($this,f));
is a workaround.
--
Edit bug report at http://bugs.php.net/?id=37152edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=37152r=trysnapshot44
Try a CVS snapshot (PHP 5.1):
http://bugs.php.net/fix.php?id=37152r=trysnapshot51
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=37152r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=37152r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=37152r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=37152r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=37152r=needscript
Try newer version:http://bugs.php.net/fix.php?id=37152r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=37152r=support
Expected behavior:http://bugs.php.net/fix.php?id=37152r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=37152r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=37152r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=37152r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=37152r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=37152r=dst
IIS Stability:http://bugs.php.net/fix.php?id=37152r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=37152r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=37152r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=37152r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=37152r=mysqlcfg
#37152 [Bgs]: __autoload is called with 'self'
ID: 37152
Updated by: [EMAIL PROTECTED]
Reported By: buchner dot johannes at gmx dot at
Status: Bogus
Bug Type: Scripting Engine problem
Operating System: Any
PHP Version: 5.1.2
New Comment:
Dupe of bug #37138
Previous Comments:
[2006-04-21 12:34:11] [EMAIL PROTECTED]
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. Due to the volume
of reports we can not explain in detail here why your report is not
a bug. The support channels will be able to provide an explanation
for you.
Thank you for your interest in PHP.
It's self not 'self'.
[2006-04-21 12:07:22] buchner dot johannes at gmx dot at
Description:
autoloader shouldn't be called with the parameter 'self' or
call_user_func(array('self','method')) shouldn't be working.
Reproduce code:
---
class A{
function A(){
call_user_func(array(self,f));
}
function f(){
echo A::f()br/;
}
}
function __autoload($class){
echo autoloader: $class br/;
}
$a = new A();
Expected result:
just: A::f()
Actual result:
--
autoloader: self
A::f()
autoloader is called with the argument self as classname.
Of course,
call_user_func(array($this,f));
is a workaround.
--
Edit this bug report at http://bugs.php.net/?id=37152edit=1
#37152 [Opn-Bgs]: __autoload is called with 'self'
ID: 37152
Updated by: [EMAIL PROTECTED]
Reported By: buchner dot johannes at gmx dot at
-Status: Open
+Status: Bogus
Bug Type: Scripting Engine problem
Operating System: Any
PHP Version: 5.1.2
New Comment:
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. 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.
It's self not 'self'.
Previous Comments:
[2006-04-21 12:07:22] buchner dot johannes at gmx dot at
Description:
autoloader shouldn't be called with the parameter 'self' or
call_user_func(array('self','method')) shouldn't be working.
Reproduce code:
---
class A{
function A(){
call_user_func(array(self,f));
}
function f(){
echo A::f()br/;
}
}
function __autoload($class){
echo autoloader: $class br/;
}
$a = new A();
Expected result:
just: A::f()
Actual result:
--
autoloader: self
A::f()
autoloader is called with the argument self as classname.
Of course,
call_user_func(array($this,f));
is a workaround.
--
Edit this bug report at http://bugs.php.net/?id=37152edit=1
#37153 [NEW]: foreach on array of object, object is referenced not copied
From: sirber at webernic dot com
Operating system: Linuix 2.6.13
PHP version: 5.1.2
PHP Bug Type: Unknown/Other Function
Bug description: foreach on array of object, object is referenced not copied
Description:
When you foreach an array of object, if you modify the object, the source
is modified.
PHP4: work as expected
PHP5 with compatibility on: work as expected
PHP5: source gets modified
Reproduce code:
---
$aTmp = array();
$oTmp = new stdClass();
$oTmp-id = 1;
$aTmp[] = $oTmp;
$oTmp = new stdClass();
$oTmp-id = 2;
$aTmp[] = $oTmp;
$oTmp = new stdClass();
$oTmp-id = 3;
$aTmp[] = $oTmp;
$oTmp = new stdClass();
$oTmp-id = 4;
$aTmp[] = $oTmp;
foreach ($aTmp as $iKey = $oTest)
$oTest-id = 'tea';
var_dump($aTmp);
Expected result:
array(4) {
[0]=
object(stdClass)#1 (1) {
[id]=
int(1)
}
[1]=
object(stdClass)#2 (1) {
[id]=
int(2)
}
[2]=
object(stdClass)#3 (1) {
[id]=
int(3)
}
[3]=
object(stdClass)#4 (1) {
[id]=
int(4)
}
}
Actual result:
--
array(4) {
[0]=
object(stdClass)#1 (1) {
[id]=
string(3) tea
}
[1]=
object(stdClass)#2 (1) {
[id]=
string(3) tea
}
[2]=
object(stdClass)#3 (1) {
[id]=
string(3) tea
}
[3]=
object(stdClass)#4 (1) {
[id]=
string(3) tea
}
}
--
Edit bug report at http://bugs.php.net/?id=37153edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=37153r=trysnapshot44
Try a CVS snapshot (PHP 5.1):
http://bugs.php.net/fix.php?id=37153r=trysnapshot51
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=37153r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=37153r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=37153r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=37153r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=37153r=needscript
Try newer version:http://bugs.php.net/fix.php?id=37153r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=37153r=support
Expected behavior:http://bugs.php.net/fix.php?id=37153r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=37153r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=37153r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=37153r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=37153r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=37153r=dst
IIS Stability:http://bugs.php.net/fix.php?id=37153r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=37153r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=37153r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=37153r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=37153r=mysqlcfg
#36752 [Fbk-Opn]: pdo_odbc crashes apache
ID: 36752
User updated by: mauroi at digbang dot com
Reported By: mauroi at digbang dot com
-Status: Feedback
+Status: Open
Bug Type: PDO related
Operating System: Win XP SP2
PHP Version: 5CVS-2006-03-16 (snap)
Assigned To: wez
New Comment:
Yes. It still happens.
phpinfo() reports 5.1.3RC4-dev.
Thank you.
Previous Comments:
[2006-04-21 04:11:50] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.1-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.1-win32-latest.zip
[2006-03-28 14:26:53] mauroi at digbang dot com
Yes.
The same happens.
Thanks.
[2006-03-28 12:30:06] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.1-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.1-win32-latest.zip
[2006-03-16 00:14:45] mauroi at digbang dot com
Description:
I'm trying to create a class that provides a layer between the
programmer and the PDO native class.
When running the following code, Apache crashes. Only with the odbc PDO
driver.
Thanks in advance.
Reproduce code:
---
class db
{
protected $_Handle;
function __construct($dsn)
{
$this-_Handle = new PDO($dsn);
}
public function DoSomething()
{
$a = $this-_Handle-prepare('SELECT * FROM valid_table');
echo $undefined_variable; // or any other error
}
}
function strange($errorNumber, $errorMessage)
{
echo $errorMessage;
exit; // if i take this out everything works as expected
}
set_error_handler('strange');
$a = new db('odbc:valid_connection_string');
$b = $a-DoSomething();
Expected result:
The $errorMessage reported by the error handler. And the script
execution terminated.
Actual result:
--
Crash
--
Edit this bug report at http://bugs.php.net/?id=36752edit=1
#37153 [Com]: foreach on array of object, object is referenced not copied
ID: 37153
Comment by: martin at webernic dot com
Reported By: sirber at webernic dot com
Status: Open
Bug Type: Unknown/Other Function
Operating System: Linuix 2.6.13
PHP Version: 5.1.2
New Comment:
Same result with a copy of the array.
Source array and the copy are modified.
Reproduce code:
---
$aTmp = array();
$oTmp = new stdClass();
$oTmp-id = 1;
$aTmp[] = $oTmp;
$oTmp = new stdClass();
$oTmp-id = 2;
$aTmp3 = $aTmp
foreach ($aTmp3 as $iKey = $oTest)
$oTest-id = 'tea';
var_dump($aTmp, $aTmp3);
Expected result:
array(2) {
[0]=
object(stdClass)#1 (1) {
[id]=
int(1)
}
[1]=
object(stdClass)#2 (1) {
[id]=
int(2)
}
}
array(2) {
[0]=
object(stdClass)#1 (1) {
[id]=
int(1)
}
[1]=
object(stdClass)#2 (1) {
[id]=
int(2)
}
}
Actual result:
--
array(2) {
[0]=
object(stdClass)#1 (1) {
[id]=
string(3) tea
}
[1]=
object(stdClass)#2 (1) {
[id]=
string(3) tea
}
}
array(2) {
[0]=
object(stdClass)#1 (1) {
[id]=
string(3) tea
}
[1]=
object(stdClass)#2 (1) {
[id]=
string(3) tea
}
}
Previous Comments:
[2006-04-21 13:33:10] sirber at webernic dot com
Description:
When you foreach an array of object, if you modify the object, the
source is modified.
PHP4: work as expected
PHP5 with compatibility on: work as expected
PHP5: source gets modified
Reproduce code:
---
$aTmp = array();
$oTmp = new stdClass();
$oTmp-id = 1;
$aTmp[] = $oTmp;
$oTmp = new stdClass();
$oTmp-id = 2;
$aTmp[] = $oTmp;
$oTmp = new stdClass();
$oTmp-id = 3;
$aTmp[] = $oTmp;
$oTmp = new stdClass();
$oTmp-id = 4;
$aTmp[] = $oTmp;
foreach ($aTmp as $iKey = $oTest)
$oTest-id = 'tea';
var_dump($aTmp);
Expected result:
array(4) {
[0]=
object(stdClass)#1 (1) {
[id]=
int(1)
}
[1]=
object(stdClass)#2 (1) {
[id]=
int(2)
}
[2]=
object(stdClass)#3 (1) {
[id]=
int(3)
}
[3]=
object(stdClass)#4 (1) {
[id]=
int(4)
}
}
Actual result:
--
array(4) {
[0]=
object(stdClass)#1 (1) {
[id]=
string(3) tea
}
[1]=
object(stdClass)#2 (1) {
[id]=
string(3) tea
}
[2]=
object(stdClass)#3 (1) {
[id]=
string(3) tea
}
[3]=
object(stdClass)#4 (1) {
[id]=
string(3) tea
}
}
--
Edit this bug report at http://bugs.php.net/?id=37153edit=1
#37153 [Opn-Bgs]: foreach on array of object, object is referenced not copied
ID: 37153
Updated by: [EMAIL PROTECTED]
Reported By: sirber at webernic dot com
-Status: Open
+Status: Bogus
Bug Type: Unknown/Other Function
Operating System: Linuix 2.6.13
PHP Version: 5.1.2
New Comment:
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. 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.
Objects are always passed by reference in PHP-5.
Previous Comments:
[2006-04-21 13:39:27] martin at webernic dot com
Same result with a copy of the array.
Source array and the copy are modified.
Reproduce code:
---
$aTmp = array();
$oTmp = new stdClass();
$oTmp-id = 1;
$aTmp[] = $oTmp;
$oTmp = new stdClass();
$oTmp-id = 2;
$aTmp3 = $aTmp
foreach ($aTmp3 as $iKey = $oTest)
$oTest-id = 'tea';
var_dump($aTmp, $aTmp3);
Expected result:
array(2) {
[0]=
object(stdClass)#1 (1) {
[id]=
int(1)
}
[1]=
object(stdClass)#2 (1) {
[id]=
int(2)
}
}
array(2) {
[0]=
object(stdClass)#1 (1) {
[id]=
int(1)
}
[1]=
object(stdClass)#2 (1) {
[id]=
int(2)
}
}
Actual result:
--
array(2) {
[0]=
object(stdClass)#1 (1) {
[id]=
string(3) tea
}
[1]=
object(stdClass)#2 (1) {
[id]=
string(3) tea
}
}
array(2) {
[0]=
object(stdClass)#1 (1) {
[id]=
string(3) tea
}
[1]=
object(stdClass)#2 (1) {
[id]=
string(3) tea
}
}
[2006-04-21 13:33:10] sirber at webernic dot com
Description:
When you foreach an array of object, if you modify the object, the
source is modified.
PHP4: work as expected
PHP5 with compatibility on: work as expected
PHP5: source gets modified
Reproduce code:
---
$aTmp = array();
$oTmp = new stdClass();
$oTmp-id = 1;
$aTmp[] = $oTmp;
$oTmp = new stdClass();
$oTmp-id = 2;
$aTmp[] = $oTmp;
$oTmp = new stdClass();
$oTmp-id = 3;
$aTmp[] = $oTmp;
$oTmp = new stdClass();
$oTmp-id = 4;
$aTmp[] = $oTmp;
foreach ($aTmp as $iKey = $oTest)
$oTest-id = 'tea';
var_dump($aTmp);
Expected result:
array(4) {
[0]=
object(stdClass)#1 (1) {
[id]=
int(1)
}
[1]=
object(stdClass)#2 (1) {
[id]=
int(2)
}
[2]=
object(stdClass)#3 (1) {
[id]=
int(3)
}
[3]=
object(stdClass)#4 (1) {
[id]=
int(4)
}
}
Actual result:
--
array(4) {
[0]=
object(stdClass)#1 (1) {
[id]=
string(3) tea
}
[1]=
object(stdClass)#2 (1) {
[id]=
string(3) tea
}
[2]=
object(stdClass)#3 (1) {
[id]=
string(3) tea
}
[3]=
object(stdClass)#4 (1) {
[id]=
string(3) tea
}
}
--
Edit this bug report at http://bugs.php.net/?id=37153edit=1
#36632 [Fbk-Opn]: SQLSTATE[] unknown error using MSAccess and write SQL with 0 matching records
ID: 36632
User updated by: gerwin84 at gmail dot com
Reported By: gerwin84 at gmail dot com
-Status: Feedback
+Status: Open
Bug Type: PDO related
Operating System: WinXP Pro SP2
-PHP Version: 5.1.2
+PHP Version: 5.1.3RC4-dev
New Comment:
With the latest windows version,
5.1.3RC4-dev
Build Date Apr 21 2006 12:14:54,
it is still not working.
Exactly the same problem, with no differences.
Previous Comments:
[2006-04-21 04:10:45] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.1-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.1-win32-latest.zip
[2006-03-06 17:12:55] gerwin84 at gmail dot com
Description:
Using the latest PHP windows package (PHP 5.1.3-dev from 19 feb.) PDO
throws an PDOException with message 'SQLSTATE[]: Unknown error: 0'
when executing an SQL statement (UPDATE or DELETE) where the WHERE
restriction matches zero records in an MSAccess database.
The following ext. are loaded in php.ini:
extension=php_pdo.dll
extension=php_pdo_odbc.dll
Using php-cgi.exe and IIS
Reproduce code:
---
/*
Table 'test' description:
field 'user' text(50) | field 'role' text(50)
*/
$situation = 1; //value can be 1 or 2
$DBPath = d:\\webroot\\database\\pdobug.mdb;
$MSAccessDB = new PDO(odbc:Driver={Microsoft Access Driver
(*.mdb)};Dbq=.$DBPath.;);
$MSAccessDB-setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
$SQL1 = INSERT INTO test VALUES( 'testuser','testrole');;
$SQL2 = UPDATE test SET role='administrator' WHERE user='testuser' AND
role='testrole';;
$SQL3 = DELETE FROM test WHERE user='testuser';;
$MSAccessDB-exec($SQL1);
switch($situation){
case 1:
$MSAccessDB-exec($SQL2); //ok
$MSAccessDB-exec($SQL2); //error
break;
case 2:
$MSAccessDB-exec($SQL3); //ok
$MSAccessDB-exec($SQL3); //error
break;
}
Expected result:
a blank page as output and changes to the database log:
- Always first a new row added.
- In situation 1: the new row changed.
- In situation 2: the new row deleted.
Actual result:
--
This is the error in in situation 1:
Fatal error: Uncaught exception 'PDOException' with message
'SQLSTATE[]: Unknown error: 0 (SQLExecDirect[0] at
ext\pdo_odbc\odbc_driver.c:230)' in D:\webroot\www\test\pdobug.php:20
Stack trace:
#0 D:\webroot\www\test\pdobug.php(20): PDO-exec('UPDATE test SET...')
#1 {main}
thrown in D:\webroot\www\test\pdobug.php on line 20
The error in situation 2 is exacly the same, except line numbers etc.
of course.
--
Edit this bug report at http://bugs.php.net/?id=36632edit=1
#37154 [NEW]: All strings input must be utf8-encoded
From: troelskn at gmail dot com Operating system: * PHP version: 5.1.2 PHP Bug Type: DOM XML related Bug description: All strings input must be utf8-encoded Description: After some digging around and experimentation, I have found out that the DOM extension needs all input strings to be utf8-encoded. This means that any code using the extension must be spingled with urf8_encode. The problem can probably not be fixed without breaking backward compatibility, so the most sane choice may be to leave it, but atleast update the documentation to state this. -- Edit bug report at http://bugs.php.net/?id=37154edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=37154r=trysnapshot44 Try a CVS snapshot (PHP 5.1): http://bugs.php.net/fix.php?id=37154r=trysnapshot51 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=37154r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=37154r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=37154r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=37154r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=37154r=needscript Try newer version:http://bugs.php.net/fix.php?id=37154r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=37154r=support Expected behavior:http://bugs.php.net/fix.php?id=37154r=notwrong Not enough info: http://bugs.php.net/fix.php?id=37154r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=37154r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=37154r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=37154r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=37154r=dst IIS Stability:http://bugs.php.net/fix.php?id=37154r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=37154r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=37154r=float No Zend Extensions: http://bugs.php.net/fix.php?id=37154r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=37154r=mysqlcfg
#37155 [NEW]: func_get_args feature change request
From: akari dot no dot ryu at whitedragons dot org
Operating system: Mac OS/X
PHP version: 5.1.2
PHP Bug Type: Feature/Change Request
Bug description: func_get_args feature change request
Description:
Is it possible to make func_get_args return a hashed array instead of a
numeric one? Possibly by adding an argument to it.
Reproduce code:
---
function changeProfileDetails($userId, $password, $surname){
echo !--\n;
foreach(func_get_args() as $key=$val){
echo $key=$val;
}
echo --;
}
changeProfileDetails(1, test, whoCares);
Expected result:
!--
userId=1
password='test'
surname='whoCares'
--
Actual result:
--
!--
0=1
1='test'
2='whoCares'
--
--
Edit bug report at http://bugs.php.net/?id=37155edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=37155r=trysnapshot44
Try a CVS snapshot (PHP 5.1):
http://bugs.php.net/fix.php?id=37155r=trysnapshot51
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=37155r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=37155r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=37155r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=37155r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=37155r=needscript
Try newer version:http://bugs.php.net/fix.php?id=37155r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=37155r=support
Expected behavior:http://bugs.php.net/fix.php?id=37155r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=37155r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=37155r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=37155r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=37155r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=37155r=dst
IIS Stability:http://bugs.php.net/fix.php?id=37155r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=37155r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=37155r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=37155r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=37155r=mysqlcfg
#37154 [Opn-Bgs]: All strings input must be utf8-encoded
ID: 37154 Updated by: [EMAIL PROTECTED] Reported By: troelskn at gmail dot com -Status: Open +Status: Bogus Bug Type: DOM XML related Operating System: * PHP Version: 5.1.2 New Comment: Wrong. The *default* input encoding is UTF8. But you can always use ?xml version=1.0 encoding=your encoding?. All the result data are in UTF8 anyway, this is libxml2 feature. Previous Comments: [2006-04-21 14:37:34] troelskn at gmail dot com Description: After some digging around and experimentation, I have found out that the DOM extension needs all input strings to be utf8-encoded. This means that any code using the extension must be spingled with urf8_encode. The problem can probably not be fixed without breaking backward compatibility, so the most sane choice may be to leave it, but atleast update the documentation to state this. -- Edit this bug report at http://bugs.php.net/?id=37154edit=1
#37154 [Bgs]: All strings input must be utf8-encoded
ID: 37154 User updated by: troelskn at gmail dot com Reported By: troelskn at gmail dot com Status: Bogus Bug Type: DOM XML related Operating System: * PHP Version: 5.1.2 New Comment: Not true. $mb_detect_charsets = ASCII,UTF-8,ISO-8859-1; $dom = new DOMDocument(1.0, UTF-8); $doc = $dom-appendChild($dom-createElement(document)); $doc-appendChild($dom-createTextNode(utf8_encode(Iñtërnâtiônàlizætiøn))); echo mb_detect_encoding($dom-saveXML(), $mb_detect_charsets) . br; $dom = new DOMDocument(1.0, ISO-8859-1); $doc = $dom-appendChild($dom-createElement(document)); $doc-appendChild($dom-createTextNode(utf8_encode(Iñtërnâtiônàlizætiøn))); echo mb_detect_encoding($dom-saveXML(), $mb_detect_charsets) . br; --- outputs : UTF-8 ISO-8859-1 --- Removing ut8_encode crashes the second example. Previous Comments: [2006-04-21 15:02:53] [EMAIL PROTECTED] Wrong. The *default* input encoding is UTF8. But you can always use ?xml version=1.0 encoding=your encoding?. All the result data are in UTF8 anyway, this is libxml2 feature. [2006-04-21 14:37:34] troelskn at gmail dot com Description: After some digging around and experimentation, I have found out that the DOM extension needs all input strings to be utf8-encoded. This means that any code using the extension must be spingled with urf8_encode. The problem can probably not be fixed without breaking backward compatibility, so the most sane choice may be to leave it, but atleast update the documentation to state this. -- Edit this bug report at http://bugs.php.net/?id=37154edit=1
#37156 [NEW]: referenced memory cannot be written
From: hajblind at sbcglobal dot net Operating system: windows media center 2005 PHP version: 5CVS-2006-04-21 (CVS) PHP Bug Type: Unknown/Other Function Bug description: referenced memory cannot be written Description: Everytime i play a game called rakion, every two minutes an error pops up saying The instruction at 0x1000103c referenced memory at 0x71a55a1c, the memory could not be written. Click ok to terminate the program. I have asked the game staff and they said my computer was fine. Please help me solve the solution. Oh, and im not sure what the php version is... -- Edit bug report at http://bugs.php.net/?id=37156edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=37156r=trysnapshot44 Try a CVS snapshot (PHP 5.1): http://bugs.php.net/fix.php?id=37156r=trysnapshot51 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=37156r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=37156r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=37156r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=37156r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=37156r=needscript Try newer version:http://bugs.php.net/fix.php?id=37156r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=37156r=support Expected behavior:http://bugs.php.net/fix.php?id=37156r=notwrong Not enough info: http://bugs.php.net/fix.php?id=37156r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=37156r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=37156r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=37156r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=37156r=dst IIS Stability:http://bugs.php.net/fix.php?id=37156r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=37156r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=37156r=float No Zend Extensions: http://bugs.php.net/fix.php?id=37156r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=37156r=mysqlcfg
#37156 [Opn-Fbk]: referenced memory cannot be written
ID: 37156 Updated by: [EMAIL PROTECTED] Reported By: hajblind at sbcglobal dot net -Status: Open +Status: Feedback Bug Type: Unknown/Other Function Operating System: windows media center 2005 PHP Version: 5CVS-2006-04-21 (CVS) 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: [2006-04-21 20:40:59] hajblind at sbcglobal dot net Description: Everytime i play a game called rakion, every two minutes an error pops up saying The instruction at 0x1000103c referenced memory at 0x71a55a1c, the memory could not be written. Click ok to terminate the program. I have asked the game staff and they said my computer was fine. Please help me solve the solution. Oh, and im not sure what the php version is... -- Edit this bug report at http://bugs.php.net/?id=37156edit=1
#37157 [NEW]: force-cgi-redirect is not checked under FastCGI
From: askalski at gmail dot com Operating system: Linux PHP version: 5CVS-2006-04-21 (snap) PHP Bug Type: CGI related Bug description: force-cgi-redirect is not checked under FastCGI Description: The FastCGI version of PHP does not perform the force-cgi-redirect check for page requests. If I request http://localhost/cgi-bin/php, PHP tries to parse the PHP binary in /cgi-bin as if it was a script. If cgi.fix_pathinfo is turned off, users can bypass .htaccess security. See also bug #22846. Reproduce code: --- PHP was configured with: ./configure --enable-fastcgi --enable-force-cgi-redirect My /cgi-bin/php is a wrapper script that sets up FastCGI environment variables: #! /bin/sh export PHPRC=/etc/apache export PHP_FCGI_CHILDREN=4 export PHP_FCGI_MAX_REQUESTS=512 exec /usr/local/bin/php Expected result: Security Alert! The PHP CGI cannot be accessed directly. This PHP CGI binary was compiled with force-cgi-redirect enabled. This means that a page will only be served up if the REDIRECT_STATUS CGI variable is set, e.g. via an Apache Action directive. For more information as to why this behaviour exists, see the manual page for CGI security. For more information about changing this behaviour or re-enabling this webserver, consult the installation file that came with this distribution, or visit the manual page. Actual result: -- export PHPRC=/etc/apache export PHP_FCGI_CHILDREN=4 export PHP_FCGI_MAX_REQUESTS=512 exec /usr/local/bin/php -- Edit bug report at http://bugs.php.net/?id=37157edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=37157r=trysnapshot44 Try a CVS snapshot (PHP 5.1): http://bugs.php.net/fix.php?id=37157r=trysnapshot51 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=37157r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=37157r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=37157r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=37157r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=37157r=needscript Try newer version:http://bugs.php.net/fix.php?id=37157r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=37157r=support Expected behavior:http://bugs.php.net/fix.php?id=37157r=notwrong Not enough info: http://bugs.php.net/fix.php?id=37157r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=37157r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=37157r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=37157r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=37157r=dst IIS Stability:http://bugs.php.net/fix.php?id=37157r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=37157r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=37157r=float No Zend Extensions: http://bugs.php.net/fix.php?id=37157r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=37157r=mysqlcfg
#37132 [Fbk-Opn]: undefined reference to `xmlParserInputBufferCreateFilenameDefault'
ID: 37132 User updated by: brad_kwastel at wgresorts dot com Reported By: brad_kwastel at wgresorts dot com -Status: Feedback +Status: Open Bug Type: Compile Failure Operating System: RH9 PHP Version: 5.1.2 New Comment: Compiling without sybase seems to work fine now. So I guess this solved that part of the issue, any ideas on the sybase problem or should I open another bug report. Previous Comments: [2006-04-20 07:55:26] [EMAIL PROTECTED] Ok, lets not mix two different problems. Please configure WITHOUT sybase and try to build it again. [2006-04-19 23:14:40] brad_kwastel at wgresorts dot com Ok now it makes it past the libxml2 problem and just exits at this line(thanks for the help there). /opt/sybase-12.5/OCS-12_5/lib/libintl.so: undefined reference to `__ctype_b' collect2: ld returned 1 exit status make: *** [sapi/cli/php] Error 1 That is a fresh install of Sybase Open Client. Any ideas? [2006-04-19 22:55:57] brad_kwastel at wgresorts dot com previously when going to install php 5.1.2 I noticed my libxml2(2.6.9) was below the required(2.6.11) so I downloaded the rpms needed to install 2.6.16, the highest version I can on rh9 without redoing python. I didn't however check xml2-config version after doing that, it still shows the old version. So I downloaded the source for libxml2 and I installed it and now my xml2-config shows 2.6.16. I am in the process of running configure / make, and will post further details. Thanks. [2006-04-19 07:33:33] [EMAIL PROTECTED] Please update your libxml2 version to the latest available and try again. [2006-04-19 04:46:57] brad_kwastel at wgresorts dot com Description: When running make on my php compile I get the following error : http://generalhaberdashery.com/offsite/phpcompileerror.txt And it stops compiling. I saw a previous bug on here http://bugs.php.net/bug.php?id=35603 but it didnt have a solution and it mentioned something about xsl not being linked, I tried to compile --without-xsl and I still got the same response. My configure is http://generalhaberdashery.com/offsite/phpconfigure.txt Any help would be appreciated. -- Edit this bug report at http://bugs.php.net/?id=37132edit=1
#37158 [NEW]: if userspace stream is present, fread() reads in 8192 max, otherwise it works
From: [EMAIL PROTECTED]
Operating system: n/a
PHP version: 5CVS-2006-04-21 (CVS)
PHP Bug Type: Streams related
Bug description: if userspace stream is present, fread() reads in 8192 max,
otherwise it works
Description:
fread($fp, 2); will read in 2 bytes from a local file, but is a
userspace stream is defined anywhere, it will only read in 8192 bytes,
without any warning or error.
This is actually similar to Bug #30936, but as I say the problem here is
that the presence of a userspace stream handler changes the behavior of
fread() - any indeterminate behavior is bad.
I wonder if the fix from #32810 could be helpful for this problem as well?
Reproduce code:
---
?php
// paste in the stream code from the example in the manual
// be sure to include stream_wrapper_register
error_reporting(E_ALL | E_STRICT);
$file = dirname(__FILE__) . '/footest.txt';
$x = str_repeat('1', 8192);
$fp = fopen($file, 'w');
for ($i = 0; $i 5; $i++) {
fwrite($fp, $x);
}
fclose($fp);
$fp = fopen($file, 'r');
$outsidecontents = fread($fp, 2);
fclose($fp);
var_dump('size of contents 1 = ' . strlen($outsidecontents));
$outsidecontents = file_get_contents($file);
var_dump('size of contents 2 = ' . strlen($outsidecontents));
?
Expected result:
string(26) size of contents 1 = 2
string(26) size of contents 2 = 40960
Actual result:
--
string(25) size of contents 1 = 8192
string(26) size of contents 2 = 40960
--
Edit bug report at http://bugs.php.net/?id=37158edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=37158r=trysnapshot44
Try a CVS snapshot (PHP 5.1):
http://bugs.php.net/fix.php?id=37158r=trysnapshot51
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=37158r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=37158r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=37158r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=37158r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=37158r=needscript
Try newer version:http://bugs.php.net/fix.php?id=37158r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=37158r=support
Expected behavior:http://bugs.php.net/fix.php?id=37158r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=37158r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=37158r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=37158r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=37158r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=37158r=dst
IIS Stability:http://bugs.php.net/fix.php?id=37158r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=37158r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=37158r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=37158r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=37158r=mysqlcfg
#37158 [Opn]: if userspace stream is present, fread() reads in 8192 max, otherwise it works
ID: 37158
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Streams related
Operating System: n/a
PHP Version: 5CVS-2006-04-21 (CVS)
New Comment:
P.S. The documentation still sucks for fread() on the need to read in
chunks.
I ran into this bug because I had an fread() from a local file handle
within a streams handler (pear.php.net/PHP_Archive) that had never been
more than 8192 before.
I would recommend fixing this by adding an E_STRICT warning if a value
larger than 8192 is passed into fread()
Previous Comments:
[2006-04-21 22:11:09] [EMAIL PROTECTED]
Description:
fread($fp, 2); will read in 2 bytes from a local file, but is a
userspace stream is defined anywhere, it will only read in 8192 bytes,
without any warning or error.
This is actually similar to Bug #30936, but as I say the problem here
is that the presence of a userspace stream handler changes the behavior
of fread() - any indeterminate behavior is bad.
I wonder if the fix from #32810 could be helpful for this problem as
well?
Reproduce code:
---
?php
// paste in the stream code from the example in the manual
// be sure to include stream_wrapper_register
error_reporting(E_ALL | E_STRICT);
$file = dirname(__FILE__) . '/footest.txt';
$x = str_repeat('1', 8192);
$fp = fopen($file, 'w');
for ($i = 0; $i 5; $i++) {
fwrite($fp, $x);
}
fclose($fp);
$fp = fopen($file, 'r');
$outsidecontents = fread($fp, 2);
fclose($fp);
var_dump('size of contents 1 = ' . strlen($outsidecontents));
$outsidecontents = file_get_contents($file);
var_dump('size of contents 2 = ' . strlen($outsidecontents));
?
Expected result:
string(26) size of contents 1 = 2
string(26) size of contents 2 = 40960
Actual result:
--
string(25) size of contents 1 = 8192
string(26) size of contents 2 = 40960
--
Edit this bug report at http://bugs.php.net/?id=37158edit=1
#37132 [Opn-Bgs]: undefined reference to `xmlParserInputBufferCreateFilenameDefault'
ID: 37132 Updated by: [EMAIL PROTECTED] Reported By: brad_kwastel at wgresorts dot com -Status: Open +Status: Bogus Bug Type: Compile Failure Operating System: RH9 PHP Version: 5.1.2 New Comment: No need to open a new report, it was already discussed: http://bugs.php.net/bug.php?id=23884 Previous Comments: [2006-04-21 22:03:10] brad_kwastel at wgresorts dot com Compiling without sybase seems to work fine now. So I guess this solved that part of the issue, any ideas on the sybase problem or should I open another bug report. [2006-04-20 07:55:26] [EMAIL PROTECTED] Ok, lets not mix two different problems. Please configure WITHOUT sybase and try to build it again. [2006-04-19 23:14:40] brad_kwastel at wgresorts dot com Ok now it makes it past the libxml2 problem and just exits at this line(thanks for the help there). /opt/sybase-12.5/OCS-12_5/lib/libintl.so: undefined reference to `__ctype_b' collect2: ld returned 1 exit status make: *** [sapi/cli/php] Error 1 That is a fresh install of Sybase Open Client. Any ideas? [2006-04-19 22:55:57] brad_kwastel at wgresorts dot com previously when going to install php 5.1.2 I noticed my libxml2(2.6.9) was below the required(2.6.11) so I downloaded the rpms needed to install 2.6.16, the highest version I can on rh9 without redoing python. I didn't however check xml2-config version after doing that, it still shows the old version. So I downloaded the source for libxml2 and I installed it and now my xml2-config shows 2.6.16. I am in the process of running configure / make, and will post further details. Thanks. [2006-04-19 07:33:33] [EMAIL PROTECTED] Please update your libxml2 version to the latest available and try again. 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/37132 -- Edit this bug report at http://bugs.php.net/?id=37132edit=1
#37159 [NEW]: imap_fetchstructure returns wrong encoding
From: oliver dot block at lycos dot de Operating system: Unix PHP version: 5.1.2 PHP Bug Type: IMAP related Bug description: imap_fetchstructure returns wrong encoding Description: applying imap_fetchstructure to a message return wrong encoding value, if the message has NO Content-Encoding field. Reproduce code: --- $stream = imap_open($server, $username, $password); $msg_struct = imap_fetchstructure($stream, $uid, FT_UID); $encoding = $msg_struct-encoding; Expected result: If I apply this on a message with NO Content-Encoding field, $encoding should be equal to 0 -- according to RFC2045, Sect. 6.1. Actual result: -- If I apply this code on a message with NO Content-Encoding field, $encoding is equal to 5. -- Edit bug report at http://bugs.php.net/?id=37159edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=37159r=trysnapshot44 Try a CVS snapshot (PHP 5.1): http://bugs.php.net/fix.php?id=37159r=trysnapshot51 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=37159r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=37159r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=37159r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=37159r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=37159r=needscript Try newer version:http://bugs.php.net/fix.php?id=37159r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=37159r=support Expected behavior:http://bugs.php.net/fix.php?id=37159r=notwrong Not enough info: http://bugs.php.net/fix.php?id=37159r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=37159r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=37159r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=37159r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=37159r=dst IIS Stability:http://bugs.php.net/fix.php?id=37159r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=37159r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=37159r=float No Zend Extensions: http://bugs.php.net/fix.php?id=37159r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=37159r=mysqlcfg
#37158 [Opn-Bgs]: if userspace stream is present, fread() reads in 8192 max, otherwise it works
ID: 37158
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Bogus
Bug Type: Streams related
Operating System: n/a
PHP Version: 5CVS-2006-04-21 (CVS)
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
...or (after opening userspace stream) when 8192 bytes have been read
whichever comes first.
I think it is clear. What do you suggest to make it more clear? Reopen
and change it to documentation bug if you have a better text.
It is not a bug.
Previous Comments:
[2006-04-21 22:15:15] [EMAIL PROTECTED]
P.S. The documentation still sucks for fread() on the need to read in
chunks.
I ran into this bug because I had an fread() from a local file handle
within a streams handler (pear.php.net/PHP_Archive) that had never been
more than 8192 before.
I would recommend fixing this by adding an E_STRICT warning if a value
larger than 8192 is passed into fread()
[2006-04-21 22:11:09] [EMAIL PROTECTED]
Description:
fread($fp, 2); will read in 2 bytes from a local file, but is a
userspace stream is defined anywhere, it will only read in 8192 bytes,
without any warning or error.
This is actually similar to Bug #30936, but as I say the problem here
is that the presence of a userspace stream handler changes the behavior
of fread() - any indeterminate behavior is bad.
I wonder if the fix from #32810 could be helpful for this problem as
well?
Reproduce code:
---
?php
// paste in the stream code from the example in the manual
// be sure to include stream_wrapper_register
error_reporting(E_ALL | E_STRICT);
$file = dirname(__FILE__) . '/footest.txt';
$x = str_repeat('1', 8192);
$fp = fopen($file, 'w');
for ($i = 0; $i 5; $i++) {
fwrite($fp, $x);
}
fclose($fp);
$fp = fopen($file, 'r');
$outsidecontents = fread($fp, 2);
fclose($fp);
var_dump('size of contents 1 = ' . strlen($outsidecontents));
$outsidecontents = file_get_contents($file);
var_dump('size of contents 2 = ' . strlen($outsidecontents));
?
Expected result:
string(26) size of contents 1 = 2
string(26) size of contents 2 = 40960
Actual result:
--
string(25) size of contents 1 = 8192
string(26) size of contents 2 = 40960
--
Edit this bug report at http://bugs.php.net/?id=37158edit=1
#37160 [NEW]: help! my band website postcard page doesn't work!
From: jzerony at aol dot com Operating system: windows 98 PHP version: 4.4.2 PHP Bug Type: Performance problem Bug description: help! my band website postcard page doesn't work! Description: I'm no programmer or even that webpage saavy, so please forgive me if I don't fill this form out correctly... but I have a little self-made band website with a postcard page that doesn't work, and I need help to set it right. I don't know what PHP version it is either - and there was no I don't know box - so I just clicked ver 4.4.2. - Once again, sorry - I just have no idea. Reproduce code: --- http://www.outofbodies.com/whats Expected result: What the postcard page is SUPPOSED to do - Visitors select a picture and have the option of including a short song sample. They type their message, and fill in the sender and recipient fields. They then click preview which brings them to a preview page where they will see (and hear) their e-card exactly as the recipient will. At this point they can click edit (to go back and make changes) or they can click send. After sending their card they get a confirmation page telling them that their card is on it's way, and thank you. Actual result: -- What the postcard page DOES - Everything seems to work accordingly on the first postcard page. Selecting the picture, selecting a song, filling in the message box and sender/recipient fields - all okay so far. There is even a song preview on this page - where one can listen to the song before choosing it - which works as it should. But click preview and this is where it begins to go wrong... It goes to a preview page, but the song picked seems to be having a player conflict. You can hear the song, but it plays differently. Half speed at first, before eventually catching up on itself. If you click send it gives you the appropriate your card is on it's way message, but you'll notice if you typed a quotation mark in your message ( ) your message gets truncated at that very point. The preview doesn't show it this way, but after sending your message it's revealed that that is how your message went out. Also, even though the preview played sound - the sent card has no sound at all. This used to work great until one day I thought I was mr. webmaster and moved all the files into one directory, that were previously in one directory and a sub-directory. -- Edit bug report at http://bugs.php.net/?id=37160edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=37160r=trysnapshot44 Try a CVS snapshot (PHP 5.1): http://bugs.php.net/fix.php?id=37160r=trysnapshot51 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=37160r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=37160r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=37160r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=37160r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=37160r=needscript Try newer version:http://bugs.php.net/fix.php?id=37160r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=37160r=support Expected behavior:http://bugs.php.net/fix.php?id=37160r=notwrong Not enough info: http://bugs.php.net/fix.php?id=37160r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=37160r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=37160r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=37160r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=37160r=dst IIS Stability:http://bugs.php.net/fix.php?id=37160r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=37160r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=37160r=float No Zend Extensions: http://bugs.php.net/fix.php?id=37160r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=37160r=mysqlcfg
#37158 [Bgs-Opn]: if userspace stream is present, fread() reads in 8192 max, otherwise it works
ID: 37158
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Bogus
+Status: Open
Bug Type: Streams related
Operating System: n/a
PHP Version: 5CVS-2006-04-21 (CVS)
New Comment:
...or (after opening userspace stream) when 8192 bytes have been read
whichever comes first.
Pierre, I never opened a userspace stream. A user stream was
registered with stream_wrapper_register(), and never used. Read the
example code. The only thing opened was a local file, which is very
much a built-in stream.
This would be equivalent to mysql_query() failing because the code
initialized a pdo object. The two should not affect each other.
Previous Comments:
[2006-04-21 22:40:09] [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
...or (after opening userspace stream) when 8192 bytes have been read
whichever comes first.
I think it is clear. What do you suggest to make it more clear? Reopen
and change it to documentation bug if you have a better text.
It is not a bug.
[2006-04-21 22:15:15] [EMAIL PROTECTED]
P.S. The documentation still sucks for fread() on the need to read in
chunks.
I ran into this bug because I had an fread() from a local file handle
within a streams handler (pear.php.net/PHP_Archive) that had never been
more than 8192 before.
I would recommend fixing this by adding an E_STRICT warning if a value
larger than 8192 is passed into fread()
[2006-04-21 22:11:09] [EMAIL PROTECTED]
Description:
fread($fp, 2); will read in 2 bytes from a local file, but is a
userspace stream is defined anywhere, it will only read in 8192 bytes,
without any warning or error.
This is actually similar to Bug #30936, but as I say the problem here
is that the presence of a userspace stream handler changes the behavior
of fread() - any indeterminate behavior is bad.
I wonder if the fix from #32810 could be helpful for this problem as
well?
Reproduce code:
---
?php
// paste in the stream code from the example in the manual
// be sure to include stream_wrapper_register
error_reporting(E_ALL | E_STRICT);
$file = dirname(__FILE__) . '/footest.txt';
$x = str_repeat('1', 8192);
$fp = fopen($file, 'w');
for ($i = 0; $i 5; $i++) {
fwrite($fp, $x);
}
fclose($fp);
$fp = fopen($file, 'r');
$outsidecontents = fread($fp, 2);
fclose($fp);
var_dump('size of contents 1 = ' . strlen($outsidecontents));
$outsidecontents = file_get_contents($file);
var_dump('size of contents 2 = ' . strlen($outsidecontents));
?
Expected result:
string(26) size of contents 1 = 2
string(26) size of contents 2 = 40960
Actual result:
--
string(25) size of contents 1 = 8192
string(26) size of contents 2 = 40960
--
Edit this bug report at http://bugs.php.net/?id=37158edit=1
