#47610 [NEW]: Block access to session file.
From: lonelywolf at damagelab dot org Operating system: Linux, Ubuntu 8.10 PHP version: 5.2.9 PHP Bug Type: Session related Bug description: Block access to session file. Description: Hello. A mistake is noticed when you try paying for the session while working with it at this point. I'm from Russia, therefore, to explain through an interpreter is not the best option, I will show you some example code, and you can understand the result of work. Reproduce code: --- Example source code: http://www.damagelab.org/dl/scripts/phpbuginsession.zip zip.php - test file for sleep on wrok with session. ajax.php - interface for example testing, include 2 ajax query. ajax.js - library for used ajax.php log.txt - debug log with result in real-time working Expected result: He must show for every ajax request(ajax.php?do=status): 46:[00:26:46] work 2 47:[00:26:46] work 2 48:[00:26:46] work 2 49:[00:26:49] work 3 Actual result: -- 52:[00:26:52] end This finding does not immediately, but only when the script is run for zip.php and the latest result. -- Edit bug report at http://bugs.php.net/?id=47610&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=47610&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=47610&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=47610&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=47610&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=47610&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=47610&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=47610&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=47610&r=needscript Try newer version: http://bugs.php.net/fix.php?id=47610&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=47610&r=support Expected behavior: http://bugs.php.net/fix.php?id=47610&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=47610&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=47610&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=47610&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47610&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=47610&r=dst IIS Stability: http://bugs.php.net/fix.php?id=47610&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=47610&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=47610&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=47610&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=47610&r=mysqlcfg
#47609 [Opn->Bgs]: foreach() fails to compare key properly
ID: 47609
Updated by: ka...@php.net
Reported By: se...@php.net
-Status: Open
+Status: Bogus
Bug Type: Arrays related
Operating System: RHEL 5.3
PHP Version: 5.2CVS-2009-03-09 (snap)
New Comment:
Expected result, see the first example on the comparison operators
page:
http://www.php.net/manual/en/language.operators.comparison.php
Previous Comments:
[2009-03-10 00:01:38] se...@php.net
Description:
Following script will print '4-FAIL' using php 5.2.9 build and today's
snapshot php5.2-200903092130.
Following returns true where $k = int(0), which is wrong:
if ($k == 'abc')
echo "3-FAIL\n";
Also confirmed this is failing on 5.1.6.
Reproduce code:
---
$v)
{
// $k is ONLY and ALWAYS ZERO (0)
var_dump($k);
var_dump($v);
if ($k == 'abc')
echo "4-FAIL\n";
if ($k === 'abc')
echo "5-FAIL\n";
if ($v == 'abc')
echo "6-FAIL\n";
}
Expected result:
Code should not print anything.
Only key is int(0) and only value is int(4)
--
Edit this bug report at http://bugs.php.net/?id=47609&edit=1
#41350 [Com]: Error in my_thread_global_end()
ID: 41350 Comment by: paul at orac dot clara dot co dot uk Reported By: graham at directhostinguk dot com Status: No Feedback Bug Type: MySQL related Operating System: * PHP Version: 5.2.6 Assigned To: scottmac New Comment: Libmysql.dll from Mysql 5.0.77 seems to work fine and doesn't have the problems detailed in bug #46842. Libmysql.dll from Mysql 5.1.32 still doesn't work. I don't know why the PHP folks have closed #46842 as Bogus when it quite clearly is not. Previous Comments: [2009-03-03 00:12:17] chaz_meister_rock at yahoo dot com Same error in PHP 5.2.9. [2009-02-20 03:14:23] kram0815 at gmx dot net have this bug too on my system uname -a = 2.6.26-1-amd64 Debian Lenny php -v = PHP 5.2.6-1+lenny2 mysql -V = Ver 14.12 Distrib 5.0.51a msg in /var/log/apache2/error.log = Error in my_thread_global_end(): 41 threads didn't exit [2009-02-12 01:40:30] dbmuller at gmail dot com I had this problem on a Windows 2003 server running PHP 5.2.5 as CGI with hsphere. I would copy the 5.2.1 DLL in and the error would persist. The fix was to delete the old DLL, refresh the page to produce a new error and then copy up the 5.2.1 libmysql.dll. [2009-01-23 16:35:24] onehourlate at hotmail dot com Unfortunately, libmysql.dll 5.1.30 seems crash. see #46842. I don't know if this crash is necesserally php related, but it's still useful to investigate because trying to ship a version of libmysql.dll that finally solves this bug would be a good thing [2008-12-29 18:18:42] chaz_meister_rock at yahoo dot com In case anyone is wondering how to fix this, comments above give a workaround. I'll lay out the steps for the newbies: 1) Download PHP v5.1.6 from http://museum.php.net/php5/php-5.1.6-Win32.zip 2) Extract that zip and replace the "libmysql.dll" in your production PHP directory (probably c:\php) with the newly downloaded libmysql.dll. This worked successfully on Windows2003 PHP v5.2.8 Threadsafe. Also, for some reason, many other versions of libmysql.dll (either bundled with PHP or released with MySQL server) do not work correctly. Cheers 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/41350 -- Edit this bug report at http://bugs.php.net/?id=41350&edit=1
#47609 [NEW]: foreach() fails to compare key properly
From: se...@php.net
Operating system: RHEL 5.3
PHP version: 5.2CVS-2009-03-09 (snap)
PHP Bug Type: Arrays related
Bug description: foreach() fails to compare key properly
Description:
Following script will print '4-FAIL' using php 5.2.9 build and today's
snapshot php5.2-200903092130.
Following returns true where $k = int(0), which is wrong:
if ($k == 'abc')
echo "3-FAIL\n";
Also confirmed this is failing on 5.1.6.
Reproduce code:
---
$v)
{
// $k is ONLY and ALWAYS ZERO (0)
var_dump($k);
var_dump($v);
if ($k == 'abc')
echo "4-FAIL\n";
if ($k === 'abc')
echo "5-FAIL\n";
if ($v == 'abc')
echo "6-FAIL\n";
}
Expected result:
Code should not print anything.
Only key is int(0) and only value is int(4)
--
Edit bug report at http://bugs.php.net/?id=47609&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=47609&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=47609&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=47609&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=47609&r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=47609&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=47609&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=47609&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=47609&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=47609&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=47609&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=47609&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=47609&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=47609&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=47609&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47609&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=47609&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=47609&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=47609&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=47609&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=47609&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=47609&r=mysqlcfg
#44433 [Com]: Text with null characters (\0) truncated when bound to prepared statement
ID: 44433
Comment by: bmauser at gmail dot com
Reported By: hans at velum dot net
Status: Verified
Bug Type: PDO related
Operating System: Gentoo Linux
PHP Version: 5.2.5
New Comment:
I noticed the same problem on windows (vista) and same php version
5.2.5. The serialized string I tried to store in the database was:
O:8:"Psa_User":3:{s:9:" * groups";a:0:{}s:13:" *
last_login";i:0;s:10:"test_value";i:391;}
and when I put output from serialize() in hex editor you can see some
null characters:
h: 4F 3A 38 3A 22 50 73 61 5F 55 73 65 72 22 3A 33 ;
O:8:"Psa_User":3
0010h: 3A 7B 73 3A 39 3A 22 00 2A 00 67 72 6F 75 70 73 ;
:{s:9:".*.groups
0020h: 22 3B 61 3A 30 3A 7B 7D 73 3A 31 33 3A 22 00 2A ;
";a:0:{}s:13:".*
0030h: 00 6C 61 73 74 5F 6C 6F 67 69 6E 22 3B 69 3A 30 ;
.last_login";i:0
0040h: 3B 73 3A 31 30 3A 22 74 65 73 74 5F 76 61 6C 75 ;
;s:10:"test_valu
0050h: 65 22 3B 69 3A 33 39 31 3B 7D ;
e";i:391;}
The value in query that should update the database is truncated to the
first null character in string. That is true for prepared statements
with PDO->prepare() and also for only escaped values with PDO->quote().
When using the same code with mysql_pdo driver queries are not
truncated and the null characters are stored in the database blob
object.
I used base64_encode and decode functions to workaround this and stored
base64 encoded string in the database.
Previous Comments:
[2008-03-13 18:30:19] hans at velum dot net
Description:
I'm using PostgreSQL (8.2.x) and am having a problem inserting
serialized data containing null characters (\0) into the database. I am
using prepared statements and the bindValue() method to bind the
serialized data as a PDO::PARAM_STR.
It's not obvious from the output below, but these serialized strings
contain null values because of the private variables.
I can't seem to find an existing bug for this; however, it surprises me
that no one has reported this before.
Reproduce code:
---
$pdo = new PDO('pgsql: dbname=testdb user=postgres');
$pdo->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
try {
$pdo->exec('DROP TABLE testtbl');
} catch (PDOException $x) { /* ignore */ }
$pdo->exec('CREATE TABLE testtbl (id integer not null, txtcol text)');
class MyClass {
private $var1;
function __construct($val) { $this->var1 = $val; }
}
$serialized = serialize(array('foo' => new MyClass('bar'), 'baz' => new
MyClass('bingo!')));
print "Serialized data: " . $serialized . PHP_EOL;
$stmt = $pdo->prepare('INSERT INTO testtbl (id, txtcol) VALUES (1,
?)');
$stmt->bindValue(1, $serialized, PDO::PARAM_STR);
$stmt->execute();
$stmt = $pdo->query('SELECT * FROM testtbl WHERE id = 1');
$row = $stmt->fetch();
print "From database: " . $row['txtcol'] . PHP_EOL;
Expected result:
Serialized data:
a:2:{s:3:"foo";O:7:"MyClass":1:{s:13:"MyClassvar1";s:3:"bar";}s:3:"baz";O:7:"MyClass":1:{s:13:"MyClassvar1";s:6:"bingo!";}}
>From database:
a:2:{s:3:"foo";O:7:"MyClass":1:{s:13:"MyClassvar1";s:3:"bar";}s:3:"baz";O:7:"MyClass":1:{s:13:"MyClassvar1";s:6:"bingo!";}}
Actual result:
--
Serialized data:
a:2:{s:3:"foo";O:7:"MyClass":1:{s:13:"MyClassvar1";s:3:"bar";}s:3:"baz";O:7:"MyClass":1:{s:13:"MyClassvar1";s:6:"bingo!";}}
>From database: a:2:{s:3:"foo";O:7:"MyClass":1:{s:13:"
--
Edit this bug report at http://bugs.php.net/?id=44433&edit=1
#47608 [Bgs]: unable to dynamically load php_radius.dll
ID: 47608 User updated by: mgregory at gregory dot com Reported By: mgregory at gregory dot com Status: Bogus Bug Type: Dynamic loading Operating System: Windows XP SP2 PHP Version: 5.2.9 New Comment: I have left a bug report with the PECL people as well with no response so far. Previous Comments: [2009-03-09 23:03:29] mgregory at gregory dot com The answer to both questions is yes and yes. The dll was copied into the ext directory where is resides with the other extension dll's. The extension_dir in php_ini. is defauled, as you point out, to point to the extension directory. [2009-03-09 21:14:46] ka...@php.net Since radius is in PECL, please referer to the PECL bug tracker at: http://pecl.php.net/ [2009-03-09 20:56:41] ka...@php.net Did you place php_radius.dll in the ext/ folder of your php installation and then pointed extension_dir to that directory (which should be default) ? [2009-03-09 20:07:34] mgregory at gregory dot com Description: I get the following error message from Aache 2.2.11 at start-up:PHP Warning: PHP Startup: "Unable to load dynamic library 'C:\\Program Files\\PHP\\ext\\php_radius.dll' - The specified module could not be found.\r\n in Unknown on line 0." extension_dir in php.ini is correct and the extention has been enabled properly. I have read through all the other bug reports and tried the fixes used before. I have moved php_radius.dll to system 32 with no effect. I have also added the extension directory path to the environment variables and rebooted without effect. Also tried adding a directory directive to apache with no effect. Expected result: Expected dynamic linking of module without error message. Actual result: -- Got error message as follows: "Unable to load dynamic library 'C:\\Program Files\\PHP\\ext\\php_radius.dll' - The specified module could not be found.\r\n in Unknown on line 0." -- Edit this bug report at http://bugs.php.net/?id=47608&edit=1
#47608 [Bgs]: unable to dynamically load php_radius.dll
ID: 47608 User updated by: mgregory at gregory dot com Reported By: mgregory at gregory dot com Status: Bogus Bug Type: Dynamic loading Operating System: Windows XP SP2 PHP Version: 5.2.9 New Comment: The answer to both questions is yes and yes. The dll was copied into the ext directory where is resides with the other extension dll's. The extension_dir in php_ini. is defauled, as you point out, to point to the extension directory. Previous Comments: [2009-03-09 21:14:46] ka...@php.net Since radius is in PECL, please referer to the PECL bug tracker at: http://pecl.php.net/ [2009-03-09 20:56:41] ka...@php.net Did you place php_radius.dll in the ext/ folder of your php installation and then pointed extension_dir to that directory (which should be default) ? [2009-03-09 20:07:34] mgregory at gregory dot com Description: I get the following error message from Aache 2.2.11 at start-up:PHP Warning: PHP Startup: "Unable to load dynamic library 'C:\\Program Files\\PHP\\ext\\php_radius.dll' - The specified module could not be found.\r\n in Unknown on line 0." extension_dir in php.ini is correct and the extention has been enabled properly. I have read through all the other bug reports and tried the fixes used before. I have moved php_radius.dll to system 32 with no effect. I have also added the extension directory path to the environment variables and rebooted without effect. Also tried adding a directory directive to apache with no effect. Expected result: Expected dynamic linking of module without error message. Actual result: -- Got error message as follows: "Unable to load dynamic library 'C:\\Program Files\\PHP\\ext\\php_radius.dll' - The specified module could not be found.\r\n in Unknown on line 0." -- Edit this bug report at http://bugs.php.net/?id=47608&edit=1
#47285 [Com]: strtotime() still leaks memory
ID: 47285
Comment by: martin at 925 dot dk
Reported By: danger at FreeBSD dot org
Status: Assigned
Bug Type: Date/time related
Operating System: FreeBSD
PHP Version: 5.2.8
Assigned To: derick
New Comment:
Removing UTC from the timestamp in php_date.c also fixes the leak:
--- php_date_.c 2009-03-09 22:30:15.0 +0100
+++ php_date.c 2009-03-09 22:30:21.0 +0100
@@ -1117,7 +1117,7 @@
now = timelib_time_ctor();
initial_ts = emalloc(25);
- snprintf(initial_ts, 24, "@%ld UTC", preset_ts);
+ snprintf(initial_ts, 24, "@%ld", preset_ts);
t = timelib_strtotime(initial_ts, strlen(initial_ts),
NULL, DATE_TIMEZONEDB); /* we ignore the error here, as this should
never fail */
timelib_update_ts(t, tzi);
now->tz_info = tzi;
Previous Comments:
[2009-03-09 18:46:22] martin at 925 dot dk
This patch (which reverts the fix for bug 45529) against parse_date.c
seems to fix the leak:
Hence this patch against parse_date.c:
--- parse_date_.c 2009-03-09 19:33:37.0 +0100
+++ parse_date.c2009-03-09 19:33:45.0 +0100
@@ -733,7 +733,7 @@
}
#endif
/* If we have a TimeZone identifier to start with, use
it */
- if (strstr(tz_abbr, "/") || strcmp(tz_abbr, "UTC") ==
0) {
+ if (strstr(tz_abbr, "/")) {
if ((res = timelib_parse_tzfile(tz_abbr,
tzdb)) != NULL) {
t->tz_info = res;
t->zone_type = TIMELIB_ZONETYPE_ID;
[2009-02-27 14:48:14] maarten at vivesta dot com
Same here. I've added a date_default_timezone_set() before using
strtotime() and it removed the error but not the leak.
[2009-02-27 13:53:29] danger at FreeBSD dot org
I tried to run my script with php -d error_reporting=E_STRICT test.php
and been receiving this error until I stopped the script:
Strict Standards: strtotime(): It is not safe to rely on the system's
timezone settings. Please use the date.timezone setting, the TZ
environment variable or the date_default_timezone_set() function. In
case you used any of those methods and you are still getting this
warning, you most likely misspelled the timezone identifier. We selected
'Europe/Berlin' for 'CET/1.0/no DST' instead in /root/test.php on line
10
[2009-02-27 13:25:37] danger at FreeBSD dot org
Hey there,
I have tried to build a stock php-5.2.9 (no FreeBSD patches or anything
else) with ./configure && make.
When I run my test script as this:
r...@[temp /var/ports/distfiles/php-5.2.9]# sapi/cli/php
/root/test.php
No modified php.ini is being used, no additional extensions are being
loaded. I can still verify that it leaks.
[2009-02-27 11:44:35] der...@php.net
I am not forgetting about this, but at the moment just really occupied.
Just as a quick question, this is the *stock* PHP without any ports
patches, also, if you set the error level to also show e_Strict
messages, do you see anything? Also, do you have the date.timezone
setting made in PHP.ini?
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/47285
--
Edit this bug report at http://bugs.php.net/?id=47285&edit=1
#47607 [Com]: Add LDAP escaping
ID: 47607
Comment by: gdr at go2 dot pl
Reported By: gdr at go2 dot pl
Status: Open
Bug Type: Feature/Change Request
Operating System: Linux
PHP Version: 5.2.9
New Comment:
One implementation of this function in PHP, found here:
http://lists.evolvis.org/pipermail/evolvis-commits/2008-November/54.html
is:
+ function ldap_escape_string($string) //public
+ {
+$string = str_replace(",", '\\,', $string);
+$string = str_replace('"', '\\"', $string);
+$string = str_replace("'", '\\\'', $string);
+$string = str_replace("<", '\\<', $string);
+$string = str_replace(">", '\\>', $string);
+$string = str_replace(";", '\\;', $string);
+$string = str_replace('\\', '', $string);
+$string = str_replace("+", '\\+,', $string);
+$string = str_replace("=", '\\=,', $string);
+$string = str_replace("#", '\\#', $string);
+ return $string;
+ }
I haven't, however, read RFC for this and therefore I don't know if
it's 100% correct.
Previous Comments:
[2009-03-09 17:36:36] gdr at go2 dot pl
Description:
The LDAP module needs a function to escape strings to prevent LDAP
injections, like MySQL module has mysql_escape_string()
Reproduce code:
---
$sr=ldap_search($ds, "", "(sn=$_GET[lastname])");
Expected result:
$sr=ldap_search($ds, "",
"(sn=".ldap_escape_string($_GET[lastname]).")");
--
Edit this bug report at http://bugs.php.net/?id=47607&edit=1
#47535 [Opn]: Compilation failure in ps_fetch_from_1_to_8_bytes()
ID: 47535 Updated by: ka...@php.net Reported By: Bjorn dot Wiberg at its dot uu dot se Status: Open Bug Type: MySQL related Operating System: IBM AIX 5.3 5300-08-01-0819 PHP Version: 5.3.0beta1 New Comment: Now I don't have an AIX env. or anything, but after reading over a few articles I created the following patch. I'm not sure whether "_AIX" is the right macro to check for here though, if any of the MySQL guys can review it would be great: Index: mysqlnd_portability.h === RCS file: /repository/php-src/ext/mysqlnd/mysqlnd_portability.h,v retrieving revision 1.4.2.12 diff -u -r1.4.2.12 mysqlnd_portability.h --- mysqlnd_portability.h 18 Nov 2008 17:02:18 - 1.4.2.12 +++ mysqlnd_portability.h 9 Mar 2009 21:13:32 - @@ -199,6 +199,11 @@ #define MYSQLND_LLU_SPEC "%llu" #endif +#ifdef _AIX +#define MYSQLND_LL_SPEC "%lli" +#define MYSQLND_LLU_SPEC "%llu" +#endif + #define MYSQLND_SZ_T_SPEC "%zd" #ifndef L64 #define L64(x) x##LL Previous Comments: [2009-03-03 03:22:49] ka...@php.net Guess this is because there is not a check for AIX in mysqlnd/mysqlnd_portability.h either way mysqlnd should probably use #error to indicate a *possible* unsupported compilation env. [2009-03-01 09:18:05] Bjorn dot Wiberg at its dot uu dot se Description: Compilation fails with undeclared references to MYSQLND_LLU_SPEC and MYSQLND_LL_SPEC. Reproduce code: --- #! /bin/sh # # Created by configure LDFLAGS='-Wl,-bbigtoc' \ CC='gcc' \ './configure' \ '--enable-bcmath' \ '--enable-calendar' \ '--enable-cli' \ '--enable-dba' \ '--enable-debug' \ '--enable-exif' \ '--enable-flatfile' \ '--enable-ftp' \ '--enable-gd-jis-conv' \ '--enable-gd-native-ttf' \ '--enable-inifile' \ '--enable-mbstring' \ '--enable-pcntl' \ '--enable-shmop' \ '--enable-soap' \ '--enable-sockets' \ '--enable-sqlite-utf8' \ '--enable-sysvmsg' \ '--enable-sysvsem' \ '--enable-sysvshm' \ '--enable-wddx' \ '--enable-zip' \ '--enable-zend-multibyte' \ '--prefix=/apache/php' \ '--with-apxs2=/apache/bin/apxs' \ '--with-bz2' \ '--with-cdb' \ '--with-curl' \ '--with-freetype-dir' \ '--with-gd' \ '--with-gdbm' \ '--with-gettext' \ '--with-jpeg-dir' \ '--with-ldap' \ '--with-libxml-dir=/usr/local' \ '--with-mysql=mysqlnd' \ '--with-mysqli=mysqlnd' \ '--with-openssl=/opt/freeware' \ '--with-pdo-mysql=mysqlnd' \ '--with-png-dir' \ '--with-xmlrpc' \ '--with-xpm-dir' \ '--with-xsl' \ '--with-zlib' \ '--with-zlib-dir' \ "$@" Expected result: No compilation failure. Actual result: -- /bin/sh /home/bwiberg/rpm/BUILD/php-5.3.0beta1/libtool --preserve-dup-deps --mode=compile gcc -Iext/mysqlnd/ -I/home/bwiberg/rpm/BUILD/php-5.3.0beta1/ext/mysqlnd/ -DPHP_ATOM_INC -I/home/bwiberg/rpm/BUILD/php-5.3.0beta1/include -I/home/bwiberg/rpm/BUILD/php-5.3.0beta1/main -I/home/bwiberg/rpm/BUILD/php-5.3.0beta1 -I/home/bwiberg/rpm/BUILD/php-5.3.0beta1/ext/ereg/regex -I/usr/local/include/libxml2 -I/opt/freeware/include -I/usr/local/include -I/home/bwiberg/rpm/BUILD/php-5.3.0beta1/ext/date/lib -I/usr/X11R6/include -I/usr/include/freetype2 -I/home/bwiberg/rpm/BUILD/php-5.3.0beta1/ext/mbstring/oniguruma -I/home/bwiberg/rpm/BUILD/php-5.3.0beta1/ext/mbstring/libmbfl -I/home/bwiberg/rpm/BUILD/php-5.3.0beta1/ext/mbstring/libmbfl/mbfl -I/home/bwiberg/rpm/BUILD/php-5.3.0beta1/ext/sqlite3/libsqlite -I/home/bwiberg/rpm/BUILD/php-5.3.0beta1/TSRM -I/home/bwiberg/rpm/BUILD/php-5.3.0beta1/Zend-I/usr/include -g -fvisibility=hidden -O0 -Wall -c /home/bwiberg/rpm/BUILD/php-5.3.0beta1/ext/mysqlnd/mysqlnd_ps_codec.c -o ext/mysqlnd/mysqlnd_ps_codec.lo gcc -Iext/mysqlnd/ -I/home/bwiberg/rpm/BUILD/php-5.3.0beta1/ext/mysqlnd/ -DPHP_ATOM_INC -I/home/bwiberg/rpm/BUILD/php-5.3.0beta1/include -I/home/bwiberg/rpm/BUILD/php-5.3.0beta1/main -I/home/bwiberg/rpm/BUILD/php-5.3.0beta1 -I/home/bwiberg/rpm/BUILD/php-5.3.0beta1/ext/ereg/regex -I/usr/local/include/libxml2 -I/opt/freeware/include -I/usr/local/include -I/home/bwiberg/rpm/BUILD/php-5.3.0beta1/ext/date/lib -I/usr/X11R6/include -I/usr/include/freetype2 -I/home/bwiberg/rpm/BUILD/php-5.3.0beta1/ext/mbstring/oniguruma -I/home/bwiberg/rpm/BUILD/php-5.3.0beta1/ext/mbstring/libmbfl -I/home/bwiberg/rpm/BUILD/php-5.3.0beta1/ext/mbstring/libmbfl/mbfl -I/home/bwiberg/rpm/BUILD/php-5.3.0beta1/ext/sqlite3/libsqlite -I/home/bwiberg/rpm/BUILD/php-5.3.0beta1/TSRM -I/home/bwiberg/rpm/BUILD/php-5.3.0beta1/Zend -I/usr/include -g -fvisibility=hidden -O0 -Wall -c /home/bwiberg/rpm/BUILD/php-5.3.0beta1/ext/mysqlnd/mysqlnd_ps_codec.c -DPIC -o ext/mysqlnd/.libs/mysqlnd_ps_codec.o In file included from /home/bwiberg/rpm/BUILD/php-5.3.0beta1/ext/mysqlnd/mysqlnd.h:59, from /home/bwiberg/rpm/BUILD/php-5.3.0beta1/ext/mysqlnd/mysqlnd_ps_cod
#47608 [Fbk->Bgs]: unable to dynamically load php_radius.dll
ID: 47608 Updated by: ka...@php.net Reported By: mgregory at gregory dot com -Status: Feedback +Status: Bogus Bug Type: Dynamic loading Operating System: Windows XP SP2 PHP Version: 5.2.9 New Comment: Since radius is in PECL, please referer to the PECL bug tracker at: http://pecl.php.net/ Previous Comments: [2009-03-09 20:56:41] ka...@php.net Did you place php_radius.dll in the ext/ folder of your php installation and then pointed extension_dir to that directory (which should be default) ? [2009-03-09 20:07:34] mgregory at gregory dot com Description: I get the following error message from Aache 2.2.11 at start-up:PHP Warning: PHP Startup: "Unable to load dynamic library 'C:\\Program Files\\PHP\\ext\\php_radius.dll' - The specified module could not be found.\r\n in Unknown on line 0." extension_dir in php.ini is correct and the extention has been enabled properly. I have read through all the other bug reports and tried the fixes used before. I have moved php_radius.dll to system 32 with no effect. I have also added the extension directory path to the environment variables and rebooted without effect. Also tried adding a directory directive to apache with no effect. Expected result: Expected dynamic linking of module without error message. Actual result: -- Got error message as follows: "Unable to load dynamic library 'C:\\Program Files\\PHP\\ext\\php_radius.dll' - The specified module could not be found.\r\n in Unknown on line 0." -- Edit this bug report at http://bugs.php.net/?id=47608&edit=1
#47608 [Opn->Fbk]: unable to dynamically load php_radius.dll
ID: 47608 Updated by: ka...@php.net Reported By: mgregory at gregory dot com -Status: Open +Status: Feedback Bug Type: Dynamic loading Operating System: Windows XP SP2 PHP Version: 5.2.9 Previous Comments: [2009-03-09 20:56:41] ka...@php.net Did you place php_radius.dll in the ext/ folder of your php installation and then pointed extension_dir to that directory (which should be default) ? [2009-03-09 20:07:34] mgregory at gregory dot com Description: I get the following error message from Aache 2.2.11 at start-up:PHP Warning: PHP Startup: "Unable to load dynamic library 'C:\\Program Files\\PHP\\ext\\php_radius.dll' - The specified module could not be found.\r\n in Unknown on line 0." extension_dir in php.ini is correct and the extention has been enabled properly. I have read through all the other bug reports and tried the fixes used before. I have moved php_radius.dll to system 32 with no effect. I have also added the extension directory path to the environment variables and rebooted without effect. Also tried adding a directory directive to apache with no effect. Expected result: Expected dynamic linking of module without error message. Actual result: -- Got error message as follows: "Unable to load dynamic library 'C:\\Program Files\\PHP\\ext\\php_radius.dll' - The specified module could not be found.\r\n in Unknown on line 0." -- Edit this bug report at http://bugs.php.net/?id=47608&edit=1
#47608 [Opn]: unable to dynamically load php_radius.dll
ID: 47608 Updated by: ka...@php.net Reported By: mgregory at gregory dot com Status: Open Bug Type: Dynamic loading Operating System: Windows XP SP2 PHP Version: 5.2.9 New Comment: Did you place php_radius.dll in the ext/ folder of your php installation and then pointed extension_dir to that directory (which should be default) ? Previous Comments: [2009-03-09 20:07:34] mgregory at gregory dot com Description: I get the following error message from Aache 2.2.11 at start-up:PHP Warning: PHP Startup: "Unable to load dynamic library 'C:\\Program Files\\PHP\\ext\\php_radius.dll' - The specified module could not be found.\r\n in Unknown on line 0." extension_dir in php.ini is correct and the extention has been enabled properly. I have read through all the other bug reports and tried the fixes used before. I have moved php_radius.dll to system 32 with no effect. I have also added the extension directory path to the environment variables and rebooted without effect. Also tried adding a directory directive to apache with no effect. Expected result: Expected dynamic linking of module without error message. Actual result: -- Got error message as follows: "Unable to load dynamic library 'C:\\Program Files\\PHP\\ext\\php_radius.dll' - The specified module could not be found.\r\n in Unknown on line 0." -- Edit this bug report at http://bugs.php.net/?id=47608&edit=1
#47243 [Asn->Csd]: Crash at end of request on Windows
ID: 47243 Updated by: s...@php.net Reported By: pcdinh at gmail dot com -Status: Assigned +Status: Closed Bug Type: OCI8 related Operating System: Windows XP SP3 PHP Version: 5.3.0beta1 Assigned To: sixd 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. -- Fix has been merged to CVS. This changes the end-of-request shutdown and and end-of-process/thread behavior even for non thread safe builds (ie. most folk not using Windows) so please test thoroughly. Previous Comments: [2009-03-09 20:11:13] s...@php.net Changing Summary from "oci_fetch_assoc() causes Apache 2.2.11 crashed and restarted (SQL CURSOR)" [2009-02-27 23:26:06] s...@php.net Fix is being reviewed prior to testing. [2009-02-03 02:16:21] s...@php.net Reproduces on Windows. Also crashes with --enable-maintainer-zts mode on Linux [2009-01-30 04:47:03] kureikain at gmail dot com I don't think that is a bug!I have ever had same problem(MySQL)!Because i used wrong version of libmysql.dll!I copied frm XAMPP to System32! &when i install PHP from zip package,i forget to overwrite libmysql.dll in system32!Apache keep crashing whenever PHP execs query [2009-01-29 19:19:15] pcdinh at gmail dot com Description: I wrote code to retrieve data that was returned from a query with Oracle cursor. However oci_fetch_assoc() causes Apache 2.2.11 being crashed and restarted. I am not sure if it is a Oracle client native library or OCI8 issue. Reproduce code: --- Expected result: Those code is a slightly modified version taken from PHP Manual http://vn2.php.net/oci_new_cursor It should be executed without any crash and data can be retrieved normally (as guided by PHP Manual) Actual result: -- Apache crashes and restarts Type of Analysis Performed Crash Analysis Machine Name HOME-4F44218659 Operating System Windows XP Service Pack 3 Number Of Processors 2 Process ID 2200 Process Image C:\server\Apache2.2\bin\httpd.exe System Up-Time 10:12:12 Process Up-Time 00:01:07 Thread 169 - System ID 2128 Entry point msvcrt!endthreadex+3a Create time 1/30/2009 1:57:53 AM Time spent in user mode 0 Days 0:0:0.15 Time spent in kernel mode 0 Days 0:0:0.93 Function Arg 1 Arg 2 Arg 3 Source OraClient10!kpufhndl0+33 4e5f544e 0002 OraClient10!kpufhndl+10 4e5f544e 0002 049ff9e8 OraClient10!OCIHandleFree+1a 4e5f544e 0002 0084eef0 oci!OCIHandleFree+1d 4e5f544e 0002 01b8a9d8 php_oci8!php_oci_statement_free+121 05ecf448 01b8a9d8 0083aa23 php_oci8!php_oci_statement_list_dtor+11 05ed09b8 01b8a9d8 01be5278 php5ts!list_entry_destructor+43 05ed09b8 01b8a9d8 05ed0988 php5ts!zend_hash_apply_deleter+97 01be5278 05ed0988 01b8a9d8 php5ts!zend_hash_apply_with_argument+5a 01be5278 01976a90 0022 php_oci8!zm_deactivate_oci+8a 0001 0029 01b8a9d8 php5ts!module_registry_cleanup+1c 00fd4ec8 01b8a9d8 01b8a9d8 php5ts!zend_hash_apply+40 00cd7340 007882c0 01b8a9d8 php5ts!zend_deactivate_modules+62 049fffa4 56433230 php5ts!zend_deactivate_modules+48 01b82a01 05ecc7c0 php5ts!php_end_ob_buffers+26 01b8a9d8 0073a040 01b8a9d8 php5ts!php_request_shutdown+247 00622fb6 01b82a18 php5apache2_2!php_apache_request_dtor+8 01b82a18 01b8a9d8 0005 php5apache2_2!php_handler+646 01b82a18 0073a040 01b82a18 libhttpd!ap_run_handler+21 01b82a18 01b82a18 01b82a18 libhttpd!ap_invoke_handler+ae 01b7d9c0 049fff38 libhttpd!ap_die+29e 01b82a18 007447a8 libhttpd!ap_get_request_note+1c9c 01b7d9c0 01b7d9c0 01b7d9c0 libhttpd!ap_run_process_connection+21 01b7d9c0 007121e8 049fff80 libhttpd!ap_process_connection+33 01b7d9c0 01b76990 00e4 libhttpd!ap_regkey_value_remove+c7c 01b7d9b8 00e4 00e8 msvcrt!endthreadex+a9 01b73958 00e4 00e8 kernel32!GetModuleFileNameA+1b4 77c3a341 01b73958 ORACLIENT10!KPUFHNDL0+33WARNING - DebugDiag was no
#47243 [Asn]: Crash at end of request on Windows
ID: 47243 Updated by: s...@php.net -Summary: oci_fetch_assoc() causes Apache 2.2.11 crashed and restarted (SQL CURSOR) Reported By: pcdinh at gmail dot com Status: Assigned Bug Type: OCI8 related Operating System: Windows XP SP3 PHP Version: 5.3.0beta1 Assigned To: sixd New Comment: Changing Summary from "oci_fetch_assoc() causes Apache 2.2.11 crashed and restarted (SQL CURSOR)" Previous Comments: [2009-02-27 23:26:06] s...@php.net Fix is being reviewed prior to testing. [2009-02-03 02:16:21] s...@php.net Reproduces on Windows. Also crashes with --enable-maintainer-zts mode on Linux [2009-01-30 04:47:03] kureikain at gmail dot com I don't think that is a bug!I have ever had same problem(MySQL)!Because i used wrong version of libmysql.dll!I copied frm XAMPP to System32! &when i install PHP from zip package,i forget to overwrite libmysql.dll in system32!Apache keep crashing whenever PHP execs query [2009-01-29 19:19:15] pcdinh at gmail dot com Description: I wrote code to retrieve data that was returned from a query with Oracle cursor. However oci_fetch_assoc() causes Apache 2.2.11 being crashed and restarted. I am not sure if it is a Oracle client native library or OCI8 issue. Reproduce code: --- Expected result: Those code is a slightly modified version taken from PHP Manual http://vn2.php.net/oci_new_cursor It should be executed without any crash and data can be retrieved normally (as guided by PHP Manual) Actual result: -- Apache crashes and restarts Type of Analysis Performed Crash Analysis Machine Name HOME-4F44218659 Operating System Windows XP Service Pack 3 Number Of Processors 2 Process ID 2200 Process Image C:\server\Apache2.2\bin\httpd.exe System Up-Time 10:12:12 Process Up-Time 00:01:07 Thread 169 - System ID 2128 Entry point msvcrt!endthreadex+3a Create time 1/30/2009 1:57:53 AM Time spent in user mode 0 Days 0:0:0.15 Time spent in kernel mode 0 Days 0:0:0.93 Function Arg 1 Arg 2 Arg 3 Source OraClient10!kpufhndl0+33 4e5f544e 0002 OraClient10!kpufhndl+10 4e5f544e 0002 049ff9e8 OraClient10!OCIHandleFree+1a 4e5f544e 0002 0084eef0 oci!OCIHandleFree+1d 4e5f544e 0002 01b8a9d8 php_oci8!php_oci_statement_free+121 05ecf448 01b8a9d8 0083aa23 php_oci8!php_oci_statement_list_dtor+11 05ed09b8 01b8a9d8 01be5278 php5ts!list_entry_destructor+43 05ed09b8 01b8a9d8 05ed0988 php5ts!zend_hash_apply_deleter+97 01be5278 05ed0988 01b8a9d8 php5ts!zend_hash_apply_with_argument+5a 01be5278 01976a90 0022 php_oci8!zm_deactivate_oci+8a 0001 0029 01b8a9d8 php5ts!module_registry_cleanup+1c 00fd4ec8 01b8a9d8 01b8a9d8 php5ts!zend_hash_apply+40 00cd7340 007882c0 01b8a9d8 php5ts!zend_deactivate_modules+62 049fffa4 56433230 php5ts!zend_deactivate_modules+48 01b82a01 05ecc7c0 php5ts!php_end_ob_buffers+26 01b8a9d8 0073a040 01b8a9d8 php5ts!php_request_shutdown+247 00622fb6 01b82a18 php5apache2_2!php_apache_request_dtor+8 01b82a18 01b8a9d8 0005 php5apache2_2!php_handler+646 01b82a18 0073a040 01b82a18 libhttpd!ap_run_handler+21 01b82a18 01b82a18 01b82a18 libhttpd!ap_invoke_handler+ae 01b7d9c0 049fff38 libhttpd!ap_die+29e 01b82a18 007447a8 libhttpd!ap_get_request_note+1c9c 01b7d9c0 01b7d9c0 01b7d9c0 libhttpd!ap_run_process_connection+21 01b7d9c0 007121e8 049fff80 libhttpd!ap_process_connection+33 01b7d9c0 01b76990 00e4 libhttpd!ap_regkey_value_remove+c7c 01b7d9b8 00e4 00e8 msvcrt!endthreadex+a9 01b73958 00e4 00e8 kernel32!GetModuleFileNameA+1b4 77c3a341 01b73958 ORACLIENT10!KPUFHNDL0+33WARNING - DebugDiag was not able to locate debug symbols for OraClient10.Dll, so the information below may be incomplete. In httpd__PID__2200__Date__01_30_2009__Time_01_59_00AM__328__Second_Chance_Exception_C005.dmp the assembly instruction at OraClient10!kpufhndl0+33 in C:\oraclexe\app\oracle\product\10.2.0\server\BIN\OraClient10.Dll from Oracle Corporation has caused an access violation exception (0xC005) when trying to read from memory location 0x4e5f544e on thread 169 Module Information Ima
#47608 [NEW]: unable to dynamically load php_radius.dll
From: mgregory at gregory dot com Operating system: Windows XP SP2 PHP version: 5.2.9 PHP Bug Type: Dynamic loading Bug description: unable to dynamically load php_radius.dll Description: I get the following error message from Aache 2.2.11 at start-up:PHP Warning: PHP Startup: "Unable to load dynamic library 'C:\\Program Files\\PHP\\ext\\php_radius.dll' - The specified module could not be found.\r\n in Unknown on line 0." extension_dir in php.ini is correct and the extention has been enabled properly. I have read through all the other bug reports and tried the fixes used before. I have moved php_radius.dll to system 32 with no effect. I have also added the extension directory path to the environment variables and rebooted without effect. Also tried adding a directory directive to apache with no effect. Expected result: Expected dynamic linking of module without error message. Actual result: -- Got error message as follows: "Unable to load dynamic library 'C:\\Program Files\\PHP\\ext\\php_radius.dll' - The specified module could not be found.\r\n in Unknown on line 0." -- Edit bug report at http://bugs.php.net/?id=47608&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=47608&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=47608&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=47608&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=47608&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=47608&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=47608&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=47608&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=47608&r=needscript Try newer version: http://bugs.php.net/fix.php?id=47608&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=47608&r=support Expected behavior: http://bugs.php.net/fix.php?id=47608&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=47608&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=47608&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=47608&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47608&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=47608&r=dst IIS Stability: http://bugs.php.net/fix.php?id=47608&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=47608&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=47608&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=47608&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=47608&r=mysqlcfg
#47285 [Com]: strtotime() still leaks memory
ID: 47285
Comment by: martin at 925 dot dk
Reported By: danger at FreeBSD dot org
Status: Assigned
Bug Type: Date/time related
Operating System: FreeBSD
PHP Version: 5.2.8
Assigned To: derick
New Comment:
This patch (which reverts the fix for bug 45529) against parse_date.c
seems to fix the leak:
Hence this patch against parse_date.c:
--- parse_date_.c 2009-03-09 19:33:37.0 +0100
+++ parse_date.c2009-03-09 19:33:45.0 +0100
@@ -733,7 +733,7 @@
}
#endif
/* If we have a TimeZone identifier to start with, use
it */
- if (strstr(tz_abbr, "/") || strcmp(tz_abbr, "UTC") ==
0) {
+ if (strstr(tz_abbr, "/")) {
if ((res = timelib_parse_tzfile(tz_abbr,
tzdb)) != NULL) {
t->tz_info = res;
t->zone_type = TIMELIB_ZONETYPE_ID;
Previous Comments:
[2009-02-27 14:48:14] maarten at vivesta dot com
Same here. I've added a date_default_timezone_set() before using
strtotime() and it removed the error but not the leak.
[2009-02-27 13:53:29] danger at FreeBSD dot org
I tried to run my script with php -d error_reporting=E_STRICT test.php
and been receiving this error until I stopped the script:
Strict Standards: strtotime(): It is not safe to rely on the system's
timezone settings. Please use the date.timezone setting, the TZ
environment variable or the date_default_timezone_set() function. In
case you used any of those methods and you are still getting this
warning, you most likely misspelled the timezone identifier. We selected
'Europe/Berlin' for 'CET/1.0/no DST' instead in /root/test.php on line
10
[2009-02-27 13:25:37] danger at FreeBSD dot org
Hey there,
I have tried to build a stock php-5.2.9 (no FreeBSD patches or anything
else) with ./configure && make.
When I run my test script as this:
r...@[temp /var/ports/distfiles/php-5.2.9]# sapi/cli/php
/root/test.php
No modified php.ini is being used, no additional extensions are being
loaded. I can still verify that it leaks.
[2009-02-27 11:44:35] der...@php.net
I am not forgetting about this, but at the moment just really occupied.
Just as a quick question, this is the *stock* PHP without any ports
patches, also, if you set the error level to also show e_Strict
messages, do you see anything? Also, do you have the date.timezone
setting made in PHP.ini?
[2009-02-27 10:41:02] danger at FreeBSD dot org
verified to still leak with:
r...@[temp /basejail/usr/ports/lang/php5]# php -v
PHP 5.2.9 (cli) (built: Feb 27 2009 11:36:57)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2009 Zend Technologies
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/47285
--
Edit this bug report at http://bugs.php.net/?id=47285&edit=1
#47174 [Csd]: base64_decode interprets pad char in mid string as terminator
ID: 47174
Updated by: s...@php.net
Reported By: rricha...@php.net
Status: Closed
Bug Type: *URL Functions
Operating System: *
PHP Version: 5.2.8
Assigned To: iliaa
New Comment:
Version 5.2.0.
Previous Comments:
[2009-03-09 18:17:18] s...@php.net
Just FYI - this fix breaks SugarCRM version 5.0.0 (which relies on
strings like dGVzdA==CRAP to decode correctly) and same may happen to
other apps. It's probably their fault but it may be good to know that
5.2.9 works differently there.
[2009-01-21 15:45:53] 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.
[2009-01-20 21:04:03] rricha...@php.net
Description:
base64_decode handles a pad as the end of data even when it is not
terminating a string, in which case it really should be handled as
non-
alphabet characters. From rfc 3548 2.3: "Furthermore, such
specifications may consider the pad character, "=", as not part of the
base alphabet until the end of the string."
By ignoring all data after the pad, it is difficult to work with
signature based technologies where the base64
decoded octects must be compared to determine validity. PHP allows for
additional data to be added to a signature which ends up being ignored
when compared, while other implementations do not.
Reproduce code:
---
if (base64_decode("dGVzdA==") == base64_decode("dGVzdA==CRAP")) {
echo "Same octect data - Signature Valid";
} else {
echo "Invalid Signature";
}
Expected result:
Invalid Signature
Actual result:
--
Same octect data - Signature Valid
--
Edit this bug report at http://bugs.php.net/?id=47174&edit=1
#47174 [Csd]: base64_decode interprets pad char in mid string as terminator
ID: 47174
Updated by: s...@php.net
Reported By: rricha...@php.net
Status: Closed
Bug Type: *URL Functions
Operating System: *
PHP Version: 5.2.8
Assigned To: iliaa
New Comment:
Just FYI - this fix breaks SugarCRM version 5.0.0 (which relies on
strings like dGVzdA==CRAP to decode correctly) and same may happen to
other apps. It's probably their fault but it may be good to know that
5.2.9 works differently there.
Previous Comments:
[2009-01-21 15:45:53] 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.
[2009-01-20 21:04:03] rricha...@php.net
Description:
base64_decode handles a pad as the end of data even when it is not
terminating a string, in which case it really should be handled as
non-
alphabet characters. From rfc 3548 2.3: "Furthermore, such
specifications may consider the pad character, "=", as not part of the
base alphabet until the end of the string."
By ignoring all data after the pad, it is difficult to work with
signature based technologies where the base64
decoded octects must be compared to determine validity. PHP allows for
additional data to be added to a signature which ends up being ignored
when compared, while other implementations do not.
Reproduce code:
---
if (base64_decode("dGVzdA==") == base64_decode("dGVzdA==CRAP")) {
echo "Same octect data - Signature Valid";
} else {
echo "Invalid Signature";
}
Expected result:
Invalid Signature
Actual result:
--
Same octect data - Signature Valid
--
Edit this bug report at http://bugs.php.net/?id=47174&edit=1
#46623 [Asn->Csd]: phpinfo() doesn't show compile time home with phpize install
ID: 46623 Updated by: s...@php.net Reported By: s...@php.net -Status: Assigned +Status: Closed Bug Type: OCI8 related Operating System: Linux PHP Version: 5.3.0alpha2 Assigned To: sixd New Comment: This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. Previous Comments: [2008-11-21 12:44:34] j...@php.net Sixd, when you assign something to yourself, change the status too. [2008-11-19 20:09:08] s...@php.net Description: If OCI8 is installed from PECL, then phpinfo() doesn't show anything for the "Compile-time ORACLE_HOME" or "Libraries Used" field. There is no runtime impact on scripts because these are strings constructed at build time, The incorrect macros values are: PHP_OCI8_SHARED_LIB_ADD PHP_OCI8_DIR The macros are defined as empty strings in the pre-existing /usr/include/php/main/build-def.h. Nothing in phpize/configure overrides them. The PHP_OCI8_VERSION value is correct since it is overridden in php_oci8.h (after Steph's PECL versioning project) Potential solution is to change config.m4 and add these lines at the end of the ORACEL_HOME and Instant Client blocks: AC_DEFINE_UNQUOTED(PHP_OCI8_DEF_DIR, "$OCI8_DIR", [ ]) AC_DEFINE_UNQUOTED(PHP_OCI8_DEF_SHARED_LIBADD, "$OCI8_SHARED_LIBADD", [ ]) Then change oci8.c to use the new macros: #ifdef PHP_OCI8_DEF_DIR php_info_print_table_row(2, "Compile-time ORACLE_HOME", PHP_OCI8_DEF_DIR); #endif #ifdef PHP_OCI8_DEF_SHARED_LIBADD php_info_print_table_row(2, "Libraries Used", PHP_OCI8_DEF_SHARED_LIBADD); #endif Reproduce code: --- tar -zxf oci8-1.3.4.tgz cd oci8-1.3.4 phpize && ./configure --with-oci8=shared,$ORACLE_HOME && make install [Add extension=oci8.so to php.ini] php -i |grep ORACLE_HOME Expected result: phpinfo() should show: Compile-time ORACLE_HOME => /home/oracle/app/oracle Actual result: -- phpinfo() shows: Compile-time ORACLE_HOME => -- Edit this bug report at http://bugs.php.net/?id=46623&edit=1
#47607 [NEW]: Add LDAP escaping
From: gdr at go2 dot pl Operating system: Linux PHP version: 5.2.9 PHP Bug Type: Feature/Change Request Bug description: Add LDAP escaping Description: The LDAP module needs a function to escape strings to prevent LDAP injections, like MySQL module has mysql_escape_string() Reproduce code: --- $sr=ldap_search($ds, "", "(sn=$_GET[lastname])"); Expected result: $sr=ldap_search($ds, "", "(sn=".ldap_escape_string($_GET[lastname]).")"); -- Edit bug report at http://bugs.php.net/?id=47607&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=47607&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=47607&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=47607&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=47607&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=47607&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=47607&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=47607&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=47607&r=needscript Try newer version: http://bugs.php.net/fix.php?id=47607&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=47607&r=support Expected behavior: http://bugs.php.net/fix.php?id=47607&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=47607&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=47607&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=47607&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47607&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=47607&r=dst IIS Stability: http://bugs.php.net/fix.php?id=47607&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=47607&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=47607&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=47607&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=47607&r=mysqlcfg
#43917 [Com]: checking whether libxml build works... no
ID: 43917
Comment by: ua9oty at qrz dot ru
Reported By: lnycm at msn dot com
Status: No Feedback
Bug Type: Compile Failure
Operating System: Cent OS 5.0
PHP Version: 5.2.5
New Comment:
I have got a same problem with CentOS 5.2 x64 edition
Problem has been solved after zlib install with command
yum install zlib-devel
and add key --with-libdir=lib64
in configuration line
Previous Comments:
[2008-02-02 01:00:01] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
[2008-01-26 00:56:17] j...@php.net
Not enough information was provided for us to be able
to handle this bug. Please re-read the instructions at
http://bugs.php.net/how-to-report.php
If you can provide more information, feel free to add it
to this bug and change the status back to "Open".
Thank you for your interest in PHP.
[2008-01-23 07:11:41] lnycm at msn dot com
Description:
Configuring extensions
checking whether to enable LIBXML support... yes
checking libxml2 install dir... no
checking for xml2-config path... /usr/bin/xml2-config
checking whether libxml build works... no
configure: error: build test failed. Please check the config.log for
details.
Reproduce code:
---
configure:20055: gcc -o conftest -g -O2 -L/usr/local/lib conftest.c
-lresolv -lm -ldl -lnsl -lxml2 -lz -liconv -lm 1>&5
configure: failed program was:
#line 20044 "configure"
#include "confdefs.h"
char xmlInitParser();
int main() {
xmlInitParser();
return 0;
}
--
Edit this bug report at http://bugs.php.net/?id=43917&edit=1
#47480 [Com]: preg_replace with "/i" is not case insensitive
ID: 47480 Comment by: mmcnickle at gmail dot com Reported By: sehh at ionos dot gr Status: Open Bug Type: PCRE related Operating System: Linux PHP Version: 5.2.8 New Comment: It wouldn't be impossible, no. But to someone without detailed knowledge of Greek it would be. The unicode.org article on regular expressions [1] has this to say: "All of the above deals with a default specification for a regular expression. However, a regular expression engine also may want to support tailored specifications, typically tailored for a particular language or locale. This may be important when the regular expression engine is being used by end-users instead of programmers, such as in a word-processor allowing some level of regular expressions in searching." Earlier in the document it says about how basic regex engines are only required to include the basic unicode uppercase/lowercase matching. Looking though the source code of the PRCE library, it does seem possible to generate locale-specific character tables; this may be an avenue to look into. Perhaps the best thing to do would be to drop a message in the internationalization mailing list (http://marc.info/?l=php-i18n) and see what they have to say. [1] http://unicode.org/reports/tr18/#Tailored_Support Previous Comments: [2009-03-09 16:01:59] sehh at ionos dot gr Indeed thats far from ideal, its impossible from my development point of view to re-write every single accented character with its possible equivalent for the entire string, for every string in the regex. For example, this: /Âáëâßäåò åéóáãùãÞò-åîáãùãÞò/i Would become a monster like this: /Âáëâ[É|ß|º]ä[Å|å|¸]ò åéóáãùã[Ç|Þ|¹]ò-åîáãùã[Ç|Þ|¹]ò/i We would need a regex to create the regex! or at least a text search/replace method in PHP. Are you sure its impossible to add a few exceptions within the PCRE library? [2009-03-09 15:25:51] mmcnickle at gmail dot com Yes, unfortunately trying to include locale and language specific cases is next to impossible for regular expression engine developers. The best that can be done, though far from ideal, is for the user to try to take these changes into account when they are crafting the regex: $target1 = "ÊÉÍÇÔ[Ç|Þ]ÑÁ"; // Greek; $target1 = "Stra[ss|ß]ebahn" // German [2009-03-09 15:00:25] sehh at ionos dot gr I forgot the capital accented characters, so the above should read: "Ç" == "Þ" == "ç" == "¹" "Á" == "Ü" == "á" == "¶" etc.. Remember that in Greek, the accent may be omitted from capital letters or may be included for the first letter only. So that should produce proper case-insensitive results. [2009-03-09 14:54:32] sehh at ionos dot gr The PCRE library is wrong then. "Ç" is correctly defined in Unicode as "ç", but the library should also understand the meaning of "Ç" == "Þ" == "ç". This counts for all Greek accents: "Á" == "Ü" == "á" etc... Otherwise, the parameter "/i" is useless for the Greek language and thats why the current implementation does not work for Greek. Thank you for taking the time to look into this issue, much appreciated. [2009-03-09 14:31:03] mmcnickle at gmail dot com You're absolutely correct, I do not speak Greek. But neither does the PCRE library. It determines the uppercase/lowercase relationship between characters solely using Unicode properties. The lowercase of Ç is defined in Unicode as ç [1], not Þ. Therefore the case-insensitive search will not match. [1]http://www.fileformat.info/info/unicode/char/00c7/index.htm 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/47480 -- Edit this bug report at http://bugs.php.net/?id=47480&edit=1
#47606 [NEW]: Access denied with double quotes
From: hugo at 1key dot nl Operating system: Debian 4.0 PHP version: 5.2.9 PHP Bug Type: MySQL related Bug description: Access denied with double quotes Description: please note the special characters in the password. When you try to connect using this command you get the error even though you can connect using phpmyadmin, commandline mysql etc. When you change the double quotes to single quotes the problem is solved. It might be of interest to those used to set strings in double quotes. It is not really a bug, or at least i can easily work around it, but I was not allowed to submit it as a usernote and got the message i should report a bug.. Reproduce code: --- --- >From manual page: function.mysql-connect --- Expected result: A connection to the database Actual result: -- Access denied for user 'user_name'@'localhost' (using password: YES) -- Edit bug report at http://bugs.php.net/?id=47606&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=47606&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=47606&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=47606&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=47606&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=47606&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=47606&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=47606&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=47606&r=needscript Try newer version: http://bugs.php.net/fix.php?id=47606&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=47606&r=support Expected behavior: http://bugs.php.net/fix.php?id=47606&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=47606&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=47606&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=47606&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47606&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=47606&r=dst IIS Stability: http://bugs.php.net/fix.php?id=47606&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=47606&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=47606&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=47606&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=47606&r=mysqlcfg
#47480 [Opn]: preg_replace with "/i" is not case insensitive
ID: 47480 User updated by: sehh at ionos dot gr Reported By: sehh at ionos dot gr Status: Open Bug Type: PCRE related Operating System: Linux PHP Version: 5.2.8 New Comment: Indeed thats far from ideal, its impossible from my development point of view to re-write every single accented character with its possible equivalent for the entire string, for every string in the regex. For example, this: /Âáëâßäåò åéóáãùãÞò-åîáãùãÞò/i Would become a monster like this: /Âáëâ[É|ß|º]ä[Å|å|¸]ò åéóáãùã[Ç|Þ|¹]ò-åîáãùã[Ç|Þ|¹]ò/i We would need a regex to create the regex! or at least a text search/replace method in PHP. Are you sure its impossible to add a few exceptions within the PCRE library? Previous Comments: [2009-03-09 15:25:51] mmcnickle at gmail dot com Yes, unfortunately trying to include locale and language specific cases is next to impossible for regular expression engine developers. The best that can be done, though far from ideal, is for the user to try to take these changes into account when they are crafting the regex: $target1 = "ÊÉÍÇÔ[Ç|Þ]ÑÁ"; // Greek; $target1 = "Stra[ss|ß]ebahn" // German [2009-03-09 15:00:25] sehh at ionos dot gr I forgot the capital accented characters, so the above should read: "Ç" == "Þ" == "ç" == "¹" "Á" == "Ü" == "á" == "¶" etc.. Remember that in Greek, the accent may be omitted from capital letters or may be included for the first letter only. So that should produce proper case-insensitive results. [2009-03-09 14:54:32] sehh at ionos dot gr The PCRE library is wrong then. "Ç" is correctly defined in Unicode as "ç", but the library should also understand the meaning of "Ç" == "Þ" == "ç". This counts for all Greek accents: "Á" == "Ü" == "á" etc... Otherwise, the parameter "/i" is useless for the Greek language and thats why the current implementation does not work for Greek. Thank you for taking the time to look into this issue, much appreciated. [2009-03-09 14:31:03] mmcnickle at gmail dot com You're absolutely correct, I do not speak Greek. But neither does the PCRE library. It determines the uppercase/lowercase relationship between characters solely using Unicode properties. The lowercase of Ç is defined in Unicode as ç [1], not Þ. Therefore the case-insensitive search will not match. [1]http://www.fileformat.info/info/unicode/char/00c7/index.htm [2009-03-09 12:16:43] sehh at ionos dot gr Obviously you have no idea what you are talking about and obviously you don't speak Greek or know anything about the Greek language. The word "êéíçôÞñá" is capitalized as "ÊÉÍÇÔÇÑÁ". What you are suggesting is like capitalizing the word "engine" as "ENGiNE". Obviously, there is no word "ENGiNE", same way there is no word "ÊÉÍÇÔÞÑÁ" :) 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/47480 -- Edit this bug report at http://bugs.php.net/?id=47480&edit=1
#47480 [Com]: preg_replace with "/i" is not case insensitive
ID: 47480 Comment by: mmcnickle at gmail dot com Reported By: sehh at ionos dot gr Status: Open Bug Type: PCRE related Operating System: Linux PHP Version: 5.2.8 New Comment: Yes, unfortunately trying to include locale and language specific cases is next to impossible for regular expression engine developers. The best that can be done, though far from ideal, is for the user to try to take these changes into account when they are crafting the regex: $target1 = "ÊÉÍÇÔ[Ç|Þ]ÑÁ"; // Greek; $target1 = "Stra[ss|ß]ebahn" // German Previous Comments: [2009-03-09 15:00:25] sehh at ionos dot gr I forgot the capital accented characters, so the above should read: "Ç" == "Þ" == "ç" == "¹" "Á" == "Ü" == "á" == "¶" etc.. Remember that in Greek, the accent may be omitted from capital letters or may be included for the first letter only. So that should produce proper case-insensitive results. [2009-03-09 14:54:32] sehh at ionos dot gr The PCRE library is wrong then. "Ç" is correctly defined in Unicode as "ç", but the library should also understand the meaning of "Ç" == "Þ" == "ç". This counts for all Greek accents: "Á" == "Ü" == "á" etc... Otherwise, the parameter "/i" is useless for the Greek language and thats why the current implementation does not work for Greek. Thank you for taking the time to look into this issue, much appreciated. [2009-03-09 14:31:03] mmcnickle at gmail dot com You're absolutely correct, I do not speak Greek. But neither does the PCRE library. It determines the uppercase/lowercase relationship between characters solely using Unicode properties. The lowercase of Ç is defined in Unicode as ç [1], not Þ. Therefore the case-insensitive search will not match. [1]http://www.fileformat.info/info/unicode/char/00c7/index.htm [2009-03-09 12:16:43] sehh at ionos dot gr Obviously you have no idea what you are talking about and obviously you don't speak Greek or know anything about the Greek language. The word "êéíçôÞñá" is capitalized as "ÊÉÍÇÔÇÑÁ". What you are suggesting is like capitalizing the word "engine" as "ENGiNE". Obviously, there is no word "ENGiNE", same way there is no word "ÊÉÍÇÔÞÑÁ" :) [2009-03-09 11:59:53] mmcnickle at gmail dot com The test case is wrong and the bug should be closed. The upper case search target is misspelled. $target1 = "ÊÉÍÇÔÇÑÁ"; $target2 = "êéíçôÞñá"; should read $target1 = "ÊÉÍÇÔÞÑÁ"; $target2 = "êéíçôÞñá"; (note the replacement of the second Ç with a capital Thorn (U+00DE). With this change I get the expected result: Actual Result - Searching for: ÊÉÍÇÔÞÑÁ Result string: Ôï êõñßùò ôìÞìá ôïõ itworks, áõôü ðïõ ðåñéëáìâÜíåé ôïõò êõëßíäñïõò Found and replaced: 1 Searching for: êéíçôþñá Result string: Ôï êõñßùò ôìÞìá ôïõ itworks, áõôü ðïõ ðåñéëáìâÜíåé ôïõò êõëßíäñïõò Found and replaced: 1 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/47480 -- Edit this bug report at http://bugs.php.net/?id=47480&edit=1
#47480 [Opn]: preg_replace with "/i" is not case insensitive
ID: 47480 User updated by: sehh at ionos dot gr Reported By: sehh at ionos dot gr Status: Open Bug Type: PCRE related Operating System: Linux PHP Version: 5.2.8 New Comment: I forgot the capital accented characters, so the above should read: "Ç" == "Þ" == "ç" == "¹" "Á" == "Ü" == "á" == "¶" etc.. Remember that in Greek, the accent may be omitted from capital letters or may be included for the first letter only. So that should produce proper case-insensitive results. Previous Comments: [2009-03-09 14:54:32] sehh at ionos dot gr The PCRE library is wrong then. "Ç" is correctly defined in Unicode as "ç", but the library should also understand the meaning of "Ç" == "Þ" == "ç". This counts for all Greek accents: "Á" == "Ü" == "á" etc... Otherwise, the parameter "/i" is useless for the Greek language and thats why the current implementation does not work for Greek. Thank you for taking the time to look into this issue, much appreciated. [2009-03-09 14:31:03] mmcnickle at gmail dot com You're absolutely correct, I do not speak Greek. But neither does the PCRE library. It determines the uppercase/lowercase relationship between characters solely using Unicode properties. The lowercase of Ç is defined in Unicode as ç [1], not Þ. Therefore the case-insensitive search will not match. [1]http://www.fileformat.info/info/unicode/char/00c7/index.htm [2009-03-09 12:16:43] sehh at ionos dot gr Obviously you have no idea what you are talking about and obviously you don't speak Greek or know anything about the Greek language. The word "êéíçôÞñá" is capitalized as "ÊÉÍÇÔÇÑÁ". What you are suggesting is like capitalizing the word "engine" as "ENGiNE". Obviously, there is no word "ENGiNE", same way there is no word "ÊÉÍÇÔÞÑÁ" :) [2009-03-09 11:59:53] mmcnickle at gmail dot com The test case is wrong and the bug should be closed. The upper case search target is misspelled. $target1 = "ÊÉÍÇÔÇÑÁ"; $target2 = "êéíçôÞñá"; should read $target1 = "ÊÉÍÇÔÞÑÁ"; $target2 = "êéíçôÞñá"; (note the replacement of the second Ç with a capital Thorn (U+00DE). With this change I get the expected result: Actual Result - Searching for: ÊÉÍÇÔÞÑÁ Result string: Ôï êõñßùò ôìÞìá ôïõ itworks, áõôü ðïõ ðåñéëáìâÜíåé ôïõò êõëßíäñïõò Found and replaced: 1 Searching for: êéíçôþñá Result string: Ôï êõñßùò ôìÞìá ôïõ itworks, áõôü ðïõ ðåñéëáìâÜíåé ôïõò êõëßíäñïõò Found and replaced: 1 [2009-02-23 13:32:39] sehh at ionos dot gr Description: preg_replace with the "/i" (case insensitive search) does not do a case insensitive search for UTF-8 Greek characters, while it works fine for English characters. Reproduce code: --- Expected result: I expect the Found and Replaced to be both "1" since the expression is not case sensitive. Actual result: -- $ php -f test.php Searching for: ÊÉÍÇÔÇÑÁ Result string: Ôï êõñßùò ôìÞìá ôïõ êéíçôÞñá, áõôü ðïõ ðåñéëáìâÜíåé ôïõò êõëßíäñïõò Found and replaced: 0 Searching for: êéíçôÞñá Result string: Ôï êõñßùò ôìÞìá ôïõ itworks, áõôü ðïõ ðåñéëáìâÜíåé ôïõò êõëßíäñïõò Found and replaced: 1 -- Edit this bug report at http://bugs.php.net/?id=47480&edit=1
#47480 [Opn]: preg_replace with "/i" is not case insensitive
ID: 47480 User updated by: sehh at ionos dot gr Reported By: sehh at ionos dot gr Status: Open Bug Type: PCRE related Operating System: Linux PHP Version: 5.2.8 New Comment: The PCRE library is wrong then. "Ç" is correctly defined in Unicode as "ç", but the library should also understand the meaning of "Ç" == "Þ" == "ç". This counts for all Greek accents: "Á" == "Ü" == "á" etc... Otherwise, the parameter "/i" is useless for the Greek language and thats why the current implementation does not work for Greek. Thank you for taking the time to look into this issue, much appreciated. Previous Comments: [2009-03-09 14:31:03] mmcnickle at gmail dot com You're absolutely correct, I do not speak Greek. But neither does the PCRE library. It determines the uppercase/lowercase relationship between characters solely using Unicode properties. The lowercase of Ç is defined in Unicode as ç [1], not Þ. Therefore the case-insensitive search will not match. [1]http://www.fileformat.info/info/unicode/char/00c7/index.htm [2009-03-09 12:16:43] sehh at ionos dot gr Obviously you have no idea what you are talking about and obviously you don't speak Greek or know anything about the Greek language. The word "êéíçôÞñá" is capitalized as "ÊÉÍÇÔÇÑÁ". What you are suggesting is like capitalizing the word "engine" as "ENGiNE". Obviously, there is no word "ENGiNE", same way there is no word "ÊÉÍÇÔÞÑÁ" :) [2009-03-09 11:59:53] mmcnickle at gmail dot com The test case is wrong and the bug should be closed. The upper case search target is misspelled. $target1 = "ÊÉÍÇÔÇÑÁ"; $target2 = "êéíçôÞñá"; should read $target1 = "ÊÉÍÇÔÞÑÁ"; $target2 = "êéíçôÞñá"; (note the replacement of the second Ç with a capital Thorn (U+00DE). With this change I get the expected result: Actual Result - Searching for: ÊÉÍÇÔÞÑÁ Result string: Ôï êõñßùò ôìÞìá ôïõ itworks, áõôü ðïõ ðåñéëáìâÜíåé ôïõò êõëßíäñïõò Found and replaced: 1 Searching for: êéíçôþñá Result string: Ôï êõñßùò ôìÞìá ôïõ itworks, áõôü ðïõ ðåñéëáìâÜíåé ôïõò êõëßíäñïõò Found and replaced: 1 [2009-02-23 13:32:39] sehh at ionos dot gr Description: preg_replace with the "/i" (case insensitive search) does not do a case insensitive search for UTF-8 Greek characters, while it works fine for English characters. Reproduce code: --- Expected result: I expect the Found and Replaced to be both "1" since the expression is not case sensitive. Actual result: -- $ php -f test.php Searching for: ÊÉÍÇÔÇÑÁ Result string: Ôï êõñßùò ôìÞìá ôïõ êéíçôÞñá, áõôü ðïõ ðåñéëáìâÜíåé ôïõò êõëßíäñïõò Found and replaced: 0 Searching for: êéíçôÞñá Result string: Ôï êõñßùò ôìÞìá ôïõ itworks, áõôü ðïõ ðåñéëáìâÜíåé ôïõò êõëßíäñïõò Found and replaced: 1 -- Edit this bug report at http://bugs.php.net/?id=47480&edit=1
#47605 [NEW]: PHP CGI fails to ever output HTTP 200 header
From: c dot c dot dean at durham dot ac dot uk
Operating system: Linux
PHP version: 5.2.9
PHP Bug Type: HTTP related
Bug description: PHP CGI fails to ever output HTTP 200 header
Description:
If you invoke header("HTTP/1.0 200 OK"); from PHP in CGI mode, the header
is never output, because it's suppressed at line 379 in
sapi/cgi/cgi_main.c. If you use any value other than 200, it is output
correctly.
This means for instance, that if you use PHP in CGI mode as an Apache
errordocument handler, you cannot send back a non-error 200 OK to the
user.
The following trivial change fixes this, but you might prefer a more
elegant solution.
--- php-5.2.9/sapi/cgi/cgi_main.c.orig 2009-01-19 18:17:59.0
+
+++ php-5.2.9/sapi/cgi/cgi_main.c 2009-03-09 14:04:11.0
+
@@ -376,7 +376,7 @@
return SAPI_HEADER_SENT_SUCCESSFULLY;
}
- if (CGIG(nph) || SG(sapi_headers).http_response_code != 200)
+ if (CGIG(nph) || SG(sapi_headers).http_response_code != 666)
{
int len;
zend_bool has_status = 0;
@@ -914,7 +914,7 @@
SG(request_info).request_uri = NULL;
SG(request_info).content_type = NULL;
SG(request_info).content_length = 0;
- SG(sapi_headers).http_response_code = 200;
+ SG(sapi_headers).http_response_code = 666;
/* script_path_translated being set is a good indication that
we are running in a cgi environment, since it is always
Reproduce code:
---
Use this as the Apache errordocument handler:
Expected result:
HTTP/1.0 200 OK in the header and "This is OK" in the body
Actual result:
--
HTTP/1.0 404 Not Found
--
Edit bug report at http://bugs.php.net/?id=47605&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=47605&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=47605&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=47605&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=47605&r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=47605&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=47605&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=47605&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=47605&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=47605&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=47605&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=47605&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=47605&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=47605&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=47605&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47605&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=47605&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=47605&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=47605&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=47605&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=47605&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=47605&r=mysqlcfg
#47480 [Com]: preg_replace with "/i" is not case insensitive
ID: 47480 Comment by: mmcnickle at gmail dot com Reported By: sehh at ionos dot gr Status: Open Bug Type: PCRE related Operating System: Linux PHP Version: 5.2.8 New Comment: You're absolutely correct, I do not speak Greek. But neither does the PCRE library. It determines the uppercase/lowercase relationship between characters solely using Unicode properties. The lowercase of Ç is defined in Unicode as ç [1], not Þ. Therefore the case-insensitive search will not match. [1]http://www.fileformat.info/info/unicode/char/00c7/index.htm Previous Comments: [2009-03-09 12:16:43] sehh at ionos dot gr Obviously you have no idea what you are talking about and obviously you don't speak Greek or know anything about the Greek language. The word "êéíçôÞñá" is capitalized as "ÊÉÍÇÔÇÑÁ". What you are suggesting is like capitalizing the word "engine" as "ENGiNE". Obviously, there is no word "ENGiNE", same way there is no word "ÊÉÍÇÔÞÑÁ" :) [2009-03-09 11:59:53] mmcnickle at gmail dot com The test case is wrong and the bug should be closed. The upper case search target is misspelled. $target1 = "ÊÉÍÇÔÇÑÁ"; $target2 = "êéíçôÞñá"; should read $target1 = "ÊÉÍÇÔÞÑÁ"; $target2 = "êéíçôÞñá"; (note the replacement of the second Ç with a capital Thorn (U+00DE). With this change I get the expected result: Actual Result - Searching for: ÊÉÍÇÔÞÑÁ Result string: Ôï êõñßùò ôìÞìá ôïõ itworks, áõôü ðïõ ðåñéëáìâÜíåé ôïõò êõëßíäñïõò Found and replaced: 1 Searching for: êéíçôþñá Result string: Ôï êõñßùò ôìÞìá ôïõ itworks, áõôü ðïõ ðåñéëáìâÜíåé ôïõò êõëßíäñïõò Found and replaced: 1 [2009-02-23 13:32:39] sehh at ionos dot gr Description: preg_replace with the "/i" (case insensitive search) does not do a case insensitive search for UTF-8 Greek characters, while it works fine for English characters. Reproduce code: --- Expected result: I expect the Found and Replaced to be both "1" since the expression is not case sensitive. Actual result: -- $ php -f test.php Searching for: ÊÉÍÇÔÇÑÁ Result string: Ôï êõñßùò ôìÞìá ôïõ êéíçôÞñá, áõôü ðïõ ðåñéëáìâÜíåé ôïõò êõëßíäñïõò Found and replaced: 0 Searching for: êéíçôÞñá Result string: Ôï êõñßùò ôìÞìá ôïõ itworks, áõôü ðïõ ðåñéëáìâÜíåé ôïõò êõëßíäñïõò Found and replaced: 1 -- Edit this bug report at http://bugs.php.net/?id=47480&edit=1
#47604 [Opn->Fbk]: Sgmentation Fault on big MySQL Funktion
ID: 47604 Updated by: ka...@php.net Reported By: valkum at globalgameport dot com -Status: Open +Status: Feedback Bug Type: MySQL related Operating System: Debian Etch 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-03-09 12:53:45] valkum at globalgameport dot com Description: When i run the php script with CLI i get a Segmentation Fault. The code reads out a table and convert it from iso-8859 to utf-8 But on one table i get a Segmentation Fault. The Database ist a Joomla 1.0.x Database with more then 100 records. i test the Script on Debian Lenny but the Segmentation Fault is still there. Reproduce code: --- A little bit changed version of http://blog.dopefreshtight.de/artikel/von-iso-8859-1-zu-utf-8-in-php-und-mysql#convert Expected result: A converted MySql Database. Actual result: -- Segmentation Fault -- Edit this bug report at http://bugs.php.net/?id=47604&edit=1
#46587 [Com]: mt_/rand produce out of range numbers when min = 0 and max > get_randmax
ID: 46587
Comment by: mmcnickle at gmail dot com
Reported By: atomo64 at gmail dot com
Status: Assigned
Bug Type: Math related
Operating System: Debian sid
PHP Version: 5.2.6
Assigned To: pajoye
New Comment:
The problem is that there is an integer overflow on UL:
mt_getrandmax()) {
$max = mt_getrandmax();
}
$r = mt_rand(0, $max); // $r is now a number between 0 and
mt_getrandmax()
Previous Comments:
[2008-11-17 02:50:20] atomo64 at gmail dot com
Description:
Whenever min is set to 0 and max is set to anything greater than
getrandmax (or the mt_ version) the returned PRN is always (despite
the upper limit check in the example code) a number minor than 0.
Reproduce code:
---
define("UL", mt_getrandmax()+1000);
$r=mt_rand(0, UL);
if ($r < 0 || $r > UL)
echo "Random value out of range\n";
Expected result:
No output
Actual result:
--
Random value out of range
--
Edit this bug report at http://bugs.php.net/?id=46587&edit=1
#18833 [Com]: exec() : After throusands calls, causes "Unable to fork" error
ID: 18833
Comment by: steveg at bscopes dot com
Reported By: antoine dot bajolet at tdf dot fr
Status: No Feedback
Bug Type: *General Issues
Operating System: GNU/Linux 2.4.9 RH 7.1
PHP Version: 4.2.1
New Comment:
1. did you ever figure out what caused this problem?
2. do you know which apache/php parameters to adjust ?
Previous Comments:
[2009-02-05 11:37:09] scherbakov_koksa at mail dot ru
I'm having the same issue with PHP 5.2.8, Apache 2.2.11, GNU/Linux
(2.6.20-1.2320.fc5). A php script periodically (per user request)
executes the following command:
xsltproc
In some time the script starts throwing the "unable to fork" warning.
It is fixed by Apache restart.
[2008-06-01 16:48:39] pahan at hubbitus dot spb dot su
Have same trouble in PHP snapshot 200805080630:
PHP Warning: exec(): Unable to fork [echo -ne '2008-06-01 05:15:27:
Login: Unable to login (User: hel...@simpla
y.ru)! reason:not connected! (CMD:LOGIN)
sleep 50 seconds
' >> /home/pasha/temp/php-IMAP/logs/log_ERR 2>&1] in
/var/www/_SHARED_/Debug/HuLOG.php on line 115
PHP Stack trace:
PHP 1. {main}() /home/pasha/temp/php-IMAP/IMAP_answer.php:0
PHP 2. IMAP_mailbox_change_answer()
/home/pasha/temp/php-IMAP/IMAP_answer.php:201
PHP 3. HuLOG->toLog() /home/pasha/temp/php-IMAP/IMAP_answer.php:67
PHP 4. HuLOG->writeLogs() /var/www/_SHARED_/Debug/HuLOG.php:158
PHP 5. HuLOG->log_to_file() /var/www/_SHARED_/Debug/HuLOG.php:162
PHP 6. exec() /var/www/_SHARED_/Debug/HuLOG.php:115
Warning: exec(): Unable to fork [echo -ne '2008-06-01 05:15:27: Login:
Unable to login (User: hel...@simplay.ru)
! reason:not connected! (CMD:LOGIN)
sleep 50 seconds
' >> /home/pasha/temp/php-IMAP/logs/log_ERR 2>&1] in
/var/www/_SHARED_/Debug/HuLOG.php on line 115
Call Stack:
0.0019 375364 1. {main}()
/home/pasha/temp/php-IMAP/IMAP_answer.php:0
184145.8861 16442044 2. IMAP_mailbox_change_answer()
/home/pasha/temp/php-IMAP/IMAP_answer.php:201
184145.8903 16451552 3. HuLOG->toLog()
/home/pasha/temp/php-IMAP/IMAP_answer.php:67
184145.8908 16451648 4. HuLOG->writeLogs()
/var/www/_SHARED_/Debug/HuLOG.php:158
184145.8908 16451648 5. HuLOG->log_to_file()
/var/www/_SHARED_/Debug/HuLOG.php:162
184145.8917 16451824 6. exec()
/var/www/_SHARED_/Debug/HuLOG.php:115
[2007-12-05 05:22:57] jinglerobs at yahoo dot com
Im using PHP 5.2.4 (cli), Apache & Mysql combination on a Slackware
box.
While running a script that processes large XML files and writes the
log to a log file, I get
Warning: exec(): Unable to fork
Initially the script runs fine for some 3 or 4 hours after which it
gives out the warnings. The script has a huge amount of data to process.
I also tried to use the nohup command but was of no use.
A screenshot of the problem is given below:
DEBUG:INSERT into package
(id,vendor,title,version,ver_major,ver_minor,ver_sub,ver_ext,type)
values ('13001','Microsoft','Windows XP
Home','0.0.0SP1','0','0','0','SP1','Software')
Warning: exec(): Unable to fork [/usr/bin/bash -c "exec nohup setsid
echo \"DEBUG: INSERT into package
(id,vendor,title,version,ver_major,ver_minor,ver_sub,ver_ext,type)
values ('13001','Microsoft','Windows XP
Home','0.0.0SP1','0','0','0','SP1','Software') \">>feed2vendorDB.log
2>&1 &"] in
/usr/local/apache2/htdocs/xml_feed/sircc_agnostic/feed2vendorDB/feed2vendorDB.php
on line 1454
DEBUG:INSERT into package
(id,vendor,title,version,ver_major,ver_minor,ver_sub,ver_ext,type)
values ('13002','Microsoft','Windows XP
Professional','0.0.0SP1','0','0','0','SP1','Software')
Warning: exec(): Unable to fork [/usr/bin/bash -c "exec nohup setsid
echo \"DEBUG: INSERT into package
(id,vendor,title,version,ver_major,ver_minor,ver_sub,ver_ext,type)
values ('13002','Microsoft','Windows XP
Professional','0.0.0SP1','0','0','0','SP1','Software')
\">>feed2vendorDB.log 2>&1 &"] in
/usr/local/apache2/htdocs/xml_feed/sircc_agnostic/feed2vendorDB/feed2vendorDB.php
on line 1454
DEBUG:INSERT into package
(id,vendor,title,version,ver_major,ver_minor,ver_sub,ver_ext,type)
values ('13134','KaZaA','KaZaA Media
Desktop','2.0.0','2','0','0','','Software')
Warning: exec(): Unable to fork [/usr/bin/bash -c "exec nohup setsid
echo \"DEBUG: INSERT into package
(id,vendor,title,version,ver_major,ver_minor,ver_sub,ver_ext,type)
values ('13134','KaZaA','KaZaA Media
Desktop','2.0.0','2','0','0','','Software') \">>feed2vendorDB.log 2>&1
&"] in
/usr/local/apache2/htdocs/xml_feed/sircc_agnostic/feed2vendorDB/feed2vendorDB.php
on line 1454
DEBUG:INSERT into package
(id,vendor,title,version,ver_major,ver_minor,ver_sub,ver_ext,type)
values ('11051','KaZaA','KaZaA Media
Desktop','1.6.1','1','6','1','','Software')
Warning: exec(): Unable to fork [/usr/bin/bash -c "exec
#47604 [NEW]: Sgmentation Fault on big MySQL Funktion
From: valkum at globalgameport dot com Operating system: Debian Etch PHP version: 5.2.9 PHP Bug Type: MySQL related Bug description: Sgmentation Fault on big MySQL Funktion Description: When i run the php script with CLI i get a Segmentation Fault. The code reads out a table and convert it from iso-8859 to utf-8 But on one table i get a Segmentation Fault. The Database ist a Joomla 1.0.x Database with more then 100 records. i test the Script on Debian Lenny but the Segmentation Fault is still there. Reproduce code: --- A little bit changed version of http://blog.dopefreshtight.de/artikel/von-iso-8859-1-zu-utf-8-in-php-und-mysql#convert Expected result: A converted MySql Database. Actual result: -- Segmentation Fault -- Edit bug report at http://bugs.php.net/?id=47604&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=47604&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=47604&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=47604&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=47604&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=47604&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=47604&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=47604&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=47604&r=needscript Try newer version: http://bugs.php.net/fix.php?id=47604&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=47604&r=support Expected behavior: http://bugs.php.net/fix.php?id=47604&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=47604&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=47604&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=47604&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47604&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=47604&r=dst IIS Stability: http://bugs.php.net/fix.php?id=47604&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=47604&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=47604&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=47604&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=47604&r=mysqlcfg
#47480 [Opn]: preg_replace with "/i" is not case insensitive
ID: 47480 User updated by: sehh at ionos dot gr Reported By: sehh at ionos dot gr Status: Open Bug Type: PCRE related Operating System: Linux PHP Version: 5.2.8 New Comment: Obviously you have no idea what you are talking about and obviously you don't speak Greek or know anything about the Greek language. The word "êéíçôÞñá" is capitalized as "ÊÉÍÇÔÇÑÁ". What you are suggesting is like capitalizing the word "engine" as "ENGiNE". Obviously, there is no word "ENGiNE", same way there is no word "ÊÉÍÇÔÞÑÁ" :) Previous Comments: [2009-03-09 11:59:53] mmcnickle at gmail dot com The test case is wrong and the bug should be closed. The upper case search target is misspelled. $target1 = "ÊÉÍÇÔÇÑÁ"; $target2 = "êéíçôÞñá"; should read $target1 = "ÊÉÍÇÔÞÑÁ"; $target2 = "êéíçôÞñá"; (note the replacement of the second Ç with a capital Thorn (U+00DE). With this change I get the expected result: Actual Result - Searching for: ÊÉÍÇÔÞÑÁ Result string: Ôï êõñßùò ôìÞìá ôïõ itworks, áõôü ðïõ ðåñéëáìâÜíåé ôïõò êõëßíäñïõò Found and replaced: 1 Searching for: êéíçôþñá Result string: Ôï êõñßùò ôìÞìá ôïõ itworks, áõôü ðïõ ðåñéëáìâÜíåé ôïõò êõëßíäñïõò Found and replaced: 1 [2009-02-23 13:32:39] sehh at ionos dot gr Description: preg_replace with the "/i" (case insensitive search) does not do a case insensitive search for UTF-8 Greek characters, while it works fine for English characters. Reproduce code: --- Expected result: I expect the Found and Replaced to be both "1" since the expression is not case sensitive. Actual result: -- $ php -f test.php Searching for: ÊÉÍÇÔÇÑÁ Result string: Ôï êõñßùò ôìÞìá ôïõ êéíçôÞñá, áõôü ðïõ ðåñéëáìâÜíåé ôïõò êõëßíäñïõò Found and replaced: 0 Searching for: êéíçôÞñá Result string: Ôï êõñßùò ôìÞìá ôïõ itworks, áõôü ðïõ ðåñéëáìâÜíåé ôïõò êõëßíäñïõò Found and replaced: 1 -- Edit this bug report at http://bugs.php.net/?id=47480&edit=1
#47480 [Com]: preg_replace with "/i" is not case insensitive
ID: 47480 Comment by: mmcnickle at gmail dot com Reported By: sehh at ionos dot gr Status: Open Bug Type: PCRE related Operating System: Linux PHP Version: 5.2.8 New Comment: The test case is wrong and the bug should be closed. The upper case search target is misspelled. $target1 = "ÊÉÍÇÔÇÑÁ"; $target2 = "êéíçôÞñá"; should read $target1 = "ÊÉÍÇÔÞÑÁ"; $target2 = "êéíçôÞñá"; (note the replacement of the second Ç with a capital Thorn (U+00DE). With this change I get the expected result: Actual Result - Searching for: ÊÉÍÇÔÞÑÁ Result string: Ôï êõñßùò ôìÞìá ôïõ itworks, áõôü ðïõ ðåñéëáìâÜíåé ôïõò êõëßíäñïõò Found and replaced: 1 Searching for: êéíçôþñá Result string: Ôï êõñßùò ôìÞìá ôïõ itworks, áõôü ðïõ ðåñéëáìâÜíåé ôïõò êõëßíäñïõò Found and replaced: 1 Previous Comments: [2009-02-23 13:32:39] sehh at ionos dot gr Description: preg_replace with the "/i" (case insensitive search) does not do a case insensitive search for UTF-8 Greek characters, while it works fine for English characters. Reproduce code: --- Expected result: I expect the Found and Replaced to be both "1" since the expression is not case sensitive. Actual result: -- $ php -f test.php Searching for: ÊÉÍÇÔÇÑÁ Result string: Ôï êõñßùò ôìÞìá ôïõ êéíçôÞñá, áõôü ðïõ ðåñéëáìâÜíåé ôïõò êõëßíäñïõò Found and replaced: 0 Searching for: êéíçôÞñá Result string: Ôï êõñßùò ôìÞìá ôïõ itworks, áõôü ðïõ ðåñéëáìâÜíåé ôïõò êõëßíäñïõò Found and replaced: 1 -- Edit this bug report at http://bugs.php.net/?id=47480&edit=1
#47580 [Csd]: MSSQL: "Changed database context to" when connecting
ID: 47580
User updated by: maxcamo at gmail dot com
Reported By: maxcamo at gmail dot com
Status: Closed
Bug Type: MSSQL related
Operating System: Win2003
PHP Version: 5.2CVS-2009-03-05 (snap)
New Comment:
ok but i can't connect to the db,
chaging the script like this
if ($connDb)
mssql_select_db($db, $connDb);
else
$lastmsg=mssql_get_last_message()
and...
fputs($fp, gmdate("M d Y H:i:s") . ":: Try:$tries ::
".$ServerName."::
".$lastmsg." :: ". $pageName . "\r\n");
i dont' get any mssql errors, but i get the same problem
I see this error randomly, or on heavy load, i think
Previous Comments:
[2009-03-08 14:30:50] ka...@php.net
This is an informal notice from dblib, Microsoft's TechNet have
information about this here:
http://technet.microsoft.com/en-us/library/aa275768(SQL.80).aspx
[2009-03-05 21:27:58] maxcamo at gmail dot com
Description:
Hi,
with MSSQL 2005,Apache 2.2.11 and PHP 5.2.6 i get this error when i
try to connect to the db
Changed database context to
The error raise up when I try to connect to the DB.
connections timeout are high
mssql.connect_timeout = 300
mssql.timeout = 300
It happen randomly, but more frequently when the site traffic si very
high
Reproduce code:
---
$Maxtries=60;
$delayMin=5;
$delayMax=10;
$delay=rand($delayMin,$delayMax);
$log_filename="conn_failed.log";
$tries=1;
$connDb = @mssql_connect($host, $user, $pwd));
if ($connDb)
mssql_select_db($db, $connDb);
while(!$connDb){
if ($tries>=$Maxtries){
//echo "Database failed to respond.";
$fp = fopen($log_filename,"a+");
fputs($fp, gmdate("M d Y H:i:s") . ": Errore Connessione \r\n");
fclose($fp);
exit;
}
usleep($delay*$tries);
$connDb = @mssql_connect($host, $user, $pwd));
if ($connDb)
mssql_select_db($db, $connDb);
$tries++;
}
if ($tries>1){
$fp = fopen($log_filename,"a+");
fputs($fp, gmdate("M d Y H:i:s") . ":: Try:$tries ::
".$ServerName.":: ".mssql_get_last_message()." :: ". $pageName .
"\r\n");
fclose($fp);
}
Expected result:
Db Connection
Actual result:
--
Mar 05 2009 21:08:19:: Try:2 :: B-C2N1:: Il contesto di database è
stato sostituito con 'dbName'. :: /index.html
Mar 05 2009 21:08:20:: Try:8 :: B-C2N1:: Il contesto di database è
stato sostituito con 'dbName'. :: /page2.html
Mar 05 2009 21:09:26:: Try:6 :: B-C2N1:: Il contesto di database è
stato sostituito con 'dbName'. :: /page3.html
--
Edit this bug report at http://bugs.php.net/?id=47580&edit=1
