#44208 [NEW]: preg_* UTF-8 support breaks w/ external PCRE
From: martin dot adolfsson at movel dot se
Operating system: Debian GNU/Linux 4.0
PHP version: 5.2.5
PHP Bug Type: PCRE related
Bug description: preg_* UTF-8 support breaks w/ external PCRE
Description:
Attempting to use external PCRE library (7.6), configured with
--enable-static
--disable-shared
--enable-utf8
--enable-unicode-properties
--disable-cpp
in PHP 5.2.5, configured with (among other options):
--with-pcre-regex={PATH_TO_PCRE_INSTALLATION}
Results in calls to preg_match() with /u modifier triggering an error and
stating that this version of PCRE is not compiled with PCRE_UTF8 support.
Reproduce code:
---
preg_match('//u', '' );
Expected result:
empty
Actual result:
--
preg_match() [a href='function.preg-match'function.preg-match/a]:
Compilation failed: this version of PCRE is not compiled with PCRE_UTF8
support at offset 0 in ...
--
Edit bug report at http://bugs.php.net/?id=44208edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=44208r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=44208r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=44208r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=44208r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=44208r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=44208r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=44208r=needscript
Try newer version:http://bugs.php.net/fix.php?id=44208r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=44208r=support
Expected behavior:http://bugs.php.net/fix.php?id=44208r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=44208r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=44208r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=44208r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=44208r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=44208r=dst
IIS Stability:http://bugs.php.net/fix.php?id=44208r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=44208r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=44208r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=44208r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=44208r=mysqlcfg
#44208 [Opn]: preg_* UTF-8 support breaks w/ external PCRE
ID: 44208
User updated by: martin dot adolfsson at movel dot se
Reported By: martin dot adolfsson at movel dot se
Status: Open
Bug Type: PCRE related
Operating System: Debian GNU/Linux 4.0
PHP Version: 5.2.5
New Comment:
Might add some details from pcre-7.6:
pcre-7.6 configuration summary:
...
Enable UTF-8 support : yes
Unicode properties .. : yes
...
[src/pcre_tables.c]--
#ifdef SUPPORT_UTF8
const int _pcre_utf8_table1[] =...
.
[src/pcre_tables.c]--
$ strings lib/libpcre.a | grep pcre_utf8_table1
_pcre_utf8_table1
...
So AFAIK, PCRE has been built successfully w/ UTF-8 support.
Previous Comments:
[2008-02-22 08:03:39] martin dot adolfsson at movel dot se
Description:
Attempting to use external PCRE library (7.6), configured with
--enable-static
--disable-shared
--enable-utf8
--enable-unicode-properties
--disable-cpp
in PHP 5.2.5, configured with (among other options):
--with-pcre-regex={PATH_TO_PCRE_INSTALLATION}
Results in calls to preg_match() with /u modifier triggering an error
and stating that this version of PCRE is not compiled with PCRE_UTF8
support.
Reproduce code:
---
preg_match('//u', '' );
Expected result:
empty
Actual result:
--
preg_match() [a href='function.preg-match'function.preg-match/a]:
Compilation failed: this version of PCRE is not compiled with PCRE_UTF8
support at offset 0 in ...
--
Edit this bug report at http://bugs.php.net/?id=44208edit=1
#44209 [NEW]: strtotime doesn't support 64 bit timestamps
From: bishillo at gmail dot com
Operating system: linux 64 bit
PHP version: 5.2CVS-2008-02-22 (snap)
PHP Bug Type: Date/time related
Bug description: strtotime doesn't support 64 bit timestamps
Description:
strtotime() of years 2038 or 1900 does not work on 64 bit platforms,
that should not have problems with those dates. The rest of php functions
work properly with those extended dates.
Reproduce code:
---
On 64 bit platforms php date functions support greater range of dates. For
exampe:
?= date('d-m-Y',time()+3153600) ?
Returns:
3007-06-25
But strtotime does not work with those improved date ranges:
?= date('Y-m-d',strtotime('3007-06-25')) ?
Returns:
1970-01-01
I understand that output on 32 bit platforms, but on 64 bit should work as
the rest of functions, and return a valid 64bit timestamp for dates 2038
or 1900.
--
Edit bug report at http://bugs.php.net/?id=44209edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=44209r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=44209r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=44209r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=44209r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=44209r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=44209r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=44209r=needscript
Try newer version:http://bugs.php.net/fix.php?id=44209r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=44209r=support
Expected behavior:http://bugs.php.net/fix.php?id=44209r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=44209r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=44209r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=44209r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=44209r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=44209r=dst
IIS Stability:http://bugs.php.net/fix.php?id=44209r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=44209r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=44209r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=44209r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=44209r=mysqlcfg
#44209 [Asn-Csd]: strtotime doesn't support 64 bit timestamps
ID: 44209
Updated by: [EMAIL PROTECTED]
Reported By: bishillo at gmail dot com
-Status: Assigned
+Status: Closed
Bug Type: Date/time related
Operating System: linux 64 bit
PHP Version: 5.2CVS-2008-02-22 (snap)
Assigned To: derick
New Comment:
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2008-02-22 09:23:02] [EMAIL PROTECTED]
Weird, I was positive this was working.
[2008-02-22 09:00:56] bishillo at gmail dot com
Description:
strtotime() of years 2038 or 1900 does not work on 64 bit platforms,
that should not have problems with those dates. The rest of php
functions work properly with those extended dates.
Reproduce code:
---
On 64 bit platforms php date functions support greater range of dates.
For exampe:
?= date('d-m-Y',time()+3153600) ?
Returns:
3007-06-25
But strtotime does not work with those improved date ranges:
?= date('Y-m-d',strtotime('3007-06-25')) ?
Returns:
1970-01-01
I understand that output on 32 bit platforms, but on 64 bit should work
as the rest of functions, and return a valid 64bit timestamp for dates
2038 or 1900.
--
Edit this bug report at http://bugs.php.net/?id=44209edit=1
#44209 [Opn-Asn]: strtotime doesn't support 64 bit timestamps
ID: 44209
Updated by: [EMAIL PROTECTED]
Reported By: bishillo at gmail dot com
-Status: Open
+Status: Assigned
Bug Type: Date/time related
Operating System: linux 64 bit
PHP Version: 5.2CVS-2008-02-22 (snap)
-Assigned To:
+Assigned To: derick
New Comment:
Weird, I was positive this was working.
Previous Comments:
[2008-02-22 09:00:56] bishillo at gmail dot com
Description:
strtotime() of years 2038 or 1900 does not work on 64 bit platforms,
that should not have problems with those dates. The rest of php
functions work properly with those extended dates.
Reproduce code:
---
On 64 bit platforms php date functions support greater range of dates.
For exampe:
?= date('d-m-Y',time()+3153600) ?
Returns:
3007-06-25
But strtotime does not work with those improved date ranges:
?= date('Y-m-d',strtotime('3007-06-25')) ?
Returns:
1970-01-01
I understand that output on 32 bit platforms, but on 64 bit should work
as the rest of functions, and return a valid 64bit timestamp for dates
2038 or 1900.
--
Edit this bug report at http://bugs.php.net/?id=44209edit=1
#44210 [NEW]: Parser accepts functions in functions
From: dorthe at luebbert dot net
Operating system: Linux
PHP version: 5.2.5
PHP Bug Type: *Compile Issues
Bug description: Parser accepts functions in functions
Description:
php -l does not report any error on the code listed above(result of a
unresolved merge conflict), this means functions are accepted within
functions (it does not work if you add public to the doA or doB-function).
Reproduce code:
---
?php
class something
{
public function getData()
{
print foo;
function doA()
{
return $a;
}
function doB()
{
return $b;
}
print bar;
return $data;
}
}
?
Expected result:
error.
Actual result:
--
no error
--
Edit bug report at http://bugs.php.net/?id=44210edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=44210r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=44210r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=44210r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=44210r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=44210r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=44210r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=44210r=needscript
Try newer version:http://bugs.php.net/fix.php?id=44210r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=44210r=support
Expected behavior:http://bugs.php.net/fix.php?id=44210r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=44210r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=44210r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=44210r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=44210r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=44210r=dst
IIS Stability:http://bugs.php.net/fix.php?id=44210r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=44210r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=44210r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=44210r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=44210r=mysqlcfg
#44209 [Csd]: strtotime doesn't support 64 bit timestamps
ID: 44209
User updated by: bishillo at gmail dot com
Reported By: bishillo at gmail dot com
Status: Closed
Bug Type: Date/time related
Operating System: linux 64 bit
PHP Version: 5.2CVS-2008-02-22 (snap)
Assigned To: derick
New Comment:
Woa! fixed in 49 minutes! Thats fast. Thx!
Previous Comments:
[2008-02-22 09:49:40] [EMAIL PROTECTED]
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
[2008-02-22 09:23:02] [EMAIL PROTECTED]
Weird, I was positive this was working.
[2008-02-22 09:00:56] bishillo at gmail dot com
Description:
strtotime() of years 2038 or 1900 does not work on 64 bit platforms,
that should not have problems with those dates. The rest of php
functions work properly with those extended dates.
Reproduce code:
---
On 64 bit platforms php date functions support greater range of dates.
For exampe:
?= date('d-m-Y',time()+3153600) ?
Returns:
3007-06-25
But strtotime does not work with those improved date ranges:
?= date('Y-m-d',strtotime('3007-06-25')) ?
Returns:
1970-01-01
I understand that output on 32 bit platforms, but on 64 bit should work
as the rest of functions, and return a valid 64bit timestamp for dates
2038 or 1900.
--
Edit this bug report at http://bugs.php.net/?id=44209edit=1
#44210 [Opn-Bgs]: Parser accepts functions in functions
ID: 44210
Updated by: [EMAIL PROTECTED]
Reported By: dorthe at luebbert dot net
-Status: Open
+Status: Bogus
Bug Type: *Compile Issues
Operating System: Linux
PHP Version: 5.2.5
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
This isn't a bug.
See http://docs.php.net/functions
Previous Comments:
[2008-02-22 10:09:43] dorthe at luebbert dot net
Description:
php -l does not report any error on the code listed above(result of a
unresolved merge conflict), this means functions are accepted within
functions (it does not work if you add public to the doA or
doB-function).
Reproduce code:
---
?php
class something
{
public function getData()
{
print foo;
function doA()
{
return $a;
}
function doB()
{
return $b;
}
print bar;
return $data;
}
}
?
Expected result:
error.
Actual result:
--
no error
--
Edit this bug report at http://bugs.php.net/?id=44210edit=1
#42682 [Com]: stream_select() indicates bad number of readable descriptors
ID: 42682
Comment by: hans at parse dot nl
Reported By: Slig at free dot fr
Status: Open
Bug Type: Streams related
Operating System: linux-64
PHP Version: 5CVS-2007-10-11 (snap)
New Comment:
This is stil a pretty serious issue on x86_64. Just ran into this one
while swapping out a bunch of x86 webservers for new x86_64 boxes.
Both the new and the old boxes run Gentoo, with the same gcc version,
same php version. The 32 bit boxes were fine, the new 64 bit boxes fail
on all stream fread's due to this issue.
Target: x86_64-pc-linux-gnu
Thread model: posix
gcc version 4.1.2 (Gentoo 4.1.2 p1.0.2)
glibc-2.6.1
openssl-0.9.8g
php-5.2.5 (using php-5.2.5-r1 gentoo ebuild)
Previous Comments:
[2007-10-22 11:00:26] [EMAIL PROTECTED]
Is there difference between openssl versions on those Suse/Centos
machines?
[2007-10-12 18:25:57] margus at zone dot ee
Perhaps it helps if I give test results on different machines and where
and how it manifests:
stream_select() works flawlessly without patching on:
- my multiple 32bit machines. Those have SuSE90 or SuSE93 installed.
- my multiple 64bit SuSE10 machines
stream_select() works only when patched 'long this_fd;' or 'long
this_fd=0;' on:
- my multiple 64bit CentOS 4.5 systems (Xeon Quadcore)
stream_select() works only when patched 'long this_fd=0;'
(stream_select segfaults without variable initializing) on:
- my one 64bit CentOS 4.5 machine (Opteron Dualcore).
Origin of this bug must be somewhere in php_stream_cast() or even
lower. I tried also compiling without OpenSSL support and yes, the bug
along with SSL socket support can be eliminated this way too :)
[2007-10-12 17:17:10] Slig at free dot fr
No, just setting it to 0 doesn't work.
And margus is true, using 'long this_fd;' it works (with or without
setting it to 0). I don't say it's the right solution, perhaps it's more
something to change in php_stream_cast(), i don't know.
[2007-10-12 10:10:34] [EMAIL PROTECTED]
But it won't work in future. I tried to figure out why changing that
int to long would help but AFAICT it's really supposed to be int since
everything else using this_fd is expecting it to be int..
[2007-10-11 18:50:17] margus at zone dot ee
I was hit by the same annoying bug (CentOS 4.5/x64/PHP5.1.6 5.2.3)
After debugging PHP stream_select() I found out that system's select()
returns correct number but this value get's mysteriously set to zero
(memory is overwritten?) a few steps before returning it to PHP script.
Anyway, the cure for me was to change an variable type from int to long
and explicitly reset it to 0. This patch works for both PHP 5.1 and
5.2:
--- ext/standard/streamsfuncs.c.orig2007-10-09 16:21:30.0
+0300
+++ ext/standard/streamsfuncs.c 2007-10-09 16:21:41.0 +0300
@@ -608,7 +608,7 @@
zval **elem, **dest_elem;
php_stream *stream;
HashTable *new_hash;
- int this_fd, ret = 0;
+ long this_fd = 0, ret = 0;
if (Z_TYPE_P(stream_array) != IS_ARRAY) {
return 0;
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/42682
--
Edit this bug report at http://bugs.php.net/?id=42682edit=1
#44211 [NEW]: Apache2+PHP5.2.5 php_openssl.dll problem
From: spyisaev at mail dot ru Operating system: Windows XP PHP version: 5.2.5 PHP Bug Type: OpenSSL related Bug description: Apache2+PHP5.2.5 php_openssl.dll problem Description: PHP Warning: PHP Startup: Unable to load dynamic library 'C:\\apache\\php\\ext\\php_openssl.dll' - The operating system cannot run %1.\r\n in Unknown on line 0 -- Edit bug report at http://bugs.php.net/?id=44211edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=44211r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=44211r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=44211r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=44211r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=44211r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=44211r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=44211r=needscript Try newer version:http://bugs.php.net/fix.php?id=44211r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=44211r=support Expected behavior:http://bugs.php.net/fix.php?id=44211r=notwrong Not enough info: http://bugs.php.net/fix.php?id=44211r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=44211r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=44211r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=44211r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=44211r=dst IIS Stability:http://bugs.php.net/fix.php?id=44211r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=44211r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=44211r=float No Zend Extensions: http://bugs.php.net/fix.php?id=44211r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=44211r=mysqlcfg
#44213 [NEW]: in_array returns wrong value
From: markus dot kalkbrenner at arcor dot de
Operating system: Linux
PHP version: 5.2.5
PHP Bug Type: Arrays related
Bug description: in_array returns wrong value
Description:
in_array() returns true if needle exists as key with int(0) as value, but
should return false because needle doesn't exist as value.
Reproduce code:
---
?php
var_dump( in_array('a', array('a' = 1) ) );
var_dump( in_array('a', array('a' = 0) ) );
?
Expected result:
bool(false)
bool(false)
Actual result:
--
bool(false)
bool(true)
--
Edit bug report at http://bugs.php.net/?id=44213edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=44213r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=44213r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=44213r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=44213r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=44213r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=44213r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=44213r=needscript
Try newer version:http://bugs.php.net/fix.php?id=44213r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=44213r=support
Expected behavior:http://bugs.php.net/fix.php?id=44213r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=44213r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=44213r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=44213r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=44213r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=44213r=dst
IIS Stability:http://bugs.php.net/fix.php?id=44213r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=44213r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=44213r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=44213r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=44213r=mysqlcfg
#44203 [Opn]: ibm_db2 / db2_execute failure
ID: 44203
User updated by: the_dude61 at hotmail dot com
Reported By: the_dude61 at hotmail dot com
Status: Open
-Bug Type: DBX related
+Bug Type: *Database Functions
Operating System: openSUSE 10.2
PHP Version: 5.2.5
New Comment:
Category changed.
Previous Comments:
[2008-02-21 14:37:45] the_dude61 at hotmail dot com
Description:
Problem relates to ibm_db2-1.6.5 and DB2 v9.5.0.0 LINUXAMD6495.
I called a stored procedure with a blob parameter as follows:
$stmt = db2_prepare($conn, $sqlcmd);
$par_inid = 0;
$par_indata = 0011;
$par_outrc = 0;
db2_bind_param($stmt, 1, par_inid, DB2_PARAM_IN);
db2_bind_param($stmt, 2, par_indata, DB2_PARAM_IN,DB2_BINARY);
db2_bind_param($stmt, 3, par_outrc, DB2_PARAM_OUT);
if (db2_execute($stmt) )
ok
else
error
The DB2 stored procedure raises an error with [IBM][CLI
Driver][DB2/LINUXX8664] SQL0438N Application raised error with
diagnostic text: Id not found. SQLSTATE=77100.
But the db2_execute() function returns TRUE as if it was successfull.
I added some missing error handling code in ibm_db2.c - db2_execute()
to get the correct behaviour (see code below). The while loop did not
handle a SQL_ERROR of SQLParamData() as it occurs in my case. My case
was that the SQLExecute() requested one more data packet
(SQL_NEED_MORE). The next call to SQLParamData() within the while-loop
returned a sql error raised by the application because of an invalid id.
This error was not covered and db2_execute() returned with TRUE
(=successful).
Modified code (starts at line# 3277):
if ( rc == SQL_NEED_DATA ) {
while ( (rc = SQLParamData((SQLHSTMT)stmt_res-hstmt, (SQLPOINTER
*)valuePtr)) == SQL_NEED_DATA ) {
/* passing data value for a parameter */
rc = SQLPutData((SQLHSTMT)stmt_res-hstmt,
(SQLPOINTER)(((zvalue_value*)valuePtr)-str.val),
((zvalue_value*)valuePtr)-str.len);
if ( rc == SQL_ERROR ) {
php_error_docref(NULL TSRMLS_CC, E_WARNING, Sending
data failed);
_php_db2_check_sql_errors(stmt_res-hstmt,
SQL_HANDLE_STMT, rc, 1,
NULL, -1, 1 TSRMLS_CC);
RETVAL_FALSE;
}
}
if ( rc == SQL_ERROR ) {
php_error_docref(NULL TSRMLS_CC, E_WARNING, Statement Execute
Failed);
_php_db2_check_sql_errors(stmt_res-hstmt, SQL_HANDLE_STMT, rc,
1,
NULL, -1, 1 TSRMLS_CC);
RETVAL_FALSE;
}
}
Hope that this is not a huge text ;-)
--
Edit this bug report at http://bugs.php.net/?id=44203edit=1
#44212 [NEW]: array_diff_assoc not reporting missing arguments
From: [EMAIL PROTECTED] Operating system: PHP version: 5.3CVS-2008-02-22 (snap) PHP Bug Type: Arrays related Bug description: array_diff_assoc not reporting missing arguments Description: array_diff_assoc is not reporting missing arguments - see example code Reproduce code: --- var_dump( array_diff_assoc() ); $arr1 = array(1, 2); var_dump( array_diff_assoc($arr1) ); Expected result: Warning: array_diff_assoc(): at least 2 parameters are required, 0 given in %s on line %d NULL Warning: array_diff_assoc(): at least 2 parameters are required, 1 given in %s on line %d NULL Actual result: -- NULL NULL -- Edit bug report at http://bugs.php.net/?id=44212edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=44212r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=44212r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=44212r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=44212r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=44212r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=44212r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=44212r=needscript Try newer version:http://bugs.php.net/fix.php?id=44212r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=44212r=support Expected behavior:http://bugs.php.net/fix.php?id=44212r=notwrong Not enough info: http://bugs.php.net/fix.php?id=44212r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=44212r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=44212r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=44212r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=44212r=dst IIS Stability:http://bugs.php.net/fix.php?id=44212r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=44212r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=44212r=float No Zend Extensions: http://bugs.php.net/fix.php?id=44212r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=44212r=mysqlcfg
#44213 [Opn-Bgs]: in_array returns wrong value
ID: 44213
Updated by: [EMAIL PROTECTED]
Reported By: markus dot kalkbrenner at arcor dot de
-Status: Open
+Status: Bogus
Bug Type: Arrays related
Operating System: Linux
PHP Version: 5.2.5
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
This result is expected.
In a == 0, a is converted to int. For strict comparison, use the
third parameter.
http://docs.php.net/in-array
Previous Comments:
[2008-02-22 12:24:14] markus dot kalkbrenner at arcor dot de
Description:
in_array() returns true if needle exists as key with int(0) as value,
but should return false because needle doesn't exist as value.
Reproduce code:
---
?php
var_dump( in_array('a', array('a' = 1) ) );
var_dump( in_array('a', array('a' = 0) ) );
?
Expected result:
bool(false)
bool(false)
Actual result:
--
bool(false)
bool(true)
--
Edit this bug report at http://bugs.php.net/?id=44213edit=1
#44212 [Opn-Csd]: array_diff_assoc not reporting missing arguments
ID: 44212 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type:Arrays related PHP Version: 5.3CVS-2008-02-22 (snap) New Comment: This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. Previous Comments: [2008-02-22 12:11:17] [EMAIL PROTECTED] Description: array_diff_assoc is not reporting missing arguments - see example code Reproduce code: --- var_dump( array_diff_assoc() ); $arr1 = array(1, 2); var_dump( array_diff_assoc($arr1) ); Expected result: Warning: array_diff_assoc(): at least 2 parameters are required, 0 given in %s on line %d NULL Warning: array_diff_assoc(): at least 2 parameters are required, 1 given in %s on line %d NULL Actual result: -- NULL NULL -- Edit this bug report at http://bugs.php.net/?id=44212edit=1
#44214 [NEW]: Crash using preg_replace_callback and global variable
From: php at bouchery dot fr
Operating system: Windows XP
PHP version: 5.2.5
PHP Bug Type: Reproducible crash
Bug description: Crash using preg_replace_callback and global variable
Description:
When assigning callback parameter of preg_replace_callback into a global
variable, PHP CLI interpreter crash at the end of the script.
I generate this error with PHP v5.2.3.3, and I try the last 5.2.5.5, but
the result is the same.
Reproduce code:
---
?php
$string = 'aaa bbb ccc ddd eee ccc aaa bbb';
$array = array();
function myCallBack( $match ) {
global $array;
$array[] = $match;
return 'xxx';
}
echo preg_replace_callback( '`a+`', 'myCallBack', $string);
?
Expected result:
No crash at the end of the script.
Actual result:
--
Windows crash report with signature error.
---
AppName: php.exe AppVer: 5.2.5.5 ModName: php5ts.dll
ModVer: 5.2.5.5 Offset: 0009a10a
--
--
Edit bug report at http://bugs.php.net/?id=44214edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=44214r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=44214r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=44214r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=44214r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=44214r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=44214r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=44214r=needscript
Try newer version:http://bugs.php.net/fix.php?id=44214r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=44214r=support
Expected behavior:http://bugs.php.net/fix.php?id=44214r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=44214r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=44214r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=44214r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=44214r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=44214r=dst
IIS Stability:http://bugs.php.net/fix.php?id=44214r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=44214r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=44214r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=44214r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=44214r=mysqlcfg
#43387 [Com]: Segmentation fault during shutdown in _zend_mm_free_int()
ID: 43387
Comment by: sebabar at konto dot pl
Reported By: matteo at beccati dot com
Status: No Feedback
Bug Type: Reproducible crash
Operating System: GNU/Linux 2.6.18 x86_64
PHP Version: 5.2.5
New Comment:
I just experienced the same. I don't know why this happens, but I
managed to find the last executed line before segfault. Below is method
getMock() from PHPUnit (3.2.15), file /PHPUnit/Framework/TestCase.php
I added few echos to see where it crashes.
protected function getMock($className, array $methods = array(),
array $arguments = array(), $mockClassName = '',
$callOriginalConstructor = TRUE, $callOriginalClone = TRUE,
$callAutoload = TRUE)
{
if (!is_string($className) || !is_string($mockClassName)) {
throw new InvalidArgumentException;
}
$mock = PHPUnit_Framework_MockObject_Mock::generate(
$className,
$methods,
$mockClassName,
$callOriginalConstructor,
$callOriginalClone,
$callAutoload
);
echo GENERATED ;
$mockClass = new ReflectionClass($mock-mockClassName);
echo REFLECTED ;
$mockObject = $mockClass-newInstanceArgs($arguments);
echo \n AFTER newInstanceArgs() \n;
$this-mockObjects[] = $mockObject;
echo MOCK READY ;
return $mockObject;
}
In cases when php crashes, it stops just after REFLECTED message - on
call to newInstanceArgs()
The same unit tests, testing the same code base with the same version
of PHPUnit under windows and PHP 5.2.3 works ok.
Previous Comments:
[2008-02-09 02:10:55] [EMAIL PROTECTED]
not fixed - reopen
[2007-12-13 06:18:50] phajdan dot jr at gmail dot com
As this bug is now closed due to lack of feedback, can you reopen my
original bug http://bugs.php.net/bug.php?id=43397 ?
[2007-12-07 15:27:38] phajdan dot jr at gmail dot com
I don't know if it is helpful, but I tested with recent snapshot and
the bug wasn't fixed (I submitted another bug report, marked as a
duplicate of this one).
[2007-12-05 15:40:55] [EMAIL PROTECTED]
Keep this in feedback status until you have actually tested the
snapshot. A fix was committed recently which should fix this one too.
[2007-12-04 16:06:52] matteo at beccati dot com
We'll try to reproduce it again with either 5.2.4 or 5.2.5 and see if
the snapshot fixes it.
Thanks for the feedback, we really appreciate it!
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/43387
--
Edit this bug report at http://bugs.php.net/?id=43387edit=1
#44215 [NEW]: filesize() returns wrong values for files 4gb
From: php at hack-mich dot net
Operating system: Win Vista x64
PHP version: 5.2.5
PHP Bug Type: Unknown/Other Function
Bug description: filesize() returns wrong values for files 4gb
Description:
For files 4gb filesize returns negative values (seems that it overwrites
the sign bit - becomes negative)
Same is with 2gb files and 32bit oses, but that has not been confirmed
yet.
Reproduce code:
---
echo filesize('foo.bar');
//if foo.bar is 4gb it returns a negative value
Expected result:
something like 5234556
Actual result:
--
something like -3456634
--
Edit bug report at http://bugs.php.net/?id=44215edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=44215r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=44215r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=44215r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=44215r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=44215r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=44215r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=44215r=needscript
Try newer version:http://bugs.php.net/fix.php?id=44215r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=44215r=support
Expected behavior:http://bugs.php.net/fix.php?id=44215r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=44215r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=44215r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=44215r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=44215r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=44215r=dst
IIS Stability:http://bugs.php.net/fix.php?id=44215r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=44215r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=44215r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=44215r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=44215r=mysqlcfg
#44216 [NEW]: strftime segfaults on large negative value
From: j dot vdkamp at connectux dot com Operating system: Linux 64bit PHP version: 5.2.5 PHP Bug Type: Reproducible crash Bug description: strftime segfaults on large negative value Description: The following php code crashes on 64bit systems: php -r 'print strftime(%c, -6847808401);' The format string is of no importance, only the large negative value is. Reproduce code: --- print strftime(%c, -6847808401); Expected result: Sun Dec 31 22:59:59 1752 Actual result: -- Segmentation fault -- Edit bug report at http://bugs.php.net/?id=44216edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=44216r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=44216r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=44216r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=44216r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=44216r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=44216r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=44216r=needscript Try newer version:http://bugs.php.net/fix.php?id=44216r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=44216r=support Expected behavior:http://bugs.php.net/fix.php?id=44216r=notwrong Not enough info: http://bugs.php.net/fix.php?id=44216r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=44216r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=44216r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=44216r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=44216r=dst IIS Stability:http://bugs.php.net/fix.php?id=44216r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=44216r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=44216r=float No Zend Extensions: http://bugs.php.net/fix.php?id=44216r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=44216r=mysqlcfg
#44217 [NEW]: Output after stdout/stderr cause immediate exit
From: exe at travian dot org
Operating system: GNU/Linux Kernel 2.6.18
PHP version: 5.2.5
PHP Bug Type: Filesystem function related
Bug description: Output after stdout/stderr cause immediate exit
Description:
If STDOUT and/or STDERR are closed, output by the php script cause the
interpreter to exit immediately.
According to strace output, php tries to write to the closed STDOUT file
handle, causing a Bad file descriptor error and exit of the interpreter:
[...]
close(1)= 0
[...]
write(1, foo, 3) = -1 EBADF (Bad file descriptor)
close(0)= 0
close(2)= 0
[...]
exit_group(0) = ?
Process 19177 detached
Reproduce code:
---
?php
fclose(STDOUT);
print foo;
sleep(10);
?
Expected result:
No output, php sleeping for 10 seconds.
Actual result:
--
php exits immediately, strace shows an Bad file descriptor on the
write() try to STDOUT:
[...]
read(3, ?php\nfclose(STDOUT);\n\nprint \fo..., 8192) = 51
read(3, , 4096) = 0
read(3, , 8192) = 0
close(3)= 0
munmap(0x2b1dce20, 4096)= 0
close(1)= 0
munmap(0x2b1dce202000, 4096)= 0
write(1, foo, 3) = -1 EBADF (Bad file descriptor)
close(2)= 0
close(0)= 0
munmap(0x2b1dce201000, 4096)= 0
munmap(0x2b1dce1bf000, 266240) = 0
mmap(NULL, 266240, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0x2b1dce1bf000
setitimer(ITIMER_PROF, {it_interval={0, 0}, it_value={0, 0}}, NULL) = 0
munmap(0x2b1dce1bf000, 266240) = 0
brk(0xd36000) = 0xd36000
exit_group(0) = ?
Process 19196 detached
--
Edit bug report at http://bugs.php.net/?id=44217edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=44217r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=44217r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=44217r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=44217r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=44217r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=44217r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=44217r=needscript
Try newer version:http://bugs.php.net/fix.php?id=44217r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=44217r=support
Expected behavior:http://bugs.php.net/fix.php?id=44217r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=44217r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=44217r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=44217r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=44217r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=44217r=dst
IIS Stability:http://bugs.php.net/fix.php?id=44217r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=44217r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=44217r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=44217r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=44217r=mysqlcfg
#44217 [Opn]: Output after stdout/stderr closed cause immediate exit
ID: 44217
User updated by: exe at travian dot org
-Summary: Output after stdout/stderr cause immediate exit
Reported By: exe at travian dot org
Status: Open
Bug Type: Filesystem function related
Operating System: GNU/Linux Kernel 2.6.18
PHP Version: 5.2.5
New Comment:
Summary corrected.
Previous Comments:
[2008-02-22 17:32:15] exe at travian dot org
Description:
If STDOUT and/or STDERR are closed, output by the php script cause the
interpreter to exit immediately.
According to strace output, php tries to write to the closed STDOUT
file handle, causing a Bad file descriptor error and exit of the
interpreter:
[...]
close(1)= 0
[...]
write(1, foo, 3) = -1 EBADF (Bad file
descriptor)
close(0)= 0
close(2)= 0
[...]
exit_group(0) = ?
Process 19177 detached
Reproduce code:
---
?php
fclose(STDOUT);
print foo;
sleep(10);
?
Expected result:
No output, php sleeping for 10 seconds.
Actual result:
--
php exits immediately, strace shows an Bad file descriptor on the
write() try to STDOUT:
[...]
read(3, ?php\nfclose(STDOUT);\n\nprint \fo..., 8192) = 51
read(3, , 4096) = 0
read(3, , 8192) = 0
close(3)= 0
munmap(0x2b1dce20, 4096)= 0
close(1)= 0
munmap(0x2b1dce202000, 4096)= 0
write(1, foo, 3) = -1 EBADF (Bad file
descriptor)
close(2)= 0
close(0)= 0
munmap(0x2b1dce201000, 4096)= 0
munmap(0x2b1dce1bf000, 266240) = 0
mmap(NULL, 266240, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x2b1dce1bf000
setitimer(ITIMER_PROF, {it_interval={0, 0}, it_value={0, 0}}, NULL) =
0
munmap(0x2b1dce1bf000, 266240) = 0
brk(0xd36000) = 0xd36000
exit_group(0) = ?
Process 19196 detached
--
Edit this bug report at http://bugs.php.net/?id=44217edit=1
#44216 [Opn-Csd]: strftime segfaults on large negative value
ID: 44216 Updated by: [EMAIL PROTECTED] Reported By: j dot vdkamp at connectux dot com -Status: Open +Status: Closed Bug Type: Reproducible crash Operating System: Linux 64bit PHP Version: 5.2.5 New Comment: This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. Previous Comments: [2008-02-22 16:25:39] j dot vdkamp at connectux dot com Description: The following php code crashes on 64bit systems: php -r 'print strftime(%c, -6847808401);' The format string is of no importance, only the large negative value is. Reproduce code: --- print strftime(%c, -6847808401); Expected result: Sun Dec 31 22:59:59 1752 Actual result: -- Segmentation fault -- Edit this bug report at http://bugs.php.net/?id=44216edit=1
#44218 [NEW]: Misdirected output after closing stdout/stderr and working with files.
From: exe at travian dot org
Operating system: GNU/Linux Kernel 2.6.18
PHP version: 5.2.5
PHP Bug Type: Filesystem function related
Bug description: Misdirected output after closing stdout/stderr and working
with files.
Description:
If STDOUT/STDERR are closed by a script then the first two file handles
opened by that script afterwards will take the place of the former
STDOUT/STDERR handles. This will cause any output which normaly goes to
STDOUT (like in print/echo statements) to be written to the new file
handles. This behaviour may corrupt files written by that script.
This is a similar problem as in bug #44217.
Reproduce code:
---
?php
fclose(STDOUT); fclose(STDERR);
$fp1 = fopen('test.log', 'a'); // File handle 1, formerly STDOUT
$fp2 = fopen('test.log', 'a'); // File handle 2, formerly STDERR
print foo; // Will be written to test.log
?
Expected result:
No output from php, no appended output in test.log
Actual result:
--
String foo will be appended to test.log
strace shows that php first closes file handle 1 (stdout) and 2 (stderr)
and then openes two file handles, which get the numbers 1 and 2, and then
print foo to file handle 1 which now points to test.log:
read(3, ?php\nfclose(STDOUT); fclose(STD..., 8192) = 217
read(3, , 4096) = 0
read(3, , 8192) = 0
close(3)= 0
munmap(0x2b97a043e000, 4096)= 0
close(1)= 0
munmap(0x2b97a044, 4096)= 0
close(2)= 0
getcwd(/root, 4096) = 6
lstat(/root, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
lstat(/root/test.log, {st_mode=S_IFREG|0644, st_size=290, ...}) = 0
open(/root/test.log, O_WRONLY|O_APPEND|O_CREAT, 0666) = 1
fstat(1, {st_mode=S_IFREG|0644, st_size=290, ...}) = 0
lseek(1, 0, SEEK_CUR) = 0
lseek(1, 0, SEEK_CUR) = 0
getcwd(/root, 4096) = 6
open(/root/test.log, O_WRONLY|O_APPEND|O_CREAT, 0666) = 2
fstat(2, {st_mode=S_IFREG|0644, st_size=290, ...}) = 0
lseek(2, 0, SEEK_CUR) = 0
lseek(2, 0, SEEK_CUR) = 0
write(1, foo, 3) = 3
close(2)= 0
close(1)= 0
close(0)= 0
munmap(0x2b97a043f000, 4096)= 0
munmap(0x2b97a03fd000, 266240) = 0
mmap(NULL, 266240, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0x2b97a03fd000
setitimer(ITIMER_PROF, {it_interval={0, 0}, it_value={0, 0}}, NULL) = 0
munmap(0x2b97a03fd000, 266240) = 0
brk(0xd36000) = 0xd36000
exit_group(0) = ?
Process 19229 detached
--
Edit bug report at http://bugs.php.net/?id=44218edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=44218r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=44218r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=44218r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=44218r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=44218r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=44218r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=44218r=needscript
Try newer version:http://bugs.php.net/fix.php?id=44218r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=44218r=support
Expected behavior:http://bugs.php.net/fix.php?id=44218r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=44218r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=44218r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=44218r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=44218r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=44218r=dst
IIS Stability:http://bugs.php.net/fix.php?id=44218r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=44218r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=44218r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=44218r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=44218r=mysqlcfg
#44219 [NEW]: Fix for Bug #44209 Causes Test Regression
From: kirkland at ubuntu dot com Operating system: Linux 64 bit PHP version: 5.2.5 PHP Bug Type: *Compile Issues Bug description: Fix for Bug #44209 Causes Test Regression Description: I just rolled the patch associated with the fix from Bug #44209: http://marc.info/?l=php-cvsm=120367371119481w=2 However, I see test regressions on 64-bit Linux. See the differences here: http://pastebin.com/pastebin.php?diff=d365cb1ad Most of the failed tests are in the date/time realm, so I'd think there might be some concern. Thoughts? -- Edit bug report at http://bugs.php.net/?id=44219edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=44219r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=44219r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=44219r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=44219r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=44219r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=44219r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=44219r=needscript Try newer version:http://bugs.php.net/fix.php?id=44219r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=44219r=support Expected behavior:http://bugs.php.net/fix.php?id=44219r=notwrong Not enough info: http://bugs.php.net/fix.php?id=44219r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=44219r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=44219r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=44219r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=44219r=dst IIS Stability:http://bugs.php.net/fix.php?id=44219r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=44219r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=44219r=float No Zend Extensions: http://bugs.php.net/fix.php?id=44219r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=44219r=mysqlcfg
#44219 [Opn]: Fix for Bug #44209 Causes Test Regression
ID: 44219 Updated by: [EMAIL PROTECTED] Reported By: kirkland at ubuntu dot com Status: Open Bug Type: *Compile Issues Operating System: Linux 64 bit PHP Version: 5.2.5 New Comment: Not really... it's just that results are sometimes different on 32 vs 64 bit. Previous Comments: [2008-02-22 18:28:40] kirkland at ubuntu dot com Description: I just rolled the patch associated with the fix from Bug #44209: http://marc.info/?l=php-cvsm=120367371119481w=2 However, I see test regressions on 64-bit Linux. See the differences here: http://pastebin.com/pastebin.php?diff=d365cb1ad Most of the failed tests are in the date/time realm, so I'd think there might be some concern. Thoughts? -- Edit this bug report at http://bugs.php.net/?id=44219edit=1
#44219 [Opn]: Fix for Bug #44209 Causes Test Regression
ID: 44219 User updated by: kirkland at ubuntu dot com Reported By: kirkland at ubuntu dot com Status: Open Bug Type: *Compile Issues Operating System: Linux 64 bit PHP Version: 5.2.5 New Comment: The diff shown in that pastebin is from two subsequent runs, both on 64-bit Linux. The only difference between the two is: +++ php-src/ext/date/lib/timelib.h Fri Feb 22 09:48:18 2008 ... +#if HAVE_LIMITS_H +#include limits.h +#endif ... Previous Comments: [2008-02-22 18:38:26] [EMAIL PROTECTED] Not really... it's just that results are sometimes different on 32 vs 64 bit. [2008-02-22 18:28:40] kirkland at ubuntu dot com Description: I just rolled the patch associated with the fix from Bug #44209: http://marc.info/?l=php-cvsm=120367371119481w=2 However, I see test regressions on 64-bit Linux. See the differences here: http://pastebin.com/pastebin.php?diff=d365cb1ad Most of the failed tests are in the date/time realm, so I'd think there might be some concern. Thoughts? -- Edit this bug report at http://bugs.php.net/?id=44219edit=1
#44219 [Opn]: Fix for Bug #44209 Causes Test Regression
ID: 44219
User updated by: kirkland at ubuntu dot com
Reported By: kirkland at ubuntu dot com
Status: Open
Bug Type: *Compile Issues
Operating System: Linux 64 bit
PHP Version: 5.2.5
New Comment:
In other words, adding that 3-line patch creates the following test
regressions. The following tests now fail on 64-bit Linux:
+ Bug #41523 (strtotime('-00-00 00:00:00') is parsed as 1999-11-30)
[ext/date/tests/bug41523.phpt]
+ mktime() [3] [ext/date/tests/mktime-3.phpt]
+ strtotime() and mysql timestamps
[ext/date/tests/strtotime-mysql.phpt]
+ strtotime() function [ext/date/tests/strtotime3.phpt]
+ wddx deserialization test [ext/wddx/tests/001.phpt]
Previous Comments:
[2008-02-22 19:12:18] kirkland at ubuntu dot com
The diff shown in that pastebin is from two subsequent runs, both on
64-bit Linux.
The only difference between the two is:
+++ php-src/ext/date/lib/timelib.h Fri Feb 22 09:48:18 2008
...
+#if HAVE_LIMITS_H
+#include limits.h
+#endif
...
[2008-02-22 18:38:26] [EMAIL PROTECTED]
Not really... it's just that results are sometimes different on 32 vs
64 bit.
[2008-02-22 18:28:40] kirkland at ubuntu dot com
Description:
I just rolled the patch associated with the fix from Bug #44209:
http://marc.info/?l=php-cvsm=120367371119481w=2
However, I see test regressions on 64-bit Linux. See the differences
here:
http://pastebin.com/pastebin.php?diff=d365cb1ad
Most of the failed tests are in the date/time realm, so I'd think there
might be some concern. Thoughts?
--
Edit this bug report at http://bugs.php.net/?id=44219edit=1
#44219 [Opn]: Fix for Bug #44209 Causes Test Regression
ID: 44219
User updated by: kirkland at ubuntu dot com
Reported By: kirkland at ubuntu dot com
Status: Open
Bug Type: *Compile Issues
Operating System: Linux 64 bit
PHP Version: 5.2.5
New Comment:
Test script:
# cat /tmp/foo.php
?php
var_dump(strtotime('-00-00 00:00:00'));
?
Built without patch:
# php /tmp/foo.php
bool(false)
Built with patch:
# ./cli-build/sapi/cli/php /tmp/foo.php
int(-62169962400)
Previous Comments:
[2008-02-22 20:21:41] kirkland at ubuntu dot com
In other words, adding that 3-line patch creates the following test
regressions. The following tests now fail on 64-bit Linux:
+ Bug #41523 (strtotime('-00-00 00:00:00') is parsed as 1999-11-30)
[ext/date/tests/bug41523.phpt]
+ mktime() [3] [ext/date/tests/mktime-3.phpt]
+ strtotime() and mysql timestamps
[ext/date/tests/strtotime-mysql.phpt]
+ strtotime() function [ext/date/tests/strtotime3.phpt]
+ wddx deserialization test [ext/wddx/tests/001.phpt]
[2008-02-22 19:12:18] kirkland at ubuntu dot com
The diff shown in that pastebin is from two subsequent runs, both on
64-bit Linux.
The only difference between the two is:
+++ php-src/ext/date/lib/timelib.h Fri Feb 22 09:48:18 2008
...
+#if HAVE_LIMITS_H
+#include limits.h
+#endif
...
[2008-02-22 18:38:26] [EMAIL PROTECTED]
Not really... it's just that results are sometimes different on 32 vs
64 bit.
[2008-02-22 18:28:40] kirkland at ubuntu dot com
Description:
I just rolled the patch associated with the fix from Bug #44209:
http://marc.info/?l=php-cvsm=120367371119481w=2
However, I see test regressions on 64-bit Linux. See the differences
here:
http://pastebin.com/pastebin.php?diff=d365cb1ad
Most of the failed tests are in the date/time realm, so I'd think there
might be some concern. Thoughts?
--
Edit this bug report at http://bugs.php.net/?id=44219edit=1
#44221 [NEW]: 'make test' hangs indefinitely on check #1518
From: willm1 at cs dot umbc dot edu Operating system: Solaris 10-u4 PHP version: 5.2.5 PHP Bug Type: *Compile Issues Bug description: 'make test' hangs indefinitely on check #1518 Description: Test number 1519 hangs while building on Solaris 10, for at least 40 minutes. I'm not sure if this is related, but the /tmp/BUILD/php-5.2.5/tmp-php.ini file mentioned in the output is currently empty. This problem is reproducible with the steps below; I've run it three times, nuking the php-5.2.5 directory in between. The PHP process appears to go into a loop querying NIS for i_dont_exist.com, although NIS is not specified in nsswitch.conf as a place to get hostnames from. This happens both with and without NSCD running. Reproduce code: --- export PATH=/usr/ccs/bin:/usr/sbin:/usr/bin:/bin:/opt/csw/bin:/opt/csw/sbin:/opt/sfw/bin:/usr/sfw/bin CFLAGS='-O2 -g -pipe -R/usr/site/lib -R/usr/sfw/lib -m32' \ ./configure --prefix=/usr/site --sysconfdir=/usr/site/etc --mandir=/usr/site/share/man --with-zlib --enable-dba --with-gd --with-gettext --with-imap=/usr/site --with-imap-ssl=/usr/site --enable-soap --with-pear --with-libxml-dir=/usr/site --with-apxs2=/usr/site/sbin/apxs --with-mysql=/usr/sfw make make test Note that /usr/site contains all the packages we've built ourselves. Other packages build fine against the libraries in there, so I'm fairly certain external libraries aren't the issue. Expected result: Successful build. Actual result: -- + make test Build complete. Don't forget to run 'make test'. = CWD : /tmp/BUILD/php-5.2.5 PHP : /tmp/BUILD/php-5.2.5/sapi/cli/php PHP_SAPI: cli PHP_VERSION : 5.2.5 ZEND_VERSION: 2.2.0 PHP_OS : SunOS - SunOS servername 5.10 Generic_120011-14 sun4u INI actual : /tmp/BUILD/php-5.2.5/tmp-php.ini More .INIs : Extra dirs : = TIME START 2008-02-22 14:06:36 = ... PASS Bug #29839 (incorrect convert (xml:lang to lang)) [ext/soap/tests/bugs/bug34453.phpt] PASS Bug #34643 (wsdl default value) [ext/soap/tests/bugs/bug34643.phpt] TEST 1519/3821 [ext/soap/tests/bugs/bug34657.phpt] (in another terminal) # snoop not port 22 Using device /dev/hme (promiscuous mode) servername.cs.umbc.edu - nis.cs.umbc.edu NIS C MATCH i_dont_exist.com in ipnodes.byname nis.cs.umbc.edu - servername.cs.umbc.edu NIS R MATCH No such key -- Edit bug report at http://bugs.php.net/?id=44221edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=44221r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=44221r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=44221r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=44221r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=44221r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=44221r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=44221r=needscript Try newer version:http://bugs.php.net/fix.php?id=44221r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=44221r=support Expected behavior:http://bugs.php.net/fix.php?id=44221r=notwrong Not enough info: http://bugs.php.net/fix.php?id=44221r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=44221r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=44221r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=44221r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=44221r=dst IIS Stability:http://bugs.php.net/fix.php?id=44221r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=44221r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=44221r=float No Zend Extensions: http://bugs.php.net/fix.php?id=44221r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=44221r=mysqlcfg
#44220 [NEW]: Cre Loaded error
From: machineextractor at yahoo dot com Operating system: Windows Xp Professional PHP version: 5.2.5 PHP Bug Type: *General Issues Bug description: Cre Loaded error Description: Wen i finished to install new version of creloaded and i try to go in the admin area i reveive this error: Reproduce code: --- The instruction at 0x03135bd2 refered memory at 0x.The memory could not be read. -- Edit bug report at http://bugs.php.net/?id=44220edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=44220r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=44220r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=44220r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=44220r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=44220r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=44220r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=44220r=needscript Try newer version:http://bugs.php.net/fix.php?id=44220r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=44220r=support Expected behavior:http://bugs.php.net/fix.php?id=44220r=notwrong Not enough info: http://bugs.php.net/fix.php?id=44220r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=44220r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=44220r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=44220r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=44220r=dst IIS Stability:http://bugs.php.net/fix.php?id=44220r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=44220r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=44220r=float No Zend Extensions: http://bugs.php.net/fix.php?id=44220r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=44220r=mysqlcfg
#44222 [NEW]: tempnam $prefix parameter limitation
From: c dot d dot brengel at att dot net
Operating system: Windows XP
PHP version: 5.2.5
PHP Bug Type: Unknown/Other Function
Bug description: tempnam $prefix parameter limitation
Description:
It appears that when using tempnam the $prefix parameter only accepts 3
characters. I used tempnam(getcwd(),'ADR'.date(Y.m.d).'_')
and the resulting file name ended up as ADRBA.tmp not the
ADR2008222_BA.tmp that it should have given.
I then tried tempnam(getcwd(), 'ADR123') and stil got only ADRXX.tmp.
Not sure but would appreciate it if you could determine if this is in fact
correct behavior.
Reproduce code:
---
?php
echo getcwd() . \n\r;
chdir('tmp');
echo getcwd() . \n\r;
$file=tempnam(getcwd(),'ADR'.date(Y.m.d).'_');
echo $file;
?
Expected result:
C:\Inetpub\wwwroot\ADRAL
C:\Inetpub\wwwroot\ADRAL\tmp
C:\WINDOWS\Temp\ADR2008222_C2.tmp
Actual result:
--
C:\Inetpub\wwwroot\ADRAL
C:\Inetpub\wwwroot\ADRAL\tmp
C:\WINDOWS\Temp\ADRC2.tmp
--
Edit bug report at http://bugs.php.net/?id=44222edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=44222r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=44222r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=44222r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=44222r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=44222r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=44222r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=44222r=needscript
Try newer version:http://bugs.php.net/fix.php?id=44222r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=44222r=support
Expected behavior:http://bugs.php.net/fix.php?id=44222r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=44222r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=44222r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=44222r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=44222r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=44222r=dst
IIS Stability:http://bugs.php.net/fix.php?id=44222r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=44222r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=44222r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=44222r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=44222r=mysqlcfg
#44224 [NEW]: ftp_put() Connection timed out
From: jmichae3 at yahoo dot com
Operating system: Windows XP Pro
PHP version: 5.2.5
PHP Bug Type: FTP related
Bug description: ftp_put() Connection timed out
Description:
expect ftp_put() and ftp_chdir() to work 100% of the time on a broadband
cable connection. there are 421 web pages to upload, averaging 32k
minimum/file. total upload time is about 3 minutes, so it shouldn't fail.
Reproduce code:
---
function upload($conn_id, $dest_file, $src_file) {
global $remote_public_html_dir, $current_dir;
if ($current_dir != $remote_public_html_dir . dirname($src_file)) {
// change directory first
if (ftp_chdir($conn_id, $remote_public_html_dir .
dirname($src_file))) {
$current_dir=$remote_public_html_dir . dirname($src_file);
//only do this if chdir was successful.
if (ftp_alloc($conn_id, filesize($src_file), $result)) {
ftp_put($conn_id, basename($dest_file), $src_file,
FTP_BINARY);
}
}
} else { //directory hasn't changed. don't chdir.
//since change directory was not needed, upload file
ftp_put($conn_id, basename($dest_file), $src_file, FTP_BINARY);
}
}
}
//I don't have all the file parts to demonstrate.
Expected result:
successful upload of entire web site in 3 minutes over cable internet
connection with no errors.
Actual result:
--
have to try upload script to upload site up to 12 times sometimes with
version 5.2.5 because there is always at least 1 error.
Resource id #7 dest=index.html src=./lockdown/index.html
PHP Warning: ftp_put(): Could not open data connection to port 3389:
Connection timed out in C:\www\jimm\ftp5.php on line 101
!FTP upload has failed!--
retry: success: dest=index.html src=./lockdown/index.html
workaround: retry up to 50 times on failure. If you want that code, I can
supply, but it is 74 lines long and is 2 functions.
In version 5.2.3 it could not properly find an open port to use (sometimes
fail 10 times in a row with different errors). it just increments. I
*think* this got fixed in 5.2.5.
However, I still get at least 1 timeout in 5.2.5.
from the user's perspective, ftp_put() should just work. maybe it should
try, say 20 or 100 times (?), and if it doesn't succeed, give up. then
again
this function should not be timing out in the first place. maybe there is
a design flaw - I have no troubles uploading using filezilla ftp client.
At least put a note in the documentation that you should retry on failure
up to n times if you are not going to fix the code?
--
Edit bug report at http://bugs.php.net/?id=44224edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=44224r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=44224r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=44224r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=44224r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=44224r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=44224r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=44224r=needscript
Try newer version:http://bugs.php.net/fix.php?id=44224r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=44224r=support
Expected behavior:http://bugs.php.net/fix.php?id=44224r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=44224r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=44224r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=44224r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=44224r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=44224r=dst
IIS Stability:http://bugs.php.net/fix.php?id=44224r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=44224r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=44224r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=44224r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=44224r=mysqlcfg
#44225 [NEW]: Build with newer libxml on for windows
From: daniel dot oconnor at gmail dot com
Operating system: Windows
PHP version: 5.2.5
PHP Bug Type: Feature/Change Request
Bug description: Build with newer libxml on for windows
Description:
Any chance of getting the version of libxml, libxslt, libexslt bumped
higher for windows builds?
Something around the libxml 2.6.30, libxslt 10122 and libexslt 813 mark?
The current bundled libraries produce incorrect XSLT results.
This in turn blocks implementing a php grddl implementation that properly
conforms to the spec (http://www.w3.org/2004/01/rdxh/spec)
Reproduce code:
---
?php
$xml =
http://www.w3.org/2001/sw/grddl-wg/td/xhtmlWithMoreThanOneGrddlTransformation.html;;
$stylesheet = http://www.w3.org/2001/sw/grddl-wg/td/getAuthor.xsl;;
$dom = new DOMDocument('1.0');
$dom-load($xml);
$xsl = new DOMDocument();
$xsl-load($stylesheet);
$proc = new XSLTProcessor();
$proc-importStyleSheet($xsl);
print $proc-transformToXML($dom);
phpinfo(8);
Expected result:
C:\xsltproc http://www.w3.org/2001/sw/grddl-wg/td/getAuthor.xsl
http://www.w3.org/2001/sw/grddl-wg/td/xhtmlWithMoreThanOneGrddlTransformation.html
rdf:RDF xmlns:rdf=http://www.w3.org/1999/02/22-rdf-syntax-ns#;
xmlns:foaf=http://xmlns.com/foaf/0.1/;
rdf:Description rdf:about=
dc:creator xmlns:dc=http://purl.org/dc/elements/1.1/;
rdf:parseType=Resource
foaf:homepage rdf:resource=http://www.w3.org/People/Dom//
/dc:creator
/rdf:Description
/rdf:RDF
C:\xsltproc --version
Using libxml 20630, libxslt 10122 and libexslt 813
xsltproc was compiled against libxml 20630, libxslt 10122 and libexslt
813
libxslt 10122 was compiled against libxml 20630
libexslt 813 was compiled against libxml 20630
Actual result:
--
Warning: XSLTProcessor::transformToXml(): Undefined namespace prefix in
C:\old-libxml.php on line 15
Warning: XSLTProcessor::transformToXml(): xmlXPathEval: evaluation failed
in C:\old-libxml.php on line 15
Warning: XSLTProcessor::transformToXml(): Undefined namespace prefix in
C:\old-libxml.php on line 15
Warning: XSLTProcessor::transformToXml(): xmlXPathEval: evaluation failed
in C:\old-libxml.php on line 15
Warning: XSLTProcessor::transformToXml(): Undefined namespace prefix in
C:\old-libxml.php on line 15
Warning: XSLTProcessor::transformToXml(): xmlXPathEval: evaluation failed
in C:\old-libxml.php on line 15
Warning: XSLTProcessor::transformToXml(): Undefined namespace prefix in
C:\old-libxml.php on line 15
Warning: XSLTProcessor::transformToXml(): xmlXPathEval: evaluation failed
in C:\old-libxml.php on line 15
Warning: XSLTProcessor::transformToXml(): Undefined namespace prefix in
C:\old-libxml.php on line 15
Warning: XSLTProcessor::transformToXml(): xmlXPathEval: evaluation failed
in C:\old-libxml.php on line 15
?xml version=1.0 encoding=utf-8?
rdf:RDF xmlns:rdf=http://www.w3.org/1999/02/22-rdf-syntax-ns#;
xmlns:foaf=http://xmlns.com/foaf/0.1/;
rdf:Description rdf:about=
dc:creator xmlns:dc=http://purl.org/dc/elements/1.1/;
rdf:parseType=Resource
foaf:homepage rdf:resource=//
/dc:creator
/rdf:Description
rdf:Description rdf:about=
dc:creator xmlns:dc=http://purl.org/dc/elements/1.1/;
rdf:parseType=Resource
foaf:homepage rdf:resource=simpleTransform.xsl/
/dc:creator
/rdf:Description
rdf:Description rdf:about=
dc:creator xmlns:dc=http://purl.org/dc/elements/1.1/;
rdf:parseType=Resource
foaf:homepage rdf:resource=getAuthor.xsl/
/dc:creator
/rdf:Description
rdf:Description rdf:about=
dc:creator xmlns:dc=http://purl.org/dc/elements/1.1/;
rdf:parseType=Resource
foaf:homepage rdf:resource=http://www.w3.org/People/Dom//
/dc:creator
/rdf:Description
rdf:Description rdf:about=
dc:creator xmlns:dc=http://purl.org/dc/elements/1.1/;
rdf:parseType=Resource
foaf:homepage rdf:resource=mailto:[EMAIL PROTECTED]/
/dc:creator
/rdf:Description
/rdf:RDF
phpinfo()
bcmath
BCMath support = enabled
calendar
Calendar support = enabled
com_dotnet
COM support = enabled
DCOM support = disabled
.Net support = enabled
Directive = Local Value = Master Value
com.allow_dcom = 0 = 0
com.autoregister_casesensitive = 1 = 1
com.autoregister_typelib = 0 = 0
com.autoregister_verbose = 0 = 0
com.code_page = no value = no value
com.typelib_file = no value = no value
ctype
ctype functions = enabled
date
date/time support = enabled
Olson Timezone Database Version = 2007.9
Timezone Database = internal
Default timezone = UTC
Directive = Local Value = Master Value
date.default_latitude = 31.7667 = 31.7667
date.default_longitude = 35.2333 = 35.2333
date.sunrise_zenith = 90.58 = 90.58
date.sunset_zenith = 90.58 = 90.58
date.timezone = no value = no value
dom
DOM/XML = enabled
DOM/XML API Version = 20031129
libxml Version = 2.6.26
HTML Support = enabled
XPath Support = enabled
XPointer Support = enabled
Schema Support = enabled
RelaxNG Support = enabled
filter
Input
#32330 [Com]: session_destroy, Failed to initialize storage module, custom session handler
ID: 32330
Comment by: fxmulder at gmail dot com
Reported By: [EMAIL PROTECTED]
Status: Verified
Bug Type: Session related
Operating System: *
PHP Version: 6CVS, 5CVS, 5.2.5, 4CVS (2005-03-17)
New Comment:
The problem is both mod_data getting set to NULL and
zval_ptr_dtor(mdata-names[i]); for each of the functions in
ext/session/mod_user.c:PS_CLOSE_FUNC. If the deconstructor calls are
removed as well as the NULL replacements and efree() call on mdata then
it works, except then the containing classes are never deconstructed.
This could possibly be moved to a location when the script is exiting,
and/or another call to session_set_save_handler is made.
Previous Comments:
[2008-01-22 05:43:48] [EMAIL PROTECTED]
This bug still exists in PHP 5.2.5 release and current (as of this
comment) PHP 6CVS. Using a fresh call to session_set_save_handler() does
work, but as previously noted by others, this isn't a desirable
behavior.
[2007-08-23 05:25:49] jkloske at itee dot uq dot edu dot au
I'm confirming that I'm also affected by this on all OSs and all
versions of PHP I've tried it with (4/5, win/linux)
I'm calling session_write_close() not session_destroy() and it's still
causing the same error. Re-calling session_set_save_handler between
previous close and subsequent open does nothing; the error still
occurs.
This means that phpMyAdmin (which uses multiple sessions for various
authentication handlers at least) is not compatible with user session
handlers, due to this bug :)
[2007-07-05 13:23:23] facingratio at email dot it
I confirm that the ini_set workaround doesn't work. The only solution i
found is to use the session_set_save_handler(...) again after you call
session_destroy(). Also session_write_close() followed by
session_start() seems to generate the same fatal error.
[2007-03-08 05:07:06] colossuswv at hotmail dot com
The ini_set workaround doesn't seem to work when using a db to store
sessions. Using session_set_save_handler() again after session destroy
does work however, albeit an undesirable solution.
[2006-12-14 17:24:03] faithfulsoft at tiscali dot it
I've experienced this problem today, and it was driving me crazy.
I was able to resolve it thanks to the last post on this page.
I've put this two lines of code
ini_set(session.save_handler, files);
session_start();
in a separate file, and I include them where I need.
The strange thing is that I borrowed the piece of code I am using from
a GPL portal system, which is working like a charm on my local server
with this line
ini_set('session.save_handler', 'files');
This is really strange.
Anyhow, thank you all guys.
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/32330
--
Edit this bug report at http://bugs.php.net/?id=32330edit=1
