#37171 [Opn->Fbk]: crashes when using curl_multi_*
ID: 37171 Updated by: [EMAIL PROTECTED] Reported By: bishopx at quick dot cz -Status: Open +Status: Feedback Bug Type: cURL related Operating System: win32 PHP Version: 5.1.3RC3 New Comment: Well, the backtrace is obviously invalid and doesn't add any helpful information.. >I suggest to implement debug tracing like this one: >http://www.codeproject.com/debug/extendedtrace.asp Sure. If you can do it - please, do. Unfortunately I don't use windows, so I've no clue what's this all about.. Are you able to reproduce it with Apache1 ? Did you try with PHP CLI ? Previous Comments: [2006-04-22 21:47:16] bishopx at quick dot cz This is the call stack generated in VC8 using debug symbols for VC6, so the info is incomplete. However, I was able to decipher from asm that it crashes when reading the pointer curl_llist_element *e, the second argument of Curl_llist_insert_next(), hence the error: Unhandled exception at 0x013d0c78 (php_curl.dll) in httpd.exe: 0xC005: Access violation reading location 0x0008. > php_curl.dll!_Curl_llist_insert_next() + 0x48 bytes php_curl.dll!_Curl_hash_add() + 0x71 bytes php_curl.dll!_Curl_cache_addr() + 0x6b bytes php_curl.dll!_Curl_addrinfo4_callback() + 0x82 bytes php_curl.dll!_Curl_addrinfo4_callback() + 0x14 bytes php_curl.dll!_Curl_getaddrinfo() + 0x2af bytes ntdll.dll!7c91056d() [Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll] kernel32.dll!7c80b50b() ntdll.dll!7c91056d() kernel32.dll!7c8399f3() .. this looks like a thread created in php_curl. I suggest to implement debug tracing like this one: http://www.codeproject.com/debug/extendedtrace.asp This would greatly improve the feedback from users, because there would be no need for installing Visual Studio or compiling the source. Only 2 things are needed: pdb files and dbghelp.dll (a text file is generated). [2006-04-22 20:30:57] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php for *NIX and http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32 Once you have generated a backtrace, please submit it to this bug report and change the status back to "Open". Thank you for helping us make PHP better. [2006-04-22 20:26:06] bishopx at quick dot cz I already tried, crashing.. [2006-04-22 19:58:02] [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-04-22 19:49:49] bishopx at quick dot cz Description: php_curl.dll is the cause of frequent crashes when using curl_multi_*() functions, especially curl*_close() and curl_multi_remove_handle(). However, even other functions sometimes cause a crash (I removed the above ones). The situation in the latest snapshots remains the same. It looks like a poor thread synchronisation. Apache 2.2.x used. Reproduce code: --- This should work fine: http://php.net/manual/en/function.curl-multi-exec.php#48813 ..but you may have to increase the number of links in $connomains, or change them to pictures. Expected result: The code doesn't crash the webserver. Actual result: -- The code often crashes the webserver (not always). -- Edit this bug report at http://bugs.php.net/?id=37171&edit=1
#37171 [Fbk->Opn]: crashes when using curl_multi_*
ID: 37171 User updated by: bishopx at quick dot cz Reported By: bishopx at quick dot cz -Status: Feedback +Status: Open Bug Type: cURL related Operating System: win32 PHP Version: 5.1.3RC3 New Comment: This is the call stack generated in VC8 using debug symbols for VC6, so the info is incomplete. However, I was able to decipher from asm that it crashes when reading the pointer curl_llist_element *e, the second argument of Curl_llist_insert_next(), hence the error: Unhandled exception at 0x013d0c78 (php_curl.dll) in httpd.exe: 0xC005: Access violation reading location 0x0008. > php_curl.dll!_Curl_llist_insert_next() + 0x48 bytes php_curl.dll!_Curl_hash_add() + 0x71 bytes php_curl.dll!_Curl_cache_addr() + 0x6b bytes php_curl.dll!_Curl_addrinfo4_callback() + 0x82 bytes php_curl.dll!_Curl_addrinfo4_callback() + 0x14 bytes php_curl.dll!_Curl_getaddrinfo() + 0x2af bytes ntdll.dll!7c91056d() [Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll] kernel32.dll!7c80b50b() ntdll.dll!7c91056d() kernel32.dll!7c8399f3() .. this looks like a thread created in php_curl. I suggest to implement debug tracing like this one: http://www.codeproject.com/debug/extendedtrace.asp This would greatly improve the feedback from users, because there would be no need for installing Visual Studio or compiling the source. Only 2 things are needed: pdb files and dbghelp.dll (a text file is generated). Previous Comments: [2006-04-22 20:30:57] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php for *NIX and http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32 Once you have generated a backtrace, please submit it to this bug report and change the status back to "Open". Thank you for helping us make PHP better. [2006-04-22 20:26:06] bishopx at quick dot cz I already tried, crashing.. [2006-04-22 19:58:02] [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-04-22 19:49:49] bishopx at quick dot cz Description: php_curl.dll is the cause of frequent crashes when using curl_multi_*() functions, especially curl*_close() and curl_multi_remove_handle(). However, even other functions sometimes cause a crash (I removed the above ones). The situation in the latest snapshots remains the same. It looks like a poor thread synchronisation. Apache 2.2.x used. Reproduce code: --- This should work fine: http://php.net/manual/en/function.curl-multi-exec.php#48813 ..but you may have to increase the number of links in $connomains, or change them to pictures. Expected result: The code doesn't crash the webserver. Actual result: -- The code often crashes the webserver (not always). -- Edit this bug report at http://bugs.php.net/?id=37171&edit=1
#37171 [Opn->Fbk]: crashes when using curl_multi_*
ID: 37171 Updated by: [EMAIL PROTECTED] Reported By: bishopx at quick dot cz -Status: Open +Status: Feedback Bug Type: cURL related Operating System: win32 PHP Version: 5.1.3RC3 New Comment: Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php for *NIX and http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32 Once you have generated a backtrace, please submit it to this bug report and change the status back to "Open". Thank you for helping us make PHP better. Previous Comments: [2006-04-22 20:26:06] bishopx at quick dot cz I already tried, crashing.. [2006-04-22 19:58:02] [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-04-22 19:49:49] bishopx at quick dot cz Description: php_curl.dll is the cause of frequent crashes when using curl_multi_*() functions, especially curl*_close() and curl_multi_remove_handle(). However, even other functions sometimes cause a crash (I removed the above ones). The situation in the latest snapshots remains the same. It looks like a poor thread synchronisation. Apache 2.2.x used. Reproduce code: --- This should work fine: http://php.net/manual/en/function.curl-multi-exec.php#48813 ..but you may have to increase the number of links in $connomains, or change them to pictures. Expected result: The code doesn't crash the webserver. Actual result: -- The code often crashes the webserver (not always). -- Edit this bug report at http://bugs.php.net/?id=37171&edit=1
#37171 [Fbk->Opn]: crashes when using curl_multi_*
ID: 37171 User updated by: bishopx at quick dot cz Reported By: bishopx at quick dot cz -Status: Feedback +Status: Open Bug Type: cURL related Operating System: win32 -PHP Version: 5.1.2 +PHP Version: 5.1.3RC3 New Comment: I already tried, crashing.. Previous Comments: [2006-04-22 19:58:02] [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-04-22 19:49:49] bishopx at quick dot cz Description: php_curl.dll is the cause of frequent crashes when using curl_multi_*() functions, especially curl*_close() and curl_multi_remove_handle(). However, even other functions sometimes cause a crash (I removed the above ones). The situation in the latest snapshots remains the same. It looks like a poor thread synchronisation. Apache 2.2.x used. Reproduce code: --- This should work fine: http://php.net/manual/en/function.curl-multi-exec.php#48813 ..but you may have to increase the number of links in $connomains, or change them to pictures. Expected result: The code doesn't crash the webserver. Actual result: -- The code often crashes the webserver (not always). -- Edit this bug report at http://bugs.php.net/?id=37171&edit=1
#37171 [Opn->Fbk]: crashes when using curl_multi_*
ID: 37171 Updated by: [EMAIL PROTECTED] Reported By: bishopx at quick dot cz -Status: Open +Status: Feedback Bug Type: cURL related Operating System: win32 PHP Version: 5.1.2 New Comment: 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 Previous Comments: [2006-04-22 19:49:49] bishopx at quick dot cz Description: php_curl.dll is the cause of frequent crashes when using curl_multi_*() functions, especially curl*_close() and curl_multi_remove_handle(). However, even other functions sometimes cause a crash (I removed the above ones). The situation in the latest snapshots remains the same. It looks like a poor thread synchronisation. Apache 2.2.x used. Reproduce code: --- This should work fine: http://php.net/manual/en/function.curl-multi-exec.php#48813 ..but you may have to increase the number of links in $connomains, or change them to pictures. Expected result: The code doesn't crash the webserver. Actual result: -- The code often crashes the webserver (not always). -- Edit this bug report at http://bugs.php.net/?id=37171&edit=1
#37171 [NEW]: crashes when using curl_multi_*
From: bishopx at quick dot cz Operating system: win32 PHP version: 5.1.2 PHP Bug Type: cURL related Bug description: crashes when using curl_multi_* Description: php_curl.dll is the cause of frequent crashes when using curl_multi_*() functions, especially curl*_close() and curl_multi_remove_handle(). However, even other functions sometimes cause a crash (I removed the above ones). The situation in the latest snapshots remains the same. It looks like a poor thread synchronisation. Apache 2.2.x used. Reproduce code: --- This should work fine: http://php.net/manual/en/function.curl-multi-exec.php#48813 ..but you may have to increase the number of links in $connomains, or change them to pictures. Expected result: The code doesn't crash the webserver. Actual result: -- The code often crashes the webserver (not always). -- Edit bug report at http://bugs.php.net/?id=37171&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=37171&r=trysnapshot44 Try a CVS snapshot (PHP 5.1): http://bugs.php.net/fix.php?id=37171&r=trysnapshot51 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=37171&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=37171&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=37171&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=37171&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=37171&r=needscript Try newer version:http://bugs.php.net/fix.php?id=37171&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=37171&r=support Expected behavior:http://bugs.php.net/fix.php?id=37171&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=37171&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=37171&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=37171&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=37171&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=37171&r=dst IIS Stability:http://bugs.php.net/fix.php?id=37171&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=37171&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=37171&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=37171&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=37171&r=mysqlcfg
#37169 [NEW]: Feature request: Configuration sendmail_eol
From: sd at sven-drieling dot de Operating system: PHP version: 4.4.2 PHP Bug Type: *Mail Related Bug description: Feature request: Configuration sendmail_eol Description: Configuration sendmail_eol with the end of line marker CRLF, LF or CR that works without problems with the MTA in sendmail_path to avoid the problem of doubling lines. http://www.php.net/manual/en/function.mail.php "Note: If messages are not received, try using a LF (\n) only. Some poor quality Unix mail transfer agents replace LF by CRLF automatically (which leads to doubling CR if CRLF is used). This should be a last resort, as it does not comply with RFC 2822." -- Edit bug report at http://bugs.php.net/?id=37169&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=37169&r=trysnapshot44 Try a CVS snapshot (PHP 5.1): http://bugs.php.net/fix.php?id=37169&r=trysnapshot51 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=37169&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=37169&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=37169&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=37169&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=37169&r=needscript Try newer version:http://bugs.php.net/fix.php?id=37169&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=37169&r=support Expected behavior:http://bugs.php.net/fix.php?id=37169&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=37169&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=37169&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=37169&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=37169&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=37169&r=dst IIS Stability:http://bugs.php.net/fix.php?id=37169&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=37169&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=37169&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=37169&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=37169&r=mysqlcfg
#37167 [Opn->Csd]: PDO::FETCH_FUNC doesn't work with a callback
ID: 37167
Updated by: [EMAIL PROTECTED]
Reported By: troelskn at gmail dot com
-Status: Open
+Status: Closed
Bug Type: PDO related
Operating System: *
PHP Version: 5.1.2
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:
[2006-04-22 18:42:27] troelskn at gmail dot com
Reproduce code:
---
connection = new PDO("sqlite::memory:");
$this->connection->setAttribute(PDO::ATTR_ERRMODE,
PDO::ERRMODE_EXCEPTION);
$this->connection->setAttribute(PDO::ATTR_CASE,
PDO::CASE_LOWER);
$this->connection->query("CREATE TABLE test (a integer primary
key)");
$this->connection->query("INSERT INTO test VALUES (22)");
}
function select() {
$query = "SELECT * FROM test";
$result = $this->connection->query($query);
return $result->fetchAll(PDO::FETCH_FUNC, Array($this,
'loadRecord'));
}
function loadRecord($row) {
return new ArrayObject($row);
}
}
$test = new Test();
var_dump($test->select());
?>
Expected result:
no error
Actual result:
--
Apache crashes.
[2006-04-22 17:44:55] [EMAIL PROTECTED]
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external
resources such as databases, etc.
If possible, make the script source available online and provide
an URL to it here. Try to avoid embedding huge scripts into the report.
[2006-04-22 15:30:52] troelskn at gmail dot com
Description:
Using PDO::FETCH_FUNC with fetchAll() only works with a function. It
would be nice if it worked with a normal callback type (as in
call_user_func and others).
If this can't be fixed, the error message must be changed, since
"General error: user-supplied function must be a valid callback" is
misleading.
--
Edit this bug report at http://bugs.php.net/?id=37167&edit=1
#30962 [NoF->Bgs]: Space being returned for NULL columns
ID: 30962
Updated by: [EMAIL PROTECTED]
Reported By: richard dot quadling at bandvulc dot co dot uk
-Status: No Feedback
+Status: Bogus
Bug Type: MSSQL related
Operating System: Windows XP Pro SP2
PHP Version: 5.0.3
New Comment:
See bug #29292.
Previous Comments:
[2006-04-22 18:34:36] larry dot menard at rogers dot com
I seem to be having this same problem on PHP 5.1.2 (on Windows XP).
Simple test script:
Returns:
C:\MyServer>php testMsSql_mssql.php
array(2) {
[0]=>
string(1) " "
["g_theme"]=>
string(1) " "
}
I know this is not correct, the actual content of that column is a
0-byte string:
C:\MyServer>sqlcmd -d ... -S ... -U ... -P ... -e
1> select g_theme from g2_albumitem
2> go
select g_theme from g2_albumitem
g_theme
(1 rows affected)
1> select len(g_theme) from g2_albumitem
2> go
select len(g_theme) from g2_albumitem
---
0
(1 rows affected)
1> select 'x' + g_theme + 'x' from g2_albumitem
2> go
select 'x' + g_theme + 'x' from g2_albumitem
--
xx
(1 rows affected)
1>
Is anyone still working on this? It's been about 10 months since this
bug was last updated. (Unfortunately I do not have a PHP Build
environment.)
Thanks.
[2005-06-21 20:59:48] robert dot sevcik at gmail dot com
Hi, It'd be nice to see it working in php 5.1 because right now I am
developing in php5. I've tried various php5 snaps and 5.0.4 stable
without efect.
I am on a Win2003 server and here is my try-case:
string(1) " "
["len"]=>
int(0)
["bin"]=>
string(1) " "
}
5.1.0-dev
Thank you much :)
*/
?>
[2005-03-31 10:54:11] beschr at free dot fr
Please ignore my precedent comment, the bug is still present in CVS.
I test the mssql.dll today (latest snap: Built On: Mar 29, 2005 16:30
GMT) and the bug is still present.
[2005-03-25 14:54:28] rantal at eoss dot ru
Same problem still exist in php4 snapshot
php4-win32-STABLE-200503230530.zip
[2005-03-17 17:59:57] beschr at free dot fr
I've got this problem too with php 5.0.3 on IIS/Windows XP Pro SP2.
With the mssql.dll of this snaps: Built On: Mar 17, 2005 01:30 GMT it
work great.
So I think the correction in CVs is ok and you can close this bug.
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/30962
--
Edit this bug report at http://bugs.php.net/?id=30962&edit=1
#37167 [Fbk->Opn]: PDO::FETCH_FUNC doesn't work with a callback
ID: 37167
User updated by: troelskn at gmail dot com
Reported By: troelskn at gmail dot com
-Status: Feedback
+Status: Open
Bug Type: PDO related
Operating System: *
PHP Version: 5.1.2
New Comment:
Reproduce code:
---
connection = new PDO("sqlite::memory:");
$this->connection->setAttribute(PDO::ATTR_ERRMODE,
PDO::ERRMODE_EXCEPTION);
$this->connection->setAttribute(PDO::ATTR_CASE,
PDO::CASE_LOWER);
$this->connection->query("CREATE TABLE test (a integer primary
key)");
$this->connection->query("INSERT INTO test VALUES (22)");
}
function select() {
$query = "SELECT * FROM test";
$result = $this->connection->query($query);
return $result->fetchAll(PDO::FETCH_FUNC, Array($this,
'loadRecord'));
}
function loadRecord($row) {
return new ArrayObject($row);
}
}
$test = new Test();
var_dump($test->select());
?>
Expected result:
no error
Actual result:
--
Apache crashes.
Previous Comments:
[2006-04-22 17:44:55] [EMAIL PROTECTED]
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external
resources such as databases, etc.
If possible, make the script source available online and provide
an URL to it here. Try to avoid embedding huge scripts into the report.
[2006-04-22 15:30:52] troelskn at gmail dot com
Description:
Using PDO::FETCH_FUNC with fetchAll() only works with a function. It
would be nice if it worked with a normal callback type (as in
call_user_func and others).
If this can't be fixed, the error message must be changed, since
"General error: user-supplied function must be a valid callback" is
misleading.
--
Edit this bug report at http://bugs.php.net/?id=37167&edit=1
#37168 [Opn]: WDDX serializer inefficient with larger structures
ID: 37168
User updated by: dolecek at sky dot cz
Reported By: dolecek at sky dot cz
Status: Open
Bug Type: Performance problem
Operating System: NetBSD
PHP Version: 5.1.2
New Comment:
It's a minimal intrusion patch, designed to pinpoint and show the
problem - feel free to integrate whatever way is best for PHP project.
Previous Comments:
[2006-04-22 17:55:03] [EMAIL PROTECTED]
The patch is definitely wrong, as this is just a hack overriding
functions in this particular case only.
Fix the original functions instead (if there are any problems).
[2006-04-22 17:49:32] dolecek at sky dot cz
Oh, and the patch 2) should also include the #define SMART_STR_PREALLOC
4192, so that the initial size is power-of-2 (the test result was
run with that part included).
[2006-04-22 17:38:54] dolecek at sky dot cz
The OS was set to NetBSD for this bug report because the tests were run
on NetBSD.
[2006-04-22 17:35:35] dolecek at sky dot cz
Description:
We use WDDX for persistent storage on a project, the production system
runs on MS Windows. The structure is typically small array of several
asociative arrays. We recently noticed that bigger arrays takes
significantly more time to serialize then small ones. Increasing the
size of array twice resulted to about 5-10 times time increase, with
even bigger increase as the size increased.
Problem boils down do smart string API, used by WDDX. WDDX uses it to
store the serialization results.
With default sizes, the initial smart string size is 76 bytes and the
buffer grows only by 128+1 bytes. When the buffer size grows beyond
trivial sizes, the whole smart_string_appendl() et.al. starts being
dominated by the time spend reallocating the buffer, i.e. realloc() and
the associated memory-to-memory copies and CPU cache trashing.
I've tried two strategies to alleviate the problem.
1. increase the buffer grow size to 4192 bytes
2. enforce power-of-2 size of the buffer, and always
at least double the size of buffer
Many malloc()/realloc() implementation optimize power-of-2 sizes, and
the doubling also ensures the total number of calls to realloc() and
associated memory trashing is minimized.
1) helps a lot, but the time increase is still not prortional to the
array size increase.
2) fixes the problem, the time increase is mostly exactly proportional
to the size increase.
Note - the same problem has been observed for standard serializer, i.e.
serialize(). Briefly looking at source it seems the problem is the same
as for WDDX.
Patch for 1):
--- ext/wddx/wddx.c.orig2006-04-22 19:27:19.0 +0200
+++ ext/wddx/wddx.c
@@ -22,6 +22,8 @@
#if HAVE_WDDX
+#define SMART_STR_PREALLOC 4192
+
#include "ext/xml/expat_compat.h"
#include "php_wddx.h"
#include "php_wddx_api.h"
256
Patch for 2):
--- ext/wddx/wddx.c.orig2006-01-01 13:50:16.0 +0100
+++ ext/wddx/wddx.c
@@ -38,2 +44,21 @@
+#undef SMART_STR_DO_REALLOC
+#define SMART_STR_DO_REALLOC(d, what) \
+ (d)->c = SMART_STR_REALLOC((d)->c, (d)->a, (what))
+
+#undef smart_str_alloc4
+#define smart_str_alloc4(d, n, what, newlen) do {
\
+ if (!(d)->c) {
\
+ (d)->len = 0;
\
+ (d)->a = SMART_STR_START_SIZE; \
+ } \
+\
+ newlen = (d)->len + (n);
\
+ if (newlen >= (d)->a || !(d)->c) {
\
+ while((d)->a < newlen+1)
\
+ (d)->a += (d)->a; \
+ SMART_STR_DO_REALLOC(d, what);
\
+ }
\
+} while (0)
+
#define WDDX_BUF_LEN 256
Reproduce code:
---
http://bugs.php.net/?id=37168&edit=1
#30962 [Com]: Space being returned for NULL columns
ID: 30962
Comment by: larry dot menard at rogers dot com
Reported By: richard dot quadling at bandvulc dot co dot uk
Status: No Feedback
Bug Type: MSSQL related
Operating System: Windows XP Pro SP2
PHP Version: 5.0.3
New Comment:
I seem to be having this same problem on PHP 5.1.2 (on Windows XP).
Simple test script:
Returns:
C:\MyServer>php testMsSql_mssql.php
array(2) {
[0]=>
string(1) " "
["g_theme"]=>
string(1) " "
}
I know this is not correct, the actual content of that column is a
0-byte string:
C:\MyServer>sqlcmd -d ... -S ... -U ... -P ... -e
1> select g_theme from g2_albumitem
2> go
select g_theme from g2_albumitem
g_theme
(1 rows affected)
1> select len(g_theme) from g2_albumitem
2> go
select len(g_theme) from g2_albumitem
---
0
(1 rows affected)
1> select 'x' + g_theme + 'x' from g2_albumitem
2> go
select 'x' + g_theme + 'x' from g2_albumitem
--
xx
(1 rows affected)
1>
Is anyone still working on this? It's been about 10 months since this
bug was last updated. (Unfortunately I do not have a PHP Build
environment.)
Thanks.
Previous Comments:
[2005-06-21 20:59:48] robert dot sevcik at gmail dot com
Hi, It'd be nice to see it working in php 5.1 because right now I am
developing in php5. I've tried various php5 snaps and 5.0.4 stable
without efect.
I am on a Win2003 server and here is my try-case:
string(1) " "
["len"]=>
int(0)
["bin"]=>
string(1) " "
}
5.1.0-dev
Thank you much :)
*/
?>
[2005-03-31 10:54:11] beschr at free dot fr
Please ignore my precedent comment, the bug is still present in CVS.
I test the mssql.dll today (latest snap: Built On: Mar 29, 2005 16:30
GMT) and the bug is still present.
[2005-03-25 14:54:28] rantal at eoss dot ru
Same problem still exist in php4 snapshot
php4-win32-STABLE-200503230530.zip
[2005-03-17 17:59:57] beschr at free dot fr
I've got this problem too with php 5.0.3 on IIS/Windows XP Pro SP2.
With the mssql.dll of this snaps: Built On: Mar 17, 2005 01:30 GMT it
work great.
So I think the correction in CVs is ok and you can close this bug.
[2005-03-08 01:00:11] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/30962
--
Edit this bug report at http://bugs.php.net/?id=30962&edit=1
#37168 [Opn]: WDDX serializer inefficient with larger structures
ID: 37168
Updated by: [EMAIL PROTECTED]
Reported By: dolecek at sky dot cz
Status: Open
Bug Type: Performance problem
Operating System: NetBSD
PHP Version: 5.1.2
New Comment:
The patch is definitely wrong, as this is just a hack overriding
functions in this particular case only.
Fix the original functions instead (if there are any problems).
Previous Comments:
[2006-04-22 17:49:32] dolecek at sky dot cz
Oh, and the patch 2) should also include the #define SMART_STR_PREALLOC
4192, so that the initial size is power-of-2 (the test result was
run with that part included).
[2006-04-22 17:38:54] dolecek at sky dot cz
The OS was set to NetBSD for this bug report because the tests were run
on NetBSD.
[2006-04-22 17:35:35] dolecek at sky dot cz
Description:
We use WDDX for persistent storage on a project, the production system
runs on MS Windows. The structure is typically small array of several
asociative arrays. We recently noticed that bigger arrays takes
significantly more time to serialize then small ones. Increasing the
size of array twice resulted to about 5-10 times time increase, with
even bigger increase as the size increased.
Problem boils down do smart string API, used by WDDX. WDDX uses it to
store the serialization results.
With default sizes, the initial smart string size is 76 bytes and the
buffer grows only by 128+1 bytes. When the buffer size grows beyond
trivial sizes, the whole smart_string_appendl() et.al. starts being
dominated by the time spend reallocating the buffer, i.e. realloc() and
the associated memory-to-memory copies and CPU cache trashing.
I've tried two strategies to alleviate the problem.
1. increase the buffer grow size to 4192 bytes
2. enforce power-of-2 size of the buffer, and always
at least double the size of buffer
Many malloc()/realloc() implementation optimize power-of-2 sizes, and
the doubling also ensures the total number of calls to realloc() and
associated memory trashing is minimized.
1) helps a lot, but the time increase is still not prortional to the
array size increase.
2) fixes the problem, the time increase is mostly exactly proportional
to the size increase.
Note - the same problem has been observed for standard serializer, i.e.
serialize(). Briefly looking at source it seems the problem is the same
as for WDDX.
Patch for 1):
--- ext/wddx/wddx.c.orig2006-04-22 19:27:19.0 +0200
+++ ext/wddx/wddx.c
@@ -22,6 +22,8 @@
#if HAVE_WDDX
+#define SMART_STR_PREALLOC 4192
+
#include "ext/xml/expat_compat.h"
#include "php_wddx.h"
#include "php_wddx_api.h"
256
Patch for 2):
--- ext/wddx/wddx.c.orig2006-01-01 13:50:16.0 +0100
+++ ext/wddx/wddx.c
@@ -38,2 +44,21 @@
+#undef SMART_STR_DO_REALLOC
+#define SMART_STR_DO_REALLOC(d, what) \
+ (d)->c = SMART_STR_REALLOC((d)->c, (d)->a, (what))
+
+#undef smart_str_alloc4
+#define smart_str_alloc4(d, n, what, newlen) do {
\
+ if (!(d)->c) {
\
+ (d)->len = 0;
\
+ (d)->a = SMART_STR_START_SIZE; \
+ } \
+\
+ newlen = (d)->len + (n);
\
+ if (newlen >= (d)->a || !(d)->c) {
\
+ while((d)->a < newlen+1)
\
+ (d)->a += (d)->a; \
+ SMART_STR_DO_REALLOC(d, what);
\
+ }
\
+} while (0)
+
#define WDDX_BUF_LEN 256
Reproduce code:
---
http://bugs.php.net/?id=37168&edit=1
#37168 [Opn]: WDDX serializer inefficient with larger structures
ID: 37168
User updated by: dolecek at sky dot cz
Reported By: dolecek at sky dot cz
Status: Open
Bug Type: Performance problem
Operating System: NetBSD
PHP Version: 5.1.2
New Comment:
Oh, and the patch 2) should also include the #define SMART_STR_PREALLOC
4192, so that the initial size is power-of-2 (the test result was
run with that part included).
Previous Comments:
[2006-04-22 17:38:54] dolecek at sky dot cz
The OS was set to NetBSD for this bug report because the tests were run
on NetBSD.
[2006-04-22 17:35:35] dolecek at sky dot cz
Description:
We use WDDX for persistent storage on a project, the production system
runs on MS Windows. The structure is typically small array of several
asociative arrays. We recently noticed that bigger arrays takes
significantly more time to serialize then small ones. Increasing the
size of array twice resulted to about 5-10 times time increase, with
even bigger increase as the size increased.
Problem boils down do smart string API, used by WDDX. WDDX uses it to
store the serialization results.
With default sizes, the initial smart string size is 76 bytes and the
buffer grows only by 128+1 bytes. When the buffer size grows beyond
trivial sizes, the whole smart_string_appendl() et.al. starts being
dominated by the time spend reallocating the buffer, i.e. realloc() and
the associated memory-to-memory copies and CPU cache trashing.
I've tried two strategies to alleviate the problem.
1. increase the buffer grow size to 4192 bytes
2. enforce power-of-2 size of the buffer, and always
at least double the size of buffer
Many malloc()/realloc() implementation optimize power-of-2 sizes, and
the doubling also ensures the total number of calls to realloc() and
associated memory trashing is minimized.
1) helps a lot, but the time increase is still not prortional to the
array size increase.
2) fixes the problem, the time increase is mostly exactly proportional
to the size increase.
Note - the same problem has been observed for standard serializer, i.e.
serialize(). Briefly looking at source it seems the problem is the same
as for WDDX.
Patch for 1):
--- ext/wddx/wddx.c.orig2006-04-22 19:27:19.0 +0200
+++ ext/wddx/wddx.c
@@ -22,6 +22,8 @@
#if HAVE_WDDX
+#define SMART_STR_PREALLOC 4192
+
#include "ext/xml/expat_compat.h"
#include "php_wddx.h"
#include "php_wddx_api.h"
256
Patch for 2):
--- ext/wddx/wddx.c.orig2006-01-01 13:50:16.0 +0100
+++ ext/wddx/wddx.c
@@ -38,2 +44,21 @@
+#undef SMART_STR_DO_REALLOC
+#define SMART_STR_DO_REALLOC(d, what) \
+ (d)->c = SMART_STR_REALLOC((d)->c, (d)->a, (what))
+
+#undef smart_str_alloc4
+#define smart_str_alloc4(d, n, what, newlen) do {
\
+ if (!(d)->c) {
\
+ (d)->len = 0;
\
+ (d)->a = SMART_STR_START_SIZE; \
+ } \
+\
+ newlen = (d)->len + (n);
\
+ if (newlen >= (d)->a || !(d)->c) {
\
+ while((d)->a < newlen+1)
\
+ (d)->a += (d)->a; \
+ SMART_STR_DO_REALLOC(d, what);
\
+ }
\
+} while (0)
+
#define WDDX_BUF_LEN 256
Reproduce code:
---
http://bugs.php.net/?id=37168&edit=1
#37167 [Opn->Fbk]: PDO::FETCH_FUNC doesn't work with a callback
ID: 37167 Updated by: [EMAIL PROTECTED] Reported By: troelskn at gmail dot com -Status: Open +Status: Feedback Bug Type: PDO related Operating System: * PHP Version: 5.1.2 New Comment: Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , is max. 10-20 lines long and does not require any external resources such as databases, etc. If possible, make the script source available online and provide an URL to it here. Try to avoid embedding huge scripts into the report. Previous Comments: [2006-04-22 15:30:52] troelskn at gmail dot com Description: Using PDO::FETCH_FUNC with fetchAll() only works with a function. It would be nice if it worked with a normal callback type (as in call_user_func and others). If this can't be fixed, the error message must be changed, since "General error: user-supplied function must be a valid callback" is misleading. -- Edit this bug report at http://bugs.php.net/?id=37167&edit=1
#37118 [Opn->Fbk]: is_file returns false for uploaded file
ID: 37118 Updated by: [EMAIL PROTECTED] Reported By: kimmo dot laine at zarga dot net -Status: Open +Status: Feedback Bug Type: Filesystem function related Operating System: Windows 2003 IIS 6 PHP Version: 5.1.2 New Comment: What do you get if you add var_dump($_FILES['myfile']['tmp_name']); to your code? Previous Comments: [2006-04-18 09:48:25] kimmo dot laine at zarga dot net Description: Running IIS 6 on Windows 2003 server. After an update to the most recent version of php 5.1.2, for some reacon a function handling uploaded using is_file stopped working. is_file failed for existing files. I fixed it by changing is_file to file_exists, then it worked again. Prior to the update, in the older version, presumably it was 5.0.1, is_file worked just fine without problems. Reproduce code: --- Expected result: is_file:truefile_exists:true Actual result: -- is_file:falsefile_exists:true -- Edit this bug report at http://bugs.php.net/?id=37118&edit=1
#37168 [Opn]: WDDX serializer inefficient with larger structures
ID: 37168
User updated by: dolecek at sky dot cz
Reported By: dolecek at sky dot cz
Status: Open
Bug Type: Performance problem
Operating System: NetBSD
PHP Version: 5.1.2
New Comment:
The OS was set to NetBSD for this bug report because the tests were run
on NetBSD.
Previous Comments:
[2006-04-22 17:35:35] dolecek at sky dot cz
Description:
We use WDDX for persistent storage on a project, the production system
runs on MS Windows. The structure is typically small array of several
asociative arrays. We recently noticed that bigger arrays takes
significantly more time to serialize then small ones. Increasing the
size of array twice resulted to about 5-10 times time increase, with
even bigger increase as the size increased.
Problem boils down do smart string API, used by WDDX. WDDX uses it to
store the serialization results.
With default sizes, the initial smart string size is 76 bytes and the
buffer grows only by 128+1 bytes. When the buffer size grows beyond
trivial sizes, the whole smart_string_appendl() et.al. starts being
dominated by the time spend reallocating the buffer, i.e. realloc() and
the associated memory-to-memory copies and CPU cache trashing.
I've tried two strategies to alleviate the problem.
1. increase the buffer grow size to 4192 bytes
2. enforce power-of-2 size of the buffer, and always
at least double the size of buffer
Many malloc()/realloc() implementation optimize power-of-2 sizes, and
the doubling also ensures the total number of calls to realloc() and
associated memory trashing is minimized.
1) helps a lot, but the time increase is still not prortional to the
array size increase.
2) fixes the problem, the time increase is mostly exactly proportional
to the size increase.
Note - the same problem has been observed for standard serializer, i.e.
serialize(). Briefly looking at source it seems the problem is the same
as for WDDX.
Patch for 1):
--- ext/wddx/wddx.c.orig2006-04-22 19:27:19.0 +0200
+++ ext/wddx/wddx.c
@@ -22,6 +22,8 @@
#if HAVE_WDDX
+#define SMART_STR_PREALLOC 4192
+
#include "ext/xml/expat_compat.h"
#include "php_wddx.h"
#include "php_wddx_api.h"
256
Patch for 2):
--- ext/wddx/wddx.c.orig2006-01-01 13:50:16.0 +0100
+++ ext/wddx/wddx.c
@@ -38,2 +44,21 @@
+#undef SMART_STR_DO_REALLOC
+#define SMART_STR_DO_REALLOC(d, what) \
+ (d)->c = SMART_STR_REALLOC((d)->c, (d)->a, (what))
+
+#undef smart_str_alloc4
+#define smart_str_alloc4(d, n, what, newlen) do {
\
+ if (!(d)->c) {
\
+ (d)->len = 0;
\
+ (d)->a = SMART_STR_START_SIZE; \
+ } \
+\
+ newlen = (d)->len + (n);
\
+ if (newlen >= (d)->a || !(d)->c) {
\
+ while((d)->a < newlen+1)
\
+ (d)->a += (d)->a; \
+ SMART_STR_DO_REALLOC(d, what);
\
+ }
\
+} while (0)
+
#define WDDX_BUF_LEN 256
Reproduce code:
---
http://bugs.php.net/?id=37168&edit=1
#37168 [NEW]: WDDX serializer inefficient with larger structures
From: dolecek at sky dot cz
Operating system: NetBSD
PHP version: 5.1.2
PHP Bug Type: Performance problem
Bug description: WDDX serializer inefficient with larger structures
Description:
We use WDDX for persistent storage on a project, the production system
runs on MS Windows. The structure is typically small array of several
asociative arrays. We recently noticed that bigger arrays takes
significantly more time to serialize then small ones. Increasing the size
of array twice resulted to about 5-10 times time increase, with even
bigger increase as the size increased.
Problem boils down do smart string API, used by WDDX. WDDX uses it to
store the serialization results.
With default sizes, the initial smart string size is 76 bytes and the
buffer grows only by 128+1 bytes. When the buffer size grows beyond
trivial sizes, the whole smart_string_appendl() et.al. starts being
dominated by the time spend reallocating the buffer, i.e. realloc() and
the associated memory-to-memory copies and CPU cache trashing.
I've tried two strategies to alleviate the problem.
1. increase the buffer grow size to 4192 bytes
2. enforce power-of-2 size of the buffer, and always
at least double the size of buffer
Many malloc()/realloc() implementation optimize power-of-2 sizes, and the
doubling also ensures the total number of calls to realloc() and
associated memory trashing is minimized.
1) helps a lot, but the time increase is still not prortional to the array
size increase.
2) fixes the problem, the time increase is mostly exactly proportional to
the size increase.
Note - the same problem has been observed for standard serializer, i.e.
serialize(). Briefly looking at source it seems the problem is the same as
for WDDX.
Patch for 1):
--- ext/wddx/wddx.c.orig2006-04-22 19:27:19.0 +0200
+++ ext/wddx/wddx.c
@@ -22,6 +22,8 @@
#if HAVE_WDDX
+#define SMART_STR_PREALLOC 4192
+
#include "ext/xml/expat_compat.h"
#include "php_wddx.h"
#include "php_wddx_api.h"
256
Patch for 2):
--- ext/wddx/wddx.c.orig2006-01-01 13:50:16.0 +0100
+++ ext/wddx/wddx.c
@@ -38,2 +44,21 @@
+#undef SMART_STR_DO_REALLOC
+#define SMART_STR_DO_REALLOC(d, what) \
+ (d)->c = SMART_STR_REALLOC((d)->c, (d)->a, (what))
+
+#undef smart_str_alloc4
+#define smart_str_alloc4(d, n, what, newlen) do {
\
+ if (!(d)->c) {
\
+ (d)->len = 0;
\
+ (d)->a = SMART_STR_START_SIZE; \
+ } \
+\
+ newlen = (d)->len + (n);
\
+ if (newlen >= (d)->a || !(d)->c) {
\
+ while((d)->a < newlen+1)
\
+ (d)->a += (d)->a; \
+ SMART_STR_DO_REALLOC(d, what);
\
+ }
\
+} while (0)
+
#define WDDX_BUF_LEN 256
Reproduce code:
---
http://bugs.php.net/?id=37168&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=37168&r=trysnapshot44
Try a CVS snapshot (PHP 5.1):
http://bugs.php.net/fix.php?id=37168&r=trysnapshot51
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=37168&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=37168&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=37168&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=37168&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=37168&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=37168&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=37168&r=support
Expected behavior:http://bugs.php.net/fix.php?id=37168&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=37168&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=37168&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=37168&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=37168&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=37168&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=37168&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=37168&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=37168&r=float
No Zend Extensions: http://bug
#37158 [Ana->Csd]: if userspace stream is present, fread() reads in 8192 max, otherwise it works
ID: 37158 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Analyzed +Status: Closed Bug Type: Streams related Operating System: n/a PHP Version: 5CVS-2006-04-21 (CVS) Assigned To: wez New Comment: This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. Previous Comments: [2006-04-22 16:02:23] [EMAIL PROTECTED] The following patch corrects the issue: http://y1.php.net/~wez/streams-37158.diff [2006-04-22 15:36:43] [EMAIL PROTECTED] A change was made to wrapper resolution that mean that the plain file wrapper is effectively aliased at alternate locations in memory. This fundamentally breaks the wrapper implementation macros (PHP_STREAM_IS(...)) which absolutely rely on the wrapper structures living at the definitive original address in memory. Other streams core code also relies on this being the case. The fix is to change the wrapper hash tables to store pointers to the wrapper structures instead of having them clone the wrapper structures. The reason this problem only triggered when calling stream_wrapper_register() is that it clones the hash on the first call. This coupled with a change that allows scripts to override file:// causes regular plain file access (even without file://) to lookup the cloned plain file wrapper from the cloned hash. [2006-04-22 14:52:11] [EMAIL PROTECTED] Your example is incomplete, but there was a comment to help to complete it, next time, please provide a complete script :) However, I found the problem, please try: http://pear.php.net/~pierre/check_stream_plainfile_wops.txt [2006-04-22 04:25:13] [EMAIL PROTECTED] "...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. [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. 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/37158 -- Edit this bug report at http://bugs.php.net/?id=37158&edit=1
#37158 [Ana]: if userspace stream is present, fread() reads in 8192 max, otherwise it works
ID: 37158 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Analyzed Bug Type: Streams related Operating System: n/a PHP Version: 5CVS-2006-04-21 (CVS) Assigned To: wez New Comment: The following patch corrects the issue: http://y1.php.net/~wez/streams-37158.diff Previous Comments: [2006-04-22 15:36:43] [EMAIL PROTECTED] A change was made to wrapper resolution that mean that the plain file wrapper is effectively aliased at alternate locations in memory. This fundamentally breaks the wrapper implementation macros (PHP_STREAM_IS(...)) which absolutely rely on the wrapper structures living at the definitive original address in memory. Other streams core code also relies on this being the case. The fix is to change the wrapper hash tables to store pointers to the wrapper structures instead of having them clone the wrapper structures. The reason this problem only triggered when calling stream_wrapper_register() is that it clones the hash on the first call. This coupled with a change that allows scripts to override file:// causes regular plain file access (even without file://) to lookup the cloned plain file wrapper from the cloned hash. [2006-04-22 14:52:11] [EMAIL PROTECTED] Your example is incomplete, but there was a comment to help to complete it, next time, please provide a complete script :) However, I found the problem, please try: http://pear.php.net/~pierre/check_stream_plainfile_wops.txt [2006-04-22 04:25:13] [EMAIL PROTECTED] "...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. [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() 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/37158 -- Edit this bug report at http://bugs.php.net/?id=37158&edit=1
#37158 [Fbk->Ana]: if userspace stream is present, fread() reads in 8192 max, otherwise it works
ID: 37158 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Analyzed Bug Type: Streams related Operating System: n/a PHP Version: 5CVS-2006-04-21 (CVS) -Assigned To: pajoye +Assigned To: wez New Comment: A change was made to wrapper resolution that mean that the plain file wrapper is effectively aliased at alternate locations in memory. This fundamentally breaks the wrapper implementation macros (PHP_STREAM_IS(...)) which absolutely rely on the wrapper structures living at the definitive original address in memory. Other streams core code also relies on this being the case. The fix is to change the wrapper hash tables to store pointers to the wrapper structures instead of having them clone the wrapper structures. The reason this problem only triggered when calling stream_wrapper_register() is that it clones the hash on the first call. This coupled with a change that allows scripts to override file:// causes regular plain file access (even without file://) to lookup the cloned plain file wrapper from the cloned hash. Previous Comments: [2006-04-22 14:52:11] [EMAIL PROTECTED] Your example is incomplete, but there was a comment to help to complete it, next time, please provide a complete script :) However, I found the problem, please try: http://pear.php.net/~pierre/check_stream_plainfile_wops.txt [2006-04-22 04:25:13] [EMAIL PROTECTED] "...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. [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: --- 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=37158&edit=1
#37167 [NEW]: PDO::FETCH_FUNC doesn't work with a callback
From: troelskn at gmail dot com Operating system: * PHP version: 5.1.2 PHP Bug Type: PDO related Bug description: PDO::FETCH_FUNC doesn't work with a callback Description: Using PDO::FETCH_FUNC with fetchAll() only works with a function. It would be nice if it worked with a normal callback type (as in call_user_func and others). If this can't be fixed, the error message must be changed, since "General error: user-supplied function must be a valid callback" is misleading. -- Edit bug report at http://bugs.php.net/?id=37167&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=37167&r=trysnapshot44 Try a CVS snapshot (PHP 5.1): http://bugs.php.net/fix.php?id=37167&r=trysnapshot51 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=37167&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=37167&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=37167&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=37167&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=37167&r=needscript Try newer version:http://bugs.php.net/fix.php?id=37167&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=37167&r=support Expected behavior:http://bugs.php.net/fix.php?id=37167&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=37167&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=37167&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=37167&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=37167&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=37167&r=dst IIS Stability:http://bugs.php.net/fix.php?id=37167&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=37167&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=37167&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=37167&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=37167&r=mysqlcfg
#37159 [Bgs]: imap_fetchstructure returns wrong encoding
ID: 37159 User updated by: oliver dot block at lycos dot de Reported By: oliver dot block at lycos dot de Status: Bogus Bug Type: IMAP related Operating System: Unix PHP Version: 5.1.2 New Comment: workaround: check the header for existing Content-Transfer-Encoding: field if you receive an object returning encoding equal to 5. If there is none, a 7bit encoding should be assumed (according to RFC2045). Best Regards, Oliver Previous Comments: [2006-04-22 13:19:49] oliver dot block at lycos dot de Thanks for your response. I'll do that. Yes, it is a bug. I am sure. [2006-04-22 08:11:54] [EMAIL PROTECTED] This is what IMAP c-client returns to PHP and we can't fix or change it in any way. If you consider it a bug - please report to c-client developers. Thanks. [2006-04-21 22:35:12] oliver dot block at lycos dot de 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 this bug report at http://bugs.php.net/?id=37159&edit=1
#37158 [Opn->Fbk]: 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: Feedback Bug Type: Streams related Operating System: n/a PHP Version: 5CVS-2006-04-21 (CVS) -Assigned To: +Assigned To: pajoye New Comment: Your example is incomplete, but there was a comment to help to complete it, next time, please provide a complete script :) However, I found the problem, please try: http://pear.php.net/~pierre/check_stream_plainfile_wops.txt Previous Comments: [2006-04-22 04:25:13] [EMAIL PROTECTED] "...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. [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: --- 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=37158&edit=1
#37166 [Opn->Bgs]: Detected illegal character in input string.
ID: 37166 Updated by: [EMAIL PROTECTED] Reported By: bogdan at directdesign dot ro -Status: Open +Status: Bogus Bug Type: ICONV related Operating System: windows xp & linux PHP Version: 4.4.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. . Previous Comments: [2006-04-22 14:28:03] bogdan at directdesign dot ro Description: I cannot decode the cross sign () from UTF-8. The iconv() function stops with a notice and does not parse after this sign. Reproduce code: --- Expected result: 123 456 Actual result: -- Notice: iconv(): Detected illegal character in input string in E:\Inetpub\test\bug-cruce.php on line 3 123 PHP Notice: iconv(): Detected illegal character in input string in E:\Inetpub\test\bug-cruce.php on line 3 -- Edit this bug report at http://bugs.php.net/?id=37166&edit=1
#37166 [NEW]: Detected illegal character in input string.
From: bogdan at directdesign dot ro Operating system: windows xp & linux PHP version: 4.4.2 PHP Bug Type: ICONV related Bug description: Detected illegal character in input string. Description: I cannot decode the cross sign () from UTF-8. The iconv() function stops with a notice and does not parse after this sign. Reproduce code: --- Expected result: 123 456 Actual result: -- Notice: iconv(): Detected illegal character in input string in E:\Inetpub\test\bug-cruce.php on line 3 123 PHP Notice: iconv(): Detected illegal character in input string in E:\Inetpub\test\bug-cruce.php on line 3 -- Edit bug report at http://bugs.php.net/?id=37166&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=37166&r=trysnapshot44 Try a CVS snapshot (PHP 5.1): http://bugs.php.net/fix.php?id=37166&r=trysnapshot51 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=37166&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=37166&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=37166&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=37166&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=37166&r=needscript Try newer version:http://bugs.php.net/fix.php?id=37166&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=37166&r=support Expected behavior:http://bugs.php.net/fix.php?id=37166&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=37166&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=37166&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=37166&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=37166&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=37166&r=dst IIS Stability:http://bugs.php.net/fix.php?id=37166&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=37166&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=37166&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=37166&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=37166&r=mysqlcfg
#37165 [Opn->Bgs]: '\n' not same as ord(10)
ID: 37165
Updated by: [EMAIL PROTECTED]
Reported By: plperez at stanford dot edu
-Status: Open
+Status: Bogus
Bug Type: Scripting Engine problem
Operating System: MAC OS X
PHP Version: 4CVS-2006-04-22 (snap)
New Comment:
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
Previous Comments:
[2006-04-22 13:16:48] plperez at stanford dot edu
Description:
'\n' not same as ord(10)
Reproduce code:
---
if ('\n' != ord(10)) echo "oups";
else echo "ok";
Expected result:
ok
Actual result:
--
oups
--
Edit this bug report at http://bugs.php.net/?id=37165&edit=1
#37159 [Bgs]: imap_fetchstructure returns wrong encoding
ID: 37159 User updated by: oliver dot block at lycos dot de Reported By: oliver dot block at lycos dot de Status: Bogus Bug Type: IMAP related Operating System: Unix PHP Version: 5.1.2 New Comment: Thanks for your response. I'll do that. Yes, it is a bug. I am sure. Previous Comments: [2006-04-22 08:11:54] [EMAIL PROTECTED] This is what IMAP c-client returns to PHP and we can't fix or change it in any way. If you consider it a bug - please report to c-client developers. Thanks. [2006-04-21 22:35:12] oliver dot block at lycos dot de 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 this bug report at http://bugs.php.net/?id=37159&edit=1
#37165 [NEW]: '\n' not same as ord(10)
From: plperez at stanford dot edu
Operating system: MAC OS X
PHP version: 4CVS-2006-04-22 (snap)
PHP Bug Type: Scripting Engine problem
Bug description: '\n' not same as ord(10)
Description:
'\n' not same as ord(10)
Reproduce code:
---
if ('\n' != ord(10)) echo "oups";
else echo "ok";
Expected result:
ok
Actual result:
--
oups
--
Edit bug report at http://bugs.php.net/?id=37165&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=37165&r=trysnapshot44
Try a CVS snapshot (PHP 5.1):
http://bugs.php.net/fix.php?id=37165&r=trysnapshot51
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=37165&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=37165&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=37165&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=37165&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=37165&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=37165&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=37165&r=support
Expected behavior:http://bugs.php.net/fix.php?id=37165&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=37165&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=37165&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=37165&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=37165&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=37165&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=37165&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=37165&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=37165&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=37165&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=37165&r=mysqlcfg
#37164 [NEW]: snmp_set_oid_numeric_print does not behave as expected
From: jorrit at ncode dot nl Operating system: Linux PHP version: 4.4.2 PHP Bug Type: SNMP related Bug description: snmp_set_oid_numeric_print does not behave as expected Description: The (undocumented) function snmp_set_oid_numeric_print doesn't behave like expected. If you supply 1 as argument, the oids get returned numerically, as expected, but there is no way to reverse this action, although the function description suggests so (why would you need an argument anyway?). If you look into the c code, you'll see that only the case argument != 0 is handled. -- Edit bug report at http://bugs.php.net/?id=37164&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=37164&r=trysnapshot44 Try a CVS snapshot (PHP 5.1): http://bugs.php.net/fix.php?id=37164&r=trysnapshot51 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=37164&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=37164&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=37164&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=37164&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=37164&r=needscript Try newer version:http://bugs.php.net/fix.php?id=37164&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=37164&r=support Expected behavior:http://bugs.php.net/fix.php?id=37164&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=37164&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=37164&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=37164&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=37164&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=37164&r=dst IIS Stability:http://bugs.php.net/fix.php?id=37164&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=37164&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=37164&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=37164&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=37164&r=mysqlcfg
#37163 [Opn]: timelib_structs.h requires explicit compiler include path setting
ID: 37163 Updated by: [EMAIL PROTECTED] Reported By: jdolecek at NetBSD dot org Status: Open Bug Type: Compile Failure Operating System: NetBSD PHP Version: 5.1.2 New Comment: The posted fix is therefore not correct... Previous Comments: [2006-04-22 10:54:14] [EMAIL PROTECTED] This is correct, and should be fixed in the wddx config.m4 file. [2006-04-22 10:52:40] jdolecek at NetBSD dot org Fix: --- ext/date/lib/timelib_structs.h.orig 2006-04-22 12:51:57.0 +0200 +++ ext/date/lib/timelib_structs.h 2006-04-22 12:52:01.0 +0200 @@ -21,7 +21,7 @@ #ifndef __TIMELIB_STRUCTS_H__ #define __TIMELIB_STRUCTS_H__ -#include +#include "timelib_config.h" #ifdef HAVE_SYS_TYPES_H #include [2006-04-22 10:51:06] jdolecek at NetBSD dot org Description: When php_date.h is used in a module, the build requires the include path of C compiler to be set to include ext/date/lib explicitely. This is due to php_date.h pulling "lib/timelib.h" (this is fine), then timelib.h including "timelib_structs.h" (this is fine too), but timelib_structs.h including (this fails). If this is used in a separately built module (encountered with WDDX when build as an extension), this means the include path for the extension build must be setup to include php/include/ext/date/lib. Reproduce code: --- Build WDDX as separate extension (i.e. not part of PHP build itself). Expected result: Compiles fine Actual result: -- Compile fails with error couldn't find timelib_config.h. -- Edit this bug report at http://bugs.php.net/?id=37163&edit=1
#37163 [Opn]: timelib_structs.h requires explicit compiler include path setting
ID: 37163 Updated by: [EMAIL PROTECTED] Reported By: jdolecek at NetBSD dot org Status: Open Bug Type: Compile Failure Operating System: NetBSD PHP Version: 5.1.2 New Comment: This is correct, and should be fixed in the wddx config.m4 file. Previous Comments: [2006-04-22 10:52:40] jdolecek at NetBSD dot org Fix: --- ext/date/lib/timelib_structs.h.orig 2006-04-22 12:51:57.0 +0200 +++ ext/date/lib/timelib_structs.h 2006-04-22 12:52:01.0 +0200 @@ -21,7 +21,7 @@ #ifndef __TIMELIB_STRUCTS_H__ #define __TIMELIB_STRUCTS_H__ -#include +#include "timelib_config.h" #ifdef HAVE_SYS_TYPES_H #include [2006-04-22 10:51:06] jdolecek at NetBSD dot org Description: When php_date.h is used in a module, the build requires the include path of C compiler to be set to include ext/date/lib explicitely. This is due to php_date.h pulling "lib/timelib.h" (this is fine), then timelib.h including "timelib_structs.h" (this is fine too), but timelib_structs.h including (this fails). If this is used in a separately built module (encountered with WDDX when build as an extension), this means the include path for the extension build must be setup to include php/include/ext/date/lib. Reproduce code: --- Build WDDX as separate extension (i.e. not part of PHP build itself). Expected result: Compiles fine Actual result: -- Compile fails with error couldn't find timelib_config.h. -- Edit this bug report at http://bugs.php.net/?id=37163&edit=1
#37163 [Opn]: timelib_structs.h requires explicit compiler include path setting
ID: 37163 User updated by: jdolecek at NetBSD dot org Reported By: jdolecek at NetBSD dot org Status: Open Bug Type: Compile Failure Operating System: NetBSD PHP Version: 5.1.2 New Comment: Fix: --- ext/date/lib/timelib_structs.h.orig 2006-04-22 12:51:57.0 +0200 +++ ext/date/lib/timelib_structs.h 2006-04-22 12:52:01.0 +0200 @@ -21,7 +21,7 @@ #ifndef __TIMELIB_STRUCTS_H__ #define __TIMELIB_STRUCTS_H__ -#include +#include "timelib_config.h" #ifdef HAVE_SYS_TYPES_H #include Previous Comments: [2006-04-22 10:51:06] jdolecek at NetBSD dot org Description: When php_date.h is used in a module, the build requires the include path of C compiler to be set to include ext/date/lib explicitely. This is due to php_date.h pulling "lib/timelib.h" (this is fine), then timelib.h including "timelib_structs.h" (this is fine too), but timelib_structs.h including (this fails). If this is used in a separately built module (encountered with WDDX when build as an extension), this means the include path for the extension build must be setup to include php/include/ext/date/lib. Reproduce code: --- Build WDDX as separate extension (i.e. not part of PHP build itself). Expected result: Compiles fine Actual result: -- Compile fails with error couldn't find timelib_config.h. -- Edit this bug report at http://bugs.php.net/?id=37163&edit=1
#37163 [NEW]: timelib_structs.h requires explicit compiler include path setting
From: jdolecek at NetBSD dot org Operating system: NetBSD PHP version: 5.1.2 PHP Bug Type: Compile Failure Bug description: timelib_structs.h requires explicit compiler include path setting Description: When php_date.h is used in a module, the build requires the include path of C compiler to be set to include ext/date/lib explicitely. This is due to php_date.h pulling "lib/timelib.h" (this is fine), then timelib.h including "timelib_structs.h" (this is fine too), but timelib_structs.h including (this fails). If this is used in a separately built module (encountered with WDDX when build as an extension), this means the include path for the extension build must be setup to include php/include/ext/date/lib. Reproduce code: --- Build WDDX as separate extension (i.e. not part of PHP build itself). Expected result: Compiles fine Actual result: -- Compile fails with error couldn't find timelib_config.h. -- Edit bug report at http://bugs.php.net/?id=37163&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=37163&r=trysnapshot44 Try a CVS snapshot (PHP 5.1): http://bugs.php.net/fix.php?id=37163&r=trysnapshot51 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=37163&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=37163&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=37163&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=37163&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=37163&r=needscript Try newer version:http://bugs.php.net/fix.php?id=37163&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=37163&r=support Expected behavior:http://bugs.php.net/fix.php?id=37163&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=37163&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=37163&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=37163&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=37163&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=37163&r=dst IIS Stability:http://bugs.php.net/fix.php?id=37163&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=37163&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=37163&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=37163&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=37163&r=mysqlcfg
#37162 [NEW]: WDDX module doesn't build non-bundled
From: jdolecek at NetBSD dot org Operating system: NetBSD PHP version: 5.1.2 PHP Bug Type: WDDX related Bug description: WDDX module doesn't build non-bundled Description: When WDDX module is compiled separately from main PHP build, the module contents are not actually compiled due to #ifdef HAVE_WDDX. Since config.h is not included,HAVE_WDDX is not defined in this case and empty .o file is produced. This problem also affects PHP 4.4.2. Fix is to include config.h on top: --- ext/wddx/wddx.c.orig2006-04-22 12:18:32.0 +0200 +++ ext/wddx/wddx.c @@ -20,2 +20,6 @@ +#ifdef HAVE_CONFIG_H +#include "config.h" +#endif + #include "php.h" Reproduce code: --- Build as separate module (i.e. not compiled into php) and load via extension=wddx.so Expected result: Module loads Actual result: -- php prints warning when loading the extension: PHP Warning: Unknown(): Invalid library (maybe not a PHP library) 'wddx.so' in Unknown on line 0 -- Edit bug report at http://bugs.php.net/?id=37162&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=37162&r=trysnapshot44 Try a CVS snapshot (PHP 5.1): http://bugs.php.net/fix.php?id=37162&r=trysnapshot51 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=37162&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=37162&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=37162&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=37162&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=37162&r=needscript Try newer version:http://bugs.php.net/fix.php?id=37162&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=37162&r=support Expected behavior:http://bugs.php.net/fix.php?id=37162&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=37162&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=37162&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=37162&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=37162&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=37162&r=dst IIS Stability:http://bugs.php.net/fix.php?id=37162&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=37162&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=37162&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=37162&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=37162&r=mysqlcfg
#36807 [NoF->Opn]: CLI crashes unter win32
ID: 36807 User updated by: spam2 at rhsoft dot net Reported By: spam2 at rhsoft dot net -Status: No Feedback +Status: Open Bug Type: Reproducible crash Operating System: Windows XP -PHP Version: 5.1.3RC1 +PHP Version: 5.1.3RC4 New Comment: I have tried no many Configurations The Problem seems only to exist if php_tidy.dll is loaded Whe i uncomment it the following script is running, if tidy is loaded it will crash after a few seconds Previous Comments: [2006-04-18 01:00:01] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2006-04-10 12:37:26] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php for *NIX and http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32 Once you have generated a backtrace, please submit it to this bug report and change the status back to "Open". Thank you for helping us make PHP better. [2006-04-10 02:50:52] spam2 at rhsoft dot net Is there any solution fpr this problem? I cant use 5.1.3dev because i need cli in many cases on my development machine :-( [2006-03-22 11:04:52] spam2 at rhsoft dot net A example on my computers is a simple "pear upgrade-all", after few seconds php-cli crashs The other scripts are also much bigger than 20 lines because uses a library with 5000 lines and some wrappers one of them is a db-class for mysql/pgsql/mssql who makes it possible to connect to one mysqlserver, create a table dump and excute each insert directly on a second server or buffer the dump, create single files and generate a zip with them and save it to a backup-folder. --- The last days the following script crashs after a longer time also [2006-03-20 23:25:38] spam2 at rhsoft dot net Description: The latest snapshots for win32 crashs (only the cli) Not only one - all my scripts who will alter or backup databases for a batch-command on windows will crash down if running in command line interface - same skripts over apache2handler works normal. Some snapshots before the problem went away but it exists also in an earlier build of 5.1.3dev Reproduce code: --- Sorry not possible -- Edit this bug report at http://bugs.php.net/?id=36807&edit=1
#37159 [Opn->Bgs]: imap_fetchstructure returns wrong encoding
ID: 37159 Updated by: [EMAIL PROTECTED] Reported By: oliver dot block at lycos dot de -Status: Open +Status: Bogus Bug Type: IMAP related Operating System: Unix PHP Version: 5.1.2 New Comment: This is what IMAP c-client returns to PHP and we can't fix or change it in any way. If you consider it a bug - please report to c-client developers. Thanks. Previous Comments: [2006-04-21 22:35:12] oliver dot block at lycos dot de 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 this bug report at http://bugs.php.net/?id=37159&edit=1
#37161 [Opn->Csd]: MD5 test on downloadable tarball
ID: 37161 Updated by: [EMAIL PROTECTED] Reported By: fletch at brightsparks dot net dot au -Status: Open +Status: Closed Bug Type: Unknown/Other Function Operating System: Slackware Linux PHP Version: 4.4.2 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. This will be fixed in the next release apparently. Previous Comments: [2006-04-22 06:40:03] fletch at brightsparks dot net dot au Description: Hi. PHP 4.4.2 seems to have files in pear/packages that fail the MD5 test when doing a "make install". This was mentioned in Bug ##36002 and it is apparently fixed in the CVS tree, but the main downloadable tarball hasn't been updated. Since most people will be downloading this tarball rather than grabbing from CVS, this is still effectivly broken. -- Edit this bug report at http://bugs.php.net/?id=37161&edit=1
#37160 [Opn->Bgs]: help! my band website postcard page doesn't work!
ID: 37160 Updated by: [EMAIL PROTECTED] Reported By: jzerony at aol dot com -Status: Open +Status: Bogus Bug Type: Performance problem Operating System: windows 98 PHP Version: 4.4.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. Previous Comments: [2006-04-22 02:22:43] jzerony at aol dot com 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 this bug report at http://bugs.php.net/?id=37160&edit=1
