#48187 [NEW]: DateTime::diff() corrupting microtime() result
From: wavetrex at gmail dot com Operating system: Windows 2003 Server PHP version: 5.3.0RC2 PHP Bug Type: Date/time related Bug description: DateTime::diff() corrupting microtime() result Description: calling DateTime::diff() seems to corrupt the result returned by microtime(), so it returns the wrong time after this function has been called Reproduce code: --- "; var_dump(microtime()); var_dump(time()); var_dump(date(DATE_ATOM)); var_dump($date1->diff($date2)); var_dump(microtime()); var_dump(time()); var_dump(date(DATE_ATOM)); echo ""; ?> Expected result: Expecting the 2nd microtime to be slightly bigger ( by a few miliseconds ) than first. instead, it's a totally wrong 5 seconds distance (or maybe other arbitrary value) date() and time() seem to be unaffected Actual result: -- before calling diff: string(21) "0.98425000 1241761004" after it: string(21) "0.25882200 1241709345" -- Edit bug report at http://bugs.php.net/?id=48187&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=48187&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=48187&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=48187&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=48187&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=48187&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=48187&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=48187&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=48187&r=needscript Try newer version: http://bugs.php.net/fix.php?id=48187&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=48187&r=support Expected behavior: http://bugs.php.net/fix.php?id=48187&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=48187&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=48187&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=48187&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48187&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=48187&r=dst IIS Stability: http://bugs.php.net/fix.php?id=48187&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=48187&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=48187&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=48187&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=48187&r=mysqlcfg
#48186 [NEW]: Symbol with code 0 in the 255 position of a string
From: aiskrenkov at gmail dot com
Operating system: Windows
PHP version: 5.2.9
PHP Bug Type: ODBC related
Bug description: Symbol with code 0 in the 255 position of a string
Description:
Environment:
Windows Server 2003 EE
MS SQL server 8.0.818 (MSDE 2000)
PHP 5.2.6(or high) as ISAPI or cli
I have a table 'session':
[id] [char](32) NOT NULL DEFAULT (''),
[expiry] [bigint] NOT NULL DEFAULT ('0'),
[data] [ntext] NOT NULL DEFAULT ('')
When I retrive data from table and size of data more then 255 bytes, I
found symbol with code 0(as EOL for strings) in the 255 position of the
string.
Reproduce code:
---
query("delete from session");
$string = '--';
$string .=
'123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890';
$string .= '--';
echo 'Length of source string: '.strlen($string)."\n";
$query = $pdo->query("insert into session values('".md5(time())."',
".time().", '".$string."')");
var_dump($query);
$rowset = $pdo->query("select * from session");
if($rowset === false) {
var_dump($pdo->errorInfo());
}
var_dump($rowset);
$string = $rowset->fetchAll();
//$string = $rowset->fetchColumn(2);
var_dump($string);
echo 'Length of target string: '.strlen($string[0][2])."\n";
?>
Expected result:
123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890
Actual result:
--
1234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123_45678901234567890123456789012345678901234567890
--
Edit bug report at http://bugs.php.net/?id=48186&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=48186&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=48186&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=48186&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=48186&r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=48186&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=48186&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=48186&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=48186&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=48186&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=48186&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=48186&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=48186&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=48186&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=48186&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48186&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=48186&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=48186&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=48186&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=48186&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=48186&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=48186&r=mysqlcfg
#48180 [Fbk->Opn]: mb_ereg(i)_replace() evaluate replacement string vulnerability
ID: 48180
User updated by: 5up3rh3i at gmail dot com
Reported By: 5up3rh3i at gmail dot com
-Status: Feedback
+Status: Open
Bug Type: mbstring related
Operating System: *
PHP Version: 5.2.9
New Comment:
plz try this code too
why matches escaped in preg_replace(), but mb_ereg__replace() not?
Previous Comments:
[2009-05-07 22:41:03] j...@php.net
Yes, it works fine now. What's the bug?
[2009-05-07 16:21:33] 5up3rh3i at gmail dot com
plz try this code
[2009-05-07 16:20:54] 5up3rh3i at gmail dot com
Sorry, the test code is woring
[2009-05-07 16:15:56] j...@php.net
PHP Parse error: syntax error, unexpected T_LNUMBER, expecting
T_STRING
in /home/jani/t.php on line 3
[2009-05-07 14:54:22] 5up3rh3i at gmail dot com
Description:
when option parameter set e, matches not be escaped.
ex:
phpinfo() will be evaluated.
mb_ereg_replace()
if ((replace_len - i) >= 2 && fwd == 1 &&
p[0] == '\\' && p[1] >= '0' && p[1] <=
'9') {
n = p[1] - '0';
}
if (n >= 0 && n < regs->num_regs) {
if (regs->beg[n] >= 0 && regs->beg[n] <
regs->end[n] &&
regs->end[n] <= string_len) {
smart_str_appendl(pbuf, string
+ regs->beg[n], regs->end[n] -
regs->beg[n]);
// matches not be escaped
}
preg_replace()
if ('\\' == *walk || '$' == *walk) {
smart_str_appendl(&code, segment, walk - segment);
if (walk_last == '\\') {
code.c[code.len-1] = *walk++;
segment = walk;
walk_last = 0;
continue;
}
segment = walk;
if (preg_get_backref(&walk, &backref)) {
if (backref < count) {
/* Find the corresponding string match
and substitute it
in instead of the backref */
match = subject + offsets[backref<<1];
match_len = offsets[(backref<<1)+1] -
offsets[backref<<1];
if (match_len) {
esc_match =
php_addslashes_ex(match, match_len, &esc_match_len,
0, 1 TSRMLS_CC);
// matches escaped by addslashes()
...
smart_str_appendl(&code, esc_match,
esc_match_len);
--
Edit this bug report at http://bugs.php.net/?id=48180&edit=1
#48185 [Asn->Csd]: warning: value computed is not used in pdo_sqlite_stmt_get_col line 271
ID: 48185
Updated by: mbecc...@php.net
Reported By: mbecc...@php.net
-Status: Assigned
+Status: Closed
Bug Type: PDO related
Operating System: *
PHP Version: 5.3CVS-2009-05-07 (CVS)
Assigned To: mbeccati
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:
[2009-05-07 22:58:55] mbecc...@php.net
Looks like this:
if (*len) {
/* sqlite3.h says "the NUL terminator is included in the byte
count
* for TEXT values" */
*len--;
}
is not needed (anymore?) as sqlite3_column_bytes() is already returning
the correct number of bytes. So fixing the warning by using (*len)--
would in fact break PDO_Sqlite.
[2009-05-07 22:46:23] mbecc...@php.net
Description:
Reported here:
http://gcov.php.net/viewer.php?version=PHP_5_3&func=compile_results
--
Edit this bug report at http://bugs.php.net/?id=48185&edit=1
#48185 [Asn]: warning: value computed is not used in pdo_sqlite_stmt_get_col line 271
ID: 48185
Updated by: mbecc...@php.net
Reported By: mbecc...@php.net
Status: Assigned
Bug Type: PDO related
Operating System: *
PHP Version: 5.3CVS-2009-05-07 (CVS)
Assigned To: mbeccati
New Comment:
Looks like this:
if (*len) {
/* sqlite3.h says "the NUL terminator is included in the byte
count
* for TEXT values" */
*len--;
}
is not needed (anymore?) as sqlite3_column_bytes() is already returning
the correct number of bytes. So fixing the warning by using (*len)--
would in fact break PDO_Sqlite.
Previous Comments:
[2009-05-07 22:46:23] mbecc...@php.net
Description:
Reported here:
http://gcov.php.net/viewer.php?version=PHP_5_3&func=compile_results
--
Edit this bug report at http://bugs.php.net/?id=48185&edit=1
#48185 [Opn->Asn]: warning: value computed is not used in pdo_sqlite_stmt_get_col line 271
ID: 48185 Updated by: mbecc...@php.net Reported By: mbecc...@php.net -Status: Open +Status: Assigned Bug Type: PDO related Operating System: * PHP Version: 5.3CVS-2009-05-07 (CVS) -Assigned To: +Assigned To: mbeccati Previous Comments: [2009-05-07 22:46:23] mbecc...@php.net Description: Reported here: http://gcov.php.net/viewer.php?version=PHP_5_3&func=compile_results -- Edit this bug report at http://bugs.php.net/?id=48185&edit=1
#48184 [Asn->Csd]: Missing extensions and so
ID: 48184 Updated by: paj...@php.net Reported By: tyra3l at gmail dot com -Status: Assigned +Status: Closed Bug Type: Dynamic loading Operating System: win32 only - Windows XP SP3 PHP Version: 5.3.0RC2 Assigned To: pajoye New Comment: Add the php directory to your PATH (first in it :) Previous Comments: [2009-05-07 22:43:58] tyra3l at gmail dot com About the intl extension: If I move the following dlls: icudt36.dll icuin36.dll icuio36.dll icule36.dll iculx36.dll icutu36.dll icuuc36.dll from the php directory to the apache/bin, then it works. this is my fault, how/where can I tell the php, that where should it search the extensions dll dependecy? Tyrael [2009-05-07 21:35:20] tyra3l at gmail dot com curl is working with the updated package. mssql, and pdo_mssql are removed now, but they weren't removed from the php.ini. also it seems that enchant was shipped with RC1(and mentioned on the release note), but the php.ini hasn't note it in the extensions, and now its gone with RC2. what happened with it? Its my biggest problem (after you fixed the curl extension, of course :)), that the php.ini isn't reflect the situation about the shipped/packaged extensions. thanks for your time and effort. Tyrael [2009-05-07 20:43:36] paj...@php.net Please retry :) [2009-05-07 19:26:51] tyra3l at gmail dot com Ok, I know about the db drivers dependency, but if you can mention this about the oracle driver, it should be noted for the others too. The lines about the built-in and the not-supported-yet modules should be removed, so the php.ini and the actual extension should be kept in sync imho. If the exif ext depends on the mbstring, then it should be put after that. Could this mean, that we could have some cycle reference error about the extensions loading preference, for example: If A depends on B and B on C and C on A, then it can be loaded? Sorry for asking stopid questions. :/ ps: Can I get/build somehow the curl module for myself, or it wont work with the current RC? Tyrael [2009-05-07 19:14:08] paj...@php.net In short, I will repackage it without mssql as it makes no sense to bundle it as it is not support anymore in 5.3. Thanks for your quick test&report! The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/48184 -- Edit this bug report at http://bugs.php.net/?id=48184&edit=1
#48185 [NEW]: warning: value computed is not used in pdo_sqlite_stmt_get_col line 271
From: mbecc...@php.net Operating system: * PHP version: 5.3CVS-2009-05-07 (CVS) PHP Bug Type: PDO related Bug description: warning: value computed is not used in pdo_sqlite_stmt_get_col line 271 Description: Reported here: http://gcov.php.net/viewer.php?version=PHP_5_3&func=compile_results -- Edit bug report at http://bugs.php.net/?id=48185&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=48185&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=48185&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=48185&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=48185&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=48185&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=48185&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=48185&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=48185&r=needscript Try newer version: http://bugs.php.net/fix.php?id=48185&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=48185&r=support Expected behavior: http://bugs.php.net/fix.php?id=48185&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=48185&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=48185&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=48185&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48185&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=48185&r=dst IIS Stability: http://bugs.php.net/fix.php?id=48185&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=48185&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=48185&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=48185&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=48185&r=mysqlcfg
#48184 [Asn]: Missing extensions and so
ID: 48184 User updated by: tyra3l at gmail dot com Reported By: tyra3l at gmail dot com Status: Assigned Bug Type: Dynamic loading Operating System: win32 only - Windows XP SP3 PHP Version: 5.3.0RC2 Assigned To: pajoye New Comment: About the intl extension: If I move the following dlls: icudt36.dll icuin36.dll icuio36.dll icule36.dll iculx36.dll icutu36.dll icuuc36.dll from the php directory to the apache/bin, then it works. this is my fault, how/where can I tell the php, that where should it search the extensions dll dependecy? Tyrael Previous Comments: [2009-05-07 21:35:20] tyra3l at gmail dot com curl is working with the updated package. mssql, and pdo_mssql are removed now, but they weren't removed from the php.ini. also it seems that enchant was shipped with RC1(and mentioned on the release note), but the php.ini hasn't note it in the extensions, and now its gone with RC2. what happened with it? Its my biggest problem (after you fixed the curl extension, of course :)), that the php.ini isn't reflect the situation about the shipped/packaged extensions. thanks for your time and effort. Tyrael [2009-05-07 20:43:36] paj...@php.net Please retry :) [2009-05-07 19:26:51] tyra3l at gmail dot com Ok, I know about the db drivers dependency, but if you can mention this about the oracle driver, it should be noted for the others too. The lines about the built-in and the not-supported-yet modules should be removed, so the php.ini and the actual extension should be kept in sync imho. If the exif ext depends on the mbstring, then it should be put after that. Could this mean, that we could have some cycle reference error about the extensions loading preference, for example: If A depends on B and B on C and C on A, then it can be loaded? Sorry for asking stopid questions. :/ ps: Can I get/build somehow the curl module for myself, or it wont work with the current RC? Tyrael [2009-05-07 19:14:08] paj...@php.net In short, I will repackage it without mssql as it makes no sense to bundle it as it is not support anymore in 5.3. Thanks for your quick test&report! [2009-05-07 19:13:13] paj...@php.net php -m output: [PHP Modules] bcmath calendar com_dotnet Core ctype date dom ereg filter ftp hash iconv json libxml mcrypt mhash mysqlnd odbc pcre PDO Phar Reflection session SimpleXML SPL standard tokenizer wddx xml xmlreader xmlwriter zip zlib And the one I miss: > php_dba.dll => missing not supported yet. > php_exif.dll => missing php_mbstring.dll (weird) It depends on mbstring, load mbsring first. See the manual. > php_gmp.dll => missing not support yet. > php_intl.dll => missing icuuc36.dll it is in the archive. 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/48184 -- Edit this bug report at http://bugs.php.net/?id=48184&edit=1
#48134 [Opn->Fbk]: php crash after a few days (backtrace attached) with worker MPM
ID: 48134 Updated by: j...@php.net Reported By: jimbobpalmer at gmail dot com -Status: Open +Status: Feedback Bug Type: Apache2 related Operating System: * (ZTS only) PHP Version: 5.2.9 New Comment: Can you just try with prefork MPM so we can make the list of possible issues a bit shorter..? And yes, supposedly PHP is thread safe, just some libraries might not be and of course there might be bugs in PHP. Previous Comments: [2009-05-07 19:08:55] jimbobpalmer at gmail dot com Is php not thread safe? [2009-05-07 14:00:49] j...@php.net That explains it. You propably wouldn't have any problems if you didn't use threaded MPM. Try the more stable prefork MPM instead. [2009-05-07 13:44:47] jimbobpalmer at gmail dot com Worker MPM + apache2handler [2009-05-07 13:19:30] j...@php.net Exactly what MPM are you using and what PHP SAPI module? [2009-05-07 13:10:00] jimbobpalmer at gmail dot com Yes. Both apache and php are compiled with debug. 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/48134 -- Edit this bug report at http://bugs.php.net/?id=48134&edit=1
#48180 [Opn->Fbk]: mb_ereg(i)_replace() evaluate replacement string vulnerability
ID: 48180
Updated by: j...@php.net
Reported By: 5up3rh3i at gmail dot com
-Status: Open
+Status: Feedback
Bug Type: mbstring related
Operating System: *
PHP Version: 5.2.9
New Comment:
Yes, it works fine now. What's the bug?
Previous Comments:
[2009-05-07 16:21:33] 5up3rh3i at gmail dot com
plz try this code
[2009-05-07 16:20:54] 5up3rh3i at gmail dot com
Sorry, the test code is woring
[2009-05-07 16:15:56] j...@php.net
PHP Parse error: syntax error, unexpected T_LNUMBER, expecting
T_STRING
in /home/jani/t.php on line 3
[2009-05-07 14:54:22] 5up3rh3i at gmail dot com
Description:
when option parameter set e, matches not be escaped.
ex:
phpinfo() will be evaluated.
mb_ereg_replace()
if ((replace_len - i) >= 2 && fwd == 1 &&
p[0] == '\\' && p[1] >= '0' && p[1] <=
'9') {
n = p[1] - '0';
}
if (n >= 0 && n < regs->num_regs) {
if (regs->beg[n] >= 0 && regs->beg[n] <
regs->end[n] &&
regs->end[n] <= string_len) {
smart_str_appendl(pbuf, string
+ regs->beg[n], regs->end[n] -
regs->beg[n]);
// matches not be escaped
}
preg_replace()
if ('\\' == *walk || '$' == *walk) {
smart_str_appendl(&code, segment, walk - segment);
if (walk_last == '\\') {
code.c[code.len-1] = *walk++;
segment = walk;
walk_last = 0;
continue;
}
segment = walk;
if (preg_get_backref(&walk, &backref)) {
if (backref < count) {
/* Find the corresponding string match
and substitute it
in instead of the backref */
match = subject + offsets[backref<<1];
match_len = offsets[(backref<<1)+1] -
offsets[backref<<1];
if (match_len) {
esc_match =
php_addslashes_ex(match, match_len, &esc_match_len,
0, 1 TSRMLS_CC);
// matches escaped by addslashes()
...
smart_str_appendl(&code, esc_match,
esc_match_len);
--
Edit this bug report at http://bugs.php.net/?id=48180&edit=1
#48184 [Opn->Asn]: Missing extensions and so
ID: 48184 Updated by: j...@php.net Reported By: tyra3l at gmail dot com -Status: Open +Status: Assigned -Bug Type: *Configuration Issues +Bug Type: Dynamic loading -Operating System: Windows XP SP3 +Operating System: win32 only - Windows XP SP3 PHP Version: 5.3.0RC2 Assigned To: pajoye Previous Comments: [2009-05-07 21:35:20] tyra3l at gmail dot com curl is working with the updated package. mssql, and pdo_mssql are removed now, but they weren't removed from the php.ini. also it seems that enchant was shipped with RC1(and mentioned on the release note), but the php.ini hasn't note it in the extensions, and now its gone with RC2. what happened with it? Its my biggest problem (after you fixed the curl extension, of course :)), that the php.ini isn't reflect the situation about the shipped/packaged extensions. thanks for your time and effort. Tyrael [2009-05-07 20:43:36] paj...@php.net Please retry :) [2009-05-07 19:26:51] tyra3l at gmail dot com Ok, I know about the db drivers dependency, but if you can mention this about the oracle driver, it should be noted for the others too. The lines about the built-in and the not-supported-yet modules should be removed, so the php.ini and the actual extension should be kept in sync imho. If the exif ext depends on the mbstring, then it should be put after that. Could this mean, that we could have some cycle reference error about the extensions loading preference, for example: If A depends on B and B on C and C on A, then it can be loaded? Sorry for asking stopid questions. :/ ps: Can I get/build somehow the curl module for myself, or it wont work with the current RC? Tyrael [2009-05-07 19:14:08] paj...@php.net In short, I will repackage it without mssql as it makes no sense to bundle it as it is not support anymore in 5.3. Thanks for your quick test&report! [2009-05-07 19:13:13] paj...@php.net php -m output: [PHP Modules] bcmath calendar com_dotnet Core ctype date dom ereg filter ftp hash iconv json libxml mcrypt mhash mysqlnd odbc pcre PDO Phar Reflection session SimpleXML SPL standard tokenizer wddx xml xmlreader xmlwriter zip zlib And the one I miss: > php_dba.dll => missing not supported yet. > php_exif.dll => missing php_mbstring.dll (weird) It depends on mbstring, load mbsring first. See the manual. > php_gmp.dll => missing not support yet. > php_intl.dll => missing icuuc36.dll it is in the archive. 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/48184 -- Edit this bug report at http://bugs.php.net/?id=48184&edit=1
#48184 [Fbk->Opn]: Missing extensions and so
ID: 48184 User updated by: tyra3l at gmail dot com Reported By: tyra3l at gmail dot com -Status: Feedback +Status: Open Bug Type: *Configuration Issues Operating System: Windows XP SP3 PHP Version: 5.3.0RC2 Assigned To: pajoye New Comment: curl is working with the updated package. mssql, and pdo_mssql are removed now, but they weren't removed from the php.ini. also it seems that enchant was shipped with RC1(and mentioned on the release note), but the php.ini hasn't note it in the extensions, and now its gone with RC2. what happened with it? Its my biggest problem (after you fixed the curl extension, of course :)), that the php.ini isn't reflect the situation about the shipped/packaged extensions. thanks for your time and effort. Tyrael Previous Comments: [2009-05-07 20:43:36] paj...@php.net Please retry :) [2009-05-07 19:26:51] tyra3l at gmail dot com Ok, I know about the db drivers dependency, but if you can mention this about the oracle driver, it should be noted for the others too. The lines about the built-in and the not-supported-yet modules should be removed, so the php.ini and the actual extension should be kept in sync imho. If the exif ext depends on the mbstring, then it should be put after that. Could this mean, that we could have some cycle reference error about the extensions loading preference, for example: If A depends on B and B on C and C on A, then it can be loaded? Sorry for asking stopid questions. :/ ps: Can I get/build somehow the curl module for myself, or it wont work with the current RC? Tyrael [2009-05-07 19:14:08] paj...@php.net In short, I will repackage it without mssql as it makes no sense to bundle it as it is not support anymore in 5.3. Thanks for your quick test&report! [2009-05-07 19:13:13] paj...@php.net php -m output: [PHP Modules] bcmath calendar com_dotnet Core ctype date dom ereg filter ftp hash iconv json libxml mcrypt mhash mysqlnd odbc pcre PDO Phar Reflection session SimpleXML SPL standard tokenizer wddx xml xmlreader xmlwriter zip zlib And the one I miss: > php_dba.dll => missing not supported yet. > php_exif.dll => missing php_mbstring.dll (weird) It depends on mbstring, load mbsring first. See the manual. > php_gmp.dll => missing not support yet. > php_intl.dll => missing icuuc36.dll it is in the archive. [2009-05-07 19:09:23] paj...@php.net php_curl.dll => missing zlib.dll php_dba.dll => missing php_exif.dll => missing php_mbstring.dll (weird) php_gmp.dll => missing php_intl.dll => missing icuuc36.dll > php_interbase.dll => missing gds32.dll not supported yet. > php_mime_magic.dll => missing > php_ming.dll => missing moved to pecl > php_mssql.dll => missing ntwdblib.dll not available anymore, my mistake I should have disabled it. > php_oci8.dll => missing OCI.dll You have to install the OCI client. See the manual. > php_oci8_11g.dll => missing OCI.dll Same as oci8 but using the client version 11.x. > php_pdo_firebird.dll => missing gds32.dll Not supported yet. > php_pdo_mssql.dll => missing ntwdblib.dll not available anymore, my mistake I should have disabled it. > php_pdo_oci.dll => missing OCI.dll Same as oci8 > php_pdo_pgsql.dll => missing LIBPQ.dll It is present in the archive. > php_pgsql.dll => missing LIBPQ.dll It is present in the archive. > php_phar.dll => missing builtin > php_pspell.dll => aspell-15.dll not supported anymore. > php_snmp.dll => missing not supported yet. > php_sybase_ct.dll => missing libcs.dll You have to install the sybase client. > php_zip.dll => missing builtin. For builtin module: run php -m to see them. 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/48184 -- Edit this bug report at http://bugs.php.net/?id=48184&edit=1
#48184 [Ana->Fbk]: Missing extensions and so
ID: 48184 Updated by: paj...@php.net Reported By: tyra3l at gmail dot com -Status: Analyzed +Status: Feedback Bug Type: *Configuration Issues Operating System: Windows XP SP3 PHP Version: 5.3.0RC2 Assigned To: pajoye New Comment: Please retry :) Previous Comments: [2009-05-07 19:26:51] tyra3l at gmail dot com Ok, I know about the db drivers dependency, but if you can mention this about the oracle driver, it should be noted for the others too. The lines about the built-in and the not-supported-yet modules should be removed, so the php.ini and the actual extension should be kept in sync imho. If the exif ext depends on the mbstring, then it should be put after that. Could this mean, that we could have some cycle reference error about the extensions loading preference, for example: If A depends on B and B on C and C on A, then it can be loaded? Sorry for asking stopid questions. :/ ps: Can I get/build somehow the curl module for myself, or it wont work with the current RC? Tyrael [2009-05-07 19:14:08] paj...@php.net In short, I will repackage it without mssql as it makes no sense to bundle it as it is not support anymore in 5.3. Thanks for your quick test&report! [2009-05-07 19:13:13] paj...@php.net php -m output: [PHP Modules] bcmath calendar com_dotnet Core ctype date dom ereg filter ftp hash iconv json libxml mcrypt mhash mysqlnd odbc pcre PDO Phar Reflection session SimpleXML SPL standard tokenizer wddx xml xmlreader xmlwriter zip zlib And the one I miss: > php_dba.dll => missing not supported yet. > php_exif.dll => missing php_mbstring.dll (weird) It depends on mbstring, load mbsring first. See the manual. > php_gmp.dll => missing not support yet. > php_intl.dll => missing icuuc36.dll it is in the archive. [2009-05-07 19:09:23] paj...@php.net php_curl.dll => missing zlib.dll php_dba.dll => missing php_exif.dll => missing php_mbstring.dll (weird) php_gmp.dll => missing php_intl.dll => missing icuuc36.dll > php_interbase.dll => missing gds32.dll not supported yet. > php_mime_magic.dll => missing > php_ming.dll => missing moved to pecl > php_mssql.dll => missing ntwdblib.dll not available anymore, my mistake I should have disabled it. > php_oci8.dll => missing OCI.dll You have to install the OCI client. See the manual. > php_oci8_11g.dll => missing OCI.dll Same as oci8 but using the client version 11.x. > php_pdo_firebird.dll => missing gds32.dll Not supported yet. > php_pdo_mssql.dll => missing ntwdblib.dll not available anymore, my mistake I should have disabled it. > php_pdo_oci.dll => missing OCI.dll Same as oci8 > php_pdo_pgsql.dll => missing LIBPQ.dll It is present in the archive. > php_pgsql.dll => missing LIBPQ.dll It is present in the archive. > php_phar.dll => missing builtin > php_pspell.dll => aspell-15.dll not supported anymore. > php_snmp.dll => missing not supported yet. > php_sybase_ct.dll => missing libcs.dll You have to install the sybase client. > php_zip.dll => missing builtin. For builtin module: run php -m to see them. [2009-05-07 18:31:44] tyra3l at gmail dot com Description: Problems with the default php extensions in the example php.ini.* Reproduce code: --- Try to enable the modules. Expected result: We should only have the shipped extensions in the php.ini by default, and every module should be working (which doesn't have some 3rd party dependency) Actual result: -- php_curl.dll => missing zlib.dll php_dba.dll => missing php_exif.dll => missing php_mbstring.dll (weird) php_gmp.dll => missing php_intl.dll => missing icuuc36.dll php_interbase.dll => missing gds32.dll php_mime_magic.dll => missing php_ming.dll => missing php_mssql.dll => missing ntwdblib.dll php_oci8.dll => missing OCI.dll php_oci8_11g.dll => missing OCI.dll php_pdo_firebird.dll => missing gds32.dll php_pdo_mssql.dll => missing ntwdblib.dll php_pdo_oci.dll => missing OCI.dll php_pdo_pgsql.dll => missing LIBPQ.dll php_pgsql.dll => missing LIBPQ.dll php_phar.dll => missing php_pspell.dll => aspell-15.dll php_snmp.dll => missing php_sybase_ct.dll => missing libcs.dll php_zip.dll => missing As far as I can see: - the config contains extensions, which isn't shipped - the config contains extensions, which are shipped, but cannot be loaded without the proper third party lib. - some exts are broken (curl was working fine in the RC1) I think that the lines without the extension should be removed, the lines with an ext which has dependency should be noted like with
#48184 [Ana]: Missing extensions and so
ID: 48184 User updated by: tyra3l at gmail dot com Reported By: tyra3l at gmail dot com Status: Analyzed Bug Type: *Configuration Issues Operating System: Windows XP SP3 PHP Version: 5.3.0RC2 Assigned To: pajoye New Comment: Ok, I know about the db drivers dependency, but if you can mention this about the oracle driver, it should be noted for the others too. The lines about the built-in and the not-supported-yet modules should be removed, so the php.ini and the actual extension should be kept in sync imho. If the exif ext depends on the mbstring, then it should be put after that. Could this mean, that we could have some cycle reference error about the extensions loading preference, for example: If A depends on B and B on C and C on A, then it can be loaded? Sorry for asking stopid questions. :/ ps: Can I get/build somehow the curl module for myself, or it wont work with the current RC? Tyrael Previous Comments: [2009-05-07 19:14:08] paj...@php.net In short, I will repackage it without mssql as it makes no sense to bundle it as it is not support anymore in 5.3. Thanks for your quick test&report! [2009-05-07 19:13:13] paj...@php.net php -m output: [PHP Modules] bcmath calendar com_dotnet Core ctype date dom ereg filter ftp hash iconv json libxml mcrypt mhash mysqlnd odbc pcre PDO Phar Reflection session SimpleXML SPL standard tokenizer wddx xml xmlreader xmlwriter zip zlib And the one I miss: > php_dba.dll => missing not supported yet. > php_exif.dll => missing php_mbstring.dll (weird) It depends on mbstring, load mbsring first. See the manual. > php_gmp.dll => missing not support yet. > php_intl.dll => missing icuuc36.dll it is in the archive. [2009-05-07 19:09:23] paj...@php.net php_curl.dll => missing zlib.dll php_dba.dll => missing php_exif.dll => missing php_mbstring.dll (weird) php_gmp.dll => missing php_intl.dll => missing icuuc36.dll > php_interbase.dll => missing gds32.dll not supported yet. > php_mime_magic.dll => missing > php_ming.dll => missing moved to pecl > php_mssql.dll => missing ntwdblib.dll not available anymore, my mistake I should have disabled it. > php_oci8.dll => missing OCI.dll You have to install the OCI client. See the manual. > php_oci8_11g.dll => missing OCI.dll Same as oci8 but using the client version 11.x. > php_pdo_firebird.dll => missing gds32.dll Not supported yet. > php_pdo_mssql.dll => missing ntwdblib.dll not available anymore, my mistake I should have disabled it. > php_pdo_oci.dll => missing OCI.dll Same as oci8 > php_pdo_pgsql.dll => missing LIBPQ.dll It is present in the archive. > php_pgsql.dll => missing LIBPQ.dll It is present in the archive. > php_phar.dll => missing builtin > php_pspell.dll => aspell-15.dll not supported anymore. > php_snmp.dll => missing not supported yet. > php_sybase_ct.dll => missing libcs.dll You have to install the sybase client. > php_zip.dll => missing builtin. For builtin module: run php -m to see them. [2009-05-07 18:31:44] tyra3l at gmail dot com Description: Problems with the default php extensions in the example php.ini.* Reproduce code: --- Try to enable the modules. Expected result: We should only have the shipped extensions in the php.ini by default, and every module should be working (which doesn't have some 3rd party dependency) Actual result: -- php_curl.dll => missing zlib.dll php_dba.dll => missing php_exif.dll => missing php_mbstring.dll (weird) php_gmp.dll => missing php_intl.dll => missing icuuc36.dll php_interbase.dll => missing gds32.dll php_mime_magic.dll => missing php_ming.dll => missing php_mssql.dll => missing ntwdblib.dll php_oci8.dll => missing OCI.dll php_oci8_11g.dll => missing OCI.dll php_pdo_firebird.dll => missing gds32.dll php_pdo_mssql.dll => missing ntwdblib.dll php_pdo_oci.dll => missing OCI.dll php_pdo_pgsql.dll => missing LIBPQ.dll php_pgsql.dll => missing LIBPQ.dll php_phar.dll => missing php_pspell.dll => aspell-15.dll php_snmp.dll => missing php_sybase_ct.dll => missing libcs.dll php_zip.dll => missing As far as I can see: - the config contains extensions, which isn't shipped - the config contains extensions, which are shipped, but cannot be loaded without the proper third party lib. - some exts are broken (curl was working fine in the RC1) I think that the lines without the extension should be removed, the lines with an ext which has dependency should be noted like with the oracle drivers. The broken exts should be fixed(curl, exif) -- Edit this b
#48184 [Opn->Ana]: Missing extensions and so
ID: 48184 Updated by: paj...@php.net Reported By: tyra3l at gmail dot com -Status: Open +Status: Analyzed Bug Type: *Configuration Issues Operating System: Windows XP SP3 PHP Version: 5.3.0RC2 Assigned To: pajoye Previous Comments: [2009-05-07 19:14:08] paj...@php.net In short, I will repackage it without mssql as it makes no sense to bundle it as it is not support anymore in 5.3. Thanks for your quick test&report! [2009-05-07 19:13:13] paj...@php.net php -m output: [PHP Modules] bcmath calendar com_dotnet Core ctype date dom ereg filter ftp hash iconv json libxml mcrypt mhash mysqlnd odbc pcre PDO Phar Reflection session SimpleXML SPL standard tokenizer wddx xml xmlreader xmlwriter zip zlib And the one I miss: > php_dba.dll => missing not supported yet. > php_exif.dll => missing php_mbstring.dll (weird) It depends on mbstring, load mbsring first. See the manual. > php_gmp.dll => missing not support yet. > php_intl.dll => missing icuuc36.dll it is in the archive. [2009-05-07 19:09:23] paj...@php.net php_curl.dll => missing zlib.dll php_dba.dll => missing php_exif.dll => missing php_mbstring.dll (weird) php_gmp.dll => missing php_intl.dll => missing icuuc36.dll > php_interbase.dll => missing gds32.dll not supported yet. > php_mime_magic.dll => missing > php_ming.dll => missing moved to pecl > php_mssql.dll => missing ntwdblib.dll not available anymore, my mistake I should have disabled it. > php_oci8.dll => missing OCI.dll You have to install the OCI client. See the manual. > php_oci8_11g.dll => missing OCI.dll Same as oci8 but using the client version 11.x. > php_pdo_firebird.dll => missing gds32.dll Not supported yet. > php_pdo_mssql.dll => missing ntwdblib.dll not available anymore, my mistake I should have disabled it. > php_pdo_oci.dll => missing OCI.dll Same as oci8 > php_pdo_pgsql.dll => missing LIBPQ.dll It is present in the archive. > php_pgsql.dll => missing LIBPQ.dll It is present in the archive. > php_phar.dll => missing builtin > php_pspell.dll => aspell-15.dll not supported anymore. > php_snmp.dll => missing not supported yet. > php_sybase_ct.dll => missing libcs.dll You have to install the sybase client. > php_zip.dll => missing builtin. For builtin module: run php -m to see them. [2009-05-07 18:31:44] tyra3l at gmail dot com Description: Problems with the default php extensions in the example php.ini.* Reproduce code: --- Try to enable the modules. Expected result: We should only have the shipped extensions in the php.ini by default, and every module should be working (which doesn't have some 3rd party dependency) Actual result: -- php_curl.dll => missing zlib.dll php_dba.dll => missing php_exif.dll => missing php_mbstring.dll (weird) php_gmp.dll => missing php_intl.dll => missing icuuc36.dll php_interbase.dll => missing gds32.dll php_mime_magic.dll => missing php_ming.dll => missing php_mssql.dll => missing ntwdblib.dll php_oci8.dll => missing OCI.dll php_oci8_11g.dll => missing OCI.dll php_pdo_firebird.dll => missing gds32.dll php_pdo_mssql.dll => missing ntwdblib.dll php_pdo_oci.dll => missing OCI.dll php_pdo_pgsql.dll => missing LIBPQ.dll php_pgsql.dll => missing LIBPQ.dll php_phar.dll => missing php_pspell.dll => aspell-15.dll php_snmp.dll => missing php_sybase_ct.dll => missing libcs.dll php_zip.dll => missing As far as I can see: - the config contains extensions, which isn't shipped - the config contains extensions, which are shipped, but cannot be loaded without the proper third party lib. - some exts are broken (curl was working fine in the RC1) I think that the lines without the extension should be removed, the lines with an ext which has dependency should be noted like with the oracle drivers. The broken exts should be fixed(curl, exif) -- Edit this bug report at http://bugs.php.net/?id=48184&edit=1
#48184 [Opn]: Missing extensions and so
ID: 48184 Updated by: paj...@php.net Reported By: tyra3l at gmail dot com Status: Open Bug Type: *Configuration Issues Operating System: Windows XP SP3 PHP Version: 5.3.0RC2 -Assigned To: +Assigned To: pajoye New Comment: In short, I will repackage it without mssql as it makes no sense to bundle it as it is not support anymore in 5.3. Thanks for your quick test&report! Previous Comments: [2009-05-07 19:13:13] paj...@php.net php -m output: [PHP Modules] bcmath calendar com_dotnet Core ctype date dom ereg filter ftp hash iconv json libxml mcrypt mhash mysqlnd odbc pcre PDO Phar Reflection session SimpleXML SPL standard tokenizer wddx xml xmlreader xmlwriter zip zlib And the one I miss: > php_dba.dll => missing not supported yet. > php_exif.dll => missing php_mbstring.dll (weird) It depends on mbstring, load mbsring first. See the manual. > php_gmp.dll => missing not support yet. > php_intl.dll => missing icuuc36.dll it is in the archive. [2009-05-07 19:09:23] paj...@php.net php_curl.dll => missing zlib.dll php_dba.dll => missing php_exif.dll => missing php_mbstring.dll (weird) php_gmp.dll => missing php_intl.dll => missing icuuc36.dll > php_interbase.dll => missing gds32.dll not supported yet. > php_mime_magic.dll => missing > php_ming.dll => missing moved to pecl > php_mssql.dll => missing ntwdblib.dll not available anymore, my mistake I should have disabled it. > php_oci8.dll => missing OCI.dll You have to install the OCI client. See the manual. > php_oci8_11g.dll => missing OCI.dll Same as oci8 but using the client version 11.x. > php_pdo_firebird.dll => missing gds32.dll Not supported yet. > php_pdo_mssql.dll => missing ntwdblib.dll not available anymore, my mistake I should have disabled it. > php_pdo_oci.dll => missing OCI.dll Same as oci8 > php_pdo_pgsql.dll => missing LIBPQ.dll It is present in the archive. > php_pgsql.dll => missing LIBPQ.dll It is present in the archive. > php_phar.dll => missing builtin > php_pspell.dll => aspell-15.dll not supported anymore. > php_snmp.dll => missing not supported yet. > php_sybase_ct.dll => missing libcs.dll You have to install the sybase client. > php_zip.dll => missing builtin. For builtin module: run php -m to see them. [2009-05-07 18:31:44] tyra3l at gmail dot com Description: Problems with the default php extensions in the example php.ini.* Reproduce code: --- Try to enable the modules. Expected result: We should only have the shipped extensions in the php.ini by default, and every module should be working (which doesn't have some 3rd party dependency) Actual result: -- php_curl.dll => missing zlib.dll php_dba.dll => missing php_exif.dll => missing php_mbstring.dll (weird) php_gmp.dll => missing php_intl.dll => missing icuuc36.dll php_interbase.dll => missing gds32.dll php_mime_magic.dll => missing php_ming.dll => missing php_mssql.dll => missing ntwdblib.dll php_oci8.dll => missing OCI.dll php_oci8_11g.dll => missing OCI.dll php_pdo_firebird.dll => missing gds32.dll php_pdo_mssql.dll => missing ntwdblib.dll php_pdo_oci.dll => missing OCI.dll php_pdo_pgsql.dll => missing LIBPQ.dll php_pgsql.dll => missing LIBPQ.dll php_phar.dll => missing php_pspell.dll => aspell-15.dll php_snmp.dll => missing php_sybase_ct.dll => missing libcs.dll php_zip.dll => missing As far as I can see: - the config contains extensions, which isn't shipped - the config contains extensions, which are shipped, but cannot be loaded without the proper third party lib. - some exts are broken (curl was working fine in the RC1) I think that the lines without the extension should be removed, the lines with an ext which has dependency should be noted like with the oracle drivers. The broken exts should be fixed(curl, exif) -- Edit this bug report at http://bugs.php.net/?id=48184&edit=1
#48184 [Opn]: Missing extensions and so
ID: 48184 Updated by: paj...@php.net Reported By: tyra3l at gmail dot com Status: Open Bug Type: *Configuration Issues Operating System: Windows XP SP3 PHP Version: 5.3.0RC2 New Comment: php -m output: [PHP Modules] bcmath calendar com_dotnet Core ctype date dom ereg filter ftp hash iconv json libxml mcrypt mhash mysqlnd odbc pcre PDO Phar Reflection session SimpleXML SPL standard tokenizer wddx xml xmlreader xmlwriter zip zlib And the one I miss: > php_dba.dll => missing not supported yet. > php_exif.dll => missing php_mbstring.dll (weird) It depends on mbstring, load mbsring first. See the manual. > php_gmp.dll => missing not support yet. > php_intl.dll => missing icuuc36.dll it is in the archive. Previous Comments: [2009-05-07 19:09:23] paj...@php.net php_curl.dll => missing zlib.dll php_dba.dll => missing php_exif.dll => missing php_mbstring.dll (weird) php_gmp.dll => missing php_intl.dll => missing icuuc36.dll > php_interbase.dll => missing gds32.dll not supported yet. > php_mime_magic.dll => missing > php_ming.dll => missing moved to pecl > php_mssql.dll => missing ntwdblib.dll not available anymore, my mistake I should have disabled it. > php_oci8.dll => missing OCI.dll You have to install the OCI client. See the manual. > php_oci8_11g.dll => missing OCI.dll Same as oci8 but using the client version 11.x. > php_pdo_firebird.dll => missing gds32.dll Not supported yet. > php_pdo_mssql.dll => missing ntwdblib.dll not available anymore, my mistake I should have disabled it. > php_pdo_oci.dll => missing OCI.dll Same as oci8 > php_pdo_pgsql.dll => missing LIBPQ.dll It is present in the archive. > php_pgsql.dll => missing LIBPQ.dll It is present in the archive. > php_phar.dll => missing builtin > php_pspell.dll => aspell-15.dll not supported anymore. > php_snmp.dll => missing not supported yet. > php_sybase_ct.dll => missing libcs.dll You have to install the sybase client. > php_zip.dll => missing builtin. For builtin module: run php -m to see them. [2009-05-07 18:31:44] tyra3l at gmail dot com Description: Problems with the default php extensions in the example php.ini.* Reproduce code: --- Try to enable the modules. Expected result: We should only have the shipped extensions in the php.ini by default, and every module should be working (which doesn't have some 3rd party dependency) Actual result: -- php_curl.dll => missing zlib.dll php_dba.dll => missing php_exif.dll => missing php_mbstring.dll (weird) php_gmp.dll => missing php_intl.dll => missing icuuc36.dll php_interbase.dll => missing gds32.dll php_mime_magic.dll => missing php_ming.dll => missing php_mssql.dll => missing ntwdblib.dll php_oci8.dll => missing OCI.dll php_oci8_11g.dll => missing OCI.dll php_pdo_firebird.dll => missing gds32.dll php_pdo_mssql.dll => missing ntwdblib.dll php_pdo_oci.dll => missing OCI.dll php_pdo_pgsql.dll => missing LIBPQ.dll php_pgsql.dll => missing LIBPQ.dll php_phar.dll => missing php_pspell.dll => aspell-15.dll php_snmp.dll => missing php_sybase_ct.dll => missing libcs.dll php_zip.dll => missing As far as I can see: - the config contains extensions, which isn't shipped - the config contains extensions, which are shipped, but cannot be loaded without the proper third party lib. - some exts are broken (curl was working fine in the RC1) I think that the lines without the extension should be removed, the lines with an ext which has dependency should be noted like with the oracle drivers. The broken exts should be fixed(curl, exif) -- Edit this bug report at http://bugs.php.net/?id=48184&edit=1
#48184 [Opn]: Missing extensions and so
ID: 48184 Updated by: paj...@php.net Reported By: tyra3l at gmail dot com Status: Open Bug Type: *Configuration Issues Operating System: Windows XP SP3 PHP Version: 5.3.0RC2 New Comment: php_curl.dll => missing zlib.dll php_dba.dll => missing php_exif.dll => missing php_mbstring.dll (weird) php_gmp.dll => missing php_intl.dll => missing icuuc36.dll > php_interbase.dll => missing gds32.dll not supported yet. > php_mime_magic.dll => missing > php_ming.dll => missing moved to pecl > php_mssql.dll => missing ntwdblib.dll not available anymore, my mistake I should have disabled it. > php_oci8.dll => missing OCI.dll You have to install the OCI client. See the manual. > php_oci8_11g.dll => missing OCI.dll Same as oci8 but using the client version 11.x. > php_pdo_firebird.dll => missing gds32.dll Not supported yet. > php_pdo_mssql.dll => missing ntwdblib.dll not available anymore, my mistake I should have disabled it. > php_pdo_oci.dll => missing OCI.dll Same as oci8 > php_pdo_pgsql.dll => missing LIBPQ.dll It is present in the archive. > php_pgsql.dll => missing LIBPQ.dll It is present in the archive. > php_phar.dll => missing builtin > php_pspell.dll => aspell-15.dll not supported anymore. > php_snmp.dll => missing not supported yet. > php_sybase_ct.dll => missing libcs.dll You have to install the sybase client. > php_zip.dll => missing builtin. For builtin module: run php -m to see them. Previous Comments: [2009-05-07 18:31:44] tyra3l at gmail dot com Description: Problems with the default php extensions in the example php.ini.* Reproduce code: --- Try to enable the modules. Expected result: We should only have the shipped extensions in the php.ini by default, and every module should be working (which doesn't have some 3rd party dependency) Actual result: -- php_curl.dll => missing zlib.dll php_dba.dll => missing php_exif.dll => missing php_mbstring.dll (weird) php_gmp.dll => missing php_intl.dll => missing icuuc36.dll php_interbase.dll => missing gds32.dll php_mime_magic.dll => missing php_ming.dll => missing php_mssql.dll => missing ntwdblib.dll php_oci8.dll => missing OCI.dll php_oci8_11g.dll => missing OCI.dll php_pdo_firebird.dll => missing gds32.dll php_pdo_mssql.dll => missing ntwdblib.dll php_pdo_oci.dll => missing OCI.dll php_pdo_pgsql.dll => missing LIBPQ.dll php_pgsql.dll => missing LIBPQ.dll php_phar.dll => missing php_pspell.dll => aspell-15.dll php_snmp.dll => missing php_sybase_ct.dll => missing libcs.dll php_zip.dll => missing As far as I can see: - the config contains extensions, which isn't shipped - the config contains extensions, which are shipped, but cannot be loaded without the proper third party lib. - some exts are broken (curl was working fine in the RC1) I think that the lines without the extension should be removed, the lines with an ext which has dependency should be noted like with the oracle drivers. The broken exts should be fixed(curl, exif) -- Edit this bug report at http://bugs.php.net/?id=48184&edit=1
#48134 [Fbk->Opn]: php crash after a few days (backtrace attached) with worker MPM
ID: 48134 User updated by: jimbobpalmer at gmail dot com Reported By: jimbobpalmer at gmail dot com -Status: Feedback +Status: Open Bug Type: Apache2 related Operating System: * (ZTS only) PHP Version: 5.2.9 New Comment: Is php not thread safe? Previous Comments: [2009-05-07 14:00:49] j...@php.net That explains it. You propably wouldn't have any problems if you didn't use threaded MPM. Try the more stable prefork MPM instead. [2009-05-07 13:44:47] jimbobpalmer at gmail dot com Worker MPM + apache2handler [2009-05-07 13:19:30] j...@php.net Exactly what MPM are you using and what PHP SAPI module? [2009-05-07 13:10:00] jimbobpalmer at gmail dot com Yes. Both apache and php are compiled with debug. [2009-05-07 12:47:33] j...@php.net Was that backtrace really produced with debug build? ie. with PHP build using --enable-debug ?? 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/48134 -- Edit this bug report at http://bugs.php.net/?id=48134&edit=1
#48184 [NEW]: Missing extensions and so
From: tyra3l at gmail dot com Operating system: Windows XP SP3 PHP version: 5.3.0RC2 PHP Bug Type: *Configuration Issues Bug description: Missing extensions and so Description: Problems with the default php extensions in the example php.ini.* Reproduce code: --- Try to enable the modules. Expected result: We should only have the shipped extensions in the php.ini by default, and every module should be working (which doesn't have some 3rd party dependency) Actual result: -- php_curl.dll => missing zlib.dll php_dba.dll => missing php_exif.dll => missing php_mbstring.dll (weird) php_gmp.dll => missing php_intl.dll => missing icuuc36.dll php_interbase.dll => missing gds32.dll php_mime_magic.dll => missing php_ming.dll => missing php_mssql.dll => missing ntwdblib.dll php_oci8.dll => missing OCI.dll php_oci8_11g.dll => missing OCI.dll php_pdo_firebird.dll => missing gds32.dll php_pdo_mssql.dll => missing ntwdblib.dll php_pdo_oci.dll => missing OCI.dll php_pdo_pgsql.dll => missing LIBPQ.dll php_pgsql.dll => missing LIBPQ.dll php_phar.dll => missing php_pspell.dll => aspell-15.dll php_snmp.dll => missing php_sybase_ct.dll => missing libcs.dll php_zip.dll => missing As far as I can see: - the config contains extensions, which isn't shipped - the config contains extensions, which are shipped, but cannot be loaded without the proper third party lib. - some exts are broken (curl was working fine in the RC1) I think that the lines without the extension should be removed, the lines with an ext which has dependency should be noted like with the oracle drivers. The broken exts should be fixed(curl, exif) -- Edit bug report at http://bugs.php.net/?id=48184&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=48184&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=48184&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=48184&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=48184&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=48184&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=48184&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=48184&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=48184&r=needscript Try newer version: http://bugs.php.net/fix.php?id=48184&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=48184&r=support Expected behavior: http://bugs.php.net/fix.php?id=48184&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=48184&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=48184&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=48184&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48184&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=48184&r=dst IIS Stability: http://bugs.php.net/fix.php?id=48184&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=48184&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=48184&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=48184&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=48184&r=mysqlcfg
#48183 [Opn->Bgs]: access to associative array element by key
ID: 48183
Updated by: lbarn...@php.net
Reported By: foolged at inbox dot ru
-Status: Open
+Status: Bogus
Bug Type: Arrays related
Operating System: windows xp sp3
PHP Version: 5.2.9
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:
[2009-05-07 16:36:09] foolged at inbox dot ru
Description:
$a = array ('id'=>'abc');
if (isset($a['id']['BUG']))
echo 'BUG';
$a = array ('id'=>'abc');
echo $a['id']['BUG']." <-BUG!!";
--
Edit this bug report at http://bugs.php.net/?id=48183&edit=1
#48183 [NEW]: access to associative array element by key
From: foolged at inbox dot ru
Operating system: windows xp sp3
PHP version: 5.2.9
PHP Bug Type: Arrays related
Bug description: access to associative array element by key
Description:
$a = array ('id'=>'abc');
if (isset($a['id']['BUG']))
echo 'BUG';
$a = array ('id'=>'abc');
echo $a['id']['BUG']." <-BUG!!";
--
Edit bug report at http://bugs.php.net/?id=48183&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=48183&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=48183&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=48183&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=48183&r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=48183&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=48183&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=48183&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=48183&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=48183&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=48183&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=48183&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=48183&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=48183&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=48183&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48183&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=48183&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=48183&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=48183&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=48183&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=48183&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=48183&r=mysqlcfg
#48182 [NEW]: stream_socket_client(ssl:// ... STREAM_CLIENT_ASYNC_CONNECT) fails
From: frase at cs dot wisc dot edu Operating system: Windows 2000 Pro SP4 PHP version: 5.2.9 PHP Bug Type: OpenSSL related Bug description: stream_socket_client(ssl:// ... STREAM_CLIENT_ASYNC_CONNECT) fails Description: When opening a socket connection with stream_socket_client() and the ssl:// wrapper, the connect-asynchronously flag (STREAM_CLIENT_ASYNC_CONNECT) causes ssl encryption to fail. Connecting asynchronously with tcp:// works, as does connecting synchronously with ssl://. If I remove the ASYNC flag from the example code, I get normal HTTP headers and HTML content. If I leave the flag but change the scheme to tcp:// and port to 80, launchpad.net gives me a normal HTTP/HTML redirect to the encrypted url (https://...). But as written, I instead get an error from the server indicating that my request could not be decrypted via SSL, and no HTTP headers whatsoever. I'm not sure if this bug is more properly "OpenSSL related" or "Sockets related", so I've guessed the former. But I wonder if maybe stream_select() considers the socket writable once it's opened, but before the SSL handshake is complete; that might cause this code to fwrite() too early, possibly going out plaintext. Then I suppose the solution is for stream_select() to not return ssl:// sockets until the handshake is complete, in addition to simply being opened. Reproduce code: --- http://www.w3.org/1999/xhtml"; xml:lang="en" lang="en" dir="ltr"> Launchpad ... etc Actual result: -- An HTML source error message: 400 Bad Request Bad Request Your browser sent a request that this server could not understand. Reason: You're speaking plain HTTP to an SSL-enabled server port. Instead use the HTTPS scheme to access this URL, please. Hint: https://launchpad.net/";>https://launchpad.net/ Apache/2.2.8 (Ubuntu) mod_ssl/2.2.8 OpenSSL/0.9.8g Server at launchpad.net Port 443 -- Edit bug report at http://bugs.php.net/?id=48182&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=48182&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=48182&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=48182&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=48182&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=48182&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=48182&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=48182&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=48182&r=needscript Try newer version: http://bugs.php.net/fix.php?id=48182&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=48182&r=support Expected behavior: http://bugs.php.net/fix.php?id=48182&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=48182&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=48182&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=48182&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48182&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=48182&r=dst IIS Stability: http://bugs.php.net/fix.php?id=48182&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=48182&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=48182&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=48182&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=48182&r=mysqlcfg
#48180 [Opn]: mb_ereg(i)_replace() evaluate replacement string vulnerability
ID: 48180
User updated by: 5up3rh3i at gmail dot com
Reported By: 5up3rh3i at gmail dot com
Status: Open
Bug Type: mbstring related
Operating System: *
PHP Version: 5.2.9
New Comment:
plz try this code
Previous Comments:
[2009-05-07 16:20:54] 5up3rh3i at gmail dot com
Sorry, the test code is woring
[2009-05-07 16:15:56] j...@php.net
PHP Parse error: syntax error, unexpected T_LNUMBER, expecting
T_STRING
in /home/jani/t.php on line 3
[2009-05-07 14:54:22] 5up3rh3i at gmail dot com
Description:
when option parameter set e, matches not be escaped.
ex:
phpinfo() will be evaluated.
mb_ereg_replace()
if ((replace_len - i) >= 2 && fwd == 1 &&
p[0] == '\\' && p[1] >= '0' && p[1] <=
'9') {
n = p[1] - '0';
}
if (n >= 0 && n < regs->num_regs) {
if (regs->beg[n] >= 0 && regs->beg[n] <
regs->end[n] &&
regs->end[n] <= string_len) {
smart_str_appendl(pbuf, string
+ regs->beg[n], regs->end[n] -
regs->beg[n]);
// matches not be escaped
}
preg_replace()
if ('\\' == *walk || '$' == *walk) {
smart_str_appendl(&code, segment, walk - segment);
if (walk_last == '\\') {
code.c[code.len-1] = *walk++;
segment = walk;
walk_last = 0;
continue;
}
segment = walk;
if (preg_get_backref(&walk, &backref)) {
if (backref < count) {
/* Find the corresponding string match
and substitute it
in instead of the backref */
match = subject + offsets[backref<<1];
match_len = offsets[(backref<<1)+1] -
offsets[backref<<1];
if (match_len) {
esc_match =
php_addslashes_ex(match, match_len, &esc_match_len,
0, 1 TSRMLS_CC);
// matches escaped by addslashes()
...
smart_str_appendl(&code, esc_match,
esc_match_len);
--
Edit this bug report at http://bugs.php.net/?id=48180&edit=1
#48180 [Fbk->Opn]: mb_ereg(i)_replace() evaluate replacement string vulnerability
ID: 48180
User updated by: 5up3rh3i at gmail dot com
Reported By: 5up3rh3i at gmail dot com
-Status: Feedback
+Status: Open
Bug Type: mbstring related
Operating System: *
PHP Version: 5.2.9
New Comment:
Sorry, the test code is woring
Previous Comments:
[2009-05-07 16:15:56] j...@php.net
PHP Parse error: syntax error, unexpected T_LNUMBER, expecting
T_STRING
in /home/jani/t.php on line 3
[2009-05-07 14:54:22] 5up3rh3i at gmail dot com
Description:
when option parameter set e, matches not be escaped.
ex:
phpinfo() will be evaluated.
mb_ereg_replace()
if ((replace_len - i) >= 2 && fwd == 1 &&
p[0] == '\\' && p[1] >= '0' && p[1] <=
'9') {
n = p[1] - '0';
}
if (n >= 0 && n < regs->num_regs) {
if (regs->beg[n] >= 0 && regs->beg[n] <
regs->end[n] &&
regs->end[n] <= string_len) {
smart_str_appendl(pbuf, string
+ regs->beg[n], regs->end[n] -
regs->beg[n]);
// matches not be escaped
}
preg_replace()
if ('\\' == *walk || '$' == *walk) {
smart_str_appendl(&code, segment, walk - segment);
if (walk_last == '\\') {
code.c[code.len-1] = *walk++;
segment = walk;
walk_last = 0;
continue;
}
segment = walk;
if (preg_get_backref(&walk, &backref)) {
if (backref < count) {
/* Find the corresponding string match
and substitute it
in instead of the backref */
match = subject + offsets[backref<<1];
match_len = offsets[(backref<<1)+1] -
offsets[backref<<1];
if (match_len) {
esc_match =
php_addslashes_ex(match, match_len, &esc_match_len,
0, 1 TSRMLS_CC);
// matches escaped by addslashes()
...
smart_str_appendl(&code, esc_match,
esc_match_len);
--
Edit this bug report at http://bugs.php.net/?id=48180&edit=1
#48180 [Opn->Fbk]: mb_ereg(i)_replace() evaluate replacement string vulnerability
ID: 48180
Updated by: j...@php.net
Reported By: 5up3rh3i at gmail dot com
-Status: Open
+Status: Feedback
Bug Type: mbstring related
Operating System: *
PHP Version: 5.2.9
New Comment:
PHP Parse error: syntax error, unexpected T_LNUMBER, expecting
T_STRING
in /home/jani/t.php on line 3
Previous Comments:
[2009-05-07 14:54:22] 5up3rh3i at gmail dot com
Description:
when option parameter set e, matches not be escaped.
ex:
phpinfo() will be evaluated.
mb_ereg_replace()
if ((replace_len - i) >= 2 && fwd == 1 &&
p[0] == '\\' && p[1] >= '0' && p[1] <=
'9') {
n = p[1] - '0';
}
if (n >= 0 && n < regs->num_regs) {
if (regs->beg[n] >= 0 && regs->beg[n] <
regs->end[n] &&
regs->end[n] <= string_len) {
smart_str_appendl(pbuf, string
+ regs->beg[n], regs->end[n] -
regs->beg[n]);
// matches not be escaped
}
preg_replace()
if ('\\' == *walk || '$' == *walk) {
smart_str_appendl(&code, segment, walk - segment);
if (walk_last == '\\') {
code.c[code.len-1] = *walk++;
segment = walk;
walk_last = 0;
continue;
}
segment = walk;
if (preg_get_backref(&walk, &backref)) {
if (backref < count) {
/* Find the corresponding string match
and substitute it
in instead of the backref */
match = subject + offsets[backref<<1];
match_len = offsets[(backref<<1)+1] -
offsets[backref<<1];
if (match_len) {
esc_match =
php_addslashes_ex(match, match_len, &esc_match_len,
0, 1 TSRMLS_CC);
// matches escaped by addslashes()
...
smart_str_appendl(&code, esc_match,
esc_match_len);
--
Edit this bug report at http://bugs.php.net/?id=48180&edit=1
#47507 [Opn->Fbk]: PHP Notice: iconv(): Wrong charset
ID: 47507
Updated by: j...@php.net
Reported By: aboh24 at gmx dot de
-Status: Open
+Status: Feedback
Bug Type: ICONV related
Operating System: Solaris 10 / 64-bit
PHP Version: 5.2.9
-Assigned To:
+Assigned To: fb-req-jani
New Comment:
You should actually read the help not grep for iconv in it and you'd
know what the difference is. Now, did you try it or not?
Previous Comments:
[2009-05-07 06:56:45] aboh24 at gmx dot de
Sure that I need to use --with-iconv-dir=$PX instead --with-iconv=$PX?
Sorry if I ask because the help message of the configure file display
vice versa.
src/php5.2-200904280430 $ ./configure --help | grep iconv
--without-iconv[=DIR] Exclude iconv support
--with-iconv-dir=DIR XMLRPC-EPI: iconv dir for XMLRPC-EPI
However I will test your suggestion soon.
---
Is there any more infoamtion I can provide to support you?
---
BTW: What does reason: ICONV_IMPL != "libiconv" mean.
[2009-05-06 20:46:43] j...@php.net
I missed this earlier, you're using wrong configure options.
Just change the --with-iconv-dir=$PX to --with-iconv=$PX and try again.
Note: Do this with clean build dir.
Also, do not paste more test result outputs here, they're no value for
us. Just telling which tests fail is more useful.
[2009-02-26 10:29:13] aboh24 at gmx dot de
This could maybe useful:
user# /usr/lib/iconv/UTF-8%ISO8859-1*
/usr/lib/iconv/UTF-8%ISO8859-11.so
it is mentioned in the truss output of the test php program:
access("/usr/lib/iconv/geniconvtbl/binarytables/UTF-8%ISO-8859-1//TRANSLIT.bt",
R_OK) Err#2 ENOENT
access("/usr/lib/iconv/UTF-8%ISO-8859-1//TRANSLIT.so", R_OK) Err#2
ENOENT
open("/usr/lib/iconv/alias", O_RDONLY) = 3
fstat64(3, 0xFFBFEE60) = 0
mmap(0x, 6311, PROT_READ, MAP_SHARED, 3, 0) = 0xFF3A
close(3)= 0
munmap(0xFF3A, 6311)= 0
access("/usr/lib/iconv/geniconvtbl/binarytables/UTF-8%ISO-8859-1//TRANSLIT.bt",
R_OK) Err#2 ENOENT
access("/usr/lib/iconv/UTF-8%ISO-8859-1//TRANSLIT.so", R_OK) Err#2
ENOENT
PHP Notice: iconv(): Wrong charset, conversion from `UTF-8' to
`ISO-8859-1//TRANSLIT' is not allowed in /test.php on line 13write(2, "
P H P N o t i c e : ".., 151) = 151
write(2, "\n", 1)
[2009-02-26 08:59:45] aboh24 at gmx dot de
truss ./test.php
...
access("/usr/lib/iconv/geniconvtbl/binarytables/UTF-8%8859-1.bt", R_OK)
Err#2 ENOENT
access("/usr/lib/iconv/UTF-8%8859-1.so", R_OK) = 0
stat("/usr/lib/iconv/UTF-8%8859-1.so", 0xFFBFE8A0) = 0
resolvepath("/usr/lib/iconv/UTF-8%8859-1.so",
"/usr/lib/iconv/UTF-8%8859-1.so", 1023) = 30
open("/usr/lib/iconv/UTF-8%8859-1.so", O_RDONLY) = 4
...
Althoug the php was build with a local libiconv and explicit setting of
the prefix-path and LD_LIBRARY_PATH and --with-iconv-dir, etc. the
system want to load the iconv from /usr/lib/iconv which do not
exists... :-(
[2009-02-26 07:52:46] aboh24 at gmx dot de
I rebuilt the codes with -m32 (this is default and means 32-bit
binaries) and it is the same problem.
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/47507
--
Edit this bug report at http://bugs.php.net/?id=47507&edit=1
#48181 [NEW]: pg_version returns incorrect client version and no server version
From: john dot doyle at camden dot gov dot uk Operating system: Windows Server 2003 PHP version: 5.2.9 PHP Bug Type: PostgreSQL related Bug description: pg_version returns incorrect client version and no server version Description: pg_version returns 8.3.1 for the client version and doesn't return anything for the server version. We've tested on multiple machines with Postgresql 8.3.7. We've checked our path variables, the version numbers on psql, libpg.dll, what select version() returns and whether we had any other copies of libpg.dll on our machines. Reproduce code: --- Expected result: to see pg_version return client and server as 8.3.7 Actual result: -- 8.3.1 for client and no other values -- Edit bug report at http://bugs.php.net/?id=48181&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=48181&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=48181&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=48181&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=48181&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=48181&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=48181&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=48181&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=48181&r=needscript Try newer version: http://bugs.php.net/fix.php?id=48181&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=48181&r=support Expected behavior: http://bugs.php.net/fix.php?id=48181&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=48181&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=48181&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=48181&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48181&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=48181&r=dst IIS Stability: http://bugs.php.net/fix.php?id=48181&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=48181&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=48181&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=48181&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=48181&r=mysqlcfg
#48180 [NEW]: mb_ereg(i)_replace() evaluate replacement string vulnerability
From: 5up3rh3i at gmail dot com
Operating system: Any
PHP version: 5.2.9
PHP Bug Type: mbstring related
Bug description: mb_ereg(i)_replace() evaluate replacement string vulnerability
Description:
when option parameter set e, matches not be escaped.
ex:
phpinfo() will be evaluated.
mb_ereg_replace()
if ((replace_len - i) >= 2 && fwd == 1 &&
p[0] == '\\' && p[1] >= '0' && p[1] <=
'9') {
n = p[1] - '0';
}
if (n >= 0 && n < regs->num_regs) {
if (regs->beg[n] >= 0 && regs->beg[n] <
regs->end[n] && regs->end[n]
<= string_len) {
smart_str_appendl(pbuf, string
+ regs->beg[n], regs->end[n] -
regs->beg[n]);
// matches not be escaped
}
preg_replace()
if ('\\' == *walk || '$' == *walk) {
smart_str_appendl(&code, segment, walk - segment);
if (walk_last == '\\') {
code.c[code.len-1] = *walk++;
segment = walk;
walk_last = 0;
continue;
}
segment = walk;
if (preg_get_backref(&walk, &backref)) {
if (backref < count) {
/* Find the corresponding string match
and substitute it
in instead of the backref */
match = subject + offsets[backref<<1];
match_len = offsets[(backref<<1)+1] -
offsets[backref<<1];
if (match_len) {
esc_match =
php_addslashes_ex(match, match_len, &esc_match_len, 0, 1
TSRMLS_CC);
// matches escaped by addslashes()
...
smart_str_appendl(&code, esc_match,
esc_match_len);
--
Edit bug report at http://bugs.php.net/?id=48180&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=48180&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=48180&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=48180&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=48180&r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=48180&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=48180&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=48180&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=48180&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=48180&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=48180&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=48180&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=48180&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=48180&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=48180&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48180&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=48180&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=48180&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=48180&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=48180&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=48180&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=48180&r=mysqlcfg
#48175 [Fbk->Opn]: FILE_IGNORE_NEW_LINES don't remove "\r\n"
ID: 48175 User updated by: carsten_sttgt at gmx dot de Reported By: carsten_sttgt at gmx dot de -Status: Feedback +Status: Open Bug Type: Filesystem function related Operating System: * PHP Version: 5.2.9 New Comment: executed with "php.exe -n test.php": 5.2.10-dev - Thu, 07 May 2009 11:42:06 +0100 101 101 13 5.3.0RC1 - Tue, 24 Mar 2009 22:33:04 + 5.3.0RC3-dev - Thu, 07 May 2009 13:08:08 + 101 101 101 6.0.0-dev - hu, 07 May 2009 11:30:12 + 13 101 101 So it's seems to be fixed in PHP5.3. - is there a plan to release this PHP5.2.10 (have still the old behavior)? - is this result expected in PHP6 (and why)? Previous Comments: [2009-05-07 13:46:44] lbarn...@php.net Please try using this CVS snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ [2009-05-07 12:42:05] j...@php.net See also bug #44034 [2009-05-07 09:23:02] carsten_sttgt at gmx dot de Description: Hello, if I use FILE_IGNORE_NEW_LINES with file(), a "\r\n" will not be removed. It works with a single "\r" or "\n". (Tested on *nix and Windows.) Regards, Carsten Reproduce code: --- Expected result: 101 101 101 Actual result: -- 101 101 13 -- Edit this bug report at http://bugs.php.net/?id=48175&edit=1
#48134 [Opn->Fbk]: php crash after a few days (backtrace attached) with worker MPM
ID: 48134 Updated by: j...@php.net -Summary: php crash after a few days (backtrace attached) Reported By: jimbobpalmer at gmail dot com -Status: Open +Status: Feedback Bug Type: Apache2 related -Operating System: Gentoo +Operating System: * (ZTS only) PHP Version: 5.2.9 New Comment: That explains it. You propably wouldn't have any problems if you didn't use threaded MPM. Try the more stable prefork MPM instead. Previous Comments: [2009-05-07 13:44:47] jimbobpalmer at gmail dot com Worker MPM + apache2handler [2009-05-07 13:19:30] j...@php.net Exactly what MPM are you using and what PHP SAPI module? [2009-05-07 13:10:00] jimbobpalmer at gmail dot com Yes. Both apache and php are compiled with debug. [2009-05-07 12:47:33] j...@php.net Was that backtrace really produced with debug build? ie. with PHP build using --enable-debug ?? [2009-05-07 09:26:05] jimbobpalmer at gmail dot com Yes, we use php_admin_value per vhost. I noticed we have a few boolean php_admin_value options. I have changed these to php_admin_flag. 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/48134 -- Edit this bug report at http://bugs.php.net/?id=48134&edit=1
#48147 [Ver->Bgs]: iconv with //IGNORE cuts the string
ID: 48147
Updated by: j...@php.net
Reported By: kulakov74 at yandex dot ru
-Status: Verified
+Status: Bogus
Bug Type: ICONV related
Operating System: Linux
PHP Version: 5.*, 6CVS (2009-05-05)
New Comment:
We still can't fix bugs in glibc iconv implementation. Try this on
command line and you get same results:
# iconv -f utf-8 -t iso-8859-1 iconv.html > /dev/null
iconv: illegal input sequence at position 3589
# iconv -f utf-8 -t iso-8859-1//IGNORE iconv.html > /dev/null
iconv: illegal input sequence at position 8168
Previous Comments:
[2009-05-07 07:50:52] lbarn...@php.net
Marked it as verified as I got exactly the same results:
The first iconv() call (the one without //IGNORE) fails on the emphasis
character "â¦" (value="Searchâ¦"), which can't be represented in
ISO-8859-1.
The second iconv() call (the one with //IGNORE) fails later (so the
emphasis is ignored, which may means that the //IGNORE flag is
supported), and there is no apparent reason for failing at offset 8157
(only regular ASCII chars around).
[2009-05-06 18:36:10] j...@php.net
Arnaud: Please don't reopen bogus bugs without explanation.
[2009-05-06 18:18:07] kulakov74 at yandex dot ru
No. The fact the script displays the notice "iconv(): Detected an
illegal character ..." in both cases is not related to the fact whether
the option is implemented: this is controlled by error_reporting(E_ALL).
The option IGNORE only controls whether iconv will stop at the character
or not.
Also, the length of the resulting string is different (greater) with
IGNORE, and while without it the string ends at exactly where the
illegal character is, with IGNORE it ends at a random point where no
such characters occur.
Also, I did not mention - this is not the only file I converted, many
others were converted correctly with the option, and their length only
decreased a little. But there were 2 files which were truncated, 1 of
them (the smaller) is used for the test case.
Can you run the test with the latest PHP releases? Actually this is why
I reported the bug. I tried it on other servers with PHP 4.3.3, 5.1.4,
5.1.6, 5.2.4 and 5.2.6 and yep! - I finally found one with 5.2.9 (built
Feb 27 2009) and it displayed the same results everywhere.
I repeat, the TRANSLIT option works fine, while it does the same and
even more.
[2009-05-06 14:38:39] j...@php.net
It just means you're using glibc iconv implementation which does not
have the IGNORE parameter implemented.
[2009-05-06 05:13:10] kulakov74 at yandex dot ru
Here goes the script. I'm not sure about the limit on external
resources - I have the file to convert, so it is downloaded.
http://www.oppcharts.com/iconv.html";);
echo(strlen($Body1)."\n");
$Body2=iconv('UTF-8', 'ISO-8859-1', $Body1);
echo(strlen($Body2)."\n");
$Body2=iconv('UTF-8', 'ISO-8859-1//IGNORE', $Body1);
echo(strlen($Body2)."\n");
?>
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/48147
--
Edit this bug report at http://bugs.php.net/?id=48147&edit=1
#47742 [Fbk->Opn]: mb_strtoupper() and mb_strtolower() failure cases
ID: 47742 User updated by: fsb at thefsb dot org Reported By: fsb at thefsb dot org -Status: Feedback +Status: Open Bug Type: mbstring related Operating System: os x PHP Version: 5.2.9 New Comment: jani, that looks like an improvement. should i try out the may 7 snapshot? Previous Comments: [2009-05-06 21:10:01] j...@php.net Ignore the previous, this bad bug system messed up the input. :) Here's the actual stuff: http://pecl.php.net/~jani/bug47742.out [2009-05-06 21:07:33] j...@php.net This script: Outputs: orig: Χιόνια, βροχές και θυελλώδεις άνεμοι συνθέτουν το mb_strtoupper: ΧΙΌΝΙΑ, ΒΡΟΧΈΣ ΚΑΙ ΘΥΕΛΛΏΔΕΙΣ ΆΝΕΜΟΙ ΣΥΝΘΈΤΟΥΝ ΤΟ mb_convert_case (upper): ΧΙΌΝΙΑ, ΒΡΟΧΈΣ ΚΑΙ ΘΥΕΛΛΏΔΕΙΣ ΆΝΕΜΟΙ ΣΥΝΘΈΤΟΥΝ ΤΟ mb_strtolower: χιόνια, βροχέσ και θυελλώδεισ άνεμοι συνθέτουν το mb_convert_case (lower): χιόνια, βροχέσ και θυελλώδεισ άνεμοι συνθέτουν το And this is quite correct.. [2009-05-05 11:37:26] fsb at thefsb dot org in both test scripts i provided yesterday, the character set is unicode and the encoding is utf-8. in the short test script that i provided 4 May 7:02pm UTC, there is only one short Hangul test string and no Greek, as you said. in the longer test script i provided at 4 May 5:00pm UTC, several alphabets are used including Greek, Cyrillic, Hebrew, Arabic, Thai, Kanji, ... in case it makes life easier for you, i put the longer test script on a web server: http://tomworster.net/test.php.gz it's only 1kbyte. [2009-05-05 02:02:39] j...@php.net One last question: What is the charset you used? I don't see any greek chars anywhere.. ;) [2009-05-04 19:02:43] fsb at thefsb dot org ./php -f test2.php 5.2.10-dev 1: ì´ë©° ì¸ê³ 2: Ì?Ë©? Ì?ʳ? 3ÌË© Ìʳ 4: ?? ?? 5: expected output: 1: ì´ë©° ì¸ê³ 2: ì´ë©° ì¸ê³ 3: ì´ë©° ì¸ê³ 4: ì´ë©° ì¸ê³ 5: ì´ë©° ì¸ê³ 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/47742 -- Edit this bug report at http://bugs.php.net/?id=47742&edit=1
#45132 [Asn]: escapeshellcmd removes swedish characters
ID: 45132
Updated by: j...@php.net
Reported By: tom at collegit dot se
Status: Assigned
Bug Type: Strings related
-Operating System: Linux www2 2.6.24.7-grsec
+Operating System: *
-PHP Version: 5.2.6
+PHP Version: 5.*, 6CVS (2009-05-05)
Assigned To: iliaa
New Comment:
See also bug #44564 (and can still verify using latest CVS)
Previous Comments:
[2008-08-07 06:23:19] tstarling at wikimedia dot org
The issue is that previously 8-bit clean locales, like "C", are now
being validated for whatever character set they supposedly are, with
characters above 127 being removed.
The suggested fix, here and on
https://bugzilla.wikimedia.org/show_bug.cgi?id=14944 , appears to reopen
whatever security vulnerability it was that the patch fixed in the first
place.
$ LANG=C php eval.php
> setlocale(LC_CTYPE, 'en_US.UTF-8')
> echo escapeshellarg("\xC3\x96")
'Ö'
> passthru('locale')
LANG=C
LC_CTYPE="C"
LC_NUMERIC="C"
LC_TIME="C"
LC_COLLATE="C"
LC_MONETARY="C"
LC_MESSAGES="C"
LC_PAPER="C"
LC_NAME="C"
LC_ADDRESS="C"
LC_TELEPHONE="C"
LC_MEASUREMENT="C"
LC_IDENTIFICATION="C"
LC_ALL=
Because the environment variable LC_CTYPE is not set by setlocale(),
the spawned shell sees the old character set, not the new one. So the
shell can be passed an argument escaped for the wrong character set,
potentially opening a vulnerability.
I'm assuming that the attack scenario for this vulnerability is where
an attacker can set environment variables such as LANG to a vulnerable
character set, before starting PHP. Because if an attacker can set
environment variables during execution of a script, the bug is not
fixed. But in that case you're probably screwed anyway.
[2008-05-29 23:09:34] fel...@php.net
Try using:
setlocale(LC_CTYPE, "UTF8", "en_US.UTF-8");
[2008-05-29 22:55:58] j...@php.net
Ilia, did that fix get into actual release..?
[2008-05-29 22:53:54] tom at collegit dot se
Description:
Since my web server got updated to 5.2.6 escapeshellcmd() has started
removing all Swedish characters from user input. Looks a lot like bug
#44564.
'./configure' '--with-apxs2=/usr/local/apache/bin/apxs' '--with-
mysql=/usr/local/mysql' '--enable-debug=no' '--enable-track-vars' '--
with-imap=/usr/local/imap' '--with-mcrypt' '--with-mhash' '--with-dom'
'--with-gd' '--with-jpeg-dir' '--enable-ftp' '--with-freetype-
dir=/usr' '--with-zlib-dir=/usr' '--with-png-dir=/usr' '--enable-
dbase' '--with-gettext' '--with-zlib' '--enable-inline-optimization'
'--with-openssl' '--with-curl' '--with-curlwrappers' '--enable-exif'
'--with-imap-ssl' '--enable-bcmath' '--enable-mbstring' '--enable-
wddx' '--with-xsl' '--with-pdo-mysql=/usr/local/mysql' '--with-
mysqli=/usr/local/mysql/bin/mysql_config' '--enable-soap' '--enable-
sockets' '--with-mssql' '--with-ming' '--with-pspell' '--enable-
calendar' '--enable-bcmath' '--with-t1lib' '--with-
pgsql=/usr/local/pgsql' '--with-tidy' '--enable-zip'
Reproduce code:
---
$test = "åäö";
$test = (escapeshellcmd($test));
print $test;
Expected result:
"åäö"
Actual result:
--
""
--
Edit this bug report at http://bugs.php.net/?id=45132&edit=1
#48175 [Opn->Fbk]: FILE_IGNORE_NEW_LINES don't remove "\r\n"
ID: 48175 Updated by: lbarn...@php.net Reported By: carsten_sttgt at gmx dot de -Status: Open +Status: Feedback Bug Type: Filesystem function related Operating System: * PHP Version: 5.2.9 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ Previous Comments: [2009-05-07 12:42:05] j...@php.net See also bug #44034 [2009-05-07 09:23:02] carsten_sttgt at gmx dot de Description: Hello, if I use FILE_IGNORE_NEW_LINES with file(), a "\r\n" will not be removed. It works with a single "\r" or "\n". (Tested on *nix and Windows.) Regards, Carsten Reproduce code: --- Expected result: 101 101 101 Actual result: -- 101 101 13 -- Edit this bug report at http://bugs.php.net/?id=48175&edit=1
#48134 [Fbk->Opn]: php crash after a few days (backtrace attached)
ID: 48134 User updated by: jimbobpalmer at gmail dot com Reported By: jimbobpalmer at gmail dot com -Status: Feedback +Status: Open Bug Type: Apache2 related Operating System: Gentoo PHP Version: 5.2.9 New Comment: Worker MPM + apache2handler Previous Comments: [2009-05-07 13:19:30] j...@php.net Exactly what MPM are you using and what PHP SAPI module? [2009-05-07 13:10:00] jimbobpalmer at gmail dot com Yes. Both apache and php are compiled with debug. [2009-05-07 12:47:33] j...@php.net Was that backtrace really produced with debug build? ie. with PHP build using --enable-debug ?? [2009-05-07 09:26:05] jimbobpalmer at gmail dot com Yes, we use php_admin_value per vhost. I noticed we have a few boolean php_admin_value options. I have changed these to php_admin_flag. [2009-05-07 08:02:43] j...@php.net Do you have some php settings done using the php_value / php_flag / php_admin_value / php_admin_flag directives in httpd.conf, some file included by httpd.conf or some .htaccess file in your filesystem? 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/48134 -- Edit this bug report at http://bugs.php.net/?id=48134&edit=1
#45392 [Asn->Csd]: ob_start()/ob_end_clean() and memory_limit
ID: 45392 Updated by: j...@php.net Reported By: flebron at bumeran dot com -Status: Assigned +Status: Closed Bug Type: Output Control Operating System: * PHP Version: 5CVS-2008-11-01 Assigned To: iliaa Previous Comments: [2009-04-30 11:59:26] hwallenstone at gmx dot de Changelog for 5.2.7 states this Bug as "Fixed", although it still there in 5.2.8. As it never went into 5.2, the Changelog should be changed. [2008-12-01 20:45:56] il...@php.net Works fine for me using your example script in 5.3, the patch never went into 5.2 as it is a little risky for a stable release. [2008-11-02 13:58:27] j...@php.net The test for this bug fails in both branches. [2008-09-17 00:20:51] il...@php.net 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-07-14 11:26:09] j...@php.net This slightly modified script shows the bug without massive output: 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/45392 -- Edit this bug report at http://bugs.php.net/?id=45392&edit=1
#27777 [Com]: basic authentication broken
ID: 2 Comment by: Christian dot Reingruber at gmail dot com Reported By: mikx at mikx dot de Status: No Feedback Bug Type: SOAP related Operating System: Windows XP Pro PHP Version: 5.0.0RC1 New Comment: still a problem in 5.2.8 i guess... any ideas? Previous Comments: [2008-06-19 14:16:33] trippinbilly25 at gmail dot com This is still a problem in 5.2.6. [2007-04-05 15:21:57] jgarcia at tdg-i dot com Bug still open in PHP 5.1.2 Found information from user post: Arjan van Bentem 12-Aug-2005 08:31 When using HTTP basic authentication, PHP will only send the credentials when invoking the service, not when fetching the WSDL. [2006-05-19 09:01:20] peter at adkins dot nl This is still a problem with 5.1.1. [2005-04-12 14:33:55] lobbin at localhost dot nu This is still a problem. The soap-extension is not able to get a password-protected wsdl even though the credentials are provided and used when posting the real soap-request. [2004-08-05 15:32:21] technique at kaiman dot fr I've the same probleme here with 5.0.0 on freebsd 4.3 the SOAP client doesn't authenticate himself with login and pass of options array when retrieving the wsdl file but do it correctly on SOAP request. So I can't instanciate a SOAP client with a protected wsdl file. I've a network capture of this, contact me if you need it. regards 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/2 -- Edit this bug report at http://bugs.php.net/?id=2&edit=1
#47670 [Opn->Fbk]: issue w/ zlib.output_compression + mysql.trace_mode + "result set not freed"
ID: 47670 Updated by: j...@php.net Reported By: ch+php at -internet dot com -Status: Open +Status: Feedback Bug Type: Zlib Related Operating System: freebsd 7.0 PHP Version: 5.2.9 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://windows.php.net/snapshots/ And please provide a proper reproduce script without any mysql stuff. Previous Comments: [2009-03-16 07:35:55] ch+php at -internet dot com Description: Seeing some unexpected behavior when getting a mysql "result set not freed" warning while using zlib.output_compression + mysql.trace_mode - the warning is not displayed, and getting some intermittent reload behavior in IE6 if the page also has a large amount of content Reproduce code: --- Expected result: 25 random ASCII characters followed by: Warning: Unknown: 1 result set(s) not freed. Use mysql_free_result to free result sets which were requested using mysql_query() in Unknown on line 0 Actual result: -- Firefox: 25 random ASCII characters, no warning IE6: same, plus intermittent reload behavior -- Edit this bug report at http://bugs.php.net/?id=47670&edit=1
#48134 [Opn->Fbk]: php crash after a few days (backtrace attached)
ID: 48134 Updated by: j...@php.net Reported By: jimbobpalmer at gmail dot com -Status: Open +Status: Feedback Bug Type: Apache2 related Operating System: Gentoo PHP Version: 5.2.9 New Comment: Exactly what MPM are you using and what PHP SAPI module? Previous Comments: [2009-05-07 13:10:00] jimbobpalmer at gmail dot com Yes. Both apache and php are compiled with debug. [2009-05-07 12:47:33] j...@php.net Was that backtrace really produced with debug build? ie. with PHP build using --enable-debug ?? [2009-05-07 09:26:05] jimbobpalmer at gmail dot com Yes, we use php_admin_value per vhost. I noticed we have a few boolean php_admin_value options. I have changed these to php_admin_flag. [2009-05-07 08:02:43] j...@php.net Do you have some php settings done using the php_value / php_flag / php_admin_value / php_admin_flag directives in httpd.conf, some file included by httpd.conf or some .htaccess file in your filesystem? [2009-05-07 06:53:09] jimbobpalmer at gmail dot com # gdb -q /usr/sbin/apache2 /var/tmp/core.6111 (no debugging symbols found) warning: Can't read pathname for load map: Input/output error. Reading symbols from /lib/libm.so.6...(no debugging symbols found)...done. Loaded symbols for /lib/libm.so.6 Reading symbols from /usr/lib/libpcre.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libpcre.so.0 Reading symbols from /lib/libz.so.1... (no debugging symbols found)...done. Loaded symbols for /lib/libz.so.1 Reading symbols from /lib/libbz2.so.1...(no debugging symbols found)...done. Loaded symbols for /lib/libbz2.so.1 Reading symbols from /usr/lib/libaprutil-1.so.0... (no debugging symbols found)...done. Loaded symbols for /usr/lib/libaprutil-1.so.0 Reading symbols from /usr/lib/libgdbm.so.3...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libgdbm.so.3 Reading symbols from /usr/lib/libdb-4.5.so... (no debugging symbols found)...done. Loaded symbols for /usr/lib/libdb-4.5.so Reading symbols from /usr/lib/libexpat.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libexpat.so.1 Reading symbols from /usr/lib/libapr-1.so.0... (no debugging symbols found)...done. Loaded symbols for /usr/lib/libapr-1.so.0 Reading symbols from /lib/libuuid.so.1...(no debugging symbols found)...done. Loaded symbols for /lib/libuuid.so.1 Reading symbols from /lib/librt.so.1... (no debugging symbols found)...done. Loaded symbols for /lib/librt.so.1 Reading symbols from /lib/libcrypt.so.1...(no debugging symbols found)...done. Loaded symbols for /lib/libcrypt.so.1 Reading symbols from /lib/libpthread.so.0... (no debugging symbols found)...done. Loaded symbols for /lib/libpthread.so.0 Reading symbols from /lib/libdl.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/libdl.so.2 Reading symbols from /lib/libc.so.6... (no debugging symbols found)...done. Loaded symbols for /lib/libc.so.6 Reading symbols from /lib/ld-linux.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/ld-linux.so.2 Reading symbols from /lib/libnsl.so.1... (no debugging symbols found)...done. Loaded symbols for /lib/libnsl.so.1 Reading symbols from /lib/libnss_compat.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/libnss_compat.so.2 Reading symbols from /lib/libnss_nis.so.2... (no debugging symbols found)...done. Loaded symbols for /lib/libnss_nis.so.2 Reading symbols from /lib/libnss_files.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/libnss_files.so.2 Reading symbols from /usr/lib/gcc/i686-pc-linux-gnu/4.3.2/libgcc_s.so.1... (no debugging symbols found)...done. Loaded symbols for /usr/lib/gcc/i686-pc-linux-gnu/4.3.2/libgcc_s.so.1 Reading symbols from /usr/lib/apache2/modules/mod_auth_basic.so...(no debugging symbols found)...done. Loaded symbols for /usr/lib/apache2/modules/mod_auth_basic.so Reading symbols from /usr/lib/apache2/modules/mod_authn_default.so... (no debugging symbols found)...done. Loaded symbols for /usr/lib/apache2/modules/mod_authn_default.so Reading symbols from /usr/lib/apache2/modules/mod_authn_file.so...(no debugging symbols found)...done. Loaded symbols for /usr/lib/apache2/modules/mod_authn_file.so Reading symbols from /usr/lib/apache2/modules/mod_authz_default.so... (no debugging symbols found)...done. Loaded symbols for /usr/lib/apache2/modules/mod_authz_default.so Reading symbols from /usr/lib/apache2/modules/mod_authz_host.so...(no debugging symbols found)...done. Loaded symbols for /usr/lib/apache2/modules/mod_authz_host.so Reading symbols from /usr/l
#48179 [Opn->Bgs]: imagecreatefromjpeg() crashes i.s.o. return FALSE
ID: 48179
Updated by: j...@php.net
Reported By: ronald dot muller at gmail dot com
-Status: Open
+Status: Bogus
Bug Type: GD related
Operating System: *
PHP Version: 5.2.9
New Comment:
To be able to read huge images you just have to increase the
memory_limit. There is no other fix for this.
Previous Comments:
[2009-05-07 13:08:36] ronald dot muller at gmail dot com
new example url:
http://www.plasticdaisy.net/dlvs/pr/index.php
reports:
Fatal error: Allowed memory size of 33554432 bytes exhausted (tried to
allocate 13056 bytes) in
/mounted-storage/home6a/sub004/sc11402-FHCV/www/dlvs/pr/index.php on
line 5
script contains following lines:
[2009-05-07 12:45:20] ronald dot muller at gmail dot com
Description:
imagecreatefromjpeg() should return FALSE on errors (as documented),
not crash - hence aborting the php script.
http://www.plasticdaisy.net/dlvs/dlvs.php?c=pr
shows "Fatal error: Allowed memory size of 33554432 bytes exhausted"
and aborts the script.
The crash occurs because memory_limit is exceeded, as mentioned in
previous submissions on the same bug. In the example case a 3.8MB jpg is
expanded internally to somewhere in between 32MB and 64MB. Increasing
the memory_limit does not solve the bug, it merely hides it again. The
function should be made according to spec, i.e. return FALSE. Then the
php script can act properly on this error.
Reproduce code:
---
ini_set('memory_limit', $TOO_SMALL);
$someVar = imagecreatefromjpeg($img);
echo $someVar;
Expected result:
return FALSE i.s.o. crash, as documented.
Actual result:
--
Fatal error: Allowed memory size of 33554432 bytes exhausted
http://www.plasticdaisy.net/dlvs/dlvs.php?c=pr
--
Edit this bug report at http://bugs.php.net/?id=48179&edit=1
#48048 [Bgs]: Empty files corrupt zip
ID: 48048
User updated by: php at codecaster dot nl
Reported By: php at codecaster dot nl
Status: Bogus
Bug Type: Zip Related
Operating System: FreeBSD 7
PHP Version: 5.2.9
New Comment:
The function zip_entry_compressedsize returns the compressed file size
(referred to as "directory entry" in the Manual), which is 2 bytes for a
zero-size file. The actual (uncompressed) size returned by
zip_entry_filesize indeed is 0, which is correct, but that was not the
issue.
The problem is that the bsdtar program has only recently been patched
for this issue as can be read here:
http://code.google.com/p/libarchive/issues/detail?id=3
If you would have executed the provided code and opened the zip file in
any program you would have seen the compressed size is 2 bytes, which is
"a silly thing to do, as it only makes the file larger".
We are not always able to patch libarchive/bsdtar, neither are we
always able to use other programs than tar.
Previous Comments:
[2009-05-07 13:02:50] j...@php.net
RTFM:
"zip_entry_compressedsize()
Returns the compressed size of the specified directory entry."
When you use the correct function zip_entry_filesize() the output is 0
as it should be. Also the "corrupt.zip" is not corrupt at all, you can
unzip it just fine with regular unzip found in pretty much every *nix.
:)
[2009-04-28 11:58:44] php at codecaster dot nl
I have installed the latest build, PHP 5.2.10-dev. Same results.
>From phpinfo():
Zip enabled
Extension Version $Id: php_zip.c,v 1.1.2.50 2009/03/01 17:35:25 iliaa
Exp $
Zip version 1.8.11
Libzip version 0.9.0
Updated test script (will output 2, should be 0):
open("corrupt.zip", ZIPARCHIVE::CREATE);
$zip->addFile("empty.txt");
$zip->close();
// open the file, show compressed size (returns 2, should be 0)
if (($zip = zip_open("corrupt.zip"))) {
// read first entry
$zip_entry = zip_read($zip);
echo "Compressed Size: " . zip_entry_compressedsize($zip_entry);
zip_close($zip);
}
?>
[2009-04-22 14:38:46] php at codecaster dot nl
Description:
When you use ZipArchive->addFile() on an empty file, the file will be
compressed anyway. This is incorrectly read by some (older)
decompression programs.
Reproduce code:
---
if (file_put_contents("empty.txt", "") === false) {
die("Cannot write files");
}
$zip = new ZipArchive();
$zip->open("corrupt.zip", ZIPARCHIVE::CREATE);
$zip->addFile("empty.txt");
$zip->close();
Expected result:
A zip file containing empty.txt with a size of 0 bytes and a compressed
size of 0 bytes.
Actual result:
--
A zip file containing empty.txt with a size of 0 bytes and a compressed
size of 2 bytes.
--
Edit this bug report at http://bugs.php.net/?id=48048&edit=1
#48134 [Fbk->Opn]: php crash after a few days (backtrace attached)
ID: 48134 User updated by: jimbobpalmer at gmail dot com Reported By: jimbobpalmer at gmail dot com -Status: Feedback +Status: Open Bug Type: Apache2 related Operating System: Gentoo PHP Version: 5.2.9 New Comment: Yes. Both apache and php are compiled with debug. Previous Comments: [2009-05-07 12:47:33] j...@php.net Was that backtrace really produced with debug build? ie. with PHP build using --enable-debug ?? [2009-05-07 09:26:05] jimbobpalmer at gmail dot com Yes, we use php_admin_value per vhost. I noticed we have a few boolean php_admin_value options. I have changed these to php_admin_flag. [2009-05-07 08:02:43] j...@php.net Do you have some php settings done using the php_value / php_flag / php_admin_value / php_admin_flag directives in httpd.conf, some file included by httpd.conf or some .htaccess file in your filesystem? [2009-05-07 06:53:09] jimbobpalmer at gmail dot com # gdb -q /usr/sbin/apache2 /var/tmp/core.6111 (no debugging symbols found) warning: Can't read pathname for load map: Input/output error. Reading symbols from /lib/libm.so.6...(no debugging symbols found)...done. Loaded symbols for /lib/libm.so.6 Reading symbols from /usr/lib/libpcre.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libpcre.so.0 Reading symbols from /lib/libz.so.1... (no debugging symbols found)...done. Loaded symbols for /lib/libz.so.1 Reading symbols from /lib/libbz2.so.1...(no debugging symbols found)...done. Loaded symbols for /lib/libbz2.so.1 Reading symbols from /usr/lib/libaprutil-1.so.0... (no debugging symbols found)...done. Loaded symbols for /usr/lib/libaprutil-1.so.0 Reading symbols from /usr/lib/libgdbm.so.3...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libgdbm.so.3 Reading symbols from /usr/lib/libdb-4.5.so... (no debugging symbols found)...done. Loaded symbols for /usr/lib/libdb-4.5.so Reading symbols from /usr/lib/libexpat.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libexpat.so.1 Reading symbols from /usr/lib/libapr-1.so.0... (no debugging symbols found)...done. Loaded symbols for /usr/lib/libapr-1.so.0 Reading symbols from /lib/libuuid.so.1...(no debugging symbols found)...done. Loaded symbols for /lib/libuuid.so.1 Reading symbols from /lib/librt.so.1... (no debugging symbols found)...done. Loaded symbols for /lib/librt.so.1 Reading symbols from /lib/libcrypt.so.1...(no debugging symbols found)...done. Loaded symbols for /lib/libcrypt.so.1 Reading symbols from /lib/libpthread.so.0... (no debugging symbols found)...done. Loaded symbols for /lib/libpthread.so.0 Reading symbols from /lib/libdl.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/libdl.so.2 Reading symbols from /lib/libc.so.6... (no debugging symbols found)...done. Loaded symbols for /lib/libc.so.6 Reading symbols from /lib/ld-linux.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/ld-linux.so.2 Reading symbols from /lib/libnsl.so.1... (no debugging symbols found)...done. Loaded symbols for /lib/libnsl.so.1 Reading symbols from /lib/libnss_compat.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/libnss_compat.so.2 Reading symbols from /lib/libnss_nis.so.2... (no debugging symbols found)...done. Loaded symbols for /lib/libnss_nis.so.2 Reading symbols from /lib/libnss_files.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/libnss_files.so.2 Reading symbols from /usr/lib/gcc/i686-pc-linux-gnu/4.3.2/libgcc_s.so.1... (no debugging symbols found)...done. Loaded symbols for /usr/lib/gcc/i686-pc-linux-gnu/4.3.2/libgcc_s.so.1 Reading symbols from /usr/lib/apache2/modules/mod_auth_basic.so...(no debugging symbols found)...done. Loaded symbols for /usr/lib/apache2/modules/mod_auth_basic.so Reading symbols from /usr/lib/apache2/modules/mod_authn_default.so... (no debugging symbols found)...done. Loaded symbols for /usr/lib/apache2/modules/mod_authn_default.so Reading symbols from /usr/lib/apache2/modules/mod_authn_file.so...(no debugging symbols found)...done. Loaded symbols for /usr/lib/apache2/modules/mod_authn_file.so Reading symbols from /usr/lib/apache2/modules/mod_authz_default.so... (no debugging symbols found)...done. Loaded symbols for /usr/lib/apache2/modules/mod_authz_default.so Reading symbols from /usr/lib/apache2/modules/mod_authz_host.so...(no debugging symbols found)...done. Loaded symbols for /usr/lib/apache2/modules/mod_authz_host.so Reading symbols from /usr/lib/apache2/modules/mod_authz_user.so... (no debugging symbols found)...done. Loaded symbols for /usr/lib/apache2/modules/mod_authz_user.so Reading symbols from /usr/lib
#48179 [Fbk->Opn]: imagecreatefromjpeg() crashes i.s.o. return FALSE
ID: 48179
User updated by: ronald dot muller at gmail dot com
Reported By: ronald dot muller at gmail dot com
-Status: Feedback
+Status: Open
Bug Type: GD related
Operating System: *
PHP Version: 5.2.9
New Comment:
new example url:
http://www.plasticdaisy.net/dlvs/pr/index.php
reports:
Fatal error: Allowed memory size of 33554432 bytes exhausted (tried to
allocate 13056 bytes) in
/mounted-storage/home6a/sub004/sc11402-FHCV/www/dlvs/pr/index.php on
line 5
script contains following lines:
Previous Comments:
[2009-05-07 12:51:26] j...@php.net
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 the script requires a
database to demonstrate the issue, please make sure it creates
all necessary tables, stored procedures etc.
Please avoid embedding huge scripts into the report.
[2009-05-07 12:45:20] ronald dot muller at gmail dot com
Description:
imagecreatefromjpeg() should return FALSE on errors (as documented),
not crash - hence aborting the php script.
http://www.plasticdaisy.net/dlvs/dlvs.php?c=pr
shows "Fatal error: Allowed memory size of 33554432 bytes exhausted"
and aborts the script.
The crash occurs because memory_limit is exceeded, as mentioned in
previous submissions on the same bug. In the example case a 3.8MB jpg is
expanded internally to somewhere in between 32MB and 64MB. Increasing
the memory_limit does not solve the bug, it merely hides it again. The
function should be made according to spec, i.e. return FALSE. Then the
php script can act properly on this error.
Reproduce code:
---
ini_set('memory_limit', $TOO_SMALL);
$someVar = imagecreatefromjpeg($img);
echo $someVar;
Expected result:
return FALSE i.s.o. crash, as documented.
Actual result:
--
Fatal error: Allowed memory size of 33554432 bytes exhausted
http://www.plasticdaisy.net/dlvs/dlvs.php?c=pr
--
Edit this bug report at http://bugs.php.net/?id=48179&edit=1
#42765 [NoF->Asn]: PDO ODBC: Long binary field in query result crashes PHP ("Out of memory" error)
ID: 42765 Updated by: skett...@php.net Reported By: sms at inbox dot ru -Status: No Feedback +Status: Assigned Bug Type: PDO related Operating System: Windows 2000 SP4 PHP Version: 5.2.4 Assigned To: pajoye Previous Comments: [2009-05-07 01:00:00] 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". [2009-04-29 10:44:33] skett...@php.net Confirmed not fixed with latest PHP 5.2 snapshot VC6 x86 Thread Safe (2009-Apr-27 00:00:00): Fatal error: Out of memory (allocated 262144) (tried to allocate 4294967295 bytes) Current workaround is getting the length of the image, retrieving chunks of 4096 characters and putting them back together in PHP. SQL-Queries for this workaround look like these: SELECT DATALENGTH(imagefield) AS imagelength FROM imagetable WHERE imageid = ? SELECT CAST(SUBSTRING(imagefield, offset, length) AS VARCHAR(4096)) AS imagechunk FROM imagetable WHERE imageid = ? [2009-04-25 14:50:26] j...@php.net Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://windows.php.net/snapshots/ [2008-10-03 21:41:35] paj...@php.net Thanks for the patches and testing. About compiling php on windows, take a look here: http://wiki.php.net/internals/windows [2008-10-03 15:34:14] jeffreybolle at gmail dot com I had the same problem recently. I'd like to thank csa for the great source code patch. Recompiling the source under windows wasn't easy and it took me many hours to piece together all the software and libraries required. The result was a fixed extension that can access large blob files, this has been tested under Windows Vista 32bit. I thought I'd post a link for the compiled extension (PHP 5.2.6) in case any other windows users want to make use of this fix without going through the hassle of learning how to compile PHP from source. http://s3.paramorphicdesigns.com/random/php/php_pdo_odbc.dll If there are any problems feel free to contact me at jeffreybo...@gmail.com Jeffrey 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/42765 -- Edit this bug report at http://bugs.php.net/?id=42765&edit=1
#48048 [Opn->Bgs]: Empty files corrupt zip
ID: 48048
Updated by: j...@php.net
Reported By: php at codecaster dot nl
-Status: Open
+Status: Bogus
Bug Type: Zip Related
Operating System: FreeBSD 7
PHP Version: 5.2.9
New Comment:
RTFM:
"zip_entry_compressedsize()
Returns the compressed size of the specified directory entry."
When you use the correct function zip_entry_filesize() the output is 0
as it should be. Also the "corrupt.zip" is not corrupt at all, you can
unzip it just fine with regular unzip found in pretty much every *nix.
:)
Previous Comments:
[2009-04-28 11:58:44] php at codecaster dot nl
I have installed the latest build, PHP 5.2.10-dev. Same results.
>From phpinfo():
Zip enabled
Extension Version $Id: php_zip.c,v 1.1.2.50 2009/03/01 17:35:25 iliaa
Exp $
Zip version 1.8.11
Libzip version 0.9.0
Updated test script (will output 2, should be 0):
open("corrupt.zip", ZIPARCHIVE::CREATE);
$zip->addFile("empty.txt");
$zip->close();
// open the file, show compressed size (returns 2, should be 0)
if (($zip = zip_open("corrupt.zip"))) {
// read first entry
$zip_entry = zip_read($zip);
echo "Compressed Size: " . zip_entry_compressedsize($zip_entry);
zip_close($zip);
}
?>
[2009-04-22 14:38:46] php at codecaster dot nl
Description:
When you use ZipArchive->addFile() on an empty file, the file will be
compressed anyway. This is incorrectly read by some (older)
decompression programs.
Reproduce code:
---
if (file_put_contents("empty.txt", "") === false) {
die("Cannot write files");
}
$zip = new ZipArchive();
$zip->open("corrupt.zip", ZIPARCHIVE::CREATE);
$zip->addFile("empty.txt");
$zip->close();
Expected result:
A zip file containing empty.txt with a size of 0 bytes and a compressed
size of 0 bytes.
Actual result:
--
A zip file containing empty.txt with a size of 0 bytes and a compressed
size of 2 bytes.
--
Edit this bug report at http://bugs.php.net/?id=48048&edit=1
#48179 [Opn->Fbk]: imagecreatefromjpeg() crashes i.s.o. return FALSE
ID: 48179
Updated by: j...@php.net
Reported By: ronald dot muller at gmail dot com
-Status: Open
+Status: Feedback
Bug Type: GD related
Operating System: *
PHP Version: 5.2.9
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 the script requires a
database to demonstrate the issue, please make sure it creates
all necessary tables, stored procedures etc.
Please avoid embedding huge scripts into the report.
Previous Comments:
[2009-05-07 12:45:20] ronald dot muller at gmail dot com
Description:
imagecreatefromjpeg() should return FALSE on errors (as documented),
not crash - hence aborting the php script.
http://www.plasticdaisy.net/dlvs/dlvs.php?c=pr
shows "Fatal error: Allowed memory size of 33554432 bytes exhausted"
and aborts the script.
The crash occurs because memory_limit is exceeded, as mentioned in
previous submissions on the same bug. In the example case a 3.8MB jpg is
expanded internally to somewhere in between 32MB and 64MB. Increasing
the memory_limit does not solve the bug, it merely hides it again. The
function should be made according to spec, i.e. return FALSE. Then the
php script can act properly on this error.
Reproduce code:
---
ini_set('memory_limit', $TOO_SMALL);
$someVar = imagecreatefromjpeg($img);
echo $someVar;
Expected result:
return FALSE i.s.o. crash, as documented.
Actual result:
--
Fatal error: Allowed memory size of 33554432 bytes exhausted
http://www.plasticdaisy.net/dlvs/dlvs.php?c=pr
--
Edit this bug report at http://bugs.php.net/?id=48179&edit=1
#48134 [Opn->Fbk]: php crash after a few days (backtrace attached)
ID: 48134 Updated by: j...@php.net Reported By: jimbobpalmer at gmail dot com -Status: Open +Status: Feedback Bug Type: Apache2 related Operating System: Gentoo PHP Version: 5.2.9 New Comment: Was that backtrace really produced with debug build? ie. with PHP build using --enable-debug ?? Previous Comments: [2009-05-07 09:26:05] jimbobpalmer at gmail dot com Yes, we use php_admin_value per vhost. I noticed we have a few boolean php_admin_value options. I have changed these to php_admin_flag. [2009-05-07 08:02:43] j...@php.net Do you have some php settings done using the php_value / php_flag / php_admin_value / php_admin_flag directives in httpd.conf, some file included by httpd.conf or some .htaccess file in your filesystem? [2009-05-07 06:53:09] jimbobpalmer at gmail dot com # gdb -q /usr/sbin/apache2 /var/tmp/core.6111 (no debugging symbols found) warning: Can't read pathname for load map: Input/output error. Reading symbols from /lib/libm.so.6...(no debugging symbols found)...done. Loaded symbols for /lib/libm.so.6 Reading symbols from /usr/lib/libpcre.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libpcre.so.0 Reading symbols from /lib/libz.so.1... (no debugging symbols found)...done. Loaded symbols for /lib/libz.so.1 Reading symbols from /lib/libbz2.so.1...(no debugging symbols found)...done. Loaded symbols for /lib/libbz2.so.1 Reading symbols from /usr/lib/libaprutil-1.so.0... (no debugging symbols found)...done. Loaded symbols for /usr/lib/libaprutil-1.so.0 Reading symbols from /usr/lib/libgdbm.so.3...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libgdbm.so.3 Reading symbols from /usr/lib/libdb-4.5.so... (no debugging symbols found)...done. Loaded symbols for /usr/lib/libdb-4.5.so Reading symbols from /usr/lib/libexpat.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libexpat.so.1 Reading symbols from /usr/lib/libapr-1.so.0... (no debugging symbols found)...done. Loaded symbols for /usr/lib/libapr-1.so.0 Reading symbols from /lib/libuuid.so.1...(no debugging symbols found)...done. Loaded symbols for /lib/libuuid.so.1 Reading symbols from /lib/librt.so.1... (no debugging symbols found)...done. Loaded symbols for /lib/librt.so.1 Reading symbols from /lib/libcrypt.so.1...(no debugging symbols found)...done. Loaded symbols for /lib/libcrypt.so.1 Reading symbols from /lib/libpthread.so.0... (no debugging symbols found)...done. Loaded symbols for /lib/libpthread.so.0 Reading symbols from /lib/libdl.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/libdl.so.2 Reading symbols from /lib/libc.so.6... (no debugging symbols found)...done. Loaded symbols for /lib/libc.so.6 Reading symbols from /lib/ld-linux.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/ld-linux.so.2 Reading symbols from /lib/libnsl.so.1... (no debugging symbols found)...done. Loaded symbols for /lib/libnsl.so.1 Reading symbols from /lib/libnss_compat.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/libnss_compat.so.2 Reading symbols from /lib/libnss_nis.so.2... (no debugging symbols found)...done. Loaded symbols for /lib/libnss_nis.so.2 Reading symbols from /lib/libnss_files.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/libnss_files.so.2 Reading symbols from /usr/lib/gcc/i686-pc-linux-gnu/4.3.2/libgcc_s.so.1... (no debugging symbols found)...done. Loaded symbols for /usr/lib/gcc/i686-pc-linux-gnu/4.3.2/libgcc_s.so.1 Reading symbols from /usr/lib/apache2/modules/mod_auth_basic.so...(no debugging symbols found)...done. Loaded symbols for /usr/lib/apache2/modules/mod_auth_basic.so Reading symbols from /usr/lib/apache2/modules/mod_authn_default.so... (no debugging symbols found)...done. Loaded symbols for /usr/lib/apache2/modules/mod_authn_default.so Reading symbols from /usr/lib/apache2/modules/mod_authn_file.so...(no debugging symbols found)...done. Loaded symbols for /usr/lib/apache2/modules/mod_authn_file.so Reading symbols from /usr/lib/apache2/modules/mod_authz_default.so... (no debugging symbols found)...done. Loaded symbols for /usr/lib/apache2/modules/mod_authz_default.so Reading symbols from /usr/lib/apache2/modules/mod_authz_host.so...(no debugging symbols found)...done. Loaded symbols for /usr/lib/apache2/modules/mod_authz_host.so Reading symbols from /usr/lib/apache2/modules/mod_authz_user.so... (no debugging symbols found)...done. Loaded symbols for /usr/lib/apache2/modules/mod_authz_user.so Reading symbols from /usr/lib/apache2/modules/mod_headers.so...(no debugging symbols found)...done. Loaded symbols for /usr/lib/apache2/modules/mod_headers.so Reading symbols from /usr/lib/apache2/modules/mo
#48179 [NEW]: imagecreatefromjpeg() crashes i.s.o. return FALSE
From: ronald dot muller at gmail dot com
Operating system: apache
PHP version: 5.2.9
PHP Bug Type: GD related
Bug description: imagecreatefromjpeg() crashes i.s.o. return FALSE
Description:
imagecreatefromjpeg() should return FALSE on errors (as documented), not
crash - hence aborting the php script.
http://www.plasticdaisy.net/dlvs/dlvs.php?c=pr
shows "Fatal error: Allowed memory size of 33554432 bytes exhausted" and
aborts the script.
The crash occurs because memory_limit is exceeded, as mentioned in
previous submissions on the same bug. In the example case a 3.8MB jpg is
expanded internally to somewhere in between 32MB and 64MB. Increasing the
memory_limit does not solve the bug, it merely hides it again. The function
should be made according to spec, i.e. return FALSE. Then the php script
can act properly on this error.
Reproduce code:
---
ini_set('memory_limit', $TOO_SMALL);
$someVar = imagecreatefromjpeg($img);
echo $someVar;
Expected result:
return FALSE i.s.o. crash, as documented.
Actual result:
--
Fatal error: Allowed memory size of 33554432 bytes exhausted
http://www.plasticdaisy.net/dlvs/dlvs.php?c=pr
--
Edit bug report at http://bugs.php.net/?id=48179&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=48179&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=48179&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=48179&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=48179&r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=48179&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=48179&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=48179&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=48179&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=48179&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=48179&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=48179&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=48179&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=48179&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=48179&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48179&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=48179&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=48179&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=48179&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=48179&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=48179&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=48179&r=mysqlcfg
#48175 [Opn]: FILE_IGNORE_NEW_LINES don't remove "\r\n"
ID: 48175 Updated by: j...@php.net Reported By: carsten_sttgt at gmx dot de Status: Open Bug Type: Filesystem function related Operating System: * PHP Version: 5.2.9 New Comment: See also bug #44034 Previous Comments: [2009-05-07 09:23:02] carsten_sttgt at gmx dot de Description: Hello, if I use FILE_IGNORE_NEW_LINES with file(), a "\r\n" will not be removed. It works with a single "\r" or "\n". (Tested on *nix and Windows.) Regards, Carsten Reproduce code: --- Expected result: 101 101 101 Actual result: -- 101 101 13 -- Edit this bug report at http://bugs.php.net/?id=48175&edit=1
#48048 [NoF->Opn]: Empty files corrupt zip
ID: 48048
User updated by: php at codecaster dot nl
Reported By: php at codecaster dot nl
-Status: No Feedback
+Status: Open
Bug Type: Zip Related
Operating System: FreeBSD 7
PHP Version: 5.2.9
New Comment:
It still doesn't work so should I reopen this?
Previous Comments:
[2009-05-03 01:00:21] 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".
[2009-04-28 11:58:44] php at codecaster dot nl
I have installed the latest build, PHP 5.2.10-dev. Same results.
>From phpinfo():
Zip enabled
Extension Version $Id: php_zip.c,v 1.1.2.50 2009/03/01 17:35:25 iliaa
Exp $
Zip version 1.8.11
Libzip version 0.9.0
Updated test script (will output 2, should be 0):
open("corrupt.zip", ZIPARCHIVE::CREATE);
$zip->addFile("empty.txt");
$zip->close();
// open the file, show compressed size (returns 2, should be 0)
if (($zip = zip_open("corrupt.zip"))) {
// read first entry
$zip_entry = zip_read($zip);
echo "Compressed Size: " . zip_entry_compressedsize($zip_entry);
zip_close($zip);
}
?>
[2009-04-25 16:07:18] j...@php.net
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
I can't reproduce this with latest CVS checkout of PHP_5_2.
[2009-04-22 14:38:46] php at codecaster dot nl
Description:
When you use ZipArchive->addFile() on an empty file, the file will be
compressed anyway. This is incorrectly read by some (older)
decompression programs.
Reproduce code:
---
if (file_put_contents("empty.txt", "") === false) {
die("Cannot write files");
}
$zip = new ZipArchive();
$zip->open("corrupt.zip", ZIPARCHIVE::CREATE);
$zip->addFile("empty.txt");
$zip->close();
Expected result:
A zip file containing empty.txt with a size of 0 bytes and a compressed
size of 0 bytes.
Actual result:
--
A zip file containing empty.txt with a size of 0 bytes and a compressed
size of 2 bytes.
--
Edit this bug report at http://bugs.php.net/?id=48048&edit=1
#48177 [Bgs]: Cannot wrap eval'd code with HTML
ID: 48177
User updated by: skds1433 at hotmail dot com
Reported By: skds1433 at hotmail dot com
Status: Bogus
Bug Type: Unknown/Other Function
Operating System: Windows Vista
PHP Version: 5.2.9
New Comment:
Thank you for the explanation, that makes a lot of sense now that you
mention it. Sorry for wasting your time.
Previous Comments:
[2009-05-07 10:38:39] matt...@php.net
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
eval() doesn't return anything but NULL unless a return statement is
used in the eval'd code (wouldn't work in this case with inline HTML
anyway, which gets echo'd immediately). You'd need to 1) echo "";
before the eval() call, 2) use eval('return "testing 123, a string, not
HTML...";'), or 3) use output buffering, etc.
[2009-05-07 10:22:38] skds1433 at hotmail dot com
Changed category, from 'Output Control'. Not really sure what this
applies to.
[2009-05-07 10:13:29] skds1433 at hotmail dot com
Description:
For debugging purposes of a template system, I am trying to wrap the
output of an eval inside pre HTML tags. Oddly, the tags are simply being
appended.
PHP version: 5.2.9-2
Apache: 2.2.11
Reproduce code:
---
testing1 "testing2 extended" "testing3 extended")0123456789
012345678901234567890123456789
testing4 testing5 ';
$buffer = eval("?>".$buffer);
echo "".$buffer."";
?>
Expected result:
testing 1 2 3, test test test test.
0123456789012345678901234567890123456789
012345678901234567890123456789
0123456789012345678901234567890123456789()0123456789
012345678901234567890123456789
Actual result:
--
testing 1 2 3, test test test test.
0123456789012345678901234567890123456789
012345678901234567890123456789
0123456789012345678901234567890123456789()0123456789
012345678901234567890123456789
--
Edit this bug report at http://bugs.php.net/?id=48177&edit=1
#48178 [Com]: Error in test DateTimeZone_getOffset_basic1.phpt
ID: 48178 Comment by: tobias dot john at fondsnet dot de Reported By: tobias dot john at fondsnet dot de Status: Open Bug Type: Date/time related Operating System: All PHP Version: 5.3.0RC1 New Comment: Ups sorry. Postet the wrong patch. This is the correct one. --- DateTimeZone_getOffset_basic1.phpt.orig 2009-05-07 12:30:07.0 +0200 +++ DateTimeZone_getOffset_basic1.phpt 2009-05-07 12:30:53.0 +0200 @@ -27,7 +27,7 @@ ===DONE=== --EXPECTF-- *** Testing DateTimeZone::getOffset() : basic functionality *** -int(0) +%rint\(0\)|int\(3600\)%r %rint\(-18000\)|int\(-14400\)%r %rint\(-28800\)|int\(-25200\)%r ===DONE=== Previous Comments: [2009-05-07 10:37:38] tobias dot john at fondsnet dot de Here is a patch. --- DateTimeZone_getOffset_basic1.phpt.orig 2009-05-07 12:30:07.0 +0200 +++ DateTimeZone_getOffset_basic1.phpt 2009-05-07 12:30:53.0 +0200 @@ -27,7 +27,7 @@ ===DONE=== --EXPECTF-- *** Testing DateTimeZone::getOffset() : basic functionality *** -int(0) +%rint(0\)|int\(3600)%r %rint\(-18000\)|int\(-14400\)%r %rint\(-28800\)|int\(-25200\)%r ===DONE=== [2009-05-07 10:28:57] tobias dot john at fondsnet dot de Description: The Europe/London timezone switched to daylight saving. See: http://www.convertunits.com/time/zone/Europe/London The GMT timezone has no daylight saving. So the offset of the Europe/London timezone ist either 0 or 3600 not always 0. -- Edit this bug report at http://bugs.php.net/?id=48178&edit=1
#48177 [Opn->Bgs]: Cannot wrap eval'd code with HTML
ID: 48177
Updated by: matt...@php.net
Reported By: skds1433 at hotmail dot com
-Status: Open
+Status: Bogus
Bug Type: Unknown/Other Function
Operating System: Windows Vista
PHP Version: 5.2.9
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
eval() doesn't return anything but NULL unless a return statement is
used in the eval'd code (wouldn't work in this case with inline HTML
anyway, which gets echo'd immediately). You'd need to 1) echo "";
before the eval() call, 2) use eval('return "testing 123, a string, not
HTML...";'), or 3) use output buffering, etc.
Previous Comments:
[2009-05-07 10:22:38] skds1433 at hotmail dot com
Changed category, from 'Output Control'. Not really sure what this
applies to.
[2009-05-07 10:13:29] skds1433 at hotmail dot com
Description:
For debugging purposes of a template system, I am trying to wrap the
output of an eval inside pre HTML tags. Oddly, the tags are simply being
appended.
PHP version: 5.2.9-2
Apache: 2.2.11
Reproduce code:
---
testing1 "testing2 extended" "testing3 extended")0123456789
012345678901234567890123456789
testing4 testing5 ';
$buffer = eval("?>".$buffer);
echo "".$buffer."";
?>
Expected result:
testing 1 2 3, test test test test.
0123456789012345678901234567890123456789
012345678901234567890123456789
0123456789012345678901234567890123456789()0123456789
012345678901234567890123456789
Actual result:
--
testing 1 2 3, test test test test.
0123456789012345678901234567890123456789
012345678901234567890123456789
0123456789012345678901234567890123456789()0123456789
012345678901234567890123456789
--
Edit this bug report at http://bugs.php.net/?id=48177&edit=1
#48178 [Com]: Error in test DateTimeZone_getOffset_basic1.phpt
ID: 48178 Comment by: tobias dot john at fondsnet dot de Reported By: tobias dot john at fondsnet dot de Status: Open Bug Type: Date/time related Operating System: All PHP Version: 5.3.0RC1 New Comment: Here is a patch. --- DateTimeZone_getOffset_basic1.phpt.orig 2009-05-07 12:30:07.0 +0200 +++ DateTimeZone_getOffset_basic1.phpt 2009-05-07 12:30:53.0 +0200 @@ -27,7 +27,7 @@ ===DONE=== --EXPECTF-- *** Testing DateTimeZone::getOffset() : basic functionality *** -int(0) +%rint(0\)|int\(3600)%r %rint\(-18000\)|int\(-14400\)%r %rint\(-28800\)|int\(-25200\)%r ===DONE=== Previous Comments: [2009-05-07 10:28:57] tobias dot john at fondsnet dot de Description: The Europe/London timezone switched to daylight saving. See: http://www.convertunits.com/time/zone/Europe/London The GMT timezone has no daylight saving. So the offset of the Europe/London timezone ist either 0 or 3600 not always 0. -- Edit this bug report at http://bugs.php.net/?id=48178&edit=1
#48178 [NEW]: Error in test DateTimeZone_getOffset_basic1.phpt
From: tobias dot john at fondsnet dot de Operating system: All PHP version: 5.3.0RC1 PHP Bug Type: Date/time related Bug description: Error in test DateTimeZone_getOffset_basic1.phpt Description: The Europe/London timezone switched to daylight saving. See: http://www.convertunits.com/time/zone/Europe/London The GMT timezone has no daylight saving. So the offset of the Europe/London timezone ist either 0 or 3600 not always 0. -- Edit bug report at http://bugs.php.net/?id=48178&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=48178&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=48178&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=48178&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=48178&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=48178&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=48178&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=48178&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=48178&r=needscript Try newer version: http://bugs.php.net/fix.php?id=48178&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=48178&r=support Expected behavior: http://bugs.php.net/fix.php?id=48178&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=48178&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=48178&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=48178&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48178&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=48178&r=dst IIS Stability: http://bugs.php.net/fix.php?id=48178&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=48178&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=48178&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=48178&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=48178&r=mysqlcfg
#48177 [Opn]: Cannot wrap eval'd code with HTML
ID: 48177
User updated by: skds1433 at hotmail dot com
Reported By: skds1433 at hotmail dot com
Status: Open
-Bug Type: Output Control
+Bug Type: Unknown/Other Function
Operating System: Windows Vista
PHP Version: 5.2.9
New Comment:
Changed category, from 'Output Control'. Not really sure what this
applies to.
Previous Comments:
[2009-05-07 10:13:29] skds1433 at hotmail dot com
Description:
For debugging purposes of a template system, I am trying to wrap the
output of an eval inside pre HTML tags. Oddly, the tags are simply being
appended.
PHP version: 5.2.9-2
Apache: 2.2.11
Reproduce code:
---
testing1 "testing2 extended" "testing3 extended")0123456789
012345678901234567890123456789
testing4 testing5 ';
$buffer = eval("?>".$buffer);
echo "".$buffer."";
?>
Expected result:
testing 1 2 3, test test test test.
0123456789012345678901234567890123456789
012345678901234567890123456789
0123456789012345678901234567890123456789()0123456789
012345678901234567890123456789
Actual result:
--
testing 1 2 3, test test test test.
0123456789012345678901234567890123456789
012345678901234567890123456789
0123456789012345678901234567890123456789()0123456789
012345678901234567890123456789
--
Edit this bug report at http://bugs.php.net/?id=48177&edit=1
#48177 [NEW]: Cannot wrap eval'd code with HTML
From: skds1433 at hotmail dot com
Operating system: Windows Vista
PHP version: 5.2.9
PHP Bug Type: Output Control
Bug description: Cannot wrap eval'd code with HTML
Description:
For debugging purposes of a template system, I am trying to wrap the
output of an eval inside pre HTML tags. Oddly, the tags are simply being
appended.
PHP version: 5.2.9-2
Apache: 2.2.11
Reproduce code:
---
testing1 "testing2 extended" "testing3 extended")0123456789
012345678901234567890123456789
testing4 testing5 ';
$buffer = eval("?>".$buffer);
echo "".$buffer."";
?>
Expected result:
testing 1 2 3, test test test test.
0123456789012345678901234567890123456789
012345678901234567890123456789
0123456789012345678901234567890123456789()0123456789
012345678901234567890123456789
Actual result:
--
testing 1 2 3, test test test test.
0123456789012345678901234567890123456789
012345678901234567890123456789
0123456789012345678901234567890123456789()0123456789
012345678901234567890123456789
--
Edit bug report at http://bugs.php.net/?id=48177&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=48177&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=48177&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=48177&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=48177&r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=48177&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=48177&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=48177&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=48177&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=48177&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=48177&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=48177&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=48177&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=48177&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=48177&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48177&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=48177&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=48177&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=48177&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=48177&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=48177&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=48177&r=mysqlcfg
#47351 [Com]: Memory leak in DateTime
ID: 47351
Comment by: tobias dot john at fondsnet dot de
Reported By: tobias dot john at fondsnet dot de
Status: Assigned
Bug Type: Date/time related
Operating System: Mac OS X 10.5
PHP Version: 5.3.0beta1
Assigned To: derick
New Comment:
I use this patch for 5.3.0RC1.
--- php-5.3.0RC1/ext/date/php_date.c2009-01-27 14:48:10.0
+0100
+++ php-5.3.0RC1patched/ext/date/php_date.c 2009-05-07
10:54:48.0 +0200
@@ -2362,7 +2362,7 @@
}
timelib_unixtime2local(now, (timelib_sll) time(NULL));
- timelib_fill_holes(dateobj->time, now, 0);
+ timelib_fill_holes(dateobj->time, now, TIMELIB_NO_CLONE);
timelib_update_ts(dateobj->time, tzi);
dateobj->time->have_relative = 0;
Previous Comments:
[2009-03-11 15:29:23] bloudon at townnews dot com
This patch against 5.2.9 seems to be working out for us so far:
--- ext/date/php_date.orig.c2009-03-10 15:02:40.0 -0500
+++ ext/date/php_date.c 2009-03-10 15:02:57.0 -0500
@@ -1737,7 +1737,7 @@
}
timelib_unixtime2local(now, (timelib_sll) time(NULL));
- timelib_fill_holes(dateobj->time, now, 0);
+ timelib_fill_holes(dateobj->time, now, TIMELIB_NO_CLONE);
timelib_update_ts(dateobj->time, tzi);
dateobj->time->have_weekday_relative = dateobj->time->have_relative
= 0;
[2009-03-05 17:39:39] bloudon at townnews dot com
Same bug found in PHP versions 5.2.8 and 5.2.9 on Linux.
-
Test code:
for ( $i = 0; $i < 100; $i++ ) {
$d = new DateTime();
unset($d);
}
-
valgrind --leak-check=yes php test.php:
==20642== 235 bytes in 1 blocks are possibly lost in loss record 4 of
12
==20642==at 0x40203C0: malloc (vg_replace_malloc.c:149)
==20642==by 0x80AB486: timelib_tzinfo_clone (in /usr/bin/php)
==20642==by 0x8097FD3: timelib_fill_holes (in /usr/bin/php)
==20642==by 0x8095535: (within /usr/bin/php)
==20642==by 0x8095605: zim_DateTime___construct (in /usr/bin/php)
==20642==by 0x817D834: (within /usr/bin/php)
==20642==by 0x819ED4F: execute (in /usr/bin/php)
==20642==by 0x8166F25: zend_execute_scripts (in /usr/bin/php)
==20642==by 0x813862F: php_execute_script (in /usr/bin/php)
==20642==by 0x81A7178: main (in /usr/bin/php)
==20642==
==20642==
==20642== 2,820 bytes in 3 blocks are possibly lost in loss record 8 of
12
==20642==at 0x40203C0: malloc (vg_replace_malloc.c:149)
==20642==by 0x80AB47A: timelib_tzinfo_clone (in /usr/bin/php)
==20642==by 0x8097FD3: timelib_fill_holes (in /usr/bin/php)
==20642==by 0x8095535: (within /usr/bin/php)
==20642==by 0x8095605: zim_DateTime___construct (in /usr/bin/php)
==20642==by 0x817D834: (within /usr/bin/php)
==20642==by 0x819ED4F: execute (in /usr/bin/php)
==20642==by 0x8166F25: zend_execute_scripts (in /usr/bin/php)
==20642==by 0x813862F: php_execute_script (in /usr/bin/php)
==20642==by 0x81A7178: main (in /usr/bin/php)
==20642==
==20642==
==20642== 132,845 (4,800 direct, 128,045 indirect) bytes in 100 blocks
are definitely lost in loss record 9 of 12
==20642==at 0x401F6FF: calloc (vg_replace_malloc.c:279)
==20642==by 0x80AB420: timelib_tzinfo_ctor (in /usr/bin/php)
==20642==by 0x80AB446: timelib_tzinfo_clone (in /usr/bin/php)
==20642==by 0x8097FD3: timelib_fill_holes (in /usr/bin/php)
==20642==by 0x8095535: (within /usr/bin/php)
==20642==by 0x8095605: zim_DateTime___construct (in /usr/bin/php)
==20642==by 0x817D834: (within /usr/bin/php)
==20642==by 0x819ED4F: execute (in /usr/bin/php)
==20642==by 0x8166F25: zend_execute_scripts (in /usr/bin/php)
==20642==by 0x813862F: php_execute_script (in /usr/bin/php)
==20642==by 0x81A7178: main (in /usr/bin/php)
-
Setting a default time zone through date_default_timezone_set() or
putenv() changes the leak to:
==20819== 7,600 (4,800 direct, 2,800 indirect) bytes in 100 blocks are
definitely lost in loss record 10 of 10
==20819==at 0x401F6FF: calloc (vg_replace_malloc.c:279)
==20819==by 0x80AB420: timelib_tzinfo_ctor (in /usr/bin/php)
==20819==by 0x80AB446: timelib_tzinfo_clone (in /usr/bin/php)
==20819==by 0x8097FD3: timelib_fill_holes (in /usr/bin/php)
==20819==by 0x8095535: (within /usr/bin/php)
==20819==by 0x8095605: zim_DateTime___construct (in /usr/bin/php)
==20819==by 0x817D834: (within /usr/bin/php)
==20819==by 0x819ED4F: execute (in /usr/bin/php)
==20819==by 0x8166F25: zend_execute_scripts (in /usr/bin/php)
==20819==by 0x813862F: php_execute_script (in /usr/bin/php)
==20819==by 0x81A7178: main (in /usr/bin/php)
[2009-02-23 13:49:09] paul dot assen at xs4all dot nl
I found this bug also to be present in PHP 5.2.8 under Windows XP
--
#48134 [Fbk->Opn]: php crash after a few days (backtrace attached)
ID: 48134 User updated by: jimbobpalmer at gmail dot com Reported By: jimbobpalmer at gmail dot com -Status: Feedback +Status: Open Bug Type: Apache2 related Operating System: Gentoo PHP Version: 5.2.9 New Comment: Yes, we use php_admin_value per vhost. I noticed we have a few boolean php_admin_value options. I have changed these to php_admin_flag. Previous Comments: [2009-05-07 08:02:43] j...@php.net Do you have some php settings done using the php_value / php_flag / php_admin_value / php_admin_flag directives in httpd.conf, some file included by httpd.conf or some .htaccess file in your filesystem? [2009-05-07 06:53:09] jimbobpalmer at gmail dot com # gdb -q /usr/sbin/apache2 /var/tmp/core.6111 (no debugging symbols found) warning: Can't read pathname for load map: Input/output error. Reading symbols from /lib/libm.so.6...(no debugging symbols found)...done. Loaded symbols for /lib/libm.so.6 Reading symbols from /usr/lib/libpcre.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libpcre.so.0 Reading symbols from /lib/libz.so.1... (no debugging symbols found)...done. Loaded symbols for /lib/libz.so.1 Reading symbols from /lib/libbz2.so.1...(no debugging symbols found)...done. Loaded symbols for /lib/libbz2.so.1 Reading symbols from /usr/lib/libaprutil-1.so.0... (no debugging symbols found)...done. Loaded symbols for /usr/lib/libaprutil-1.so.0 Reading symbols from /usr/lib/libgdbm.so.3...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libgdbm.so.3 Reading symbols from /usr/lib/libdb-4.5.so... (no debugging symbols found)...done. Loaded symbols for /usr/lib/libdb-4.5.so Reading symbols from /usr/lib/libexpat.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libexpat.so.1 Reading symbols from /usr/lib/libapr-1.so.0... (no debugging symbols found)...done. Loaded symbols for /usr/lib/libapr-1.so.0 Reading symbols from /lib/libuuid.so.1...(no debugging symbols found)...done. Loaded symbols for /lib/libuuid.so.1 Reading symbols from /lib/librt.so.1... (no debugging symbols found)...done. Loaded symbols for /lib/librt.so.1 Reading symbols from /lib/libcrypt.so.1...(no debugging symbols found)...done. Loaded symbols for /lib/libcrypt.so.1 Reading symbols from /lib/libpthread.so.0... (no debugging symbols found)...done. Loaded symbols for /lib/libpthread.so.0 Reading symbols from /lib/libdl.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/libdl.so.2 Reading symbols from /lib/libc.so.6... (no debugging symbols found)...done. Loaded symbols for /lib/libc.so.6 Reading symbols from /lib/ld-linux.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/ld-linux.so.2 Reading symbols from /lib/libnsl.so.1... (no debugging symbols found)...done. Loaded symbols for /lib/libnsl.so.1 Reading symbols from /lib/libnss_compat.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/libnss_compat.so.2 Reading symbols from /lib/libnss_nis.so.2... (no debugging symbols found)...done. Loaded symbols for /lib/libnss_nis.so.2 Reading symbols from /lib/libnss_files.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/libnss_files.so.2 Reading symbols from /usr/lib/gcc/i686-pc-linux-gnu/4.3.2/libgcc_s.so.1... (no debugging symbols found)...done. Loaded symbols for /usr/lib/gcc/i686-pc-linux-gnu/4.3.2/libgcc_s.so.1 Reading symbols from /usr/lib/apache2/modules/mod_auth_basic.so...(no debugging symbols found)...done. Loaded symbols for /usr/lib/apache2/modules/mod_auth_basic.so Reading symbols from /usr/lib/apache2/modules/mod_authn_default.so... (no debugging symbols found)...done. Loaded symbols for /usr/lib/apache2/modules/mod_authn_default.so Reading symbols from /usr/lib/apache2/modules/mod_authn_file.so...(no debugging symbols found)...done. Loaded symbols for /usr/lib/apache2/modules/mod_authn_file.so Reading symbols from /usr/lib/apache2/modules/mod_authz_default.so... (no debugging symbols found)...done. Loaded symbols for /usr/lib/apache2/modules/mod_authz_default.so Reading symbols from /usr/lib/apache2/modules/mod_authz_host.so...(no debugging symbols found)...done. Loaded symbols for /usr/lib/apache2/modules/mod_authz_host.so Reading symbols from /usr/lib/apache2/modules/mod_authz_user.so... (no debugging symbols found)...done. Loaded symbols for /usr/lib/apache2/modules/mod_authz_user.so Reading symbols from /usr/lib/apache2/modules/mod_headers.so...(no debugging symbols found)...done. Loaded symbols for /usr/lib/apache2/modules/mod_headers.so Reading symbols from /usr/lib/apache2/modules/mod_log_config.so... (no debugging symbols found)...done. Loaded symbols for /usr/lib/apache2/modules/mod_log_config.so Reading symbols from /usr/lib/apache2/modules/mod_rewrite.so...(no debugging symbols found)
#48175 [NEW]: FILE_IGNORE_NEW_LINES don't remove "\r\n"
From: carsten_sttgt at gmx dot de Operating system: Irrelevant PHP version: 5.2.9 PHP Bug Type: Filesystem function related Bug description: FILE_IGNORE_NEW_LINES don't remove "\r\n" Description: Hello, if I use FILE_IGNORE_NEW_LINES with file(), a "\r\n" will not be removed. It works with a single "\r" or "\n". (Tested on *nix and Windows.) Regards, Carsten Reproduce code: --- Expected result: 101 101 101 Actual result: -- 101 101 13 -- Edit bug report at http://bugs.php.net/?id=48175&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=48175&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=48175&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=48175&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=48175&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=48175&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=48175&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=48175&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=48175&r=needscript Try newer version: http://bugs.php.net/fix.php?id=48175&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=48175&r=support Expected behavior: http://bugs.php.net/fix.php?id=48175&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=48175&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=48175&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=48175&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48175&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=48175&r=dst IIS Stability: http://bugs.php.net/fix.php?id=48175&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=48175&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=48175&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=48175&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=48175&r=mysqlcfg
#48134 [Opn->Fbk]: php crash after a few days (backtrace attached)
ID: 48134 Updated by: j...@php.net Reported By: jimbobpalmer at gmail dot com -Status: Open +Status: Feedback -Bug Type: Reproducible crash +Bug Type: Apache2 related Operating System: Gentoo PHP Version: 5.2.9 New Comment: Do you have some php settings done using the php_value / php_flag / php_admin_value / php_admin_flag directives in httpd.conf, some file included by httpd.conf or some .htaccess file in your filesystem? Previous Comments: [2009-05-07 06:53:09] jimbobpalmer at gmail dot com # gdb -q /usr/sbin/apache2 /var/tmp/core.6111 (no debugging symbols found) warning: Can't read pathname for load map: Input/output error. Reading symbols from /lib/libm.so.6...(no debugging symbols found)...done. Loaded symbols for /lib/libm.so.6 Reading symbols from /usr/lib/libpcre.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libpcre.so.0 Reading symbols from /lib/libz.so.1... (no debugging symbols found)...done. Loaded symbols for /lib/libz.so.1 Reading symbols from /lib/libbz2.so.1...(no debugging symbols found)...done. Loaded symbols for /lib/libbz2.so.1 Reading symbols from /usr/lib/libaprutil-1.so.0... (no debugging symbols found)...done. Loaded symbols for /usr/lib/libaprutil-1.so.0 Reading symbols from /usr/lib/libgdbm.so.3...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libgdbm.so.3 Reading symbols from /usr/lib/libdb-4.5.so... (no debugging symbols found)...done. Loaded symbols for /usr/lib/libdb-4.5.so Reading symbols from /usr/lib/libexpat.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libexpat.so.1 Reading symbols from /usr/lib/libapr-1.so.0... (no debugging symbols found)...done. Loaded symbols for /usr/lib/libapr-1.so.0 Reading symbols from /lib/libuuid.so.1...(no debugging symbols found)...done. Loaded symbols for /lib/libuuid.so.1 Reading symbols from /lib/librt.so.1... (no debugging symbols found)...done. Loaded symbols for /lib/librt.so.1 Reading symbols from /lib/libcrypt.so.1...(no debugging symbols found)...done. Loaded symbols for /lib/libcrypt.so.1 Reading symbols from /lib/libpthread.so.0... (no debugging symbols found)...done. Loaded symbols for /lib/libpthread.so.0 Reading symbols from /lib/libdl.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/libdl.so.2 Reading symbols from /lib/libc.so.6... (no debugging symbols found)...done. Loaded symbols for /lib/libc.so.6 Reading symbols from /lib/ld-linux.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/ld-linux.so.2 Reading symbols from /lib/libnsl.so.1... (no debugging symbols found)...done. Loaded symbols for /lib/libnsl.so.1 Reading symbols from /lib/libnss_compat.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/libnss_compat.so.2 Reading symbols from /lib/libnss_nis.so.2... (no debugging symbols found)...done. Loaded symbols for /lib/libnss_nis.so.2 Reading symbols from /lib/libnss_files.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/libnss_files.so.2 Reading symbols from /usr/lib/gcc/i686-pc-linux-gnu/4.3.2/libgcc_s.so.1... (no debugging symbols found)...done. Loaded symbols for /usr/lib/gcc/i686-pc-linux-gnu/4.3.2/libgcc_s.so.1 Reading symbols from /usr/lib/apache2/modules/mod_auth_basic.so...(no debugging symbols found)...done. Loaded symbols for /usr/lib/apache2/modules/mod_auth_basic.so Reading symbols from /usr/lib/apache2/modules/mod_authn_default.so... (no debugging symbols found)...done. Loaded symbols for /usr/lib/apache2/modules/mod_authn_default.so Reading symbols from /usr/lib/apache2/modules/mod_authn_file.so...(no debugging symbols found)...done. Loaded symbols for /usr/lib/apache2/modules/mod_authn_file.so Reading symbols from /usr/lib/apache2/modules/mod_authz_default.so... (no debugging symbols found)...done. Loaded symbols for /usr/lib/apache2/modules/mod_authz_default.so Reading symbols from /usr/lib/apache2/modules/mod_authz_host.so...(no debugging symbols found)...done. Loaded symbols for /usr/lib/apache2/modules/mod_authz_host.so Reading symbols from /usr/lib/apache2/modules/mod_authz_user.so... (no debugging symbols found)...done. Loaded symbols for /usr/lib/apache2/modules/mod_authz_user.so Reading symbols from /usr/lib/apache2/modules/mod_headers.so...(no debugging symbols found)...done. Loaded symbols for /usr/lib/apache2/modules/mod_headers.so Reading symbols from /usr/lib/apache2/modules/mod_log_config.so... (no debugging symbols found)...done. Loaded symbols for /usr/lib/apache2/modules/mod_log_config.so Reading symbols from /usr/lib/apache2/modules/mod_rewrite.so...(no debugging symbols found)...done. Loaded symbols for /usr/lib/apache2/modules/mod_rewrite.so Reading symbols from /usr/lib/apache2/modules/mod_setenvif.so... (no debugging symbols found)...done. Loaded symbols for /usr/lib/apache2/modules/mod_setenvif.
#48173 [Opn->Bgs]: file_exists() fails to find in include_path when using __autoload
ID: 48173 Updated by: j...@php.net Reported By: kevinpeno at gmail dot com -Status: Open +Status: Bogus Bug Type: Filesystem function related Operating System: Windows Server 2008 PHP Version: 5.2.9 New Comment: file_exists() doesn't care about include_path. Previous Comments: [2009-05-06 23:56:21] kevinpeno at gmail dot com I'm using windows build 5.2.9-2 NTS. This option was not selectable. [2009-05-06 23:54:36] kevinpeno at gmail dot com Description: Using file_exists fails to find valid files within include_path when using an __autoload. Removing file_exists() the required file is found and loaded. Safe mode is not enabled. Reproduce code: --- Expected result: File included class initialized. Actual result: -- Fatal error: Class 'Prefix_ClassName' not found. -- Edit this bug report at http://bugs.php.net/?id=48173&edit=1
#48147 [Asn->Ver]: iconv with //IGNORE cuts the string
ID: 48147
Updated by: lbarn...@php.net
Reported By: kulakov74 at yandex dot ru
-Status: Assigned
+Status: Verified
Bug Type: ICONV related
Operating System: Linux
PHP Version: 5.*, 6CVS (2009-05-05)
Assigned To: lbarnaud
Previous Comments:
[2009-05-07 07:50:52] lbarn...@php.net
Marked it as verified as I got exactly the same results:
The first iconv() call (the one without //IGNORE) fails on the emphasis
character "â¦" (value="Searchâ¦"), which can't be represented in
ISO-8859-1.
The second iconv() call (the one with //IGNORE) fails later (so the
emphasis is ignored, which may means that the //IGNORE flag is
supported), and there is no apparent reason for failing at offset 8157
(only regular ASCII chars around).
[2009-05-06 18:36:10] j...@php.net
Arnaud: Please don't reopen bogus bugs without explanation.
[2009-05-06 18:18:07] kulakov74 at yandex dot ru
No. The fact the script displays the notice "iconv(): Detected an
illegal character ..." in both cases is not related to the fact whether
the option is implemented: this is controlled by error_reporting(E_ALL).
The option IGNORE only controls whether iconv will stop at the character
or not.
Also, the length of the resulting string is different (greater) with
IGNORE, and while without it the string ends at exactly where the
illegal character is, with IGNORE it ends at a random point where no
such characters occur.
Also, I did not mention - this is not the only file I converted, many
others were converted correctly with the option, and their length only
decreased a little. But there were 2 files which were truncated, 1 of
them (the smaller) is used for the test case.
Can you run the test with the latest PHP releases? Actually this is why
I reported the bug. I tried it on other servers with PHP 4.3.3, 5.1.4,
5.1.6, 5.2.4 and 5.2.6 and yep! - I finally found one with 5.2.9 (built
Feb 27 2009) and it displayed the same results everywhere.
I repeat, the TRANSLIT option works fine, while it does the same and
even more.
[2009-05-06 14:38:39] j...@php.net
It just means you're using glibc iconv implementation which does not
have the IGNORE parameter implemented.
[2009-05-06 05:13:10] kulakov74 at yandex dot ru
Here goes the script. I'm not sure about the limit on external
resources - I have the file to convert, so it is downloaded.
http://www.oppcharts.com/iconv.html";);
echo(strlen($Body1)."\n");
$Body2=iconv('UTF-8', 'ISO-8859-1', $Body1);
echo(strlen($Body2)."\n");
$Body2=iconv('UTF-8', 'ISO-8859-1//IGNORE', $Body1);
echo(strlen($Body2)."\n");
?>
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/48147
--
Edit this bug report at http://bugs.php.net/?id=48147&edit=1
#48147 [Asn]: iconv with //IGNORE cuts the string
ID: 48147
Updated by: lbarn...@php.net
Reported By: kulakov74 at yandex dot ru
Status: Assigned
Bug Type: ICONV related
Operating System: Linux
PHP Version: 5.*, 6CVS (2009-05-05)
Assigned To: lbarnaud
New Comment:
Marked it as verified as I got exactly the same results:
The first iconv() call (the one without //IGNORE) fails on the emphasis
character "â¦" (value="Searchâ¦"), which can't be represented in
ISO-8859-1.
The second iconv() call (the one with //IGNORE) fails later (so the
emphasis is ignored, which may means that the //IGNORE flag is
supported), and there is no apparent reason for failing at offset 8157
(only regular ASCII chars around).
Previous Comments:
[2009-05-06 18:36:10] j...@php.net
Arnaud: Please don't reopen bogus bugs without explanation.
[2009-05-06 18:18:07] kulakov74 at yandex dot ru
No. The fact the script displays the notice "iconv(): Detected an
illegal character ..." in both cases is not related to the fact whether
the option is implemented: this is controlled by error_reporting(E_ALL).
The option IGNORE only controls whether iconv will stop at the character
or not.
Also, the length of the resulting string is different (greater) with
IGNORE, and while without it the string ends at exactly where the
illegal character is, with IGNORE it ends at a random point where no
such characters occur.
Also, I did not mention - this is not the only file I converted, many
others were converted correctly with the option, and their length only
decreased a little. But there were 2 files which were truncated, 1 of
them (the smaller) is used for the test case.
Can you run the test with the latest PHP releases? Actually this is why
I reported the bug. I tried it on other servers with PHP 4.3.3, 5.1.4,
5.1.6, 5.2.4 and 5.2.6 and yep! - I finally found one with 5.2.9 (built
Feb 27 2009) and it displayed the same results everywhere.
I repeat, the TRANSLIT option works fine, while it does the same and
even more.
[2009-05-06 14:38:39] j...@php.net
It just means you're using glibc iconv implementation which does not
have the IGNORE parameter implemented.
[2009-05-06 05:13:10] kulakov74 at yandex dot ru
Here goes the script. I'm not sure about the limit on external
resources - I have the file to convert, so it is downloaded.
http://www.oppcharts.com/iconv.html";);
echo(strlen($Body1)."\n");
$Body2=iconv('UTF-8', 'ISO-8859-1', $Body1);
echo(strlen($Body2)."\n");
$Body2=iconv('UTF-8', 'ISO-8859-1//IGNORE', $Body1);
echo(strlen($Body2)."\n");
?>
[2009-05-04 14:52:10] kulakov74 at yandex dot ru
Description:
iconv() without //IGNORE as known cuts the string at the first illegal
character, but with //IGNORE it should not. Still, I get a truncated
text, but not at the point where the character is. Sorry the actual PHP
version is 5.2.6, but I cannot upgrade it. Just to let you know. Can you
test that with the last version? Please download the file from
http://www.oppcharts.com/iconv.html
Reproduce code:
---
$Body1=... //read the file
echo(strlen($Body1)."\n");
$Body2=iconv('UTF-8', 'ISO-8859-1', $Body1);
echo(strlen($Body2)."\n");
$Body2=iconv('UTF-8', 'ISO-8859-1//IGNORE', $Body1);
echo(strlen($Body2)."\n");
Expected result:
15323
Notice: iconv(): Detected an illegal character in input string in
/home/doldon/html/tdnam/dev.php on line 18
3588
---
15323
15321 - I can get this if I use //TRANSLIT or when I run the test on my
home Windows PHP 4
Actual result:
--
15323
Notice: iconv(): Detected an illegal character in input string in
/home/doldon/html/tdnam/dev.php on line 18
3588
---
15323
Notice: iconv(): Detected an illegal character in input string in
/home/doldon/html/tdnam/dev.php on line 18
8157 - THIS IS THE PROBLEM
--
Edit this bug report at http://bugs.php.net/?id=48147&edit=1
